MySQL組復制的要求和限制

本篇內容主要講解“MySQL組復制的要求和限制”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL組復制的要求和限制”吧!

組復制的要求:

1).InnoDB存儲引擎：數據必須存儲在事務型的InnoDB存儲引擎中。事務以樂觀形式執行，然后在提交前會檢測沖突問題。如果有沖突，為了維護組中一致性，有些事務必須回滾。這意味著需要事務型的存儲引擎。此外，InnoDB 存儲引擎提供了一些額外的功能，它們結合組復制時能更好地管理和處理沖突。

2).Primary Keys：每張需要被組復制的表都必須顯式定義一個主鍵。主鍵在判斷事務是否沖突扮演極其重要的角色：通過主鍵來準確識別每個事務中修改了表中的哪些行。(實際上是將主機hash成寫集，然后由certifier來并發事務之間的檢測沖突性)

3).使用IPv4 地址：MySQL組復制使用的組通信引擎組件只支持 IPv4。因此，必須使用IPv4的網絡。

4).良好的網絡性能：組復制設計的初衷是部署在集群環境中，集群中的節點相互之間都非常近，因此除了網絡延遲，網絡帶寬也會影響組復制。

組復制的限制：

1).Replication Event Checksums：由于對復制事件校驗的設計缺陷，目前組復制不能使用它們。因此，需要設置--binlog-checksum=NONE。

2).Gap Locks：在驗證階段中(certification process)，不會考慮 Gap Locks，因此在 InnoDB 的外部無法獲取任何關于Gap 鎖的信息。

注意:除非你的應用程序或業務需求依賴于REPEATABLE READ(MySQL默認該隔離級別)，否則建議在組復制中使用READ COMMITTED隔離級別。在READ COMMITTED隔離級別中，InnoDB基本上不會使用Gap Locks，這將使得InnoDB自帶的沖突探測能和組復制的沖突探測相互對齊從而保持一致。

3).Table Locks and Named Locks：驗證階段(certification process)中不考慮表鎖和命名鎖(見get_lock())。

4).不支持 SERIALIZABLE 隔離級別：在多主模型下，默認不支持該隔離級別。如果在多主模型下設置了該隔離級別，將拒絕提交事務。

5).不支持并發的 DDL 和 DML 操作：不支持在多主模型下不同節點上同時執行DDL和DML修改同一對象。在某節點上對某對象執行DDL語句時，如果在其他節點同時執行DML修改該對象，將有一定風險探測到沖突。(譯注：是 DDL+DML 的并發，DDL+DDL 的并發也不允許。這是因為MySQL中沒有DDL事務，不能保證DDL的原子性，當DDL和DML同時操作某一個對象，可能DDL修改后，DML將因為對象結構的改變而無法執行，繼而回滾)

6).不支持級聯的外鍵約束：多主模型的組(所有節點都配置了group_replication_single_primary_mode=OFF)不支持多級外鍵依賴，特別是表上定義了級聯的外鍵約束(CASCADING foreign key constraints)。這是因為多主模型下執行外鍵約束的級聯操作可能會出現未檢測到的沖突，從而導致組內成員間數據不一致。因此，我們推薦在使用多主模型時，在每個節點上都設置group_replication_enforce_update_everywhere_checks=ON以避免出現未檢測到的沖突。在單主模型下沒有這種問題，因為沒有并發寫操作，從而不可能會出現未被探測到的沖突。

7).大事務可能會錯誤：如果一個事務非常大，導致GTID的內容非常多，以至于無法在 5 秒內通過網絡傳輸完成，這時組成員間的通信將失敗。要避免該問題，可以盡可能地限制事務的大小。例如，將LOAD DATA INFILE的文件切割為多個小塊。

8).多主模型可能出現死鎖：在多主模型下，SELECT ... FOR UPDATE語句可能會導致死鎖。這是因為組內成員之間不會共享鎖資源(譯注：share nothing)，因此這樣的語句可能達不到預期的結果。

到此，相信大家對“MySQL組復制的要求和限制”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！