[[188684]]

本文詳細描述了PhxSQL的設計與實現。從MySQL的容災缺陷開始講起，接著闡述實現高可用強一致的思路，然后具體分析每個實現環節要注意的要點和解決方案，***展示了PhxSQL在容災和性能上的成果。

設計背景

互聯網應用中賬號和金融類關鍵系統要求和強調強一致性及高可用性。當面臨機器損壞、網絡分區、主備手工或者自動切換時，傳統的MySQL主備難以保證強一致性和高可用性。PhxSQL將MySQL集群構建在一致性完善的Paxos協議基礎上，保證了集群內MySQL機器之間數據的強一致性和整個集群的高可用性。

原生MySQL的容災缺陷 【MySQL容災方案】

MySQL有兩種常見的復制方案，異步復制和半同步復制。

1、異步復制方案

Master對數據進行commit操作后再將數據異步復制到Slave。

但數據無法保證成功復制，也就無法保證MySQL主備間的數據一致性，如圖1所示。

圖1 MySQL異步復制流程

2、半同步復制方案

Master對數據進行commit操作前將數據復制到Slave，確認復制成功后再對數據進行commit操作。

絕大多數情況下，半同步復制能保證MySQL主備間的數據一致性，如圖2所示。

圖2 MySQL半同步復制流程

【MySQL重啟流程】

半同步方案中的“半”是指Master在等待Slave的ACK失敗時將退化成異步復制。同時，MySQL在重啟時也不會執行半同步復制。

如圖3中的id(Gtid)=101數據是Master機器中新寫入到Binlog File的Binlog數據。但Master在復制數據到Slave的過程中MySQL宕機導致復制失敗。MySQL重啟時，數據(id=101)會被直接進行commit操作，隨后再將數據異步復制到Slave。(下文將已經寫入到Binlog File但未進行commit操作的數據(id=101)稱為Pending Binlog。)

圖3 MySQL重啟時直接提交Pending Binlog

該情況下MySQL容易出現Master-Slave之間數據不一致的情況，官方也描述了該問題。

http://bugs.mysql.com/bug.php?id=80395

https://mariadb.atlassian.net/browse/MDEV-162

【MySQL重啟缺陷】

下面將解釋MySQL在重啟時不執行半同步會產生數據不一致的原因。

當對上述例子中的Pending Binlog(id=101)進行復制時Master宕機導致復制失敗，隨后Slave1切換成新Master并開始提供服務(寫入id=201的數據)。此后，當舊Master重啟時，Pending Binlog(id=101)不會被重新進行復制而直接進行commit操作，從而導致舊Master比新Master多了一條數據，舊Master無法成為新Master的Slave，需要人工處理掉這條數據之后，才能讓舊Master作為Slave提供服務，如圖4所示。

圖4 MySQL重啟缺陷導致主備數據不一致

上述case只對舊Master的數據造成影響，不會使得MySQL Client讀取到錯誤數據。但當Master連續出現兩次宕機后產生Master切換，兩次宕機間隔較短使得Pending Binlog未能及時復制到Slave，且期間有查詢請求時(Master宕機→Master重啟→查詢數據→Master宕機→Master切換)，MySQL Client會產生如圖5所示的幻讀(兩次讀到的結果不一致)。

圖5 MySQL重啟缺陷導致Client產生幻讀

【MySQL Client分裂】

當Master出現故障且產生Master切換時，由于原生MySQL缺乏調用端的通知/重定向機制，使得不同的Client可能訪問不同的Master，導致數據的錯誤寫入和讀取，如圖6所示。

圖6 MySQL進行Master導致Client端分裂

【MySQL缺乏自動選主機制】

由于半同步復制不需要等待所有Slave的ACK，因此當Master出現故障時，需要選有***Binlog的Slave為新的Master;而MySQL并沒有內置這個選主機制，如圖7所示。

圖7 MySQL缺少自動選主機制

【MySQL的容災缺陷總結】

• MySQL在容災方面存在的問題：
• Master切換時主備數據不能保證一致：Master重啟并切換可能導致MySQL主備間數據不一致。Master重啟并切換可能導致MySQL Client產生幻讀。
• 原生MySQL缺乏高可用機制：Master切換導致調用端分裂。缺乏自動選主機制。
• 對于原生MySQL，在高可用和強一致兩個特性中，只能二選一：
• 要求MySQL主備間的數據強一致，不做主備自動切換。
• 借助MHA實現高可用，容忍MySQL主備間的數據不一致。

因此MySQL在容災上無法同時滿足數據強一致和服務高可用兩個特性。

PhxSQL設計思路

【可靠日志存儲】

實現一個以可靠日志存儲為中心的架構來解決MySQL數據復制時產生的數據不一致問題。

Master將Binlog發送到BinlogSvr集群(可靠日志存儲)，Slave從BinlogSvr集群獲取Binlog數據完成數據復制。

Master在重啟時，根據BinlogSvr集群的數據判斷Pending Binlog是否已經被復制。如果未被復制則從Binlog File中刪除。

利用BinlogSvr集群(可靠日志存儲)，使得Master(重啟時檢查本地Binlog是否和BinlogSvr集群的數據一致)和Slave(從BinlogSvr集群中獲取Binlog)的數據保持一致，從而保證了整個集群中的MySQL主備間數據的一致性，如圖8所示。

圖8 實現一個可靠日志存儲保證各MySQL的數據一致

【請求透傳】

在Master進行切換時，切換操作可能會導致部分MySQL Client仍然訪問舊Master并讀到舊數據。

最直觀的方法是修改MySQL Client API，在每一次進行查詢時，先確認當前Master的位置。但此方法有以下缺點：

• 需要維護一個MySQL Client API的私有版本，維護成本高。
• 所有的調用端需要集成這個私有的MySQL Client API，操作成本很高。

為了避免修改MySQL Client API，可通過增加Proxy進行請求透傳來解決上述問題。在每一個MySQL結點上增加一個Proxy，MySQL Client的請求不再直接訪問MySQL而直接訪問Proxy。Proxy根據Master的位置，將訪問Slave機器的請求透傳到Master機器，再進行MySQL操作。

通過增加Proxy進行請求透傳，解決了MySQL Client分裂導致有可能讀取到舊數據的問題，如圖9所示。

圖9 實現一個可靠日志存儲保證各MySQL的數據一致

【自動選主】

多機自動選主最常見的實現方式是由各個參與者發起投票，獲得多數派支持的機器為Master，同時把Master信息記錄到可靠存儲。Master機器定期到可靠存儲延長租約;非Master機器定期檢查Master租約是否過期，從而決定是否要發起選舉自己為Master的投票。

為了避免修改MySQL代碼，在MySQL機器上增加一個Agent，由Agent來替代MySQL發起選主投票和續期租約;可靠存儲繼續由BinlogSvr承擔。

Agent完成以下功能：

• Master機器的Agent監控本機MySQL是否正常服務;如果正常服務，則定期到可靠存儲延長租約，否則停止續約。
• 非Master機器的Agent定期從可靠存儲檢查Master租約是否過期;如果過期，再檢查本機MySQL是否已經執行了所有Binlog。如果已經執行了所有Binlog，則發起選舉自己為Master的投票，如圖10所示。

圖10 可靠日志存儲和Agent共同實現自動選主機制

PhxSQL架構和實現

從上述思路可以得出PhxSQL的簡單三層架構。對于每一個節點，部署3個模塊(PhxSQLProxy，MySQL，PhxBinlogSvr)。多個節點上的PhxBinlogSvr組成一個可靠的日志存儲集群和可靠的Master信息存儲集群;PhxBinlogSvr同時承擔Agent的責任。PhxSQLProxy負責請求的透傳。Master結點上的PhxSync負責將MySQL的Binlog發送到PhxBinlogSvr，如圖11所示。

圖11 PhxSQL基本架構

【Proxy(PhxSQLProxy)】

請求透傳

請求透傳是Proxy主要的功能。主要解決在進行Master切換的時候，MySQL Client會被分裂，不同的Client可能連接到不同的MySQL。導致出現MySQL Client寫入數據到錯誤的Master或者從錯誤的Master讀取到錯誤的數據。

Proxy的請求透傳分兩種：

• 讀寫端口請求透傳：Slave節點收到的請求透傳給Master節點執行。Master節點收到的請求直接透傳給本機MySQL執行。
• 只讀端口請求透傳：Master節點收到的請求透傳給Slave節點執行。Slave節點收到的請求直接透傳給本機MySQL執行，如圖12所示。

圖12 Proxy請求透傳流程

高性能：由于Proxy接管了MySQL Client的請求，為了使整個集群的讀寫性能接近單機MySQL，Proxy使用協程模型提高自身的處理能力。

Proxy的協程模型使用開源的Libco庫。Libco庫是微信團隊開源的一個高性能協程庫，具有以下特點：

• 用同步方式寫代碼，實現異步代碼的性能。
• 支持***的并發連接。
• 項目地址 https://github.com/tencent-wechat/libco

完全兼容MySQL：為了已有的應用程序能夠不做任何修改就能遷移到PhxSQL，Proxy需兼容MySQL的所有功能。

兼容MySQL事務

MySQL事務管理基于連接，同一個事務的所有請求通過同一個連接通信。在事務處理中連接丟失，事務將被rollback( http://dev.mysql.com/doc/refman/5.6/en/innodb-autocommit-commit-rollback.html )。

Proxy使用1:1連接模型完全兼容MySQL事務。每當MySQL Client發起一個連接到Proxy，Proxy都會相應地發起一個連接到MySQL。兩條連接中，任意一個中斷，另外一個也相應斷開，對應的事務會被rollback，如圖13所示。

圖13 Proxy的1對1事務連接模型

兼容MySQL權限

MySQL的權限管理基于(用戶，源IP)對，源IP是通過socket句柄反查獲取。當請求通過Proxy連接到MySQL時，源IP為Proxy本地IP，權限管理會出現異常。

Proxy利用MySQL協議HEAD保留字段透傳真實源IP到MySQ，MySQL再從HEAD保留字段獲取正確的源IP進行權限管理，如圖14所示。

圖14 Proxy通過修改MySQL協議兼容MySQL權限

PhxSync

PhxSync的功能和MySQL的semisync插件類似。經過調研，對semisync插件的接口做少量的調整，就可以使用這些插件接口來實現PhxSync。

PhxSync功能主要是：

• 正常運行時提交Binlog：MySQL在正常寫入或者更新數據時，會調用after_flush接口。PhxSync插件通過實現after_flush接口將MySQL新寫入的Binlog提交到本機的BinlogSvr，由本機BinlogSvr通過Paxos協議同步到BinlogSvr集群。
• 重啟時校準本地Binlog：MySQL在重啟時通過查詢BinlogSvr集群判斷本地Pending Binlog的狀態。如果Pending Binlog未復制到BinlogSvr集群則從本地刪除，保持本地的Binlog數據和BinlogSvr集群的Binlog數據一致。

由于MySQL沒有提供在重啟時的插件接口，為了后續維護方便，在MySQL代碼層抽象出了一個新插件接口before_binlog_init用于校準Binlog。

上述對after_flush接口的調整，和新增的before_binlog_init接口已經提交補丁給MySQL官方( http://bugs.mysql.com/bug.php?id=83158 )。

【PhxBinlogSvr】

PhxBinlogSvr主要負責存儲Binlog和Master信息的維護。在數據復制階段，通過Paxos協議保證PhxBinlogSvr各節點的數據一致性(下文稱PhxBinlogSvr為BinlogSvr)。

• PhxPaxos庫：BinlogSvr使用PhxPaxos庫進行數據的復制。PhxPaxos庫是微信團隊開源的Paxos類庫，具有以下特性：1. 保證各節點的數據一致。
• 保證集群機器超過一半存活還能服務。
• 高性能。
• 功能完善。
• 穩定性經過大規模驗證。
• 接口方便易用。
• 項目地址 https://github.com/tencent-wechat/phxpaxos

BinlogSvr異常情況處理 防止Slave的節點提交數據

當舊Master在提交數據時由于網絡問題數據包被卡在網絡，且新Mater已經成功切換時，或者人為錯誤直接往Slave節點的MySQL寫入數據時，則會出現Slave節點提交數據的情況。多節點同時提交數據會出現BinlogSvr的Binlog數據和MySQL存儲的Binlog數據不一致的情況。

BinlogSvr存儲了集群內的Master信息。當其收到MySQL提交的數據時，可根據Master信息拒絕非Master節點的提交，如圖15所示。

圖15 BinlogSvr通過Master信息拒絕非Master節點的提交

防止Master提交錯誤數據

在某些情況下，Master可能會重新發送數據或者發送錯誤數據。譬如在網絡不好的情況下Master由于提交數據超時而重發數據。磁盤發生故障或者數據被錯誤回滾或者修改的時候，Master會提交錯誤的數據。

BinlogSvr使用樂觀鎖機制來防止Master的異常提交。在MySQL提交數據給BinlogSvr時，以本機MySQL已經執行的GTID為樂觀鎖，提交的內容為(本機MySQL已經執行的***GTID，本次要提交的Binlog)。BinlogSvr通過檢查請求中(本機MySQL已經執行的***GTID)和自身保存的***GTID是否匹配來拒絕重新發送或者異常發送的數據，如圖16所示。

圖16 BinlogSvr使用樂觀鎖拒絕Master在數據異常的情況下提交數據

• 支持MySQL原生復制協議：為了讓Slave能從BinlogSvr獲取Binlog，***的方式就是BinlogSvr支持MySQL原生的復制協議，這樣不用對Slave做任何修改，如圖17所示。

圖17 BinlogSvr支持MySQL使用原生復制協議獲取Binlog數據

• Master管理：BinlogSvr除了存儲MySQL的Binlog數據，還存儲了Master信息。同時還承擔了Agent的角色，負責監控MySQL的狀態，必要時發起選舉自己為Master的投票。

BinlogSvr通過Paxos協議進行Master選舉，選舉成功后成為Master并擁有租約。通過Paxos協議選舉保證了最終只產生一個Master且每個節點記錄了一致的Master信息。

PhxSQL效果 【PhxSQL數據一致性】

通過比較PhxSQL集群中各節點的數據(MySQL Binlog，PhxPaxos，BinlogSvr) 判斷各節點數據是否一致，如圖18所示。

圖18 PhxSQL 3機數據對比

【Master自動切換】

通過觀察Master宕機時各節點的流量變化判斷Master是否順利切換。下圖中的紅線代表流量。當Master宕機時，流量會隨之轉移，代表Master順利切換，如圖19所示。

圖19 PhxSQL進行Master切換時各節點的寫入流量變化

【PhxSQL性能】

MySQL版本：Percona 5.6.31-77.0

機器信息：

CPU ：Intel Xeon CPU E5-2420 0 @ 1.90GHz * 24。

Memory : 32G。

Disk:SSD Raid10。

Ping Costs：Master→Slave:3 ~ 4ms; client→Master :4ms。

工具和參數：

sysbench。  
–oltp-tables-count=10 –oltp-table-size=1000000 –num-threads=500。  
–max-requests=100000 –report-interval=1 –max-time=200。 

PhxSQL的寫性能比MySQL的半同步好，讀性能由于多了一層Proxy導致比MySQL的半同步稍差。

圖20 PhxSQL和MySQL的性能對比