MySQL半同步复制演进

MySQL 提供了异步复制，主库并不关心备库是否收到日志，从而可能导致较多的数据丢失。从MySQL5.5开始引入了一种半同步复制功能，该功能可以确保主服务器和至少一台从服务器之间的数据一致性和冗余，从而可以减少数据的丢失。

    master将binlog event发送给slave后，不去确认slave是否已经收到就返回成功给客户端。

   master将binlog event发送给slave后，确认slave已经收到时才返回成功给客户端。

在MySQL5.7.2版本中重构DUMP线程减小了LOCK_log锁冲突。

    在之前版本中，写binlog的设计为先持有LOCK_log锁（锁住了整个binlog文件），写完后释放锁，再发送binlog更新信号。DUMP线程在读取binlog内容时，也要先获取到LOCK_log锁，然后读取binlog内容，然后释放锁。这样当写binlog的线程和DUMP线程在处理同一个binlog时，就会有较严重的冲突。

    在MySQL5.7中调整了这块的设计。因为写binlog时是追加写入，DUMP线程只是读取，这样可以用一个变量（binlog_end）记录binlog文件末尾位置，每次追加写入后更新下这个变量就可以（用lock_binlog_end锁保护变量binlog_end），DUMP线程在读取时只要不超过标记的binlog末尾位置就可以。只需要在读取到末尾位置时，获取下lock_binlog_end锁，获取下最新的末尾位置。

    在MySQL5.6版本中，master将每个事物写入binlog传递到slave刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。

    这样主库返回给客户端commit ok前，可能事物已经真正提交了，但是从库还没有收到日志。这时其他客户端已经可以看到了提交的事物，这时如果主库故障，主备切换后，其他客户端发现刚才提交的事物又消失了。

    为了解决这个问题MySQL在5.7.2中有了一个解决方案” transaction loss-less”.具体逻辑为master将每个事务写入binlog , 传递到slave刷新到磁盘(relay log)。master等待slave反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。同时引入了参数rpl_semi_sync_master_wait_point来控制使用的策略，默认值为AFTER_SYNC，即5.7的改进做法，还有一个可选值为AFTER_COMMIT，即5.6中的策略。

MySQL5.6处理逻辑图：

MySQL5.7.2处理逻辑图：

MySQL5.6的semi sync 受限于dump thread，原因是dump thread 承担了两份不同且又十分频繁的任务：传送binlog给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS 。

为了解决上述问题，在5.7.4版本的semi sync框架中，独立出一个 ack collector thread ，专门用于接收slave的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。

在MySQL5.6中当半同步开启时，master只是保证一个slave接收到日志，这样当在一主多从的场景下，master和接收到最新日志的slave都挂掉了，那就会丢失数据。这样增加多个备库也不会提高HA的可用性。

在MySQL5.7.3中新增了参数rpl_semi_sync_master_wait_slave_count，可以用来控制master需要保证多少个slave接收到日志。