本節列出和解釋了組複製相關的要求和限制。
要使用組複製，每個mysql節點必須滿足以下條件：
innodb儲存引擎：資料必須儲存在事務型的innodb儲存引擎中。事務以樂觀形式執行，然後在提交前會檢測衝突問題。如果有衝突，為了維護組中一致性，有些事務必須回滾。這意味著需要事務型的儲存引擎。此外，innodb 儲存引擎提供了一些額外的功能，它們結合組複製時能更好地管理和處理衝突。
primary keys：每張需要被組複製的表都必須顯式定義乙個主鍵。主鍵在判斷事務是否衝突扮演極其重要的角色：通過主鍵來準確識別每個事務中修改了表中的哪些行。(實際上是將主機hash成寫集，然後由certifier來併發事務之間的檢測衝突性)
良好的網路效能：組複製設計的初衷是部署在集群環境中，集群中的節點相互之間都非常近，因此除了網路延遲，網路頻寬也會影響組複製。
組中的每個成員都必須配置以下選項：
必須開啟二進位制日誌：設定--log-bin[=log_file_name]。mysql組複製會複製二進位制日誌的內容，因此必須開啟二進位制日誌。
row format的二進位制日誌：設定--binlog-format=row。組複製依賴於基於行格式的二進位制日誌，以便在組中傳播所發生的更改能保持一致性。而且，在探測組中不同節點間發生的併發事務是否衝突時，需要從行格式的日誌中提取一些內容來做比較。
開啟gtid複製：設定--gtid-mode=on。組複製使用gtid(全域性事務id)來精確跟蹤每個節點上已經提交了哪些事務。也因此可以推斷出某節點上要執行的事務是否和已執行的事務(每個節點上都有副本)衝突。換句話說，gtid是整個組複製判斷事務是否衝突的基礎。
transaction write set extraction：設定--transaction-write-setextraction=xxhash64，以便將行寫入到二進位制日誌中時，節點也收集寫集。寫集基於每行的主鍵，是唯一標識被更改行的標籤的簡化形式，該標籤後續會用於探測事務衝突性。
下面是使用組複製已知的限制：
replication event checksums：由於對複製事件校驗的設計缺陷，目前組複製不能使用它們。因此，需要設定--binlog-checksum=none。
gap locks：在驗證階段中(certification process)，不會考慮 gap locks，因此在 innodb 的外部無法獲取任何關於gap 鎖的資訊。
注意:除非你的應用程式或業務需求依賴於repeatable read(mysql預設該隔離級別)，否則建議在組複製中使用read committed隔離級別。在read committed隔離級別中，innodb基本上不會使用gap locks，這將使得innodb自帶的衝突探測能和組複製的衝突探測相互對齊從而保持一致。
table locks and named locks：驗證階段(certification process)中不考慮表鎖和命名鎖(見get_lock())。
不支援 serializable 隔離級別：在多主模型下，預設不支援該隔離級別。如果在多主模型下設定了該隔離級別，將拒絕提交事務。
不支援併發的 ddl 和 dml 操作：不支援在多主模型下不同節點上同時執行ddl和dml修改同一物件。在某節點上對某物件執行ddl語句時，如果在其他節點同時執行dml修改該物件，將有一定風險探測到衝突。(譯註：是 ddl+dml 的併發，ddl+ddl 的併發也不允許。這是因為mysql中沒有ddl事務，不能保證ddl的原子性，當ddl和dml同時操作某乙個物件，可能ddl修改後，dml將因為物件結構的改變而無法執行，繼而回滾)
不支援級聯的外來鍵約束：多主模型的組(所有節點都配置了group_replication_single_primary_mode=off)不支援多級外來鍵依賴，特別是表上定義了級聯的外來鍵約束(cascading foreign key constraints)。這是因為多主模型下執行外來鍵約束的級聯操作可能會出現未檢測到的衝突，從而導致組內成員間資料不一致。因此，我們推薦在使用多主模型時，在每個節點上都設定group_replication_enforce_update_everywhere_checks=on以避免出現未檢測到的衝突。在單主模型下沒有這種問題，因為沒有併發寫操作，從而不可能會出現未被探測到的衝突。
大事務可能會錯誤：如果乙個事務非常大，導致gtid的內容非常多，以至於無法在 5 秒內通過網路傳輸完成，這時組成員間的通訊將失敗。要避免該問題，可以盡可能地限制事務的大小。例如，將load data infile的檔案切割為多個小塊。
多主模型可能出現死鎖：在多主模型下，select ... for update語句可能會導致死鎖。這是因為組內成員之間不會共享鎖資源(譯註：share nothing)，因此這樣的語句可能達不到預期的結果。
監控MySQL組複製
使用 perfomance schema 中的表來監控組複製，假定你的mysql編譯時已經啟動了 performance schema 表。組複製將新增如下兩張 p s 表 下面這些已存在的 p s 複製表同樣也顯示一些組複製的資訊。組複製外掛程式建立的通道名稱為 下面一些小節中將描述這些表中可以獲...
監控MySQL組複製
強烈譴責大量盜文狗 波波說運維，說不定你們的文章也已被抄襲 使用 perfomance schema 中的表來監控組複製，假定你的mysql編譯時已經啟動了 performance schema 表。組複製將新增如下兩張 p s 表 下面這些已存在的 p s 複製表同樣也顯示一些組複製的資訊。組複製...
mysql非同步複製 半同步複製 組複製
sorce不管replica的死活，寫進binlog後，commit完成就算成功。如果最後乙個event沒有發給replica，主庫就掛了，那麼就會有丟失資料的風險。通過官方的半同步外掛程式，將binlog寫完後，傳送給replica，當replica寫入到relay log後，在主庫commit。...