MySQL 8.0.20 MGR數(shù)據(jù)遷移過(guò)程以及注意事項(xiàng)

1.背景

    近期由于業(yè)務(wù)調(diào)整，需要將Windows Server 2008 MySQL5.5數(shù)據(jù)庫(kù)遷移到Windows Server 2012 MySQL8.0集群MGR中，由于實(shí)際部署時(shí)，有一臺(tái)機(jī)器硬盤損壞，只能構(gòu)建雙節(jié)點(diǎn)MGR，在遷移以及應(yīng)用遷移過(guò)程中遇到許多參數(shù)與遷移效率問(wèn)題，特此記錄。

2.遷移表單個(gè)文件過(guò)大

    由于有部分?jǐn)?shù)據(jù)來(lái)源于文本文件，單個(gè)文件達(dá)到40G之大，且原表為MyISAM存儲(chǔ)引擎，由于MGR只支持事務(wù)引擎InnoDB，

所以需要修改文本文件頭建表語(yǔ)句以及拆分文件，并行導(dǎo)入，使用如下兩款軟件進(jìn)行了修改大文件以及拆分：

EmEditor，可以打開超大文件。

Windows Unix增強(qiáng)工具。

3.并行導(dǎo)入遇到問(wèn)題

    第一階段：由于最開始導(dǎo)入時(shí)開啟了MGR，由于使用Navicat執(zhí)行SQL文件方式導(dǎo)入數(shù)據(jù)，導(dǎo)致由于關(guān)閉autocommit，單個(gè)事務(wù)超大，MGR在最后提交階段由于網(wǎng)絡(luò)不穩(wěn)定，導(dǎo)致驗(yàn)證過(guò)長(zhǎng)，效率非常底下。

    第二階段：嘗試打開autocommit方式，發(fā)現(xiàn)由于不停寫binlog與數(shù)據(jù)文件，效率更差。

    第三階段：拆分MGR，將文件傳送兩個(gè)服務(wù)器，關(guān)閉binlog，分別導(dǎo)入，效率非常高，將1.7億萬(wàn)，40G數(shù)據(jù)拆分為20個(gè)

文件，分別開20個(gè)并行導(dǎo)入，兩臺(tái)機(jī)器并行導(dǎo)入，并且將MySQL所有文件遷移到服務(wù)器SSD磁盤，40分鐘即可完成所有數(shù)據(jù)導(dǎo)入。

4.導(dǎo)入過(guò)程遇到MGR與MySQL參數(shù)限制問(wèn)題

group_replication_transaction_size_limit 
# 最大值2147483647，近似2G，在組成MGR進(jìn)行單事務(wù)大量數(shù)據(jù)導(dǎo)入或更新時(shí)，需要考慮該參數(shù)影響，有可能由于
該參數(shù)設(shè)置過(guò)小導(dǎo)致最后階段失敗，不過(guò)大事務(wù)對(duì)于MGR確實(shí)不太友好，節(jié)點(diǎn)互相確認(rèn)消耗大量網(wǎng)絡(luò)帶寬。 
max_binlog_cache_size 
# 事務(wù)過(guò)大，需要相應(yīng)調(diào)大該參數(shù)，實(shí)測(cè)，1000萬(wàn)行數(shù)據(jù)大約需要3~4G該參數(shù)，
# 官方文檔不建議設(shè)置過(guò)大該參數(shù)，最大建議4G

5.由于需要導(dǎo)入MyISAM導(dǎo)致MGR數(shù)據(jù)不一致問(wèn)題解決

最后數(shù)據(jù)遷移完畢之后，由于在之前由于導(dǎo)入MyISAM引擎表，臨時(shí)禁用disable_storage_engines，導(dǎo)致啟動(dòng)MGR之后

有MGR不支持的操作報(bào)錯(cuò)：

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

上面報(bào)錯(cuò)，MGR中違反MGR限制的報(bào)錯(cuò)都報(bào)上述錯(cuò)誤，并不會(huì)具體表述由于詳細(xì)原因，比如使用對(duì)MyISAM表操作，

沒(méi)有主鍵唯一鍵表創(chuàng)建之后，插入數(shù)據(jù)，都將報(bào)上述錯(cuò)誤。

MGR不一致問(wèn)題解決流程如下：

1. 查看集群狀態(tài)，確定故障節(jié)點(diǎn)
SELECT * FROM PERFORMANCE_SCHEMA.REPLICATION_GROUP_MEMBERS;
# 查看集群所有節(jié)點(diǎn)狀態(tài)，找到具體Error或recovering節(jié)點(diǎn)。
2.查看故障節(jié)點(diǎn)error log
# 查看error log，確定故障gtid，position
3.分析當(dāng)前讀寫節(jié)點(diǎn)發(fā)生問(wèn)題binlog
# mysqlbinlog命令分析，找到故障執(zhí)行語(yǔ)句，明確故障原因。
4.查看具體故障發(fā)生表大小，狀態(tài)
（1）確定表大小以及是否經(jīng)常修改，如果為經(jīng)常修改大表，則考慮對(duì)故障節(jié)點(diǎn)利用備份重建
（2）如果表不大或不經(jīng)常改變，改變可以明確預(yù)知時(shí)段，可以考慮故障節(jié)點(diǎn)reset master，然后設(shè)置gtid_purged或者
使用設(shè)置gtid_next為故障gtid方式，如果可以正常復(fù)制到讀寫節(jié)點(diǎn)當(dāng)前gtid，然后再在不變時(shí)段導(dǎo)出，如果繼續(xù)報(bào)錯(cuò)，則
繼續(xù)查看是否為故障表，如果是繼續(xù)跳過(guò)，知道可以正常追數(shù)據(jù)到讀寫節(jié)點(diǎn)當(dāng)前gtid，記錄故障節(jié)點(diǎn)show master status
復(fù)制點(diǎn)，臨時(shí)設(shè)置故障read_only與super_read_only為off，導(dǎo)入故障節(jié)點(diǎn)，然后reset master或設(shè)置gtid_next為
show master status記錄的gtid，使復(fù)制繼續(xù)，即可修復(fù)。