分布式數據庫PhxSQL設計與實現的實例分析
“本文詳細描述了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之間數據不一致的情況，官方也描述了該問題。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%
下載地址
分布式數據庫PhxSQL設計與實現的實例分析下載
相關電子資料下載
- 多方位優化！憶聯分布式數據庫存儲解決方案，助力MySQL實現高性能、低時延 357
- **分布式數據庫|數據庫數據類型** 157
- 數字化轉型下我國分布式數據庫應用挑戰及發展建議 213
- 華為云新一代分布式數據庫GaussDB正式發布 521
- 華為新一代分布式數據庫GaussDB向全球客戶提供服務 223
- 華為云新一代分布式數據庫GaussDB，給世界一個更優選擇 386
- 如何對全國分布式數據庫機房動環進行監控和報警 59
- 美國數倉巨頭退出中國 國產新一代分布式數據庫開啟達夢新紀元 209
- 低延遲的分布式數據庫架構對于新興的霧應用程序至關重要 250
- 榮膺桂冠！中興GoldenDB蟬聯中國金融級分布式數據庫第一 640