近一个月处理历史数据问题时，居然连续遇到了2个MySQL BUG，分享给大家一下，也欢迎指正是否有问题。
Bug1
数据库版本： MySQL5.7.25 - 28
操作系统： Centos 7.7（不重要）
数据库架构：主-从-级联从
数据库参数：
innodb_support_xa = 1 # 因主库存在XA事务，因此设置支持xa事务replicate_wild_do_table=yy.% # 只同步其中一个库
异常场景：级联从库上同步从库中的其中一个库（或者部分表，即存在过滤筛选部分表的场景），其中主库中其他库（非需要的库）存在XA事务，此时级联从库上启动主从同步时出现以下错误
[ERROR] Slave SQL for channel 'yy': Worker 1 failed executing transaction 'ANONYMOUS' at master log , end_log_pos 120460779;The use of replication filters with XA transactions is not supported, and can lead to an undefined state in the replication slave.Error_code: 3227
官方文档解答：
查找官方文档，有记录对应问题
https://forums.mysql.com/read.php?3,667908,667908
该问题已在MySQL8.0中修复，对应的MySQL8.0中的内容可以参考此链接
https://dev.mysql.com/doc/refman/8.0/en/xa.html
临时解决办法：
方式一：将本架构中的其中一个从库设置binlog过滤，只记录所需库的binlog，再开启级联从库的同步即可。方式二：使用ogg或canal等第三方工具处理同步方式三：写同步脚本定时同步
Bug2
数据库版本： MySQL5.6.27-75,MySQL5.7.25-28(从MySQL5.6.27-75原地升级的）
数据库架构：主-从
异常场景：
将一张大表转移到备份库中，使用rename的方式出现异常
SQL> alter table tbname rename to bak_db.tbname;
错误信息如下：
2020-06-21T03:10:54.694718Z 200 [ERROR] InnoDB: Operating system error number 2 in a file operation.2020-06-21T03:10:54.694737Z 200 [ERROR] InnoDB: The error means the system cannot find the path specified.2020-06-21T03:10:54.694742Z 200 [ERROR] InnoDB: File ./testdb/tbname.ibd: 'rename' returned OS error 71.
在MySQL5.6.27 -75及其从库MySQL5.7.25-28的版本中均出现
官方文档解答：
经查，官方文档中有对应的bug记录
https://bugs.mysql.com/bug.php?id=74004
https://bugs.mysql.com/bug.php?id=86253
解决办法：
方式一：如果是静态表， 手动创建一张新表，再将数据复制过去的方式进行移动
方式二：可以使用表空间迁移，具体可以参考MySQL innodb表使用表空间ibd文件复制或迁移表
方式三：如果是非静态表，则可以考虑手动在目标库创建新表，在原表上添加增删改的触发器（类似上文中的pt-osc变更表的处理方法）。
该BUG已修复，其他版本中已解决，但是通过实践发现，原地升级的方式仍未解决，大家可以亲自实践验证一下。
1. MySQL高可用之MHA集群部署
2. mysql8.0新增用户及加密规则修改的那些事
3. 比hive快10倍的大数据查询利器-- presto
4. 监控利器出鞘：Prometheus+Grafana监控MySQL、Redis数据库
5. PostgreSQL主从复制--物理复制
6. MySQL传统点位复制在线转为GTID模式复制
