最近想对Atlas进行一次的大的改造, 其中涉及了一点主从复制的东西,之前Atlas通过定时建立连接方式来检测主从db的存活,如果不能建立成功,则会摘除该节点。这种方式比较简单。其实可以考虑用更精细的控制, 心跳机制通过过检测show slave status中seconds_Behind_Master、 Slave_IO_Running、Slave_SQL_Runing三个字段来确定当前主从同步的状态以及Seconds_Behind_Master主从复制延迟, 当Seconds_Behind_Master大于所设置的阈值时,就把该节点摘除点(其实这一块和Atlas本身关系不大,但是可以把其移入到Atlas中)
Mysql复制是通过将mysql的某一台主机的数据复制到其他主机(简称slaves)上,并且在slaves上重新执行一遍来实现。主服务器每次数据操作都会将更新记录到二进制日志文件,并维护文件的一个索引跟踪日志循环,slaves服务器通过获取主服务器的二进制日志来更新同步数据。当一个从服务器连接主服务器时,它通知主服务器从服务器的日志中读取的最后一次成功更新的为止。注意:当进行主从复制时,所有对表的更新必须在主服务器上进行,否则会造成冲突
1.1 mysql支持的复制类型
a. 基于语句的复制:在主服务器上执行SQL语句,在从服务器上执行同样的SQL语句(默认采用的),如果没法精确复制,就会自动选择基于行的复制
b. 基于行的复制:把改变的内容复制过去,而不是把命令在从服务器执行一遍,从mysql5.0开始支持
c. 混合类型,默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,采用基于行的复制
1.2 复制如何工作
a. master服务器将数据更新记录到二进制日志文件中(主服务器上必须开启log-bin)
b. slave将master的二进制日志拷贝到它的中继日志(relay log)
c.slave通过SQL线程从relay log中读取二进制日志,重新执行一遍,以改变自己的数据,整个过程如下所示
a. master服务器上开启二进制日志,每个事务更新数据完成之前,master都会把数据变化记录到二进制日志文件中(串行写入)
b. slave上配置change master to,将master的binary日志拷贝到它自己的中继日志(I/O线程)
c. SQL线程从中继日志中读取事件,并重放其中的事件更新slave的数据,使得和master的数据一样
MySQL主从复制几个重要的启动选项
log-slave-updates
log-slave-updates这个参数用来配置从服务器的更新是否写入二进制日志,这个选项默认是不打开的,但是,如果这个从服务器B是服务器A的从服务器,同时还作为服务器C的主服务器,那么就需要开发这个选项,这样它的从服务器C才能获得它的二进制日志进行同步操作
master-connect-retry
master-connect-retry这个参数是用来设置在和主服务器连接丢失的时候,重试的时间间隔,默认是60秒
read-only
read-only是用来限制普通用户对从数据库的更新操作,以确保从数据库的安全性,不过如果是超级用户依然可以对从数据库进行更新操作
slave-skip-errors
在复制过程中,由于各种的原因,从服务器可能会遇到执行BINLOG中的SQL出错的情况,在默认情况下,服务器会停止复制进程,不再进行同步,等到用户自行来处理。
Slave-skip-errors的作用就是用来定义复制过程中从服务器可以自动跳过的错误号,当复制过程中遇到定义的错误号,就可以自动跳过,直接执行后面的SQL语句。
–slave-skip-errors=[err1,err2,…….|ALL]
但必须注意的是,启动这个参数,如果处理不当,很可能造成主从数据库的数据不同步,在应用中需要根据实际情况,如果对数据完整性要求不是很严格,那么这个选项确实可以减轻维护的成本
replicate-ignore-db = mysql,test,information_schema //忽略同步的库replicate-wild-do-table = demo.% //指定同步的表
replicate-rewrite-db=”olddb->newdb” 这个就很实用了 和可以 同步到不同名称数据库上 配合以上指定同步不同的表
网友评论