MySQL組復(fù)制的要求和限制

本篇內(nèi)容主要講解“MySQL組復(fù)制的要求和限制”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MySQL組復(fù)制的要求和限制”吧!

組復(fù)制的要求:

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

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

3).使用IPv4 地址：MySQL組復(fù)制使用的組通信引擎組件只支持 IPv4。因此，必須使用IPv4的網(wǎng)絡(luò)。

4).良好的網(wǎng)絡(luò)性能：組復(fù)制設(shè)計(jì)的初衷是部署在集群環(huán)境中，集群中的節(jié)點(diǎn)相互之間都非常近，因此除了網(wǎng)絡(luò)延遲，網(wǎng)絡(luò)帶寬也會影響組復(fù)制。

組復(fù)制的限制：

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

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

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

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

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

5).不支持并發(fā)的 DDL 和 DML 操作：不支持在多主模型下不同節(jié)點(diǎn)上同時(shí)執(zhí)行DDL和DML修改同一對象。在某節(jié)點(diǎn)上對某對象執(zhí)行DDL語句時(shí)，如果在其他節(jié)點(diǎn)同時(shí)執(zhí)行DML修改該對象，將有一定風(fēng)險(xiǎn)探測到?jīng)_突。(譯注：是 DDL+DML 的并發(fā)，DDL+DDL 的并發(fā)也不允許。這是因?yàn)镸ySQL中沒有DDL事務(wù)，不能保證DDL的原子性，當(dāng)DDL和DML同時(shí)操作某一個對象，可能DDL修改后，DML將因?yàn)閷ο蠼Y(jié)構(gòu)的改變而無法執(zhí)行，繼而回滾)

6).不支持級聯(lián)的外鍵約束：多主模型的組(所有節(jié)點(diǎn)都配置了group_replication_single_primary_mode=OFF)不支持多級外鍵依賴，特別是表上定義了級聯(lián)的外鍵約束(CASCADING foreign key constraints)。這是因?yàn)槎嘀髂Ｐ拖聢?zhí)行外鍵約束的級聯(lián)操作可能會出現(xiàn)未檢測到的沖突，從而導(dǎo)致組內(nèi)成員間數(shù)據(jù)不一致。因此，我們推薦在使用多主模型時(shí)，在每個節(jié)點(diǎn)上都設(shè)置group_replication_enforce_update_everywhere_checks=ON以避免出現(xiàn)未檢測到的沖突。在單主模型下沒有這種問題，因?yàn)闆]有并發(fā)寫操作，從而不可能會出現(xiàn)未被探測到的沖突。

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

8).多主模型可能出現(xiàn)死鎖：在多主模型下，SELECT ... FOR UPDATE語句可能會導(dǎo)致死鎖。這是因?yàn)榻M內(nèi)成員之間不會共享鎖資源(譯注：share nothing)，因此這樣的語句可能達(dá)不到預(yù)期的結(jié)果。

到此，相信大家對“MySQL組復(fù)制的要求和限制”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！