mysql复制发展历程（从5.1到8.0版本）

       mysql5.1之前的版本网上基本上都查不到什么资料了，官网上也只有5.5之后的文档。所以就从5.1开始了解复制的发展历史。

MySQL 5.1

       mysql5.1版本对于复制的新特性就是引入了基于行的复制，当服务器使用混合模式复制时，基于语句的复制是默认的，在运行时会根据具体情况动态的改变binlog格式。当使用混合模式复制时，如下几种情况会从基于语句的binlog切换到基于行：1.当函数中包含 UUID() 时。2.2个及以上包含 AUTO_INCREMENT 字段的表被更新时。3.行任何 INSERT DELAYED 语句时。4.用 UDF 时。5.视图中必须要求使用RBR 时，例如创建视图是使用了 UUID() 函数。

MySQL 5.5

       *mysql5.5版本引进了半同步复制，半同步复制在提交过程中增加了一个延迟，在提交事务后，只有在备库收到了该事务的二进制日志才会给客户端进行查询结束的反馈。这会给客户端查询体验增加一些延迟，不过一般不是问题，因为相对于写入硬盘的时间，通过网络传输一些日志的时延不算什么。需要注意的是半同步复制不会阻塞事务的提交，而是阻塞给客户端的反馈；当备库一直没有回应已收到事件主库会超时并转化成正常的异步复制模式。通过半同步复制可以让客户端清楚主备库上事务是否达到了一致，从而可以做出相应的应对。

       目前实现半同步复制主要有两种模式，AFTER_SYNC模式和AFTER_COMMIT模式。两种方式的主要区别在于是否在存储引擎提交后等待Slave的ACK。流程图如下：

       AFTER_SYNC比AFTER_COMMIT相对来讲更安全，它会在fsync binlog后直接开始对备库进行复制，而不是在commit后。考虑一种情况，在上图中第三步commit成功后，binlog还没有传给slave而master崩溃了，此时备库会比主库少一个事务，对于其他事务来说，这个事务已经commit是可见的了，但是当切换到备库后，又发现这个事务消失了就会导致幻读。这个例子很极端，尽管对于申请这个事务的用户来说，不管是那种模式，这个事务都失败了对他没影响，但是对于其他用户的事务来说可能会出现问题。使用了AFTER_SYNC模式后，不管commit后是否crash，备库都已经收到了binlog，因而不会出现上述情况。

       不过我有个疑惑就是，如果在commit的时候crash了，但是此时binlog已经发出给备库，那么对于主库的事务这个事务不可见，但是切换到备库却又可见了，那岂不是又是幻读？

       *5.5版本还有Relay log corruption recovery特性，由relay_log_recovery参数控制，这个参数的作用是：当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开