1.背景 近期由于业务调整,需要将windows Server 2008 Mysql5.5数据库迁移到Windows Server 2012 mysql8.0
近期由于业务调整,需要将windows Server 2008 Mysql5.5数据库迁移到Windows Server 2012 mysql8.0集群MGR中,由于实际部署时,有一台机器硬盘损坏,只能构建双节点MGR,在迁移以及应用迁移过程中遇到许多参数与迁移效率问题,特此记录。
由于有部分数据来源于文本文件,单个文件达到40G之大,且原表为MyISAM存储引擎,由于MGR只支持事务引擎InnoDB,
所以需要修改文本文件头建表语句以及拆分文件,并行导入,使用如下两款软件进行了修改大文件以及拆分:
EmEditor,可以打开超大文件。
Windows Unix增强工具。
第一阶段:由于最开始导入时开启了MGR,由于使用Navicat执行sql文件方式导入数据,导致由于关闭autocommit,单个事务超大,MGR在最后提交阶段由于网络不稳定,导致验证过长,效率非常底下。
第二阶段:尝试打开autocommit方式,发现由于不停写binlog与数据文件,效率更差。
第三阶段:拆分MGR,将文件传送两个服务器,关闭binlog,分别导入,效率非常高,将1.7亿万,40G数据拆分为20个
文件,分别开20个并行导入,两台机器并行导入,并且将MySQL所有文件迁移到服务器SSD磁盘,40分钟即可完成所有数据导入。
group_replication_transaction_size_limit
# 最大值2147483647,近似2G,在组成MGR进行单事务大量数据导入或更新时,需要考虑该参数影响,有可能由于
该参数设置过小导致最后阶段失败,不过大事务对于MGR确实不太友好,节点互相确认消耗大量网络带宽。
max_binlog_cache_size
# 事务过大,需要相应调大该参数,实测,1000万行数据大约需要3~4G该参数,
# 官方文档不建议设置过大该参数,最大建议4G
最后数据迁移完毕之后,由于在之前由于导入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,使复制继续,即可修复。
--结束END--
本文标题: MySQL 8.0.20 MGR数据迁移过程以及注意事项
本文链接: https://lsjlt.com/news/46278.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0