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)，因此這樣的語句可能達不到預期的結果。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15498/viewspace-2218517/，如需轉載，請註明出處，否則將追究法律責任。