一：增强半同步复制

① 半同步复制(5.5 5.6)

    过程分析：
    1 > session 发出commit请求
      2 > flush binlog and fsync binlog
      3 > InnoDB 引擎层 commit
      4 > 发送binlog到SLAVE，等待slave发送ack确认
      5 > slave 接受binlog 写入relay log ，刷盘完成发送ack确认包给master
      6 > master 返回 commit ok 信息给session

      另外 (master 等待事务A 的 ACK的时候宕机，此时新事务B在宕机之前开启)：
      1> binlog 未发送到从库:
            事务B获取到事务A提交的内容，此时宕机故障切换到slave，事务B获取到的内容却丢失了。事务A commit没有收到反馈信息(则需要业务判断了)。
      2> binlog 已经发送给从库 :
事务B获取到事务A提交的内容，故障切换到salve ，B仍然获取到A提交的内容，没毛病。事务A commit没有收到反馈信息，若重新执行该事务，则相当于执行两次A事务(则需要业务判断了)。

② 增强半同步复制(5.7)
      由该参数 rpl_semi_sync_master_wait_point=AFTER_SYNC/AFTER_COMMIT 两个值选择是否启用增强半同步
      当  半同步模式为 AFTER_COMMIT 时，为以上分析的情况
      当半同步模式为 AFTER_SYNC 模式时，则：

          过程分析：
           1 > session 发出commit请求
         2 > flush binlog and fsync binlog
      3 > 发送binlog到SLAVE，等待slave发送ack确认
      4 > slave 接受binlog 写入relay log ，刷盘完成发送ack确认包给master
          5 > InnoDB 引擎层 commit
         6 > master 返回 commit ok 信息给session

          另外(master 等待事务A 的 ACK的时候宕机，此时新事务B在宕机之前开启)：
          1> 事务B读取不到事务A的内容，因为事务A的ENGINE层还没有提交(无损复制)

二 : 半同步复制增加 ACK线程

① mysql5.5 mysql5.6
      1> master dump thread 发送binlog events 给 slave 的IO thread，等待 slave 的ack回包
      2> slave 接受binlog events 写入redo log ，返回 ack 包给master dump thread
      3> master dump thread 收到ack包，给session返回commit ok，然后继续发送写一个事务的binlog。

② mysql5.7 新增ack线程
        1> master dump thread 发送binlog events 给 slave 的IO thread，开启ack线程等待 slave 的ack回包，dump 线程继续向slaveIO thread发送下一个事务的binlog。
      2> slave 接受binlog events 写入redo log ，返回 ack 包给master ack线程，然后给session返回commit ok。

可以看到，mysql5.7半同步复制中增加了一个 ACK线程专门用来进行semi 复制的ACK确认，这提高了复制的tps。

ITPub博客

#MySQL# mysql5.7新特性之半同步复制

最新文章