群組複製是一種可用於實作容錯系統的技術。複製群組是一組伺服器，每個伺服器都有自己的完整資料副本（一種不共享任何資源的複製配置），並透過訊息傳遞相互互動。通訊層提供一組保證，例如原子訊息和總順序訊息傳遞。這些是非常強大的屬性，可以轉換為非常有用的抽象概念，您可以利用這些抽象概念來建立更進階的資料庫複製解決方案。

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

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

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

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

下圖描繪了 MySQL 群組複製協定，透過將其與 MySQL 複製（甚至是 MySQL 半同步複製）進行比較，您可以看到一些差異。為了清楚起見，此圖中遺失了一些基礎共識和 Paxos 相關訊息。

圖 20.3 MySQL 群組複製協定