记一次K8S 平台的Mysql5.7.40 MGR集群数据导入问题处理

最新推荐文章于 2024-07-14 20:43:40 发布

拉斐尔-centos7

最新推荐文章于 2024-07-14 20:43:40 发布

阅读量186

点赞数

分类专栏：运维文章标签： kubernetes 容器 mysql 运维

本文链接：https://blog.csdn.net/zp134520/article/details/132870794

版权

运维专栏收录该内容

5 篇文章 0 订阅

订阅专栏

事情起因：客户因为安全限制，只能使用sqlyog导出sql文件，再导入到Mysql5.7.40版本的MGR集群时出现故障。

处理过程：

1、尝试使用navicat导入，出现第一个报错Lost connection to MySQL server during query，怀疑是sql操作的时间过长，或者是传送的数据太大(例如使用insert ... values的语句过长， 这种情况可以通过修改max_allowed_packed的配置参数来避免，也可以在程序中将数据分批插入)。
处理办法是修改参数，配置MySQL服务器同客户端通信允许的最大数据包大小。
set global max_allowed_packet = 1024*1024*1024; 


2、随后尝试打开sql文件，发现文件大小为4.6Gb正常的文本编辑器无法打开，随后下载了大名鼎鼎的emedtray编辑器，简称EM编辑器。打开4.6G文件只需6s。打开sql后发现，整个表900多w行数据确实存在于单个insert into当中，就是说一个sql文件中只有一个insert 确实太长了。

3、换个思路，思考怎么切割sql文件，随后在网上下载SQLDumpSplitter3，尝试进行切割，分成4个的1Gb文件。

4、接着在navicat及Mysqlshell命令行中分别导入，依旧很慢并且不稳定，在测试环境4G内存的配置下，在最后提交阶段容易触发OOM导致pod中的容器被重启，重启后MGR集群状态混乱，需要手工介入恢复集群状态。

5、怀疑是单个sql文件 1Gb依旧太大，继续切割成500mb大小。再次使用navicat及Mysql命令行导入，这次出现了一个报错Transaction of size 181815674 exceeds specified limit 150000000. To increase the limit please adjust group_replication_transaction_size_limit option.'
根据日志提示在官网查看相关资料可以得知就是事务量太大超过了限制的值，需要调整。
查看当前单个事务最大限制：show global variables like '%group_replication_transaction_size_limit%';
修改最大事务限制： set global group_replication_transaction_size_limit=0; （生产环境不建议这样设置）
根据官网显示该参数在5.7.40版本最大值不超过150000000(114m),就算是修改为更大的值也会不生效。也可以尝试修改为0，即不做任何限制。

6、再次使用navicat及Mysql命令行导入500M，这次导入出现另外个问题'Member with address 192.168.244.30:3306 has become unreachable.'，集群因为主节点不可达导致被集群的多数节点标记为驱逐，同时触发选主另外两个节点组成集群，导致实例异常，尽管能重新加入集群不过也会被置于error状态并且自动设置为只读，并且会回滚之前被阻塞的写操作，该报错出现于sql文件导入集群的最后几秒钟，于是查询MGR官方手册，发现Mysql5.7版本的集群间的通信在超过5s没有响应后，将被驱逐出集群。

后边官方文档查询过程中，了解到三个重要参数group_replication_autorejoin_tries、group-replication-member-expel-timeout、group_replication_communication_max_message_size。官方解释分别为：
group_replication_autorejoin_tries：可以在群组运行时进行更改，通过这个变量可以允许因为网络等意外原因脱离集群的成员重新尝试加入集群。
group-replication-member-expel-timeout：指定的群组成员在产生怀疑之后，从群组中排除怀疑失败的成员之前等待的时间（以秒为单位）。
group_replication_communication_max_message_size：指定群组间传播消息的大小，默认值10M，超过该值后，可以自动进行分割，可以防止消息过大引起超时误报。
不过比较遗憾的是上述三个参数是在8.0.16版本后新增的，不然也许可以解决我们的5.7.40的超时问题。
附： 
	【官网Mos文档： “https://support.oracle.com/knowledge/Oracle%20Database%20Products/2271460_1.html”】
	【官方文档变量篇：“https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html”】
	【引用大佬文章：“https://www.sohu.com/a/615454128_411876”  解释了为啥会导致超时。什么是 XCom Cache？如何预估 XCom Cache 的大小？】


7、最后怀疑是sqlyog这个软件的优化或者bug导致的这些问题，进行验证，在分批次导入单个小于1g的sql文件到某个测试环境的单实例，避开MGR的各种限制，达到一个完整表数据后，于是针对测试环境的刚导入的完整表使用mysqldump进行导出，语句如下：mysqldump -h10.10.xx.xx -uroot -P300 -p --single-transaction –skip-extended-insert --set-gtid-purged=OFF  --databases db_xxxg  > /home/app/test.sql 。
随后再使用命令行导入MGR集群， mysql -uroot -hxxx.xx.xx.xx -p < test.sql ,震惊的发现该过程特别顺利，一个全量900多w行，2.3G的sql文件导入只花了7分钟，并且无任何报错， 尽管服务器dump到服务器比 经过4A和个人办公电脑的Navicat上行带宽高很多，但也不至于说一个报错也没有。


结论： sqlyog或者Navicat确实不使用于生产环境大数据量的导入导出，还是使用mysql官方的插件或者api进行数据迁移靠谱。

最后让客户去申请一台专用服务器，用于数据迁移导入了。