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

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

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

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

您可以使用 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。如果 relay_log 變數發生變更，或者當選項未設定且主機名稱變更時，可能會發生錯誤。請參閱第 19.2.4.1 節，「relay log」，以了解在此情況下的復原程序。或者，在群組複製中專門修復此問題的另一種方法是發出 STOP GROUP_REPLICATION 陳述式，然後發出 START GROUP_REPLICATION 陳述式以重新啟動執行個體。群組複製外掛程式會再次建立 group_replication_applier 通道。

群組複製使用兩個繫結位址，以便將網路流量在 SQL 位址（用戶端用來與成員通訊）和 group_replication_local_address（群組成員在內部用來通訊）之間分開。例如，假設一個伺服器有兩個網路介面指派給網路位址 203.0.113.1 和 198.51.100.179。在這種情況下，您可以透過設定 group_replication_local_address=203.0.113.1:33061，將 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 節「尋找主要節點」。