單位時間內事務能力（TPS）會跟叢集成員數量成反比

增加叢集成員會顯著且無法預期的增加事務響應時間

增加了叢集成員資料複製的衝突和死鎖的可能性

將基於 binlog 改為基於 write-set，write-set 中包含修改的資料，Global Transaction ID（後面簡稱 GTID）和 Primary Key。

GTID 類似 45eec521-2f34-11e0-0800-2a36050b826b:94530586304

94530586304 為 64-bit 有符號整型，用來表示事務在序列中的位置

將傳統的 Synchronous Replication 改為 Deferred Update Replication，並將整個過程大致分解成四個階段，本地階段、傳送階段、驗證階段和應用階段，其中：

本地階段：樂觀執行，在事務 Commit 前，假設該 Transcation 在叢集中複製時不會產生衝突。

傳送階段：優化同步時間視窗，除去全域性排序並獲取 GTID 為同步操作，衝突驗證和事務應用都為非同步，極大的優化了複製效率。

驗證階段：只有收到該事務的所有前置事務後（不能有 “hole”），該事務和所有未執行的前置事務才能併發驗證，不然不能保證 Global Ordering，因此這裡需要犧牲效率，引入一定的序列化。

需要等待事務 3

3 資料庫節點：

4 資料庫節點：設定權重避免”split-brain” (⅙ + ⅙ ) + ⅓ + ⅓

5 資料庫節點：

6 資料庫節點：

7 資料庫節點 : 可支援兩種拓撲關係

基於Corosync實現（Totem協議），外掛式安裝，MySQL 官方原生外掛。

叢集架構，支援多寫（建議單寫）

允許少數節點故障，同步延遲較小，保證強一致，資料零丟失

單位時間的交易量受 flow control 影響。

該專案由 Youtube 開源，從文件看功能極為強大，高度產品化。

作為第二個儲存類專案（第一個是 Rook，有意思是儲存類而不是資料庫類）加入 CNCF，目前還處於孵化階段（incubation-level）。

筆者沒有使用經驗，也不知道國內有哪些使用者，不做評論。