详细报错:
Last_Errno: 1032
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being:
Worker 1 failed executing transaction '268b285c-e7fb-11ee-9a70-fe4e80fb7012:84858' at master log mysql-bin.000003,
end_log_pos 38100441. See error log and/or performance_schema.replication_applier_status_by_worker
table for more details about this failure or others, if any.
排查过程:
1、解析binlog
mysqlbinlog --base64-output=decode-rows -vvv mysql-bin.000003 >>a.log
grep -C30 '268b285c-e7fb-11ee-9a70-fe4e80fb7012:84858' a.log
2、主库查看
3、从库查看
发现主库有数据,但是备库没有数据。所以主库update成功,传到从库失败。同时发现从库多了俩个GTID、且GTID是从库的,并且表是内存表。
4、解析从库的binlog
mysqlbinlog --base64-output=decode-rows -vvv mysql-bin.000003 >1.log
grep -C10 'dc7c38f6-ea4b-11ee-bf7a-82b443ce3b05' 1.log
发现是TRUNCATE并且 后面备注generated by server, implicitly emptying in-memory table
故怀疑是内存表的原因导致的。
查看官方文档:
mysql 官方文档 memory表描述
问题原因:
备库重启后产生了自身的gtid,解析该gtid发现是备库主动truncated了自身的memory引擎内存表。该机制是mysql为了避免重启后主从memory表数据不一致(memory表重启后数据会丢失),会在数据库重启后自动执行该动作并写入binlog,这个机制导致了备库重启后无法change master到主库,建立主从关系。
解决办法
方案一:
更改memory的内存表引擎为innodb,创建全量备份,然后把备份应用到备库。
1、主库修改引擎
alter table taf_stat_md.t_ecstatus engine=innodb;
alter table taf_property_1.t_ecstatus engine=innodb;
2、备份
3、把备份恢复到备库
4、备份完之后修改回来引擎
alter table taf_stat_md.t_ecstatus engine=memory;
alter table taf_property_1.t_ecstatus engine=memory;
方案二:
忽略主从内存表不一致的问题(业务允许备库丢失内存表数据),直接改slave_exec_mode=IDEMPOTENT参数。(会导致正常的表主键冲突等都不会报错 遇到主键或唯一键冲突以及主键不存在时,并不会报错,会直接覆盖数据或者忽略数据不存在,主从复制仍然正常进行。)
方案三:
1、修改GTID
show master status\G
resert maser;
set global gtid_purged=’复制上面正常的gtid,屏蔽掉TRUNCATE语句的’
2、去故障的备库把主库里面的数据手动插入到从库
SET global read_only=0;
set sql_log_bin=0;
show variables like 'sql_log_bin';
3、此数据需要去主库查(主库的数据)。
INSERT INTO test.test VAIUES(主库数据);
set sql_loq_bin=1;
SET global read_only=1;
4、重新搭建主备关系
change master to MASTER_HOST='主库IP',
MASTER_USER='用户',
MASTER_PASSWORD='密码',
master_auto_position=l;
#启动主从
start slave;