MySQL 8.4 版本注意事項
每當發生需要複寫的變更時，群組需要達成共識。一般交易是這種情況，但群組成員資格變更和保持群組一致性的一些內部訊息也需要這樣做。共識要求大多數群組成員同意給定的決策。當多數群組成員遺失時，群組將無法進展並封鎖，因為它無法確保多數或仲裁。
當發生多個非自願性失敗時，可能會遺失仲裁，導致大多數伺服器突然從群組中移除。例如，在 5 個伺服器的群組中，如果其中 3 個伺服器同時靜止，則多數會受到損害，因此無法達成仲裁。實際上，其餘兩個伺服器無法判斷另外 3 個伺服器是否已當機，或是網路分割是否已將這 2 個伺服器隔離，因此群組無法自動重新設定。
另一方面，如果伺服器自願退出群組，它們會指示群組應該重新設定本身。實際上，這表示即將離開的伺服器會告知其他伺服器它即將離開。這表示其他成員可以正確地重新設定群組，維護成員資格的一致性，並重新計算多數。例如，在上述 5 個伺服器的案例中，如果離開的 3 個伺服器逐一警告群組它們即將離開，則成員資格能夠從 5 個調整為 2 個，同時在發生這種情況時確保仲裁。
注意
仲裁遺失本身是不良規劃的副作用。請針對預期的失敗次數規劃群組大小 (無論它們是連續的、同時發生還是零星的)。
對於單主機模式的群組，在網路分割時，主機可能會有其他成員尚未存在的交易。如果您考慮將主機排除在新群組之外，請注意這些交易可能會遺失。具有額外交易的成員無法重新加入群組，並且嘗試會導致錯誤，訊息為 此成員的已執行交易多於群組中存在的交易。請設定群組成員的 group_replication_unreachable_majority_timeout 系統變數，以避免發生這種情況。
下列章節說明如果系統以群組中的伺服器無法自動達成仲裁的方式分割，該怎麼辦。
效能結構描述 replication_group_members 資料表會呈現此伺服器觀點中目前檢視中每個伺服器的狀態。大多數情況下，系統不會遇到分割，因此該資料表會顯示在群組中所有伺服器之間一致的資訊。換句話說，目前檢視中的所有人都同意此資料表上每個伺服器的狀態。但是，如果有網路分割，並且遺失仲裁，則該資料表會針對無法連線的伺服器顯示 UNREACHABLE 狀態。此資訊是由內建於群組複寫的本機失敗偵測器所匯出。
為了理解這種類型的網路分割，以下章節將描述一個情境，其中最初有 5 台伺服器正常協同運作，以及當只有 2 台伺服器在線上時，群組發生的變化。此情境如圖所示。
因此，假設有一個包含以下 5 台伺服器的群組：
伺服器 s1，其成員識別碼為
199b2df7-4aaf-11e6-bb16-28b2bd168d07伺服器 s2，其成員識別碼為
199bb88e-4aaf-11e6-babe-28b2bd168d07伺服器 s3，其成員識別碼為
1999b9fb-4aaf-11e6-bb54-28b2bd168d07伺服器 s4，其成員識別碼為
19ab72fc-4aaf-11e6-bb51-28b2bd168d07伺服器 s5，其成員識別碼為
19b33846-4aaf-11e6-ba81-28b2bd168d07
最初，群組運作良好，且伺服器之間愉快地互相通訊。您可以登入 s1 並查看其 replication_group_members 效能結構描述表格來驗證此情況。例如：
mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+-------------+
| MEMBER_ID | MEMBER_STATE | MEMBER_ROLE |
+--------------------------------------+--------------+-------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE | SECONDARY |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | PRIMARY |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | SECONDARY |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE | SECONDARY |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE | SECONDARY |
+--------------------------------------+--------------+-------------+然而，稍後發生災難性故障，伺服器 s3、s4 和 s5 意外停止。幾秒鐘後，再次查看 s1 上的 replication_group_members 表格，會發現它仍然在線上，但其他幾個成員不在線上。實際上，如下所示，它們被標記為 UNREACHABLE。此外，系統無法重新設定成員資格，因為多數成員已遺失。
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE |
+--------------------------------------+--------------+表格顯示，s1 現在位於一個在沒有外部干預的情況下無法進展的群組中，因為大多數伺服器都無法連線。在這種特殊情況下，需要重設群組成員清單，以允許系統繼續執行，這在本節中進行了解釋。或者，您也可以選擇停止 s1 和 s2 上的群組複製（或完全停止 s1 和 s2），找出 s3、s4 和 s5 發生了什麼問題，然後重新啟動群組複製（或伺服器）。
群組複製可讓您透過強制使用特定組態來重設群組成員清單。例如，在上述情況中，s1 和 s2 是唯一在線的伺服器，您可以選擇強制僅包含 s1 和 s2 的成員資格組態。這需要檢查關於 s1 和 s2 的一些資訊，然後使用 group_replication_force_members 變數。
假設您回到只有 s1 和 s2 伺服器留在群組中的情況。伺服器 s3、s4 和 s5 意外離開群組。為了讓伺服器 s1 和 s2 繼續運作，您想要強制使用僅包含 s1 和 s2 的成員資格組態。
警告
此程序使用 group_replication_force_members，應被視為最後的補救措施。它必須極其謹慎地使用，並且僅用於覆寫仲裁遺失的情況。如果濫用，可能會產生人為的腦裂情況，或完全封鎖整個系統。
在強制使用新的成員資格組態時，請確保任何將被強制退出群組的伺服器都已停止運作。在上述情境中，如果 s3、s4 和 s5 並非真的無法連線，而是在線上，它們可能已形成自己可運作的分割區（它們是 5 台中的 3 台，因此它們擁有大多數）。在這種情況下，強制使用包含 s1 和 s2 的群組成員清單可能會產生人為的腦裂情況。因此，在強制使用新的成員資格組態之前，請務必確認要排除的伺服器確實已關閉，如果沒有，請在繼續操作之前將它們關閉。
警告
對於單主機模式的群組，在網路分割時，主機可能會有其他成員尚未存在的交易。如果您考慮將主機排除在新群組之外，請注意這些交易可能會遺失。具有額外交易的成員無法重新加入群組，並且嘗試會導致錯誤，訊息為 此成員的已執行交易多於群組中存在的交易。請設定群組成員的 group_replication_unreachable_majority_timeout 系統變數，以避免發生這種情況。
請回想一下，系統已封鎖，且目前的組態如下（由 s1 上的本機故障偵測器感知）：
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE |
+--------------------------------------+--------------+首先要做的是檢查 s1 和 s2 的本機位址（群組通訊識別碼）。登入 s1 和 s2，並依照下列方式取得該資訊。
mysql> SELECT @@group_replication_local_address;一旦您知道 s1 (127.0.0.1:10000) 和 s2 (127.0.0.1:10001) 的群組通訊位址，您就可以在其中一台伺服器上使用它來注入新的成員資格組態，從而覆寫已失去仲裁的現有組態。在 s1 上執行此操作：
mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";這會強制使用不同的組態來解除群組的封鎖。在此變更後，檢查 s1 和 s2 上的 replication_group_members，以驗證群組成員資格。首先在 s1 上：
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE |
+--------------------------------------+--------------+然後在 s2 上：
mysql> SELECT * FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE |
+--------------------------------------+--------------+在使用 group_replication_force_members 系統變數成功強制使用新的群組成員資格並解除群組的封鎖之後，請務必清除該系統變數。group_replication_force_members 必須為空，才能發出 START GROUP_REPLICATION 陳述式。