MGR8.0.16从节点报错001146原因分析和修复及规避注意事项

MGR8.0.16从节点报错001146原因分析和修复及规避注意事项

架构背景介绍：
某系统数据库使用原来使用mysql 5.7双主架构，现经过架构改造采用mysql 8.0.16 MGR 架构一主两从单主模式架构，生产机房一主一从，同城机房一从。

MGR同步异常报错001146信息：
项目组反馈MGR同步异常，两个从节点都脱离了MGR集群。报错如下：
两个从节点mysqld1.log同时报错：
[Warning] [MY-010584] [Repl] Slave: Table ‘fit.cloud_old’ doesn’t exist Error_code: MY-001146
[Error] [MY-010451] [Repl] Plugin group_replication reported: ‘The applier thread execution as aborted.
Unable to process more transactions, this member will now leave the group.’

报错分析：
1、登录主节点查看是否有此表
use fit;
desc fit.cloud_old;
发现确认主库确实有此表，再登录两个从节点发现从节点确实没有fit.cloud_old表，查看mysql datadir目录查看fit.cloud_old物理文件，也发现只有主库有对应的物理文件，从节点
没有对应的物理文件，所以报错1146也正常。

2、根据主库fit.cloud_old物理文件更新时间，和项目组沟通对此表有什么操作，项目组反馈fit.cloud_old是从老系统主库导出然后source fit.cloud_old.sql到新的MGR主库中的。
查看对应的
导入文件fit.cloud_old.sql
cat fit.cloud_old.sql
发现打开了会话级别的sql_log_bin=off; 也就是说往MGR主库导入此表的定义和数据，主库有，但是因为导入动作不记binlog所以两个从节点没有此表。
此时的MGR复制状态是正常的，当再对此表fit.cloud_old进行更新操作时候，两个从节点就会报错 MY-001146 找不到对应的表。

报错修复：
1、将fit.cloud_old.sql 传到MGR 两个从节点
use fit;
source fit.cloud_old.sql;

2、两个从节点重启组复制
stop group_replication;
start group_replication;

3、查看节点状态
在MGR集群任意节点查看
select * from performance_schema.replication_group_members;
观察两个的从节点的MEMBER_STATE 由RECOVRING状态到ONLINE状态；

规避注意事项：
原因是双主开启了gtid模式：
mysqldump -u root -ppassword -d database t fit.cloud_old> fit.cloud_old.sql
此时的会话
cat fit.cloud_old.sql
SET @@SESSION.SQL_LOG_BIN= 0;

涉及mysql gtid主从导出单表应该加参数
mysqldump -u root -ppassword --set-gtid-purged=OFF -d database t fit.cloud_old> fit.cloud_old.sql
此时的会话
cat fit.cloud_old.sql
没有了不记日志设置

结论：
在老系统双主导出表，没有加参数–set-gtid-purged=OFF，导致导出的文件是打开了SET @@SESSION.SQL_LOG_BIN= 0;
然后把导出的文件再往MGR 主库导入的时候，导致只有主库有此表，两个从节点没有此表。
涉及mysql gtid主从mysqldump导出表务必使用–set-gtid-purged=OFF参数。否则往新的主从或者MGR架构的主库导入相关数据后，出现只有主库有相关数据而从库没有现象。