MySQL工作记录——并行复制同步出错Last_Errno: 1032 Last_Error: Coordinator stopped because

结论

先说一下问题原因，就是你在主库上操作的记录同步到从库上的时候没有找到该条记录导致。
可能有人在从库进行操作了。

背景

老任今天工作又遇到了一个奇葩问题，先说一下背景，方便大家快速理解这个报错。
背景由于历史的原因我们有个DB，存了大量的log，其实业务数据不多，数据大概有3.7T的数据，
业务数据可能就几百G，所以在我接手之后，我第一件事情进行了DB种业务数据和log数据的
拆分，之前他们在原库是每天跑ctonjob去删除log数据，但是这样子有个问题，因为这个库的
qps很高，所以会导致主从延时，甚至删除数据过多会影响到主库的性能，所以就进行了拆分。

在一切备份文件重搭从库以及对日志表进行分区分表之后，我就根据业务需要保留的log类数据时间，
根据分区清理了log数据，大概数据能缩小2T左右，效果也很明显。

然后问题这就来了。
由于主库上有cronjob删除数据，而我在自己心搭建的log数据进行了清理，所以
同步过来的删除语句就找不到记录，然后复制就中断了，所以产生如下的错误。

解决思路

#查看同步的状态
>show slave status\G;
....
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 '233f10d6-5f9e-11eb-b55d-42010a8e000d:17097464006' at master log , end_log_pos 199137532.
  See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
....

#上面的报错没有找到具体哪条记录，因为采用了并行复制，所以我们需要进行查看报错中提示的表查看到底问题出现在哪里
backup@localhost:mysql.sock:[(none)]>select * from performance_schema.replication_applier_status_by_worker\G；
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 1
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_ERROR_NUMBER: 1032
LAST_ERROR_MESSAGE: Worker 1 failed executing transaction '233f10d6-5f9e-11eb-b55d-42010a8e000d:17097464006' at master log , end_log_pos 199137532; Could not execute Delete_rows event on table dbname.table_name; Can't find record in 'table_name', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.877, end_log_pos 199137532                                  
.....

#这里我们主要关心LAST_ERROR_MESSAGE字段，这个会告诉我们出错的地方位点以及binlog相关表等
#这里我们很清楚看到，是哪张表的哪条记录在binlog的哪个位点进行同步的时候，因为从库记录报错导致的。
#所以我们可以回到主库去查看一下到底是哪条记录导致的。

但是，问题又来了,对于少量的数据，比如几条删除的，可以直接gtid跳过位点就可以了
但是我这个会删除很多条，所以会有很多
解决方案：
1.脚本循环处理show slave status中的gtid值
2.跳过对应的错误码
经过简单和开发进行沟通，确定了这个log对应的表只会insert和select，除了cronjob不会有人删除，
考虑到现在需要跳过的报错以及后续还会有的报错，我选择了后者

#在mysql的从库中，/etc/my.cnf [mysqld]中加入下面的参数
$ cat /etc/my.cnf|grep skip
slave-skip-errors=1032

#这个参数的意思就是跳过该报错码的报错
#mysql中每个错误码会对应相对应的报错
#这个可以在show slave status 以及刚才查询报错的表中看到对应的错误码。

改了之后，重启了一下这个准备上线但是还未上线的mysqld，果然报错过滤掉了
畅快。