MySQL 8.0.20 MGR數據遷移過程以及注意事項

1.背景

    近期由于業務調整，需要將Windows Server 2008 MySQL5.5數據庫遷移到Windows Server 2012 MySQL8.0集群MGR中，由于實際部署時，有一臺機器硬盤損壞，只能構建雙節點MGR，在遷移以及應用遷移過程中遇到許多參數與遷移效率問題，特此記錄。

2.遷移表單個文件過大

    由于有部分數據來源于文本文件，單個文件達到40G之大，且原表為MyISAM存儲引擎，由于MGR只支持事務引擎InnoDB，

所以需要修改文本文件頭建表語句以及拆分文件，并行導入，使用如下兩款軟件進行了修改大文件以及拆分：

EmEditor，可以打開超大文件。

Windows Unix增強工具。

3.并行導入遇到問題

    第一階段：由于最開始導入時開啟了MGR，由于使用Navicat執行SQL文件方式導入數據，導致由于關閉autocommit，單個事務超大，MGR在最后提交階段由于網絡不穩定，導致驗證過長，效率非常底下。

    第二階段：嘗試打開autocommit方式，發現由于不停寫binlog與數據文件，效率更差。

    第三階段：拆分MGR，將文件傳送兩個服務器，關閉binlog，分別導入，效率非常高，將1.7億萬，40G數據拆分為20個

文件，分別開20個并行導入，兩臺機器并行導入，并且將MySQL所有文件遷移到服務器SSD磁盤，40分鐘即可完成所有數據導入。

4.導入過程遇到MGR與MySQL參數限制問題

group_replication_transaction_size_limit 
# 最大值2147483647，近似2G，在組成MGR進行單事務大量數據導入或更新時，需要考慮該參數影響，有可能由于
該參數設置過小導致最后階段失敗，不過大事務對于MGR確實不太友好，節點互相確認消耗大量網絡帶寬。 
max_binlog_cache_size 
# 事務過大，需要相應調大該參數，實測，1000萬行數據大約需要3~4G該參數，
# 官方文檔不建議設置過大該參數，最大建議4G

5.由于需要導入MyISAM導致MGR數據不一致問題解決

最后數據遷移完畢之后，由于在之前由于導入MyISAM引擎表，臨時禁用disable_storage_engines，導致啟動MGR之后

有MGR不支持的操作報錯：

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

上面報錯，MGR中違反MGR限制的報錯都報上述錯誤，并不會具體表述由于詳細原因，比如使用對MyISAM表操作，

沒有主鍵唯一鍵表創建之后，插入數據，都將報上述錯誤。

MGR不一致問題解決流程如下：

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