mysql事件复制需同时启用log_bin和log_bin_trust_function_creators，主库创建事件须指定definer账户（如'root'@'localhost'），从库需开启event_scheduler并避免复制过滤影响，否则事件无法同步或执行。
MySQL 事件复制必须显式启用 log_bin 和 log_bin_trust_function_creators
MySQL 默认不复制存储过程、函数、触发器和事件（EVENT），因为它们可能产生非确定性行为。要让 CREATE EVENT、DROP EVENT 等语句被写入二进制日志并同步到从库，必须同时满足两个前提：
-
log_bin必须为 ON（即开启二进制日志）——这是复制的基础，没有它就谈不上任何基于日志的复制 -
log_bin_trust_function_creators必须设为 1（或 ON）——否则创建事件时会报错ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration，即使你创建的是事件而非函数
这两个参数需在主库的 my.cnf 中配置并重启 MySQL（或动态设置后验证）：
log_bin = /var/lib/mysql/mysql-bin log_bin_trust_function_creators = 1
主库上创建事件前必须用 DEFINER 指定具备 SUPER 权限的账户
事件在从库重放时，是以 DEFINER 身份执行的。如果定义者账户在从库不存在，或没有足够权限，事件会创建失败甚至导致 SQL 线程中断（Seconds_Behind_Master 停滞）。
- 推荐使用
DEFINER = 'root'@'localhost'（确保该用户在主从库都存在且有SUPER权限） - 避免用
CURRENT_USER或匿名用户，否则从库因权限缺失无法解析事件定义 - 创建语句必须包含完整
DEFINER子句，例如：CREATE DEFINER = 'root'@'localhost' EVENT daily_cleanup<br> ON SCHEDULE EVERY 1 DAY<br> DO DELETE FROM logs WHERE created
从库必须启用 event_scheduler = ON 才能实际执行事件
主库创建事件后，从库会收到 CREATE EVENT 语句并成功写入本地事件表（mysql.event），但这只是“注册”，不代表事件会自动运行。
-
event_scheduler默认是OFF，必须手动开启：SET GLOBAL event_scheduler = ON;（或写入my.cnf的[mysqld]段） - 仅靠主库的
event_scheduler = ON不会影响从库行为；从库是否运行事件完全由自己的event_scheduler状态决定 - 可检查状态：
SELECT @@event_scheduler;返回ON才表示已启用
复制过滤规则（如 replicate-ignore-db）会导致事件被跳过
事件本身没有所属数据库，但其定义语句在 binlog 中仍按“当前默认数据库”记录。若你在从库配置了 replicate-ignore-db = mysql 或类似规则，而事件创建时默认库是 mysql（常见于直接在 mysql 库下执行 CREATE EVENT），该语句就会被从库忽略。
- 最稳妥的做法：所有事件统一在业务库（如
app_db）下创建，且显式指定库名：CREATE DEFINER = 'root'@'localhost' EVENT app_db.hourly_sync ... - 避免依赖默认库上下文；不要在
mysql库中创建业务事件 - 检查从库的复制过滤配置：
SHOW SLAVE STATUS\G中关注Replicate_Ignore_DB和Replicate_Wild_Ignore_Table
事件复制不是“开箱即用”的功能，它高度依赖主从权限一致性、binlog 格式（建议用 ROW 或 MIXED，STATEMENT 在某些事件场景下可能出错）、以及对 DEFINER 和调度器状态的手动管控。漏掉任意一环，事件就只存在于主库，或在从库静默失效。
