【主从复制】

主从复制（replication）的工作原理

复制（replication）是MySQL数据库提供的一种高可用高性能的解决方案，一般用来建立大型的应用。总体来说，replication的工作原理分为以下3个步骤：1）主服务器（master）把数据更改记录到二进制日志（binlog）中。2）从服务器（slave）把主服务器的二进制日志复制到自己的中继日志（relaylog）中。3）从服务器重做中继日志中的日志，把更改应用到自己的数据库上，以达到数据的最终一致性。复制的工作原理并不复杂，其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上实时在进行中。这里特别需要注意的是，复制不是完全实时地进行同步，而是异步实时。这中间存在主从服务器之间的执行延时，如果主服务器的压力很大，则可能导致主从服务器延时较大。

主从复制bin log 日志有几种记录方式，说说各自的优缺点

Replication之所以能够工作，主要还是归结于binlog（binary log），所以在 Replication 模式下必须开启binlog功能；slave从masters 上增量获取 binlog 信息，并在本地应用日志中的变更操作（即 “重放”）。变更操作将根据选定的格式类型写入binlog文件，目前支持三种format：statement-based Replication（SBR） ：master将SQL statements语句写入binlog，slave 也将statements 复制到本地执行；简单而言，就是在 master 上执行的 SQL 变更语句，也同样在 slaves 上执行。SBR 模式是 MySQL 最早支持的类型，也是Replication默认类型。row-based Replication（RBR）： master将每行数据的变更信息写入binlog，每条 binlog 信息表示一行（row）数据的变更内容，对于 slaves 而言将会复制 binlog 信息，然后单条或者批量执行变更操作；mix-format Replication：混合模式，在这种模式下，master将根据根据存储引擎、变更操作类型等，从SBR、RBR中来选择更合适的日志格式，默认为 SBR；具体选择那种格式，这取决于变更操作发生的存储引擎、statement 的类型以及特征，优先选择“数据一致性” 最好的方式（RBR），然后才兼顾性能，比如 statement 中含有 “不确定性” 方法或者批量变更，那么将选择RBR方式，其他的将选择 SBR 以减少binlog 的大小。我们建议使用mix方式。SBR 和 RBR 都有各自的优缺点，对于大部分用而言，mix 方式在兼顾数据完整性和性能方面是最佳的选择。

SBR的优点：

• 因为 binlog 中只写入了变更操作的statements，所以日志量将会很小；
• 当使用 SQL 语句批量更新、删除数据时，只需要在 binlog 中记录 statement 即可，可以大大减少log文件对磁盘的使用
• 当然这也意味着 slave 复制信息量也更少，以及通过binlog恢复数据更加快速；

SBR的缺点 ：有些变更操作使用 SBR 方式会带来数据不一致的问题，一些结果具有不确定性的操作使用SBR将会引入数据不一致的问题。

• statement 中如果使用了 UDF(User Defination Fuction)，UDF 的计算结果可能依赖于SQL 执行的时机和系统变量，这可能在 slave 上执行的结果与 master 不同，此外如果使用了trigger，也会带来同样的问题；
• statement 中如果使用了如下函数的（举例）：UUID()，SYSDATE()，RAND() 等，不过NOW() 函数可以正确的被Replication（但在 UDF 或者触发器中则不行）；这些函数的特点就是它们的值依赖于本地系统，RAND() 本身就是随机所以值是不确定的。如果 statement 中使用了上述函数，那么将会在日志中输出warning信息；
• 对于 “INSERT … SELECT” 语句，SBR 将比 RBR 需要更多的行锁。（主要是为了保障数据一致性，需要同时锁定受影响的所有的行，而RBR则不必要）；
• 对于 InnoDB，使用 “AUTO_INCREMENT” 的 insert 语句，将会阻塞其他 “非冲突” 的INSERT。（因为AUTO_INCREMENT，为了避免并发导致的数据一致性问题，只能串行，但 RBR 则不需要）；
• 对于复杂的SQL语句，在 slaves 上仍然需要评估（解析）然后才能执行，而对于RBR，SQL 语句只需要直接更新相应的行数据即可；在 slave 上评估、执行 SQL 时可能会发生错误，这种错误会随着时间的推移而不断累加，数据一致性的问题或许会不断增加。

RBR的优点：

• 所有的变更操作，都可以被正确的Replication，这事最安全的方式；
• 对于 “INSERT … SELECT”、包含 “AUTO_INCREMENT” 的 inserts、没有使用索引的UPDATE/DELETE，相对于SBR 将需要更少的行锁。（意味着并发能力更强）；
  RBR的缺点：
• 最大的缺点：就是 RBR 需要更多的日志量。任何数据变更操作都将被写入log，受影响的每行都要写入日志，日志包含此行所有列的值（即使没有值变更的列）；因此RBR 的日志条数和尺寸都将会远大于SBR，特别是在批量的 UPDATE/DELETE 时，可能会产生巨大的 log 量，反而对性能带来影响，尽管这确实保障了数据一致性，确导致Replication的效率较低；

主从复制有几种方式？

异步复制

MySQL主从集群默认采用的是一种异步复制的机制。Master处理事务过程中，将其写入Binlog就会通知Dumpthread线程处理，然后完成事务的提交，不会关心是否成功发送到任意一个slave中。主服务在执行用户提交的事务后，写入binlog日志，然后就给客户端返回一个成功的响应了。而binlog会由一个dump线程异步发送给Slave从服务，由于这个发送binlog的过程是异步的。主服务在向客户端反馈执行结果时，是不知道binlog是否同步成功了的。这时候如果主服务宕机了，而从服务还没有备份到新执行的binlog，那就有可能会丢数据。

半同步复制

半同步复制机制是一种介于异步复制和全同步复制之前的机制。主库在执行完客户端提交的事务后，并不是立即返回客户端响应，而是等待至少一个从库接收并写到relay log中，才会返回给客户端。MySQL在等待确认时，默认会等10秒，如果超过10秒没有收到ack，就会降级成为异步复制。

这种半同步复制相比异步复制，能够有效的提高数据的安全性。但是这种安全性也不是绝对的，他只保证事务提交后的binlog至少传输到了一个从库，并且并不保证从库应用这个事务的binlog是成功的。另一方面，半同步复制机制也会造成一定程度的延迟，这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时，主服务需要等待的时间就会更长，要等到从服务的服务恢复或者请求超时才能给用户响应。

Master 处理事务过程中，提交完事务后，必须等至少一个Slave 将收到的binlog写入relaylog返回ack 才能继续执行处理用户的事务。相关配置rpl_semi_sync_master_wait_point=AFTER_COMMIT【这里MySQL5.5并没有这个配置，MySQL5.7 为了解决半同步的问题而设置的】rpl_semi_sync_master_wait_for_slave_count=1 （最低必须收到多少个slave的ack）rpl_semi_sync_master_timeout=100（等待ack的超时时间）

半同步复制需要基于特定的扩展模块来实现。mysql从5.5版本开始，往上的版本都默认自带了这个模块。这个模块包含在mysql安装目录下的lib/plugin目录下的semisync_master.so和semisync_slave.so两个文件中。需要在主服务上安装semisync_master模块，在从服务上安装semisync_slave模块。

增强半同步复制

增强半同步和半同步不同是，等待ACK时间不同rpl_semi_sync_master_wait_point=AFTER_SYNC（唯一区别）半同步的问题是因为等待ACK的点是Commit 之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog 还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。增强半同步将等待ACK的点放在提交Commit 之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。