群組複寫是一種可以用來實作容錯系統的技術。複寫群組是一組伺服器，每個伺服器都有自己的完整資料副本 (一種無共用複寫方案)，並且透過訊息傳遞彼此互動。通訊層提供一組保證，例如原子訊息和全序訊息傳遞。這些都是非常強大的屬性，可以轉化為非常有用的抽象概念，可以依靠這些抽象概念來建構更進階的資料庫複寫解決方案。

MySQL 群組複寫建立在這些屬性和抽象概念之上，並實作多來源更新到處複寫協定。複寫群組由多個伺服器組成，群組中的每個伺服器都可以在任何時候獨立執行交易。但是，所有讀寫交易都必須在群組批准後才會提交。換句話說，對於任何讀寫交易，群組都需要決定是否提交，因此提交作業並非來自原始伺服器的單方面決定。唯讀交易不需要群組內的協調，並立即提交。

當讀寫交易準備好在原始伺服器提交時，伺服器會以原子方式廣播寫入值 (已變更的列) 和對應的寫入集 (已更新的列的唯一識別碼)。因為交易是透過原子廣播傳送的，所以群組中的所有伺服器都會收到交易，或所有伺服器都沒收到。如果它們收到交易，則它們都會以相同的順序接收交易，相對於之前傳送的其他交易。因此，所有伺服器都以相同的順序接收相同的交易集，並為交易建立全域總順序。

但是，在不同伺服器上同時執行的交易之間可能存在衝突。透過檢查和比較兩個不同且同時發生的交易的寫入集來偵測此類衝突，此過程稱為 驗證。在驗證期間，會在列級別執行衝突偵測：如果兩個同時發生的交易 (在不同的伺服器上執行) 更新相同的列，則存在衝突。衝突解決程序指出，首先排序的交易會在所有伺服器上提交，而第二個排序的交易會中止，因此會在原始伺服器上回溯，並被群組中的其他伺服器捨棄。例如，如果 t1 和 t2 同時在不同的站點執行，兩者都變更相同的列，且 t2 排在 t1 之前，則 t2 會贏得衝突，而 t1 會回溯。這實際上是分散式先提交優先規則。請注意，如果兩個交易的衝突頻率高於不高，則最好在同一個伺服器上啟動它們，它們有機會在本地鎖定管理員上同步，而不是因驗證而被回溯。

為了套用和外部化已驗證的交易，如果不會破壞一致性和有效性，群組複寫允許伺服器偏離同意的交易順序。群組複寫是一個最終一致性系統，這表示一旦傳入流量減慢或停止，所有群組成員都具有相同的資料內容。當流量正在流動時，交易可以以稍微不同的順序外部化，或者在某些成員上比其他成員更早外部化。例如，在多主機模式中，本地交易可能會在驗證後立即外部化，即使全域順序較早的遠端交易尚未套用。當驗證程序已確定交易之間沒有衝突時，這是允許的。在單主機模式中，在主要伺服器上，同時發生的非衝突本地交易有可能以不同於群組複寫同意的全域順序提交和外部化。在不接受用戶端寫入的次要伺服器上，交易始終以同意的順序提交和外部化。

下圖描述了 MySQL 群組複寫協定，並且將其與 MySQL 複寫 (甚至是 MySQL 半同步複寫) 進行比較，您可以看到一些差異。為了清楚起見，此圖中遺失了一些底層共識和 Paxos 相關訊息。

圖 20.3 MySQL 群組複寫協定