在 MySQL 群組複製中，一組伺服器會形成一個複製群組。群組有一個名稱，形式為 UUID。群組是動態的，伺服器可以隨時離開（自願或非自願）和加入。每當伺服器加入或離開時，群組都會自行調整。

如果伺服器加入群組，它會自動從現有的伺服器提取遺失的狀態，使其本身保持最新狀態。如果伺服器離開群組，例如因為維護而關閉，其餘伺服器會注意到它已離開並自動重新設定群組。

群組複製有一個群組成員服務，可定義哪些伺服器在線上並參與群組。線上伺服器的清單稱為檢視。群組中的每個伺服器都有一個一致的檢視，知道在給定時間點哪些伺服器是積極參與群組的成員。

群組成員不僅必須同意交易提交，還必須同意目前的檢視。如果現有成員同意新的伺服器應成為群組的一部分，則會重新設定群組以將該伺服器整合進去，這會觸發檢視變更。如果伺服器自願或非自願地離開群組，則群組會動態重新排列其設定並觸發檢視變更。

在成員自願離開群組的情況下，它會先啟動動態群組重新設定，在此期間，所有成員都必須在沒有離開伺服器的情況下同意新的檢視。但是，如果成員非自願地離開群組，例如因為它意外停止或網路連線中斷，則它無法啟動重新設定。在這種情況下，群組複製的失敗偵測機制會在短時間後識別出成員已離開，並提出重新設定群組而不包括失敗成員的建議。與自願離開的成員一樣，重新設定需要群組中大多數伺服器的同意。但是，如果群組無法達成協議，例如因為它分割成沒有多數伺服器在線上的方式，則系統無法動態變更設定，並且會封鎖以防止腦裂情況。這種情況需要管理員介入。

成員有可能短暫離線，然後在失敗偵測機制偵測到其失敗之前，以及群組重新設定以移除該成員之前，嘗試再次重新加入群組。在這種情況下，重新加入的成員會忘記其先前的狀態，但如果其他成員向其傳送預定給其崩潰前狀態的訊息，則可能會導致問題，包括可能出現的資料不一致。如果處於這種情況的成員參與 XCom 的共識協定，則它可能會因為在失敗前後做出不同的決策，而可能導致 XCom 為同一共識回合傳遞不同的值。

為了應對這種可能性，MySQL Group Replication 會檢查是否出現同一個伺服器的新實例嘗試加入群組，而其舊實例（具有相同的位址和連接埠號碼）仍被列為成員的情況。新實例將被阻止加入群組，直到舊實例通過重新配置被移除為止。請注意，如果已通過 group_replication_member_expel_timeout 系統變數添加了等待時間，以便允許成員在被驅逐之前有額外的時間重新連線到群組，則受懷疑的成員如果在其懷疑超時之前重新連線到群組，則可以作為其當前實例在群組中再次啟用。當成員超出驅逐超時時間並被從群組中驅逐，或者當伺服器上的 Group Replication 被 STOP GROUP_REPLICATION 語句停止或發生伺服器故障時，它必須以新實例的身分重新加入。