查看丛库状态show slave status\g
从库原文提示：Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '864e6992-0a34-11e7-a98a-7cd30ac6c9ec:148408' at master log
mysql
-bin.000010, end_log_pos 920578920. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
1、 按照丛库的提示找原因，输入命令
得到
知道这个事务发生在表 r_com_patent 上，定位到表，但是不知道哪一条记录。
2、 到主库找二进制文件发生了什么事。输入命令
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
终于定位到记录了。
主库在表r_com_patent做了更新操作，而丛库找不到更新的记录。
具体来说就是，主库将表r_com_patent中patent_id为45的记录，字段cid从NULL更改为3253026.而丛库表r_com_patent中patent_id为45的记录，字段cid原本为3253026，由于复制机制就必须找丛库表r_com_patent中patent_id为45并且id为NULL的记录，所以没找到。。。
3、 解决方法
1) 在master查看那条记录。
2) 在slave上，查找下更新后的那条记录，应该是不存在的。
3) 把丢失的数据在Slave上填补或是修改。
4) 在slave跳过报错的事务。
之后，再检查一遍
select * from performance_schema.replication_applier_status_by_worker\GMysqlbinlog --no-defaults –v –v --base64-output=decode-rows /usr/local/mysql/data/master-bin.000010 | grep –A ‘10’ 920578920Select * from r_com_patent where patent_id = 45; Select * from r_com_patent where patent_id = 45; Insert into r_com_patent values(3253026,45);Stop slave;
Set @@SESSION.GTID_NEXT=’ 864e6992-0a34-11e7-a98a-7cd30ac6c9ec:148408’
Begin;
Commit;
Set @@SESSION.GTID_NEXT = AUTOMATIC;
Start slave;Show slave status\G