1 、故障描述

某用户某次一套MySQL主从关系数据库，复杂同步出现异常，提示报错如下：

2 、根因分析

根据报错提示，我们大致可以知道以下几个情况：该实例是用来部署 zabbix 监控服务的，不属于业务数据库。报错报错 1539 ，提示主库在对 zabbix 库下的一个 event 事件 partition_maintenance 进行 alter 命令修改时，提示从库无法识别该 event 。

1.    在主库查看了该 event 的完整 SQL 。

CREATE DEFINER=`root`@`%` EVENT `partition_maintenance`

      ON SCHEDULE EVERY 25 DAY STARTS '2021-05-25 00:00:00'

      ON COMPLETION NOT PRESERVE DISABLE

      ON SLAVE DO call partition_maintenance_all('zabbix');

该 DDL 语句 SQL 中的各个参数的解释，如下：

定义者和安全性：

CREATE DEFINER='root'@'%' ：这指定了事件的创建者是 'root' 用户，允许从任何主机连接（由 @'%' 指定）。这意味着任何有权使用 'root' 账号从任何位置连接到数据库服务器的用户都可以看到这个事件的定义。

事件名称和调度：

EVENT 'partition_maintenance' ：这是事件的名称，你可以根据需要修改它。

ON SCHEDULE EVERY 25 DAY STARTS '2021-05-25 00:00:00' ：这定义了事件的调度。事件将从 2021 年 5 月 25 日开始，每 25 天运行一次。

事件执行后的行为：

ON COMPLETION NOT PRESERVE ：这表示事件完成后，不会自动保留或重新启用（如果它被禁用）。

DISABLE ON SLAVE ：这表示在复制环境中的从服务器上，该事件将被禁用。

事件要执行的操作：

DO call partition_maintenance_all('zabbix') ：这指定了事件要执行的操作，即调用名为 partition_maintenance_all 的存储过程，并传递一个参数 'zabbix' 。你需要确保数据库中已经存在这个存储过程，并且它能接受一个字符串类型的参数。

2.    检查从库是否存在该 event 事件 , 发现不存在改 event 事件，这也是导致主从复制异常的根本原因。

mysql> select * from mysql.event where name = 'partition_maintenance';

因为主从复制，仅 SQL 线程中断，说明主库 binlog 已全部同步至从库，只是没有回放，所以可以不需要通过全备来重新部署从库

MySQL 主从复制架构图，如下：

原则上主从复制报错 1539 ，是由于主库 binlog 文件丢失，就代表了数据丢失，需要重新构建主从复制。

本次问题的出现，是发生在手动主从切换过程，切换之前的主从复制是正常的，从库 binlog 过期被删除，不会导致切换主从后数据丢失，因为从库的数据非生产数据，只会导致主从切换后，复制异常。

3 、解决方案

1 、在从库创建 event 事件，但需要设置参数 event_scheduler 为 OFF 或 DISABLE ，表示计划任务处于停止状态或禁用状态，然后执行 stop slave ， start slave 。

2 、跳过 1539 的报错，不做处理。加参数 slave-skip-errors =1539 ，然后重启从库实例。本次采用该方案处理。

对于 MySQL 主从复制来说，不建议过多使用触发器、 event 事件等。

MySQL 触发器对复制的影响：

1)     ‌ 难以维护和调试 ‌ ：触发器在数据库内部执行，不易调试和维护，出现问题时排查困难。 ‌

2)     ‌ 性能影响 ‌ ：触发器执行消耗资源，复杂逻辑或大数据量时可能影响性能。 ‌

3)     ‌ 可能产生死锁 ‌ ：触发器中使用锁机制可能导致死锁，影响数据库稳定性。 ‌

4)     ‌ 增加程序复杂度 ‌ ：业务逻辑分散在代码和触发器中，后期维护困难。 ‌

‌MySQL event对复制的影响：

1)     ‌ 性能问题 ‌ ： Event 频繁执行会增加数据库负担，影响性能。 ‌

2)     ‌ 维护困难 ‌ ：大量 Event 存在时，管理和维护变得困难。 ‌

3)     ‌ 可移植性差 ‌ ：数据库迁移时， Event 可能出现兼容性问题。 ‌