MySQL 8.0.20 MGR資料遷移過程以及注意事項

你好我是李白發表於2020-08-01

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,使複製繼續,即可修復。





來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31439444/viewspace-2708593/,如需轉載,請註明出處,否則將追究法律責任。

相關文章