MySQL的EVENT对象默认不随主从复制同步，需手动在从库创建并启用；event_scheduler默认关闭，须显式开启；主从切换后需人工检查并启用事件，注意时区、DEFINER及依赖对象一致性。
MySQL主从同步中Event不自动复制的默认行为
MySQL的EVENT对象默认不会随主从复制自动同步到从库，即使binlog_format=ROW或MIXED也一样——这是设计使然，不是配置错误。主库创建的EVENT只存在于本地mysql.event表，而该表本身不参与复制。
常见错误现象：SHOW EVENTS在从库查不到主库创建的定时任务；主库ALTER EVENT ... ENABLE后，从库对应事件仍为DISABLED甚至根本不存在。
- 必须手动在从库执行
CREATE EVENT语句（建议导出主库SHOW CREATE EVENT xxx结果再执行） - 若用
mysqldump --events备份，恢复时会重建EVENT，但仅限一次性操作，不解决后续变更同步问题 -
event_scheduler=ON需在从库单独开启，且默认是OFF，否则即使事件存在也不会运行
从库禁用Event的两种可靠方式
禁用从库上的EVENT不能只靠DROP EVENT或DISABLE，因为切主后可能被误启用，或监控脚本自动恢复。真正可控的方式是双保险：
- 设置
event_scheduler=OFF（全局动态变量），立即停止所有事件调度，重启后失效，需写入my.cnf的[mysqld]段并重启才持久 - 对每个已存在的事件显式执行
ALTER EVENT event_name DISABLE，避免event_scheduler=ON后自动触发 - 注意：
DISABLE不阻止event_scheduler=OFF时的状态显示，需用SELECT * FROM mysql.event WHERE status='ENABLED'确认实际状态
主从切换后从库变主库：Event启用检查清单
当原从库提升为主库（如MHA、Orchestrator或手动CHANGE MASTER TO后STOP SLAVE），原有禁用的EVENT不会自动启用，必须人工干预。
- 先确认
event_scheduler已开启：SET GLOBAL event_scheduler = ON（临时）或更新配置文件+重启（持久） - 逐个启用事件：
ALTER EVENT event_name ENABLE，不要依赖SHOW EVENTS的Status列——它可能显示ENABLED但实际因event_scheduler=OFF未运行 - 检查事件定义中的
ON SCHEDULE是否含AT（一次性）或EVERY（周期性），AT类事件在切换后若已过期时间，需用ALTER EVENT ... ADD EVENT重置 - 验证执行日志：
SELECT * FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'db_name'，重点看LAST_EXECUTED和STATUS
跨版本/跨实例Event同步的兼容性陷阱
MySQL 5.7与8.0之间、或RDS与自建MySQL之间同步EVENT，容易因元数据格式差异失败。
-
SHOW CREATE EVENT输出在8.0中可能含SQL SECURITY DEFINER和DEFINER用户，若从库不存在该用户，执行会报错Access denied for user 'xxx'@'%' - 解决方案：导出后手动替换
DEFINER=CURRENT_USER，或用mysqldump --skip-definer - RDS（如阿里云、AWS）通常禁止修改
mysql.event表或event_scheduler变量，只能通过控制台或API管理事件，无法直接ALTER EVENT - 事件中调用存储过程或函数时，若依赖主库特定函数体，而从库未同步该函数定义，启用后执行会静默失败（无错误日志，但
LAST_EXECUTED为空）
最易被忽略的是事件时间戳的时区处理：主库system_time_zone和time_zone设置若与从库不一致，ON SCHEDULE EVERY 1 DAY可能在切换后偏移数小时。务必统一所有节点的time_zone配置，别只信SELECT @@time_zone的会话值。
