MySQL5.7新特性：lossless replication 无损复制

我会带着你远行 2022-06-17 13:58 174阅读 0赞

MySQL5.7新特性：lossless replication 无损复制  
官方文档：

> [https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html][https_dev.mysql.com_doc_refman_5.7_en_replication-semisync.html]

### MySQL的三种复制方式 ###

*  asynchronous 异步复制
 *  fully synchronous 全同步复制
 *  Semisynchronous 半同步复制

### **1. asynchronous replication** ###

> **原理：**在异步复制中，master写数据到binlog且sync，slave request binlog后写入relay-log并flush disk  
> **优点：**复制的性能最好  
> **缺点：** master挂掉后，slave可能会丢失事务  
> **代表：** MySQL原生的复制

![这里写图片描述][SouthEast]

### **2. fully synchronous replication** ###

> **原理：**在全同步复制中，master写数据到binlog且sync，所有slave request binlog后写入relay-log并flush disk，并且回放完日志且commit  
> **优点：**数据不会丢失  
> **缺点：**会阻塞master session，性能太差，非常依赖网络  
> **代表：** MySQL-Cluster

![这里写图片描述][SouthEast 1]

### **3. semisynchronous replication** ###

#### 3.1. 普通的半同步复制 ####

> **原理：** 在半同步复制中，master写数据到binlog且sync，且commit，然后一直等待ACK。当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志）  
> **优点：**会有数据丢失风险（低）  
> **缺点：**会阻塞master session，性能差，非常依赖网络，  
> **重点：**由于master是在三段提交的最后commit阶段完成后才等待，所以master的其他session是可以看到这个提交事务的，所以这时候master上的数据和slave不一致，master crash后，slave数据丢失  
> **代表：** after commit, 原生的半同步

![这里写图片描述][SouthEast 2]

#### 3.2. 增强版的半同步复制（lossless replication） ####

> **原理：** 在半同步复制中，master写数据到binlog且sync，然后一直等待ACK. 当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志）  
> **优点：**数据零丢失（前提是让其一直是lossless replication），性能好  
> **缺点：**会阻塞master session，非常依赖网络  
> **代表：** after sync, 原生的半同步  
> **重点：**由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的，所以这时候master上的数据和slave一致，master crash后，slave没有丢失数据

![这里写图片描述][SouthEast 3]

### 重要参数 ###

<table> 
 <thead> 
  <tr> 
   <th align="left">参数</th> 
   <th>comment</th> 
   <th>默认值</th> 
   <th>推荐值</th> 
   <th>是否动态</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">rpl_semi_sync_master_wait_for_slave_count</td> 
   <td>至少有N个slave接收到日志</td> 
   <td>1</td> 
   <td>1</td> 
   <td>dynamic</td> 
  </tr> 
  <tr> 
   <td align="left">rpl_semi_sync_master_wait_point</td> 
   <td>等待的point</td> 
   <td>AFTER_SYNC</td> 
   <td>AFTER_SYNC</td> 
   <td>dynamic</td> 
  </tr> 
  <tr> 
   <td align="left">rpl_semi_sync_master_timeout</td> 
   <td>切换复制的timeout</td> 
   <td>10000（10s）</td> 
   <td>1000(1s)</td> 
   <td>dynamic</td> 
  </tr> 
  <tr> 
   <td align="left">rpl_semi_sync_master_enabled</td> 
   <td>是否开启半同步</td> 
   <td>OFF</td> 
   <td>ON</td> 
   <td>dynamic</td> 
  </tr> 
  <tr> 
   <td align="left">rpl_semi_sync_slave_enabled</td> 
   <td>是否开启半同步</td> 
   <td>OFF</td> 
   <td>ON</td> 
   <td>dynamic</td> 
  </tr> 
 </tbody> 
</table>

### 如何开启lossless replication ###

########semi sync replication settings########
    plugin_dir=/usr/local/mysql/lib/plugin
    plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
    loose_rpl_semi_sync_master_enabled = 1
    loose_rpl_semi_sync_slave_enabled = 1
    loose_rpl_semi_sync_master_timeout = 1000

### 实践是检验真理的唯一标准 ###

> 如何检验上述after\_sync,after\_commit  
> 如何检验上述原理的正确性

### InnoDB commit ： 三阶段提交过程 ###

*  A阶段. wite prepare log – 写入Xid
 *  B阶段. write binlog
 *  C阶段. write commit log

### 测试点 ###

当master上一个事务Waiting for semi-sync ACK from slave的时候，后来的事务是在A,B,C哪个阶段卡住呢？

0，RC模式
    
    1. semi-sync C阶段等待
    
    假设设置time-out=100000s，当事务一提交了一个大事务，在write commit log(C阶段)时候等待，
    那么第二个事务在敲commit命令的时候，是卡在哪个阶段呢？是卡在 wite prepare log（A阶段）？还是write binlog（B阶段）？还是write commit log（C阶段）
    
    测试：semi-sync vs  loss-less semi-sync
    
    【semi-sync】 C阶段等待
    0, 开启事务1，然后在slave上执行stop slave，制造timeout的情况，让其阻塞。(Waiting for semi-sync ACK from slave)
    1，在开启一个事务2，事务2插入一条特殊记录（XXXXX）。  (Waiting for semi-sync ACK from slave)
    2，在开启一个事务3。
    2.1，测试案例：这个时候，kill -9 mysqld，造成人为的mysql crash
    3，假设卡在A阶段，那么事务3，肯定是看不到事务1,2写入的记录（XXXXX）,且重启mysql后，事务2不会提交。
    4，假设卡在C阶段，那么事务3，肯定是可以看见事务1，2写入的记录（XXXXX）。
    
    经过测试：
    1，是卡在C阶段，也就是说事务3是可以看见事务1，事务2的。
    2，MySQL crash重启后，事务1，事务2的dml都已经提交成功，说明不是卡在A阶段
    
    【loss-less semi-sync】B阶段等待
    
    0, 开启事务1，然后在slave上执行stop slave，制造timeout的情况，让其阻塞。(Waiting for semi-sync ACK from slave)
    1，在开启一个事务2，事务2插入一条特殊记录（XXXXX）。(Waiting for semi-sync ACK from slave)
    2，在开启一个事务3
    3，假设卡在A阶段，那么事务3，肯定是看不到事务1,2写入的记录（XXXXX）,且重启mysql后，事务2不会提交。。
    4，假设卡在B阶段，那么事务3，肯定是可以看见事务1,2写入的记录（XXXXX）,且重启mysql后，事务1，2都会提交。。
    5, 假设卡在C阶段，那么事务3，肯定是可以看见事务3写入的记录（XXXXX）。
    
    经过测试：
    1，是卡在B阶段，也就是说事务3，既看不见事务1的提交内容，也看不见事务2的提交内容，且重启mysql后，事务1，2都已经提交。。
    2，MySQL crash重启后，事务1，事务2的dml都已经提交成功，说明不是卡在A阶段。

### 性能 ###

#### semi-sync vs lossless semi-sync 的性能对比 ####

> 根据以上的测试，可以得知，lossless只卡在B阶段，普通的semi-sync是卡在C阶段。  
> lossless的性能远远好于普通的semi-sync，即（after\_sync 优于 after\_commit）  
> 因为lossless 卡在B阶段的时候可以堆积事务，可以在C阶段进行group commit。  
> 普通的semi-sync，卡在C阶段,事务都已经commit了，并没有堆积的过程。

### CAP理论 ###

*  一致性【C】
 *  可用性【A】
 *  分区容忍性【P】

理论：CAP 三者不可兼得，必须要牺牲一个

分区，是一定存在的，不是你想不要就不要的。所以，这里只剩下两种组合，这是对Mysql而言。

*  CP 牺牲可用性
    
    > 保留强一致性，牺牲可用性。  
    > 案例：可以将rpl\_semi\_sync\_master\_timeout设置成一个无限大的值，比如：100天，那么master和slave就强一致了，但是可用性就大打折扣。
 *  AP 牺牲一致性
    
    > 保留高可用性，牺牲一致性。  
    > 案例：比如原生的异步复制就是这样咯。可以快速做到切换，但是一致性就没有保障。

如果想要CA，可以考虑Percona XtraDB Cluster。

转载地址

> [https://yq.aliyun.com/articles/59258][https_yq.aliyun.com_articles_59258]

[https_dev.mysql.com_doc_refman_5.7_en_replication-semisync.html]: https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
[SouthEast]: /images/20220617/26527cef02974ff4a5c867d472254869.png
[SouthEast 1]: /images/20220617/dd6b2825a9804c5690ea8347412fe886.png
[SouthEast 2]: /images/20220617/51a8f93b09c144fab89aeb7d6c40eba6.png
[SouthEast 3]: /images/20220617/ff5898c62b7b440bbb999729723bd64a.png
[https_yq.aliyun.com_articles_59258]: https://yq.aliyun.com/articles/59258