Deploying in Multi-Primary or Single-Primary Mode
組複製可以在以下不同模式下運行：
single-primary 模式
multi-primary 模式
默認模式爲單主。不可能讓組的成員部署在不同的模式，例如一個配置在多主模式，而另一個在單主模式。要在模式之間切換，需要使用不同的配置並重新啓動組而不單個成員。無論部署模式如何，組複製不處理客戶端故障切換，它必須由應用程序本身，連接器或中間件框架（如代理或路由器）處理。
在多主模式下部署時，將檢查語句以確保它們與模式兼容。當在多主模式下部署組複製時，進行以下檢查：
1 如果事務在SERIALIZABLE隔離級別下執行，則在將其與組同步時，它的提交將失敗。
2 如果事務對具有級聯約束的外鍵執行，則事務在與組同步時無法提交。
可以通過將選項group_replication_enforce_update_everywhere_checks設置爲FALSE來禁用這些檢查。在單主機模式下部署時，此選項必須設置爲FALSE。
Single-PrimaryMode
在此模式下，組中只有一個一個主節點可設置爲讀寫模式。組中的所有其他成員被設置爲只讀模式（即，超級只讀，也就是超級賬戶也只能讀）。主服務器通常是用於引導組的第一個服務器，所有其他加入的服務器自動識別主服務器並設置爲只讀。
在單主模式下，將禁用在多主模式下部署的某些檢查，因爲系統會強制每次只有一個寫入程序服務器在組中。例如，允許對具有級聯外鍵的表進行更改，而在多主模式下不允許。在主成員故障時，自動領導者選擇機制選擇下一個主成員。通過服務器的UUID的字母順序進行排序，選擇列表中的第一個作爲新的主節點。
如果主節點從組中刪除，則會觸發選舉，並從組中的其餘服務器中選擇新的主節點。這個選擇通過查看新視圖，按照詞典順序排序服務器UUID並選擇第一個來執行。一旦選擇了新的主節點，它將自動設置爲只讀，其他輔助節點保留爲輔助節點，因此爲只讀。
在將客戶端應用程序重連到新主節點之前，等待新的主節點應用完相關中繼日誌是一個好習慣。
Multi-Primary Mode
在多主模式下，沒有單個主模式的概念。沒有必要參與選舉程序，因爲沒有服務器發揮任何特殊的作用。
加入組時，所有服務器都設置爲讀寫模式。
Finding the Primary
以下示例顯示了在單主機模式下部署時，如何確定當前哪個服務器是主服務器。
mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';
+--------------------------------------+
| VARIABLE_VALUE |
+--------------------------------------+
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
+--------------------------------------+
1 row in set (0,00 sec)
Tuning Recovery
每當新成員加入複製組時，它將連接到合適的提供者並提取它所錯過的數據，直到它被聲明爲在線。組複製中的這個關鍵組件是容錯和可配置的。以下部分說明恢復如何工作以及如何調整設置
複製源選擇
從羣組中的現有在線成員中隨機選擇一個作爲複製源。這樣，當多個成員進入組時，基本上可做到不會選擇同一個複製源。
如果到所選擇的複製源的連接失敗，則自動嘗試新的連接到新的候選複製源。一旦達到連接重試限制，恢復過程將終止並出現錯誤。
增強型複製源切換
完整的恢復的另一個主要關注點是確保它能夠應對故障。因此，組複製提供了強大的錯誤檢測機制。在早期版本的組複製中，當到達一個複製源時，恢復過程中只能檢測由於認證問題或一些其他問題的連接錯誤。對這種問題情況的反應是切換到新的複製源，因此對不同的成員進行了新的連接嘗試。
此行爲已擴展爲也涵蓋其他故障情形：
Purged data scenarios 如果所選擇的複製源包含恢復處理所需的一些被清除的數據，則發生錯誤。恢復檢測到此錯誤並選擇新的複製源。
Duplicated data 如果新加成員在恢復期間已經包含與來自選定複製源的數據衝突的某些數據，那麼會發生錯誤。這可能是因爲新加成員之前就有一些不當的事務執行引起的。
Other errors如果任何恢復線程失敗（接收或applier線程失敗），則會出現錯誤，恢復切換到新的複製源。
有些場景下，一些持續的錯誤或者甚至短暫的錯誤，恢復過程會自動重連到原來的複製源或者新的複製源
複製源重連
恢復數據傳輸依賴於二進制日誌和現有的MySQL複製框架，因此一些瞬態錯誤可能導致接收器或applier線程錯誤。在這種情況下，複製源切換過程具有重試功能，類似於常規復制中的retries功能。
重試次數
嘗試從複製源池連接到其中一個複製源時，joiner所嘗試的嘗試次數爲10.這通過group_replication_recovery_retry_count插件變量配置。以下命令將連接到複製源的最大嘗試次數設置爲10。
SET GLOBAL group_replication_recovery_retry_count= 10;
重連間隔
group_replication_recovery_reconnect_interval變量定義恢復進程在複製源連接嘗試之間應休眠多長時間。此變量的默認設置爲60秒，您可以動態更改此值。以下命令將恢復施主連接重試間隔設置爲120秒
SET GLOBAL group_replication_recovery_reconnect_interval= 120;
但請注意，恢復不會在每次複製源連接嘗試後sleep。在連接器連接到不同的服務器，而不是連續到同一個服務器的情況下，它會假設影響服務器A的問題可能不影響服務器B.因此，當它已經嘗試過所有可能的複製源後纔會sleep。一旦joiner嘗試連接到組中的所有合適的複製源，並且沒有剩餘，恢復過程將sleep，sleep時間是由group_replication_recovery_reconnect_interval變量配置的秒數。
Network Partitioning
當需要複製的變化發生時，組需要實現共識。這是常規事務的情況，但是對於組成員更改和保持組一致的某些內部消息傳遞也是必需的。共識需要大多數小組成員就給定的決定達成一致。當大多數組成員丟失時，組將無法運行並hang住，因爲它無法確保滿足大多數原則。
當有多個成員意外故障時，仲裁可能會失效，導致大多數服務器突然從組中刪除。例如，在一組5個服務器中，如果其中3個服務器突然沒有響應，則大多數服務器受影響，因此不能實現法定人數。事實上，剩下的兩個不能分辨其他3個服務器是否崩潰或網絡分區是否孤立這2個服務器，因此無法自動重新配置組。
另一方面，如果服務器自願退出組，則它們指示組應該重新配置自身。在實踐中，這意味着一個離開的服務器告訴別人它將要離開。這意味着其他成員可以正確地重新配置組，保持成員資格的一致性，並重新計算多數。例如，在5個服務器的上述情況中，3個一次離開，如果3個離開服務器警告組他們一個接一個地離開，則成員資格能夠將自身從5調整到2，並且在同一時間，在發生這種情況時確保法定人數。
Detecting Partitions
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 * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1 | 13002 | ONLINE |
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1 | 13003 | ONLINE |
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1 | 13004 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
但是，稍後有一個災難性的故障，服務器s3，s4和s5意外停止。幾秒鐘後，再次查看在s1的replication_group_members表顯示它仍然在線，但幾個其他成員不是。事實上，如下所示，它們被標記爲UNREACHABLE。此外，系統不能重新配置自身以改變成員資格，因爲大多數已經丟失。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1 | 13002 | UNREACHABLE |
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1 | 13003 | UNREACHABLE |
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1 | 13004 | UNREACHABLE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
該表顯示，s1現在處於沒有外部干預的情況下無法運行的組中，因爲大多數服務器不可訪問。在這種特殊情況下，組成員資格列表需要重置以允許系統繼續進行，這將在本節中解釋。或者，您也可以選擇停止s1和s2上的組複製（或完全停止s1和s2），找出s3，s4和s5發生的情況和丟失通信的原因，然後重新啓動組複製（或服務器）
Unblocking a Partition
組複製使您能夠通過強制執行特定配置來重置組成員資格列表。例如，在上面的情況中，其中s1和s2是唯一的在線服務器，您可以選擇強制包括僅s1和s2的成員資格配置。這需要檢查有關s1和s2的一些信息，然後使用group_replication_force_members變量。
假設你回到組s1和s2是組中唯一剩下的服務器的情況。服務器s3，s4和s5意外離開了組。要使服務器s1和s2繼續，您希望強制僅包含s1和s2的成員資格配置。
此過程使用group_replication_force_members並應被視爲最後手段補救措施。它必須非常小心地使用，並且僅用於覆蓋法定數量的損失。如果被濫用，它可能創建一個人爲裂腦情景或完全阻止整個系統。
回想一下，系統被阻塞，並且當前配置如下（由s1上的本地故障檢測器察覺到）：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1 | 13002 | UNREACHABLE |
| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE |
| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1 | 13003 | UNREACHABLE |
| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1 | 13004 | UNREACHABLE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
5 rows in set (0,00 sec)
首先要做的是檢查s1和s2的對等地址（組通信標識符）是什麼。登錄到s1和s2並獲取該信息，如下所示。
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10000 |
+-----------------------------------+
1 row in set (0,00 sec)
然後登錄到s2並做同樣的事操作
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| 127.0.0.1:10001 |
+-----------------------------------+
1 row in set (0,00 sec)
一旦知道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";
Query OK, 0 rows affected (7,13 sec)
這會通過強制使用不同的配置來撤銷組的阻塞情況。檢查s1和s2上的replication_group_members以驗證此更改後的組成員資格。首先在s1
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0,00 sec)
接着咋s2執行
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1 | 13000 | ONLINE |
| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1 | 13001 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0,00 sec)
當強制一個新的成員資格配置時，確保任何服務器將被強制從組中被確實停止。在上面描述的情形中，如果s3，s4和s5不是真正不可達的，而是在線，則它們可能已經形成了它們自己的功能分區（它們是5的3，因此它們具有多數）。在這種情況下，強制具有s1和s2的組成員列表可以創建人爲裂腦情況。因此，在強制新的成員資格配置之前，確保要排除的服務器確實關閉，並且如果不是，則在關閉之前關閉它們是很重要的。