數據庫服務於企業的核心交易業務和實時交互應用，承載著企業的核心數據，因此企業對於數據庫的數據一致性和高可用性有強烈的需求。

本次內容為青雲QingCloud 數據庫工程師蒙哲在 3306Pai 2018 技術大會上演講內容整理而來，從數據庫集群架構、原理、應用場景、雲平臺運維等方面向大家詳細介紹 QingCloud 金融級數據庫服務 —— MySQL Plus。

以下為本次分享的內容整理

MySQL Plus 解決了什麼問題？

作為 MySQL 的升級版本，QingCloud MySQL Plus 是一款具備金融級強一致性、主從秒級切換，集 InnoDB + TokuDB 雙存儲引擎支持的增強型 MySQL 集群應用，適用於對數據一致性和高可用性有強烈要求的企業用戶。

目前關於 MySQL 集群的方案、架構比較多，常見的方案是存在中心管理節點。而 MySQL Plus 的一個核心特性就是無中心化自主選主，不需要依賴中心節點去管理控制集群中的服務節點。

另外兩個特性：一是集群數據強一致性；二是集群主從秒級切換的特性。

MySQL Plus 核心架構

MySQL Plus 是基於 Raft 構建的 MySQL 中自動選主及維護主從的套件，上圖是 MySQL Plus 的核心架構，一個典型的 3 節點集群。之所以這樣配置是因為： Raft 協議的機制要求集群節點數是奇數個，例如 3 個節點、5 個節點和 7 個節點。

圖中圓圈節點是 Xenon 進程，可以認為它是一個 Agent。在其下面為 MySQL 服務，一個主機節點上會有一個 Xenon，它會管理 MySQL 服務。每個節點上有一個 Agent 和 MySQL 服務，Agent 之間通過 Raft 機制來為集群選主。

通過 MySQL 本身的 Semi-Sync 實現數據同步，在數據一致性層面完全由 MySQL 本身的同步機制實現。Raft 主要用於選主，每一個 Xenon 進程會探測 MySQL 服務是否正常，集群中 Leader 節點會定期向 Follower 節點發送心跳，Follower 節點接收 Leader 節點心跳超時後會發起新的選舉。

以上就是 MySQL Plus 的一個整體架構。

MySQL Plus 實現原理

Raft 主要有兩個功能：一是選主，二是數據同步。

MySQL Plus 只用 Raft 的選主功能，數據同步是基於GTID + Binlog方式，多數派確認通過 Semi-Sync 機制。

下面詳細和大家介紹基於 Raft 選主和 Leader 自動降級機制，以及關於 Semi-Sync 的一些配置。

Raft 選主機制

如上圖所示，

Leader 會定期給 Follower 發心跳，以確定這個節點的狀態。Follower 節點會定期接收 Leader 的心跳，當 Follower 無法接收到 Leader 的心跳，它將會變為 Candidate 角色，併發起選舉操作。

Leader 定期給 Follower 發送心跳，如果 Follower 無法接收 Leader 發送的心跳，它會把自己的狀態變成 Candidate，然後向所有的節點發起選舉請求，如果它能獲得多數（n/2 + 1，n 為集群節點數，比如 3 節點集群至少需要獲得兩票贊成票）節點投的贊成票就會提升為 Leader。

Raft 選主規則

集群選主機制，主要基於 Raft，跟 MySQL 相關的是選主投票時，如何決定投贊成票，這與 MySQL 相關，通過比較 binlog 位點決定是否給候選人投贊成票。

集群初始節點狀態都是 Follower ，所有 Follower 節點定期接收 Leader 心跳，如果在超時後沒有接收到 Leader 心跳，就會發起選舉。接收到選舉請求節點會通過比較 MySQL binlog位點來決定是否投贊成票。

發起選舉的節點如果獲得多數票，就會成為 Leader，如果沒有獲得多數選票，則會把自己的狀態降級為Follower。

左圖是上面介紹的集群選舉的一個過程。集群初始化起來後，這三個節點是 Follower 的狀態。其中有一個節點 Timeout，等待接收 Leader 的心跳超時後，它自己會成為 Candidate 狀態，會給其他節點發起投票。如果其他節點給它投的贊成票，這個節點就會當選成為 Leader。

右圖是選主結束後集群正常的狀態。Leader 節點定期給其他節點發送心跳。Follower 節點會從 Leader 節點同步數據。

集群節點不同角色狀態時對應的操作

集群中節點成為 Leader 後，需要定期向Follower節點發送心跳，檢查、獲取集群中所有節點的狀態。

對應的 MySQL 服務作為 Master節點，首先要等待 Relay-log 應用完成，其實就是 SQL 線程將 relay日誌重放完， 然後 Stop Slave，清理複製配置信息。

下來設置數據庫服務可以讀寫。等完成這一系列操作後，整個集群對外可用，這時候才會啟動 VIP，應用就可以連接進來。

Leader 降級處理，首先會把 VIP 停掉，保證集群處於不可用時，不會對外提供服務。Leader 會把自己降級為 Follower 角色。

Follower 會接收 Leader 心跳，接收到 Leader 心跳後，根據Leader節點信息，配置並啟動複製線程，從 Leader 上同步數據。

Candidate 比較簡單，發起選舉，獲得多數票後成為 Leader，獲得少數票會降級為 Follower。

Leader 自動降級機制

以上是集群節點不同角色對應的操作處理，下面介紹下 Leader 自動降級機制，基本分為兩種情況：第一，網絡隔離問題；第二，Leader 故障。

網絡隔離的故障處理，Leader 節點跟 Follower 節點之間網絡不通，這種情況下，Leader 會把自己降級成 Follower。

其他 Follower 節點無法接收 Leader 發送的心跳，會把自己變為 Candidate，然後發起選舉。獲得多數選票後，把自己升級為 Leader 節點，這時候整個集群可以對外服務。

MySQL 服務不可用之後，Leader 會把自己降級成 Follower 角色。降級成 Follower 角色後，整個集群中目前沒有 Leader，這兩個 Follower 節點接收 Leader 心跳會超時，其中有一個節點會發起選舉。

目前集群中剩餘的兩個 Follower 節點至少有一個節點跟之前 Leader 節點數據完全一致。如果集群中數據同步有延時的節點首先發起選舉，會收到完整數據節點投的反對票，發起選舉失敗會降級為 Follower 角色。

擁有完整數據的節點接收 Leader 心跳 Timeout 後會把自己變成 Candidate，發起選舉。這時候數據不完整節點會給它投贊成票，加上自己的一票，獲得兩票贊成票後會升級為 Leader。變成兩個節點後，這兩個節點之間目前是完全強一致的同步。如果故障節點恢復加進來後，整個集群中只要有一個節點數據跟主節點保持一致就可以了。

前面談到 MySQL Plus 其中一個特性就是秒級切換，集群故障後，不需要依靠其他的中心節點，集群內的節點可以快速選出主節點。通過數據庫並行複製和相關 I/O 參數的優化，切主後能快速重放完成 Relay 日誌對外提供服務，實現集群秒極切換、服務快速響應。

Leader 故障後，大家會想到數據一致性問題。MySQL Plus 是基於 Semi-Sync 機制做的數據同步，比如三個節點，集群中會至少有一個從節點跟主節點數據保持一致。

MySQL Plus 中 Semi-Sync 配置

大家對 MySQL 比較瞭解，也比較熟悉 Semi-Sync 機制。MySQL Plus 集群用的 MySQL 是基於 5.7 版本的，對於 rpl_semi_sync_master_timeout 參數設置比較大，所以不會出現降級的情況，參數 rpl_semi_sync_master_wait_point 默認配置是 AFTER_SYNC，來避免出現幻讀的情況。

前面大家看到的是三個節點集群，通過 Semi-Sync 機制，集群中配置的 rpl_semi_sync_master_wait_for_slave_count 是 1，如果是 5 個節點，需要配置成 2，至少要保證集群中有 2 個從節點和 Leader 的節點數據保持一致。

MySQL Plus 自動化運維

目前集群數據同步主要依靠 MySQL 自身的複製，MySQL 本身的複製由於一些原因，或多或少會存在不穩定的情況。

MySQL Plus 提供自動化運維的工具，通過這些工具可以獲取集群的狀態，對集群中故障節點做診斷，對於預期的故障類型，可以快速對故障節點進行自動化重建。

獲取集群的狀態，包括 Leader、Follower 及 SQL 線程的運行情況。獲取集群狀態後，可以瞭解到 IO 或者 SQL 線程的狀態，針對錯誤信息來做相應處理。

獲取集群 GTID ，瞭解節點 GTID 的變化，可以瞭解節點數據同步是否存在異常。

例如，通過比較時間段內節點獲取到的 GTID 和 已經執行的 GTID 變化，來判斷SQL 線程重放是否有 wait 或者 hang 住的異常情況。

這是 MySQL Plus 提供快速重建的工具，是基於 Xtrabackup 做的。當集群中有節點故障，需要重建時，可以通過 Rebuildme 工具快速重建，節點快速恢復後會自動再加到集群。重建可以基於 Leader 節點，也可以指定基於某個節點重建，避免對 Leader 節點產生過多的負載影響。

目前青雲新用戶基本使用的 MySQL Plus，很多老用戶也在逐步遷移到 Plus。上面是 QingCloud 雲平臺上 MySQL Plus 的幾個相關監控展示，包括事務提交，查詢數量、連接數。還有一些沒有列出來的，如慢查詢、全表掃描相關等。

關於開源

青雲QingCloud 提供的 MySQL Plus 採用一主多從的架構設計，通過 Semi-sync 和 Raft 技術實現數據的多副本同步複製，確保至少一個從節點與主節點始終保持數據完全一致，

未來，青雲QingCloud 將會把 MySQL Plus 開源，提供給更多對數據庫感興趣的人使用，大家期待一下吧。

閱讀更多 青雲QingCloud 的文章

關鍵字: Sync 雲計算 數據庫