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 群組複製設計為部署在伺服器執行個體彼此非常接近的叢集環境中。群組的效能與穩定性可能會受到網路延遲和網路頻寬的影響。所有群組成員之間必須隨時保持雙向通訊。如果伺服器執行個體的輸入或輸出通訊受阻 (例如，因為防火牆或連線問題)，成員便無法在群組中運作，而群組成員 (包括發生問題的成員) 可能無法針對受影響的伺服器執行個體回報正確的成員狀態。

您可以使用以 IPv4、IPv6 或兩者混合為基礎的網路基礎結構，在遠端群組複製伺服器之間進行 TCP 通訊。群組複製在虛擬私人網路 (VPN) 上運作也沒有任何限制。

如果群組複製伺服器執行個體並置並共用本機群組通訊引擎 (XCom) 執行個體，則在可能的情況下，會使用具較低額外負荷的專用輸入通道進行通訊，而不是 TCP 通訊端。對於需要遠端 XCom 執行個體之間通訊的某些群組複製工作，例如加入群組，仍然會使用 TCP 網路，因此網路效能會影響群組的效能。

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

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

記錄副本更新。 如果尚未啟用，請設定 log_replica_updates=ON。（在 MySQL 8.4 中，這是預設值。）群組成員需要記錄從捐贈者接收的交易，這些交易在加入時通過複製應用程式應用，並記錄從群組接收和應用的所有交易。這使得群組複製可以通過從現有群組成員的二進制日誌進行狀態傳輸來執行分散式恢復。

二進制日誌行格式。 如有必要，請設定 binlog_format=ROW；在 MySQL 8.4 中，這是預設值。群組複製依賴基於行的複製格式，以便在群組中的伺服器之間一致地傳播變更，並提取必要的資訊來偵測在群組中不同伺服器中並行執行的交易之間的衝突。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 設定為相同的值。設定為 1 對於使用 InnoDB 儲存引擎是正確的，這是群組複製的要求。請注意，此設定並非所有平台上的預設值。

多執行緒應用程式。 群組複製成員可以配置為多執行緒副本，允許並行應用交易。預設情況下，所有副本都配置為多執行緒。 replica_parallel_workers 的非零值會在成員上啟用多執行緒應用程式。預設值為 4 個並行應用程式執行緒；最多可以指定 1024 個並行應用程式執行緒。

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

分離的 XA 交易。 MySQL 8.4 及更高版本支援分離的 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 交易狀態」。