以下是群組複寫的已知限制。請注意,為多主節點模式群組描述的限制和問題也可能在單主節點模式叢集於容錯移轉事件期間套用,而新選出的主節點會從舊主節點清除其應用程式佇列。
群組複寫建立在以 GTID 為基礎的複寫上,因此您也應該了解第 19.1.3.7 節,「使用 GTID 複寫的限制」。
--upgrade=MINIMAL
選項。 在使用 MINIMAL 選項 (--upgrade=MINIMAL
) 的 MySQL 伺服器升級後,無法啟動群組複寫,因為該選項不會升級複寫內部運作所依賴的系統表格。間隙鎖定。 群組複寫針對並行交易的認證程序不會將間隙鎖定納入考量,因為關於間隙鎖定的資訊在
InnoDB
之外不可用。如需詳細資訊,請參閱間隙鎖定。注意對於多主節點模式的群組,除非您在應用程式中依賴
REPEATABLE READ
語意,否則我們建議將READ COMMITTED
隔離層級與群組複寫搭配使用。InnoDB 不會在READ COMMITTED
中使用間隙鎖定,這會使 InnoDB 內的本機衝突偵測與群組複寫執行的分散式衝突偵測一致。對於單主節點模式的群組,只有主要節點會接受寫入,因此READ COMMITTED
隔離層級對於群組複寫並不重要。表格鎖定和具名鎖定。 認證程序不會將表格鎖定 (請參閱第 15.3.6 節,「LOCK TABLES 和 UNLOCK TABLES 語法」) 或具名鎖定 (請參閱
GET_LOCK()
) 納入考量。二進位記錄檔檢查總和。 MySQL 9.0 中的群組複寫支援檢查總和,因此群組成員可以使用預設設定
binlog_checksum=CRC32
。binlog_checksum
的設定不必對群組的所有成員都相同。當檢查總和可用時,群組複寫不會使用檢查總和來驗證
group_replication_applier
通道上的輸入事件,因為事件是從多個來源寫入該中繼記錄檔,並且是在實際寫入來源伺服器的二進位記錄檔之前寫入,也就是產生檢查總和的時間點。檢查總和會用於驗證group_replication_recovery
通道和群組成員上任何其他複寫通道上的事件完整性。SERIALIZABLE 隔離層級。 依預設,多主節點群組不支援
SERIALIZABLE
隔離層級。將交易隔離層級設定為SERIALIZABLE
會將群組複寫設定為拒絕認可交易。並行 DDL 與 DML 作業。 當使用多主節點模式時,不支援對同一物件執行並行資料定義語句和資料操作語句,但這些語句在不同的伺服器上執行。在對物件執行資料定義語言 (DDL) 語句期間,在同一物件上執行並行資料操作語言 (DML),但在不同的伺服器執行個體上執行,會有偵測不到在不同執行個體上執行的衝突 DDL 的風險。
使用連鎖限制的外來鍵。 多主模式群組(所有成員都設定為
group_replication_single_primary_mode=OFF
)不支援具有多層外來鍵相依性的資料表,特別是定義了CASCADING
外來鍵限制的資料表。這是因為由多主模式群組執行的連鎖操作所產生的外來鍵限制,可能會導致未偵測到的衝突,並導致群組成員之間資料不一致。因此,我們建議在多主模式群組中使用的伺服器實例上設定group_replication_enforce_update_everywhere_checks=ON
,以避免未偵測到的衝突。在單主模式中,這不是問題,因為它不允許同時寫入群組的多個成員,因此沒有未偵測到衝突的風險。
多主模式死鎖。 當群組在多主模式下運作時,
SELECT .. FOR UPDATE
陳述式可能會導致死鎖。這是因為鎖定在群組的成員之間不共享,因此可能無法達到此類陳述式的預期結果。複製篩選器。 全域複製篩選器不能在為群組複製配置的 MySQL 伺服器實例上使用,因為在某些伺服器上篩選交易會使群組無法就一致的狀態達成協議。通道特定的複製篩選器可用於未直接參與群組複製的複製通道上,例如,群組成員也充當群組外部來源的複本。它們不能用於
group_replication_applier
或group_replication_recovery
通道。加密連線。 如果 MySQL 是使用 OpenSSL 1.1.1 或更高版本編譯的,則它支援 TLSv1.3 協定。群組複製支援 TLSv1.3,它可以用於群組通訊連線和分散式復原連線。
group_replication_recovery_tls_version
和group_replication_recovery_tls_ciphersuites
可用於配置用戶端支援任何密碼套件的選擇,包括如果需要的話,僅支援非預設的密碼套件。請參閱 第 8.3.2 節,「加密連線 TLS 協定和密碼」。複製作業。 群組複製會起始並管理分散式復原的複製作業,但已設定為支援複製的群組成員也可能參與使用者手動起始的複製作業。如果複製作業涉及正在執行群組複製的群組成員,則您可以手動起始複製作業,前提是複製作業不會移除和替換接收者上的資料。因此,如果正在執行群組複製,則用於起始複製作業的陳述式必須包含
DATA DIRECTORY
子句。請參閱 第 20.5.4.2.4 節,「用於其他目的的複製」。
單一複製群組中可作為成員的 MySQL 伺服器最大數量為 9 個。如果其他成員嘗試加入群組,它們的請求將被拒絕。此限制已通過測試和基準測試確定,作為群組在穩定的區域網路上可靠執行的安全邊界。
如果個別交易導致訊息內容過大,以致無法在 5 秒的時間範圍內在群組成員之間通過網路複製訊息,則可能會懷疑成員發生故障,然後將其逐出,僅僅是因為它們正忙於處理交易。大型交易也可能因記憶體配置問題而導致系統速度變慢。為避免這些問題,請使用以下緩解措施
如果因訊息過大而發生不必要的逐出,請使用系統變數
group_replication_member_expel_timeout
,以在懷疑發生故障的成員被逐出之前允許額外時間。在初始 5 秒的偵測週期後,您最多可以允許一小時,然後才將可疑成員逐出群組。預設情況下,額外允許 5 秒。在可能的情況下,請盡量限制交易的大小,然後再由群組複製處理。例如,將與
LOAD DATA
一起使用的檔案分成較小的區塊。使用系統變數
group_replication_transaction_size_limit
來指定群組接受的最大交易大小。預設的最大交易大小為 150000000 位元組(約 143 MB);超出此大小的交易將回滾,並且不會傳送到群組複製的群組通訊系統 (GCS) 以分發到群組。根據您需要群組容忍的最大訊息大小來調整此變數的值,請記住,處理交易所需的時間與其大小成正比。使用系統變數
group_replication_compression_threshold
來指定應用壓縮的訊息大小上限。此系統變數預設為 1000000 位元組 (1 MB),因此會自動壓縮大型訊息。當群組複製的群組通訊系統 (GCS) 收到允許由group_replication_transaction_size_limit
設定的訊息,但超過group_replication_compression_threshold
設定時,會執行壓縮。如需詳細資訊,請參閱 第 20.7.4 節,「訊息壓縮」。使用系統變數
group_replication_communication_max_message_size
來指定訊息大小上限,超過該大小上限訊息會被分段。此系統變數預設為 10485760 位元組 (10 MiB),因此會自動分段大型訊息。如果壓縮訊息仍超過group_replication_communication_max_message_size
限制,則 GCS 會在壓縮後執行分段。如需詳細資訊,請參閱 第 20.7.5 節,「訊息分段」。
可以通過為相關系統變數指定零值來停用最大交易大小、訊息壓縮和訊息分段。如果您已停用所有這些安全措施,則複製群組成員上的應用程式執行緒可以處理的訊息大小上限是成員的 replica_max_allowed_packet
系統變數的值,其預設值和最大值為 1073741824 位元組 (1 GB)。當接收成員嘗試處理訊息時,超出此限制的訊息將失敗。群組成員可以起始並嘗試傳輸到群組的訊息大小上限為 4294967295 位元組(約 4 GB)。這是群組複製(XCom,Paxos 變體)的群組通訊引擎接受的封包大小的硬性限制,該引擎在 GCS 處理訊息後接收訊息。當起始成員嘗試廣播訊息時,超出此限制的訊息將失敗。