宜宾网站建设公司

MySQL8.0.20MGR数据迁移过程以及注意事项

1.背景

    近期由于业务调整，需要将Windows Server 2008 MySQL5.5数据库迁移到Windows Server 2012 MySQL8.0集群MGR中，由于实际部署时，有一台机器硬盘损坏，只能构建双节点MGR，在迁移以及应用迁移过程中遇到许多参数与迁移效率问题，特此记录。

创新互联-专业网站定制、快速模板网站建设、高性价比越城网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式越城网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖越城地区。费用合理售后完善，十多年实体公司更值得信赖。

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，使复制继续，即可修复。

文章名称：MySQL8.0.20MGR数据迁移过程以及注意事项
标题链接：http://ybzwz.com/article/pcsgij.html

其他资讯