組複製要求
數據必須存儲在InnoDB事務存儲引擎中。事務以樂觀方式執行，然後在提交時檢查衝突。如果存在衝突，爲了保持整個組的一致性，將回滾一些事務，因此需要事務存儲引擎。
此外，InnoDB還提供了一些附加功能，可以在與組複製一起操作時更好地管理和處理衝突。使用其它存儲引擎（包括臨時MEMORY存儲引擎）可能會導致組複製出錯。
可以通過在組成員上設置disabled_storage_engines系統變量來阻止使用其它存儲引擎，
例如：disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
組複製的每個表必須具有主鍵，或者具有等效的非空唯一鍵。
它們作爲表中每一行的唯一標識符是必需的，這使得系統能夠通過準確識別每個事務已修改的行來確定哪些事務存在衝突。
網絡性能會影響組的性能，網絡延遲和網絡帶寬都會影響組複製性能及穩定性。
因此組複製中的MySQL服務器實例應該部署在彼此非常接近的集羣環境中，使得所有組成員之間始終保持雙向通信。
如果阻止服務器實例的收發消息（例如通過防火牆限制），則該成員無法在組中運行，並且組成員（包括有問題的成員）可能無法報告受影響的服務器實例的正確成員狀態。
從MySQL 8.0.14開始，可以使用IPv4或IPv6網絡基礎結構，或兩者的混合，用於遠程組複製服務器之間的TCP通信。
設置--log-bin [= log_file_name] 激活二進制日誌，MySQL 8中缺省啓用此選項。
與其它MySQL複製方式一樣，組複製需要複製二進制日誌內容，因此需要打開二進制日誌才能運行。
設置--log-slave-updates 記錄從庫更新。服務器需要記錄通過複製應用程序應用的二進制日誌。組中的服務器需要記錄它們收到的所有事務並從組中應用。
這是必需的，因爲分佈式恢復依賴組中成員的二進制日誌進行。因此，每個事務的副本都需要存在於每個服務器上，即使對於那些未在服務器本身上啓動的事務也是如此。
MySQL 8中缺省啓用此選項。
設置--binlog-format = row 將二進制日誌設爲行格式。組複製依賴於基於行的複製格式，以在組成員之間一致地傳播更改。
它依賴於基於行的基礎結構來提取必要信息，以檢測在組中不同服務器併發執行的事務之間的衝突。
設置--binlog-checksum = NONE 關閉二進制日誌校驗。由於複製事件校驗和的設計限制，組複製無法使用它們，因此必須禁用。
設置--gtid-mode = ON 開啓全局事務標識符。
組複製使用全局事務標識符來準確跟蹤在每個服務器實例上已提交的事務，從而能夠推斷哪些服務器執行的事務可能與其它地方已提交的事務衝突。
設置--master-info-repository = TABLE和--relay-log-info-repository = TABLE，將複製信息資料庫存儲到表中。
複製應用程序需要將主庫信息和中繼日誌元數據寫入mysql.slave_master_info和mysql.slave_relay_log_info系統表。
這可確保組複製插件具有一致的可複製性和複製元數據的事務管理。從MySQL 8.0.2開始，這些選項缺省值爲TABLE，而從MySQL 8.0.3開始，不推薦使用FILE設置。
設置--transaction-write-set-extraction = XXHASH64，以便在以將數據行記錄到二進制日誌時，服務器也會收集寫入集。
寫入集基於每行的主鍵，唯一標識已更改的行，用於檢測事務衝突。MySQL 8中缺省啓用此選項。
推薦設置slave_parallel_workers爲大於零的值，啓用組成員上的多線程複製應用程序，最多可以指定1024個並行複製應用程序線程。
設置slave_preserve_commit_order = 1，確保並行事務的最終提交與原始事務的順序相同，這是組複製所需的，它依賴於所有組成員以相同順序接收和應用已提交事務，
以保證並行事務的數據一致性。slave_preserved_commit_order = 1需要設置slave_parallel_type = LOGICAL_CLOCK，
該策略指定用於決定允許哪些事務在從庫上並行執行的策略。設置slave_parallel_workers = 0會禁用並行複製，併爲從庫提供單個應用程序線程，而不是協調器線程。
使用該設置，slave_parallel_type和slave_preserve_commit_order選項無效並被忽略。
組複製限制
認證過程沒有考慮間隙鎖。除非應用程序中依賴REPEATABLE READ語義，否則MySQL建議將READ COMMITTED隔離級別與組複製一起使用。
InnoDB在READ COMMITTED中不使用間隙鎖，它將InnoDB中的本地衝突檢測與組複製執行的分佈式衝突檢測統一化。
認證過程不考慮表鎖（LOCK TABLES和UNLOCK TABLES）或命名鎖（GET_LOCK）。
複製不支持SERIALIZABLE隔離級別。將事務隔離級別設置爲SERIALIZABLE會將使組拒絕提交事務。
使用多主模式時，不支持針對同一對象但在不同服務器上執行的併發數據定義語句（DDL）和數據操作語句（DML）。
多主模式不支持具有多級外鍵依賴關係的表，特別是具有已定義CASCADING外鍵約束的表。
MySQL建議在多主模式組複製中設置group_replication_enforce_update_everywhere_checks = ON，以避免未檢測到的衝突。
當組複製以多主模式運行時，SELECT .. FOR UPDATE語句可能導致死鎖。
全局複製過濾器不能在爲組複製配置的MySQL服務器實例上使用。
如果單個事務太大，以至於在5秒鐘內無法通過網絡在組成員之間複製消息，則可能會懷疑成員失敗，然後被移出組。由於內存分配問題，大型事務也可能導致系統速度變慢。
要避免這些問題，使用以下緩解措施：
儘可能嘗試限制事務規模。例如，將與LOAD DATA一起使用的文件拆分爲較小的塊。
使用系統變量group_replication_transaction_size_limit指定組接收的最大事務大小。超過此大小的事務將回滾，不會發送到組。
在MySQL 8.0中，此係統變量缺省值爲150000000字節（大約143 MB）。
從MySQL 8.0.13開始，可以使用系統變量group_replication_member_expel_timeout來允許在懷疑失敗的成員在被移出之前有更多的時間。
可以在最初的5秒檢測期後最多延長一個小時。
從MySQL 8.0.16開始，大型消息會自動分段，這意味着大型消息不會觸發引發懷疑的5秒檢測週期，除非此時存在其它網絡問題。
爲了使複製組使用分段，所有組成員必須處於MySQL 8.0.16或更高版本，並且組使用的組複製通信協議版本必須允許分段。
如果MySQL版本不支持消息分段，可以使用系統變量group_replication_communication_max_message_size來調整最大消息大小，缺省值爲10485760字節（10 MB），或通過指定零值來關閉分段。
