巡检发现主从异常1.确认具体的错误原因这个错误信息表明你正在使用 ​MySQL Group Replication​或者基于 GTID 的多源复制/并行复制架构其中协调器Coordinator因为工作线程Worker执行事务失败而停止了复制。具体错误代码 Last_Errno: 1418​ 对应的标准 MySQL 错误是​ER_FUNC_INEXISTENT_NAME_COLLISION​: Function %s already exists 或者在某些上下文中指代对象命名冲突但在复制报错的语境下结合 Coordinator stopped because there were error(s) in the worker(s)​这通常意味着​并行复制Multi-Threaded Slave, MTS或 Group Replication 的应用线程在应用事务时发生了冲突或状态不一致​。然而1418​ 在较新的 MySQL 版本5.7/8.0的复制报错中更常见的情况是​函数/存储过程定义冲突​或者是并行复制时的数据依赖冲突导致的特定报错映射。但最核心的问题是​Worker 1 无法应用该事务​。2.常见原因分析根据经验Last_Errno: 1418​ 配合 Worker 失败通常有以下几种可能A. 对象命名冲突 (最常见于 DDL 操作)错误字面意思通常是“函数已存在”。如果在主库执行了 CREATE FUNCTION​ 或 CREATE PROCEDURE​而从库上已经存在同名的对象可能是之前残留的或者手动创建的复制就会报错。​检查方法​在主库查看该事务对应的 SQL通过 mysqlbinlog​看是否包含创建函数的语句。​解决​在从库手动删除冲突的函数然后重启复制。B. 并行复制 (MTS) 的数据冲突如果你开启了 slave_parallel_workers 0​多个 Worker 线程并行应用事务。如果两个事务修改了同一行数据且依赖关系判断失误虽然 MySQL 逻辑通常能处理但在某些极端边界条件或 Bug 下可能发生可能导致应用失败。​注意​在 MySQL 8.0 中Group Replication 默认使用基于写集Write Set的认证如果发生认证失败通常会报 1418​ 相关的冲突错误尽管标准错误码可能不同但表现类似。C. Group Replication 中的认证失败在 MGR 架构中如果事务在认证阶段失败例如证书冲突协调器会停止。检查 performance_schema.replication_group_member_stats​ 中的 COUNT_CONFLICTS_DETECTED​ 是否增加。报错原因查看SELECT WORKER_ID, THREAD_ID, SERVICE_STATE, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER ! 0; -- Group Replication SELECT * FROM performance_schema.replication_group_member_stats WHERE MEMBER_ID (SELECT MEMBER_ID FROM performance_schema.replication_group_members WHERE MEMBER_STATE ! ONLINE LIMIT 1); -- 或者查看组复制的具体错误日志 SHOW GLOBAL STATUS LIKE group_replication_last_conflict_free_transaction;主从对比对应函数发现主库存在从库不存在从库参数检查修复后总结由于主库需要创建函数age在数据库xxx_db上从库参数log_bin_trust_function_creators默认为off导致主从同步异常现已临时修改参数为on并重启复制进程主从复制运行正常观察到主从延迟呈现减少趋势但是由于上次报错时间为25年12月仍然有可能无法最终同步正常因为过去四个月的log有可能被清理 或者由于时间久远堆积日志过多导致io压力 极端情况可能需要主从重新搭建