InnoDB 儲存引擎。  資料必須儲存在 InnoDB 交易式儲存引擎中。交易會以樂觀方式執行，然後在認可時檢查是否有衝突。如果有衝突，為了維持整個群組的一致性，會回溯某些交易。這表示需要交易式儲存引擎。此外，InnoDB 提供一些額外功能，可在與群組複製一起運作時，更好地管理和處理衝突。使用其他儲存引擎，包括暫時性的 MEMORY 儲存引擎，可能會在群組複製中造成錯誤。在使用執行個體搭配群組複製之前，請先將其他儲存引擎中的任何資料表轉換為使用 InnoDB。您可以藉由在群組成員上設定 disabled_storage_engines 系統變數，例如，來防止使用其他儲存引擎

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

主索引鍵。  群組要複製的每個資料表都必須有定義的主索引鍵，或主索引鍵等效值，其中等效值為非 Null 的唯一索引鍵。此類索引鍵是資料表中每一列的唯一識別碼，讓系統能夠透過識別每個交易已修改的確切資料列，來判斷哪些交易會衝突。群組複製有其內建的一組主索引鍵或主索引鍵等效值的檢查，並且不使用 sql_require_primary_key 系統變數所執行的檢查。您可以為執行群組複製的伺服器執行個體設定 sql_require_primary_key=ON，並且您可以將 CHANGE REPLICATION SOURCE TO 陳述式的 REQUIRE_TABLE_PRIMARY_KEY_CHECK 選項設為 ON ，以用於群組複製通道。但是，請注意，您可能會發現某些在群組複製的內建檢查下允許的交易，在您設定 sql_require_primary_key=ON 或 REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON 時所執行的檢查下不允許。

網路效能。  MySQL 群組複製的設計是在伺服器執行個體彼此非常靠近的叢集環境中部署。群組的效能和穩定性可能會受到網路延遲和網路頻寬的影響。必須在所有群組成員之間隨時維持雙向通訊。如果伺服器執行個體的傳入或傳出通訊遭到封鎖 (例如，透過防火牆或連線問題)，則成員無法在群組中運作，且群組成員 (包括有問題的成員) 可能無法回報受影響伺服器執行個體的正確成員狀態。

您可以針對遠端群組複製伺服器之間的 TCP 通訊，使用以 IPv4、IPv6 或兩者組合為基礎的網路基礎架構。也沒有任何因素會阻止群組複製透過虛擬私人網路 (VPN) 運作。

當群組複製伺服器執行個體共置且共用本機群組通訊引擎 (XCom) 執行個體時，會盡可能使用具有較低額外負荷的專用輸入通道進行通訊，而不是使用 TCP 通訊端。針對需要遠端 XCom 執行個體之間通訊的特定群組複製工作，例如加入群組，仍會使用 TCP 網路，因此網路效能會影響群組的效能。

唯一伺服器識別碼。 使用 server_id 系統變數來設定伺服器，使其具有唯一的伺服器 ID，這是複寫拓撲中所有伺服器所必需的。伺服器 ID 必須是介於 1 和 (2³²)−1 之間的正整數，並且必須與複寫拓撲中任何其他伺服器使用的其他伺服器 ID 不同。

啟用二進位日誌。 在 MySQL 9.0 中，預設會啟用二進位日誌。您可以選擇性地使用 --log-bin[=log_file_name] 指定二進位日誌檔案的名稱。群組複寫會複寫二進位日誌的內容，因此必須啟用二進位日誌才能運作。請參閱第 7.4.4 節「二進位日誌」。

記錄複本更新。 如果尚未啟用，請設定 log_replica_updates=ON。（在 MySQL 9.0 中，這是預設設定。）群組成員需要記錄從加入時的捐贈者接收並透過複寫應用程式套用的交易，以及記錄從群組接收和套用的所有交易。這使群組複寫能夠透過從現有群組成員的二進位日誌進行狀態傳輸來執行分散式復原。

二進位日誌列格式。 如有必要，請設定 binlog_format=ROW；在 MySQL 9.0 中，這是預設設定。群組複寫依賴於基於列的複寫格式，以在群組中的伺服器之間一致地傳播變更，並提取必要的資訊以偵測在群組中不同伺服器上同時執行的交易之間的衝突。REQUIRE_ROW_FORMAT 的設定會自動新增至群組複寫的通道，以強制在套用交易時使用基於列的複寫。請參閱第 19.2.1 節「複寫格式」和第 19.3.3 節「複寫權限檢查」。

啟用全域交易識別碼。 設定 gtid_mode=ON 和 enforce_gtid_consistency=ON。這些設定不是預設值。群組複寫需要基於 GTID 的複寫，它使用全域交易識別碼來追蹤在群組中每個伺服器執行個體上已提交的交易。請參閱第 19.1.3 節「使用全域交易識別碼進行複寫」。

預設資料表加密。 在所有群組成員上將 default_table_encryption 設定為相同的值。只要所有成員上的設定相同，預設綱要和資料表空間加密可以啟用 (ON) 或停用 (OFF，預設值)。

小寫資料表名稱。 在所有群組成員上將 lower_case_table_names 設定為相同的值。使用 InnoDB 儲存引擎（群組複寫需要此引擎）時，設定為 1 是正確的。請注意，此設定並非在所有平台上都是預設值。

多執行緒應用程式。 可以將群組複寫成員設定為多執行緒複本，從而可以並行套用交易。預設情況下，所有複本都設定為多執行緒。為 replica_parallel_workers 設定非零值即可在成員上啟用多執行緒應用程式。預設值為 4 個並行應用程式執行緒；最多可以指定 1024 個並行應用程式執行緒。

設定 replica_parallel_workers=0 會停用並行執行，並為複本提供單一應用程式執行緒，且沒有協調器執行緒。使用該設定時，replica_parallel_type 和 replica_preserve_commit_order 選項將不起作用，且會被忽略。如果在複本上使用 GTID 時停用並行執行，則複本實際上會使用一個並行工作執行緒，以便利用無需存取檔案位置即可重試交易的方法。但是，此行為不會對使用者產生任何改變。

分離的 XA 交易。 MySQL 9.0 和更新版本支援分離的 XA 交易。分離的交易是指一旦準備好就不再與目前工作階段連線的交易。當執行 XA PREPARE 時，就會自動發生這種情況。準備好的 XA 交易可以由另一個連線提交或復原，而目前工作階段然後可以啟動另一個 XA 交易或本機交易，而無需等待剛準備好的交易完成。

當啟用分離的 XA 交易支援 (xa_detach_on_prepare = ON) 時，任何連線到此伺服器都可以列出 (使用 XA RECOVER)、復原或提交任何準備好的 XA 交易。此外，您無法在分離的 XA 交易中使用暫存資料表。

您可以將 xa_detach_on_prepare 設定為 OFF，來停用對分離的 XA 交易的支援，但不建議這樣做。特別是，如果將此伺服器設定為 MySQL 群組複寫中的執行個體，則應將此變數設定為其預設值 (ON)。

如需更多資訊，請參閱第 15.3.8.2 節「XA 交易狀態」。