01 組復(fù)制要求

基礎(chǔ)配置：

• InnoDB存儲(chǔ)引擎：

數(shù)據(jù)必須存儲(chǔ)在InnoDB事務(wù)存儲(chǔ)引擎中。采用樂觀鎖的方式來執(zhí)行事務(wù)，然后在事務(wù)提交時(shí)檢查是否存在沖突泣崩。如果存在沖突，為了保持整個(gè)集群的數(shù)據(jù)一致性洛口，將回滾一些事務(wù)矫付。(存在沖突的事務(wù)中，先提交的事務(wù)不會(huì)受到影響第焰，繼續(xù)完成提交买优，而后提交的事務(wù)會(huì)被回滾)這需要事務(wù)存儲(chǔ)引擎。此外挺举，InnoDB提供了一些附加功能杀赢，可以在與組復(fù)制一起操作時(shí)更好地管理和處理沖突的事務(wù)。使用其他存儲(chǔ)引擎(包括臨時(shí)的MEMORY存儲(chǔ)引擎)湘纵，由于缺乏對(duì)某些事務(wù)層面特性的支持脂崔，可能會(huì)導(dǎo)致組復(fù)制中的錯(cuò)誤∥嗯纾可以通過在組成員上設(shè)置disabled_storage_engines系統(tǒng)變量來禁用其他存儲(chǔ)引擎砌左，例如：

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

• 主鍵：
  該集群要復(fù)制的每個(gè)表都必須具有定義的主鍵，或等效的主鍵铺敌，其中等效主鍵是非null的唯一鍵汇歹。此類鍵是作為表中每一行數(shù)據(jù)的唯一標(biāo)識(shí)符，從而使系統(tǒng)能夠通過該唯一標(biāo)識(shí)符準(zhǔn)確標(biāo)識(shí)每個(gè)事務(wù)已修改的行來確定哪些事務(wù)發(fā)生沖突适刀。組復(fù)制具有自己的內(nèi)置的主鍵或主鍵等效項(xiàng)檢查集秤朗，并且不使用sql_require_primary_key系統(tǒng)變量執(zhí)行的檢查。
  可以將運(yùn)行組復(fù)制實(shí)例的sql_require_primary_key = ON設(shè)置為ON笔喉，并且可以將組復(fù)制通道的CHANGE MASTER TO語句的REQUIRE_TABLE_PRIMARY_KEY_CHECK選項(xiàng)設(shè)置為ON取视。但當(dāng)設(shè)置sql_require_primary_key = ON或REQUIRE_TABLE_PRIMARY_KEY_CHECK = ON時(shí)硝皂，在執(zhí)行的檢查下可 能會(huì)不允許某些組復(fù)制的內(nèi)置檢查所允許的事務(wù)。

• 網(wǎng)絡(luò)性能：
  MySQL組復(fù)制要求部署在實(shí)例彼此非常接近的集群環(huán)境中作谭。集群的性能和穩(wěn)定性可能會(huì)受到網(wǎng)絡(luò)延遲和網(wǎng)絡(luò)帶寬的影響稽物。所有組成員之間必須始終保持雙向通信。如果針對(duì)實(shí)例阻止了入站或出站通信(例如折欠，通過防火墻或由于連接問題)贝或，則該節(jié)點(diǎn)無法在該集群中運(yùn)行，并且該組成員(包括有問題的節(jié)點(diǎn))可能無法報(bào)告受影響實(shí)例的正確狀態(tài)锐秦。
  從MySQL 8.0.14開始咪奖，可以使用IPv4或IPv6網(wǎng)絡(luò)基礎(chǔ)結(jié)構(gòu)或兩者的結(jié)合來進(jìn)行遠(yuǎn)程組復(fù)制服務(wù)器之間的TCP通信。
  同樣從MySQL 8.0.14(組復(fù)制實(shí)例位于同一位置并共享本地組通信引擎(XCom)實(shí)例)開始酱床，在可能的情況下羊赵，使用開銷較小的專用輸入通道代替TCP套接字進(jìn)行通信。對(duì)于某些需要在遠(yuǎn)程XCom實(shí)例之間進(jìn)行通信的組復(fù)制任務(wù)(例如加入組)扇谣，仍然使用TCP網(wǎng)絡(luò)昧捷，因此網(wǎng)絡(luò)性能會(huì)影響集群的性能。

• MySQL server配置：
  必須按照作為組成員的服實(shí)例上所示配置以下變量：
  server唯一標(biāo)識(shí)符：根據(jù)復(fù)制拓?fù)渲兴袑?shí)例的要求罐寨，使用server_id系統(tǒng)變量為實(shí)例配置唯一server ID靡挥。server ID必須是介于1和(232)-1之間的正整數(shù)，并且必須與復(fù)制拓?fù)渲械娜魏纹渌麑?shí)例使用的每 個(gè)其他server ID不同鸯绿。

• binlog日志
  二進(jìn)制日志處于開啟狀態(tài)：設(shè)置--log-bin [= log_file_name]跋破。MySQL Group Replication復(fù)制二進(jìn)制日 志內(nèi)容，因此二進(jìn)制日志需要打開才能運(yùn)行楞慈。默認(rèn)情況下啟用此選項(xiàng)幔烛。

備庫的所有更新都要記錄到其binlog中：設(shè)置--log-slave-updates。默認(rèn)情況下啟用此選項(xiàng)囊蓝。組成員需 要記錄加入時(shí)從其引導(dǎo)節(jié)點(diǎn)收到并通過復(fù)制應(yīng)用程序應(yīng)用的事務(wù)饿悬，記錄他們從集群中接收并應(yīng)用的所有 事務(wù)。這樣聚霜，組復(fù)制就可以通過從現(xiàn)有組成員的二進(jìn)制日志進(jìn)行狀態(tài)轉(zhuǎn)移來執(zhí)行分布式恢復(fù)狡恬。

二進(jìn)制日志行格式：設(shè)置--binlog-format = row。組復(fù)制依靠基于行的復(fù)制格式在集群中的實(shí)例之間一 致地傳播更改蝎宇。它依靠基于行的基礎(chǔ)結(jié)構(gòu)來提取必要的信息弟劲，以檢測(cè)在集群中的不同實(shí)例中同時(shí)執(zhí)行的 事務(wù)之間的沖突。從MySQL 8.0.19起姥芥，將REQUIRE_ROW_FORMAT設(shè)置自動(dòng)添加到組復(fù)制的通道中兔乞， 以在應(yīng)用事務(wù)時(shí)強(qiáng)制使用基于行的復(fù)制。

關(guān)閉二進(jìn)制日志checksum校驗(yàn)：(適用于MySQL 8.0.20)。直到MySQL 8.0.20庸追，設(shè)置--binlog- checksum = NONE霍骄。在這些發(fā)行版中，組復(fù)制無法使用校驗(yàn)和淡溯，并且不支持二進(jìn)制日志中的校驗(yàn)和读整。從MySQL 8.0.21開始，組復(fù)制支持校驗(yàn)和咱娶，因此組成員可以使用默認(rèn)設(shè)置米间。

打開gtid復(fù)制：設(shè)置gtid_mode = ON，然后設(shè)置force_gtid_consistency = ON膘侮。組復(fù)制使用全局事務(wù)標(biāo)識(shí)符來準(zhǔn)確跟蹤每個(gè)實(shí)例上已提交哪些事務(wù)屈糊，從而能夠推斷出哪些服務(wù)器已執(zhí)行可能與其他位置已提交的事務(wù)發(fā)生沖突的事務(wù)。

復(fù)制信息存儲(chǔ)到表中：設(shè)置master_info_repository = TABLE和relay_log_info_repository = TABLE喻喳。復(fù) 制應(yīng)用程序需要將復(fù)制元數(shù)據(jù)寫入mysql.slave_master_info和mysql.slave_relay_log_info系統(tǒng)表另玖。這樣可以確保組復(fù)制插件對(duì)復(fù)制元數(shù)據(jù)具有一致的可恢復(fù)性和事務(wù)管理。從MySQL 8.0.2開始表伦，這些選項(xiàng)默 認(rèn)設(shè)置為TABLE，而從MySQL 8.0.3開始慷丽，不推薦使用FILE設(shè)置蹦哼。

事務(wù)寫集提取：設(shè)置--transaction-write-set-extraction = XXHASH64要糊，以便在收集行以將其記錄到二進(jìn)制日志時(shí)纲熏，服務(wù)器也將收集寫集。寫集基于每行的主鍵锄俄，并且是標(biāo)簽的簡(jiǎn)化且緊湊的視圖局劲，該標(biāo)簽唯一地標(biāo)識(shí)已更改的行。然后奶赠，該標(biāo)簽用于檢測(cè)沖突鱼填。默認(rèn)情況下啟用此選項(xiàng)。

二進(jìn)制日志依賴跟蹤：設(shè)置binlog_transaction_dependency_tracking = WRITESET_SESSION可以提高 組成員的性能毅戈，具體取決于集群的負(fù)載苹丸。在應(yīng)用中繼日志中的事務(wù)時(shí)，組復(fù)制會(huì)在認(rèn)證后執(zhí)行自己的并行化苇经，而與binlog_transaction_dependency_tracking設(shè)置的值無關(guān)赘理。但是，binlog_transaction_dependency_tracking的值的確會(huì)影響如何將事務(wù)寫入組復(fù)制節(jié)點(diǎn)上的二進(jìn)制日志扇单。這些日志中的依賴項(xiàng)信息用于協(xié)助從引導(dǎo)節(jié)點(diǎn)的二進(jìn)制日志進(jìn)行狀態(tài)轉(zhuǎn)移的過程商模，以進(jìn)行分布式恢復(fù)，只要節(jié)點(diǎn)加入或重新加入該集群，就會(huì)發(fā)生這種情況施流。

• 表名

設(shè)置表名稱小寫：在所有組成員上將--lower-case-table-names設(shè)置為相同的值凉倚。設(shè)置1對(duì)于使用InnoDB存儲(chǔ)引擎是正確的，這對(duì)于組復(fù)制是必需的嫂沉。請(qǐng)注意稽寒，該設(shè)置并非在所有平臺(tái)上都是默認(rèn)設(shè)置。

• 多線程回放
  可以將組復(fù)制節(jié)點(diǎn)配置為多線程回放趟章，從而使事務(wù)可以并行應(yīng)用杏糙。slave_parallel_workers的非零值將在節(jié)點(diǎn)上啟用多線程回放，并且最多可以指定1024個(gè)并行應(yīng)用線程蚓土。設(shè)置slave_preserve_commit_order = 1可以確保并行事務(wù)的最終提交與原始事務(wù)的順序相同宏侍，這是組復(fù)制所必需的，它依賴于圍繞所有參與節(jié)點(diǎn)以相同順序接收和應(yīng)用已提交事務(wù)的保證的一致性機(jī)制蜀漆。最后谅河，slave_preserve_commit_order = 1需要設(shè)置slave_parallel_type = LOGICAL_CLOCK，該設(shè)置指定用于決定允許哪些事務(wù)在只讀節(jié)點(diǎn)上并行執(zhí)行的策略确丢。設(shè)置slave_parallel_workers = 0將禁用并行回放绷耍，并為副本提供一個(gè)單一的應(yīng)用程序線程，而沒有協(xié)調(diào)程序線程鲜侥。使用該設(shè)置褂始，slave_parallel_type和slave_preserve_commit_order選項(xiàng)無效，將被忽略描函。

PS
:通過前面的章節(jié)我們可以知道崎苗，組復(fù)制是基于主從復(fù)制的基礎(chǔ)架構(gòu)實(shí)現(xiàn)的，但相對(duì)于主從復(fù)制的IO和SQL線程來講舀寓，組復(fù)制中對(duì)原來接收主庫二進(jìn)制日志的IO線程改動(dòng)較大(用了一些后臺(tái)線程相互協(xié)作來代替了主從復(fù)制拓?fù)渲械腎O線程的功能)胆数，對(duì)解析二進(jìn)制日志并進(jìn)行回放的SQL線程(或者說協(xié)調(diào)器 線程與worker線程)改動(dòng)較小。每一個(gè)組成員中都會(huì)創(chuàng)建到組復(fù)制的連接(主從復(fù)制拓?fù)渲械腎O線程被 替換為了一些接收互墓、驗(yàn)證寫集的一些后臺(tái)線程必尼，可通過performance_schema.threads表進(jìn)行查看)， 每一個(gè)組成員對(duì)接收到的寫集進(jìn)行沖突認(rèn)證檢測(cè)轰豆，并將認(rèn)證通過的寫集(二進(jìn)制日志)寫入自身的中繼日志中胰伍，然后，由SQL線程讀取中繼日志進(jìn)行回放(多線程復(fù)制中酸休，由協(xié)調(diào)器線程讀取中繼日志骂租，然后 并行分發(fā)給worker線程進(jìn)行回放)。

2 組復(fù)制限制

• 故障轉(zhuǎn)移期間
  在故障轉(zhuǎn)移期間斑司，針對(duì)多主模式組描述的限制和問題也可以適用于單主模式集群渗饮，尤其是在新選舉的primary節(jié)點(diǎn)會(huì)從舊的primary節(jié)點(diǎn)中清除其applier隊(duì)列時(shí)但汞，在這個(gè)臨界點(diǎn)，可以將其類比組復(fù)制中有2個(gè)成員可寫互站。

• 服務(wù)升級(jí)
  --upgrade=minimal：當(dāng)MySQL Server指定--upgrade=minimal選項(xiàng)啟動(dòng)時(shí)私蕾，如果發(fā)現(xiàn)需要執(zhí)行更新， 則胡桃，在執(zhí)行升級(jí)操作完成之后踩叭，可能會(huì)導(dǎo)致組復(fù)制無法啟動(dòng)，因?yàn)閙inimal選項(xiàng)在執(zhí)行更新時(shí)翠胰，只會(huì)更新數(shù)據(jù)字典容贝、information_schema、performance_schema之景，但不會(huì)更新組復(fù)制內(nèi)部所依賴的系統(tǒng)表 (--upgrade選項(xiàng)在MySQL 8.0.16版本引入斤富，之后，升級(jí)操作將不再需要單獨(dú)使用mysql_upgrade工 具锻狗，默認(rèn)情況下--upgrade選項(xiàng)值為AUTO满力，表示自動(dòng)判斷是否需要執(zhí)行完整的更新操作)。

• 間隙鎖
  組復(fù)制的并發(fā)事務(wù)認(rèn)證過程未考慮間隙鎖轻纪，因?yàn)橛嘘P(guān)間隙鎖的信息在InnoDB之外不可用油额。
  ps：對(duì)于處于多主模式的集群，除非在應(yīng)用程序中依賴REPEATABLE READ語義桐磁，否則建議對(duì)組復(fù)制使 用READ COMMITTED隔離級(jí)別悔耘。InnoDB不使用READ COMMITTED中的間隙鎖，它將InnoDB中的本地 沖突檢測(cè)與組復(fù)制執(zhí)行的分布式?jīng)_突檢測(cè)保持一致我擂。對(duì)于單主模式的集群，只有primary節(jié)點(diǎn)接受寫操作缓艳，因此READ COMMITTED隔離級(jí)別對(duì)組復(fù)制并不重要校摩。

• 表鎖和命名鎖
  沖突認(rèn)證檢測(cè)過程不考慮表鎖(表鎖指的是:使用lock...table語句加鎖、使用unlock table語句解鎖)或命名鎖(命名鎖指的是：使用GET_LOCK()函數(shù)創(chuàng)建阶淘、使用RELEASE_LOCK()函數(shù)釋放的鎖)衙吩。

• 復(fù)制中event的checksum校驗(yàn)
  直到MySQL 8.0.20，組復(fù)制無法使用校驗(yàn)和溪窒，并且不支持二進(jìn)制日志中的校驗(yàn)和坤塞，因此在將實(shí)例配置為組成員時(shí)必須設(shè)置binlog_checksum = NONE。從MySQL 8.0.21開始澈蚌， 組復(fù)制支持校驗(yàn)和摹芙，因此組成員可以使用默認(rèn)設(shè)置binlog_checksum = CRC32。對(duì)于集群的所有節(jié)點(diǎn)宛瞄，binlog_checksum的設(shè)置可以不同浮禾。
  當(dāng)校驗(yàn)可用時(shí)，組復(fù)制將不使用它們來驗(yàn)證group_replication_applier通道上的傳入事件，因?yàn)槭录菑亩鄠€(gè)源寫入中繼日志的盈电，并且在它們?cè)趯?shí)際寫入原始服務(wù)器的二進(jìn)制日志之前就已寫入蝴簇。校驗(yàn)用于驗(yàn) 證group_replication_recovery通道和組成員上任何其他復(fù)制通道上事件的完整性。

• 串行化隔離級(jí)別
  默認(rèn)情況下匆帚，多主集群不支持SERIALIZABLE隔離級(jí)別熬词。將事務(wù)隔離級(jí)別設(shè)置為SERIALIZABLE將組復(fù)制將拒絕提交該事務(wù)。
  并行DDL與DML操作:使用多主模式時(shí)吸重，不支持針對(duì)同一對(duì)象但在不同實(shí)例上執(zhí)行的并發(fā)數(shù)據(jù)定義語句 和數(shù)據(jù)操作語句互拾。在對(duì)象上執(zhí)行數(shù)據(jù)定義語言(DDL)語句期間，在同一對(duì)象上但在不同服務(wù)器實(shí)例上 執(zhí)行并發(fā)數(shù)據(jù)操作語言(DML)可能會(huì)導(dǎo)致未檢測(cè)到在不同實(shí)例上執(zhí)行的DDL沖突的風(fēng)險(xiǎn)晤锹。
  注意：在同一個(gè)組成員中對(duì)同一個(gè)對(duì)象并行執(zhí)行DDL和DML語句摩幔，會(huì)由本地Server自行通過鎖進(jìn)行管理，不需要集群參與鞭铆。

• 具有級(jí)聯(lián)約束的外鍵
  多主模式集群(所有成員均配置有g(shù)roup_replication_single_primary_mode = OFF)不支持具有多級(jí)外鍵依賴關(guān)系的表或衡，特別是定義了CASCADING外鍵約束的表。這是因?yàn)閷?dǎo)致由多 主模式集群執(zhí)行級(jí)聯(lián)操作的外鍵約束可能導(dǎo)致無法檢測(cè)到的沖突车遂，并導(dǎo)致該組成員之間的數(shù)據(jù)不一致封断。因此，建議在用于多主模式集群的實(shí)例上將group_replication_enforce_update_everywhere_checks = ON設(shè)置為ON舶担，以避免未檢測(cè)到的沖突坡疼。
  在單主模式下，這不是問題衣陶，因?yàn)樗辉试S同時(shí)寫入集群中的多個(gè)節(jié)點(diǎn)柄瑰，因此不存在未檢測(cè)到?jīng)_突的風(fēng)險(xiǎn)。

• 多主模式死鎖
  當(dāng)集群以多主模式運(yùn)行時(shí)剪况，SELECT .. FOR UPDATE語句可能導(dǎo)致死鎖教沾。這是因?yàn)樵撴i未在集群上不同的節(jié)點(diǎn)之間實(shí)現(xiàn)共享。

• 復(fù)制過濾
  不能在組復(fù)制的成員中對(duì)組復(fù)制專用的group_replication_applier或group_replication_recovery通道配置使用全局復(fù)制過濾器译断，因?yàn)樵谀承┙M成員上過濾了事務(wù)會(huì)破壞組中所有成員之間的數(shù)據(jù)一致性授翻。但是，如果某個(gè)組成員同時(shí)作為主從復(fù)制拓?fù)渲械膹膸鞎r(shí)孙咪，則該主從復(fù) 制通道允許配置使用全局復(fù)制過濾器(這里的主從復(fù)制通道堪唐，不包括組復(fù)制專用的group_replication_applier或group_replication_recovery通道)。

• 集群規(guī)模限制：
  單個(gè)復(fù)制組中允許的組成員(MySQL Server實(shí)例)最大數(shù)量是9個(gè)翎蹈。如果有更多的Server嘗試加入該集群時(shí)淮菠，其連接請(qǐng)求將被拒絕。該限制數(shù)量是通過已有的測(cè)試案例和基準(zhǔn)測(cè)試中得出的一個(gè)安全邊界杨蛋，在 這個(gè)安全邊界中兜材，集群能夠安全理澎、可靠、穩(wěn)定地運(yùn)行在一個(gè)局域網(wǎng)中曙寡。

• 事務(wù)大小限制（重點(diǎn)）
  如果單個(gè)事務(wù)產(chǎn)生的消息內(nèi)容足夠大糠爬，以致于無法在5秒的時(shí)間內(nèi)通過網(wǎng)絡(luò)在組成員之間復(fù)制消息，則可 能會(huì)懷疑該節(jié)點(diǎn)失敗了举庶，然后將其驅(qū)逐出集群执隧，僅僅是因?yàn)樗麄冋诿τ谔幚硎聞?wù)。大型事務(wù)還會(huì)由于內(nèi)存分配問題而導(dǎo)致系統(tǒng)變慢户侥。為避免這些問題镀琉，請(qǐng)使用以下緩解措施：

如果由于大消息而發(fā)生不必要的驅(qū)逐，使用系統(tǒng)變量group_replication_member_expel_timeout留出更多時(shí)間蕊唐，以驅(qū)逐懷疑失敗的節(jié)點(diǎn)屋摔。在最初的5秒檢測(cè)期之后，最多可以等待一個(gè)小時(shí)替梨，然后才能將可疑節(jié)點(diǎn)從集群中驅(qū)逐出去钓试。從MySQL 8.0.21開始，默認(rèn)情況下再允許5秒副瀑。
在可能的情況下弓熏，嘗試限制事務(wù)的大小，然后再由組復(fù)制對(duì)其進(jìn)行處理糠睡。例如挽鞠，將與LOAD DATA一起使 用的文件拆分為較小的塊。

使用系統(tǒng)變量group_replication_transaction_size_limit可以指定集群接受的最大事務(wù)大小狈孔。在MySQL 8.0中信认，該系統(tǒng)變量的默認(rèn)最大事務(wù)大小為150000000字節(jié)(約143 MB)。超過此大小的事務(wù)將回滾均抽， 并且不會(huì)發(fā)送到組復(fù)制的組通信系統(tǒng)(GCS)進(jìn)行分發(fā)狮杨。處理事務(wù)所花費(fèi)的時(shí)間與其大小成正比，根據(jù) 需要該集群允許的最大消息大小來調(diào)整此變量的值到忽。

使用系統(tǒng)變量group_replication_compression_threshold指定消息大小，在此消息大小之上進(jìn)行壓縮清寇。該系統(tǒng)變量的默認(rèn)值為1000000字節(jié)(1 MB)喘漏，因此會(huì)自動(dòng)壓縮大消息。當(dāng)組復(fù)制的組通信系統(tǒng) (GCS)接收到group_replication_transaction_size_limit設(shè)置允許但超過group_replication_compression_threshold設(shè)置的消息時(shí)华烟，將執(zhí)行壓縮翩迈。

使用系統(tǒng)變量group_replication_communication_max_message_size可以指定消息大小，在該消息大小之上可以分段盔夜。該系統(tǒng)變量的默認(rèn)值為10485760字節(jié)(10 MiB)负饲，因此大型事務(wù)消息會(huì)自動(dòng)分段堤魁。如果壓縮的消息仍超過group_replication_communication_max_message_size限制，則GCS會(huì)在壓縮后執(zhí)行分段操作返十。為了使復(fù)制組使用碎片妥泉，所有組成員必須在MySQL 8.0.16或更高版本上，并且該組使 用的“組復(fù)制”通信協(xié)議版本必須允許碎片洞坑。

通過為相關(guān)系統(tǒng)變量指定零值盲链，可以停用最大事務(wù)大小，消息壓縮和消息碎片迟杂。如果停用了所有這些保護(hù)措施刽沾，則復(fù)制組的節(jié)點(diǎn)上的應(yīng)用線程可以處理的消息的大小上限是該節(jié)點(diǎn)的slave_max_allowed_packet系統(tǒng)變量的值，該變量的默認(rèn)最大值為1073741824字節(jié)(1 GB)排拷。當(dāng)接收節(jié)點(diǎn)嘗試處理此消息時(shí)侧漓，超出此限制的消息將失敗。組成員可以發(fā)起并嘗試發(fā)送到該集群的消息的大小上限為4294967295字節(jié)(約4 GB)监氢。這是組通信引擎接受的用于組復(fù)制(XCom布蔗，Paxos變體)的數(shù)據(jù)包大小的硬限制，它在GCS處理完消息后接收消息忙菠。當(dāng)發(fā)起節(jié)點(diǎn)嘗試廣播超過此限制的消息時(shí)何鸡，該消息將傳遞失敗。