最近想对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” 这个就很实用了 和可以 同步到不同名称数据库上 配合以上指定同步不同的表
