一個群組最多可以包含 9 台伺服器。嘗試將另一台伺服器加入具有 9 個成員的群組會導致加入請求被拒絕。此限制已透過測試和基準測試識別為一個安全界限，在此界限內，群組在穩定的區域網路中可靠地執行。

群組中的伺服器會透過開啟對等 TCP 連線來連線至群組中的其他伺服器。這些連線僅用於群組中伺服器之間的內部通訊和訊息傳遞。此位址由 group_replication_local_address 變數設定。

啟動旗標指示成員建立群組並作為初始種子伺服器。加入群組的第二個成員需要要求啟動群組的成員動態變更設定，以便將其新增至群組。

在兩種情況下，成員需要啟動群組。當群組最初建立時，或當關閉並重新啟動整個群組時。

您可以使用 CHANGE REPLICATION SOURCE TO 語句，將使用者認證永久設定為 group_replication_recovery 通道的認證。您可以在每次啟動群組複製時，於 START GROUP_REPLICATION 語句中指定它們。

使用 CHANGE REPLICATION SOURCE TO 設定的使用者認證會以純文字儲存在伺服器上的複製中繼資料儲存庫中，但是 START GROUP_REPLICATION 上指定的使用者認證僅儲存在記憶體中，並且會透過 STOP GROUP_REPLICATION 語句或伺服器關閉移除。因此，使用 START GROUP_REPLICATION 指定使用者認證有助於保護群組複製伺服器免於未經授權的存取。然而，此方法與自動啟動群組複製不相容，如 group_replication_start_on_boot 系統變數所指定。如需詳細資訊，請參閱第 20.6.3.1 節，「分散式復原的安全使用者認證」。

無法直接使用，但 MySQL 群組複製是一種共享無任何資料的完整複製解決方案，群組中的所有伺服器都會複製相同數量的資料。因此，如果群組中的一個成員在交易提交操作後將 N 個位元組寫入儲存空間，則大致也會將 N 個位元組寫入其他成員的儲存空間，因為交易會複製到每個位置。

然而，鑑於其他成員不需要像原始成員最初執行交易時那樣執行相同數量的處理，它們可以更快地套用變更。交易會以一種格式複製，該格式僅用於套用資料列轉換，而無需再次重新執行交易 (以資料列為基礎的格式)。

此外，鑑於變更是以資料列為基礎的格式傳播和套用，這表示它們會以最佳化且精簡的格式接收，並且可能減少與原始成員相比所需的 IO 作業次數。

總而言之，您可以透過將無衝突的交易分散到群組中不同的成員來擴展處理能力。而且，您很可能可以擴展一小部分的 IO 操作，因為遠端伺服器只會接收到讀取-修改-寫入穩定儲存所需變更。

由於伺服器需要為了同步目的而不斷地彼此互動，因此預期會有額外的負載。很難量化到底需要多少額外的資料量。這也取決於群組的大小（三個伺服器的群組對於頻寬的需求，會比九個伺服器的群組來得小）。

此外，記憶體和 CPU 的佔用量也會比較大，因為伺服器同步部分和群組訊息傳遞需要執行更複雜的工作。

可以，但是每個成員之間的網路連線必須穩定且具有合適的效能。低延遲、高頻寬的網路連線是獲得最佳效能的要求。

如果只是網路頻寬的問題，那麼可以使用第 20.7.4 節「訊息壓縮」來降低所需的頻寬。但是，如果網路丟包，導致重傳和更高的端對端延遲，吞吐量和延遲都會受到負面影響。

這取決於連線問題的原因。如果連線問題是暫時的，並且重新連線速度夠快，故障偵測器沒有感知到，那麼伺服器可能不會從群組中移除。如果是「長時間」的連線問題，那麼故障偵測器最終會懷疑存在問題，並且伺服器將會從群組中移除。

有兩個設定可以提高成員保留在群組中或重新加入群組的機會

如果伺服器被群組驅逐，並且任何自動重新加入的嘗試都未成功，您需要將其重新加入。換句話說，在伺服器被明確地從群組中移除後，您需要手動重新加入（或者使用腳本自動執行此操作）。

如果成員變得靜默，其他成員會將其從群組配置中移除。實際上，當成員崩潰或發生網路斷線時可能會發生這種情況。

在給定成員的指定逾時時間到期後，會檢測到故障，並且會建立一個不包含靜默成員的新配置。

沒有方法可以定義何時自動從群組中驅逐成員的策略。您需要找出成員落後的原因並修復它，或者將該成員從群組中移除。否則，如果伺服器速度太慢而觸發了流量控制，那麼整個群組也會減速。可以根據您的需求配置流量控制。

否，群組中沒有任何特定的成員負責觸發重新配置。

任何成員都可能會懷疑存在問題。所有成員都需要（自動）同意某個成員已失敗。其中一個成員負責透過觸發重新配置來將其從群組中驅逐。哪個成員負責驅逐成員不是您可以控制或設定的。

群組複製的設計目的是提供高可用性的複本集；資料和寫入會在群組中的每個成員上複製。為了擴展到單一系統無法提供的能力之外，您需要一個圍繞許多群組複製集建立的協調和分片框架，其中每個複本集維護和管理您總資料集的給定分片或分割區。這種通常稱為「分片叢集」的設定，允許您線性且無限制地擴展讀寫能力。

如果已啟用 SELinux（您可以使用 sestatus -v 來驗證），那麼您需要啟用群組複製通訊埠的使用。請參閱設定群組複製的 TCP 連接埠內容。

如果啟用了 iptables，則您需要打開群組複製連接埠，以便在機器之間進行通訊。若要查看每部機器上的目前規則，請發出 iptables -L。假設配置的連接埠為 33061，請透過發出 iptables -A INPUT -p tcp --dport 33061 -j ACCEPT 來啟用必要的連接埠上的通訊。

群組複製使用的複製通道的行為方式，與非同步來源到複本複製中使用的複製通道相同，因此依賴於中繼日誌。如果 relay_log 變數發生變更，或者在未設定選項且主機名稱變更時，可能會發生錯誤。請參閱第 19.2.4.1 節「中繼日誌」，了解此情況下的復原程序。或者，在群組複製中解決此問題的另一種方法是發出 STOP GROUP_REPLICATION 陳述式，然後發出 START GROUP_REPLICATION 陳述式以重新啟動實例。群組複製外掛程式會再次建立 group_replication_applier 通道。

群組複製使用兩個繫結位址，以便將網路流量分散在 SQL 位址（由用戶端用於與成員通訊）和 group_replication_local_address（由群組成員在內部通訊時使用）之間。例如，假設伺服器有兩個網路介面，分別分配給網路位址 203.0.113.1 和 198.51.100.179。在這種情況下，您可以使用 203.0.113.1:33061 作為內部群組網路位址，方法是設定 group_replication_local_address=203.0.113.1:33061。然後，您可以使用 198.51.100.179 作為 hostname，並使用 3306 作為 port。然後，用戶端 SQL 應用程式將會連線到 198.51.100.179:3306 上的成員。這可讓您在不同的網路上配置不同的規則。同樣地，內部群組通訊可以與用於用戶端應用程式的網路連線分開，以提高安全性。

群組複製使用成員之間的網路連線，因此其功能會直接受到您如何配置主機名稱和連接埠的影響。例如，群組複製的分散式復原程序會使用伺服器的主機名稱和連接埠來建立與現有群組成員的連線。當成員加入群組時，它會收到群組成員資格資訊，使用 performance_schema.replication_group_members 中列出的網路位址資訊。該表格中列出的一個成員會被選為群組中遺失資料的捐贈者，提供給加入的成員。

這表示您使用主機名稱配置的任何值，例如 SQL 網路位址或群組種子位址，都必須是完整合格的名稱，並且可以由群組中的每個成員解析。您可以使用例如 DNS，或正確配置的 /etc/hosts 檔案，或其他本機程序來確保這一點。如果您想要在伺服器上配置 MEMBER_HOST 值，請在將伺服器加入群組之前，使用伺服器上的 --report-host 選項來指定它。

若要在伺服器上配置 MEMBER_PORT，請使用 report_port 系統變數指定它。

當在伺服器上啟動群組複製時，auto_increment_increment 的值會變更為 group_replication_auto_increment_increment 的值（預設為 7），而 auto_increment_offset 的值會變更為伺服器 ID。當群組複製停止時，這些變更會還原。這些設定可避免為群組成員上的寫入選取重複的自動遞增值，這會導致交易回滾。群組複製的預設自動遞增值 7 表示可用值的數量與允許的複寫群組最大大小（9 個成員）之間的平衡。

只有當 auto_increment_increment 和 auto_increment_offset 各自具有預設值（兩者均為 1）時，才會進行和還原變更。如果它們的值已從預設值修改，群組複製不會變更它們。當群組複製處於單一主要模式（只有一個伺服器寫入）時，系統變數也不會被修改。

如果群組在單一主要模式下運作，找出哪個成員是主要伺服器可能會很有用。請參閱第 20.1.3.1.2 節「尋找主要伺服器」