> MySQL高可用方案很多，最常見的原生複製方案，即async、semi-sync那套，所以本文從原生複製方案為中心，討論資料一致性。

### 基於複製的高可用方案
* 兩節點：雙主、主從  
* 三節點或更多：一主兩從等

明確一點，這幾種結構無論怎麼變，無論是用MHA還是Orchestrator，還是什麼第三方工具，核心點都是透過`binlog event`來傳遞資料給其他節點。

這種結構常見的問題：  
**1、延遲、複製過濾、報錯等造成資料不一致：**  
這個問題，一般能夠透過優秀的DBA和業務開發大哥們，透過許可權管理、schema設計、配置最佳化、SQL調優等手段處理掉，但……還有2

**2、master crash，備庫沒有收到binlog event：**  
這個問題，有人就會說了，有個叫`semi-sync`的東西，何況5.7還最佳化了`semi-sync`，支援無損半同步（`lossless semi-synchronous`），但其實極端情況下，也有問題。

### 非同步複製
大家都懂。聽名字和實際上都不靠譜：不管一個或多個從庫是否收到了`binlog events`，主庫只管產生`binlog`，極端場景下的，發生資料不一致的機率非常大。

### 半同步複製
先簡單說一下`after_commit`和`after_sync(lossless)`的差異。    
```
after_commit：
    在engine commit之後等待ACK
after_sync：
    在engine commit之前等待ACK    
```

幾個意思呢？  
因為`after_commit`模式下，先做引擎層提交，這時候其他客戶端是可以會讀到這個事務的。如果這時發生容災，事務又沒有傳給`Slave`，容災後客戶端就讀不到這個事務了，就出現了資料不一致情況。

而`after_sync(lossless)`最佳化了這點，即，等待`ACK`返回成功，再做引擎層提交，這樣客戶端1讀不到，其他客戶端也讀不到。

我表達的不太好，倆圖勝千言：

### 基於半同步複製的容災討論
討論這個話題其實是非常大的，因為複製的場景很多。比如不同的GTID、auto-position、MTS等設定。
此處假設大家的MySQL例項都是經過專業DBA之手，配置好了支援`slave crash safe`的引數。

此處討論5.7+的`after_sync(lossless)`，假設簡單的一主一從（或雙主都可以）為例項A->例項B

#### Master Crash，未容災：
沒所謂，A拉起後繼續做crash recovery，最終主從是一致的。  
#### Master Crash，容災：
1）crash時至少有一臺Slave收到binlog event併成功返回了ACK給Master：  
沒問題，因為這種情況主從資料一致的，拉起後也不需要做額外操作。

2）Crash時binlog event傳送失敗：  
假設產生在例項A的事務t1是：`INSERT：pk_id=11, name='張三'` 。  
發生容災，例項B成為新主，可能會產生新事務t2：`INSERT：pk_id=11, name='李四'`  
例項A恢復後，做`crash recovery`，將t1直接提交，然後作為新的Slave，接收到了例項B（新主）的這條事務t2，出現了`duplicated key`，經典的`ERROR 1062`來了，設定合理的引數也沒用。

其實，事務t1是要被遺棄的小可憐（鵝廠PhxSQL團隊稱這種事務為“Pending Binlog”）
因為也沒有返回給客戶端它成功提交的資訊，這種情況是要回滾的，而且這種情況在`after_sync(lossless)`的設定下，也沒辦法的。

3）Crash時binlog event傳送成功，但在等ACK，沒有執行`engine commit`：  
因為事務t1已經傳送成功了，接管成新Master的Slave是有事務t1的，所以原Master拉起後，做`crash recovery`，也是沒問題的，拉起後不需要做額外操作。

**場景2）還有什麼風險？**  
試想一下，如果沒有pk，是不是就不會報錯？    
也沒辦法發現拉起來的老Master實際上和新Master資料不一致了？

### 場景2）的解決：
首先，場景2）MySQL原生複製結構是沒法處理的。  
但問題總要解決，為了保證整個複製節點的資料一致，考慮如下：
```
方案1、重建節點
方案2、回滾錯誤事務，斷點續傳新增binlog
```  
方案1也就是最憨的辦法，直接重建容災後的從庫，沒有技術含量，xtrabackup一把梭，不說了。      
方案2需要一定的開發量，參(bai)考(piao)了一下別人的做法：  
**微信PhxSQL：**  
額外多一個BinlogSvr的中間服務。“使得Master（重啟時檢查本地Binlog是否和BinlogSvr叢集的資料一致）和Slave（從BinlogSvr叢集中獲取Binlog）的資料保持一致，從而保證了整個叢集中的MySQL主備間資料的一致性。”

### 結論
原生複製存在對“一致性”和“可用性”的權衡挑戰。

即使是安全的配置了各種引數，使用原生複製體系和`lossless semi-sync`，也不是100%省心的（尤其是對於資料一致性要求拉滿的業務）。

即使是將`rpl_semi_sync_master_timeout`設定為無窮大，也只是保證`semi-sync`不退化。

其他一致性方案或思路：    
```
1、Paxos\Raft
2、共享儲存
```

### 參考
* 《PhxSQL設計與實現》，google一搜就有
* 《Loss-less Semi-Synchronous Replication on MySQL 5.7.2》： http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html
* 淘寶核心月報 - 《MySQL 半同步複製資料一致性分析》 http://mysql.taobao.org/monthly/2017/04/01/

![](http://img.blog.itpub.net/blog/2020/11/12/fb41413474168e6a.png?x-oss-process=style/bb)

MySQL#複製 - 原生複製的一致性探討

相關文章