定时任务是开发和运维人员常用的工具，例如cron、job、schedule、events scheduler等，这些工具旨在自动化重复执行某些任务。在这里，我们将探讨mysql数据库内置的定时任务——events scheduler带来的风险案例。
一、现象描述
从库出现了数据不同步现象，具体错误如下：
Slave_IO_Running: Yes Slave_SQL_Running: No Last_SQL_Errno: 1032 Last_SQL_Error: Could not execute Delete_rows event on table bs.dg_sale; Can't find record in 'dg_sale', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000079, end_log_pos 159513315
这种现象是由主键问题导致的删除操作失败，从而引发数据同步错误。
二、原因分析
通常，这种错误是因为从库进行了删除操作，导致在数据同步时通过主键查找并删除记录时无法执行删除操作，从而引发主从错误。
通过对比主库和从库的数据，发现表记录数均为0，但自增值不同，且从库没有外部账户访问。这时可能涉及到定时任务的影响。经过排查，主库确实设置了一些events事件，其中一个定时任务涉及到该表的多次查询、删除和插入操作。
在正常情况下，主库创建event schedule时，从库会自动禁用event scheduler。如果需要切换，需要手动启用从库的event scheduler。如果在搭建主从时将已创建的定时任务复制到从库，从库的scheduler可能会被激活，导致主从的scheduler同时执行。
三、处理过程
1.查看从库状态和错误代码信息。
2.检查主库、从库的表数据信息和表结构信息。
show slave status \G
show create table bs.dg_sale \G
select count(1) from bs.dg_sale;
3.分析产生错误的binlog信息。
主库：
show binlog events in 'mysql-bin.000079' from 159512534 limit 10;
mysqlbinlog --base64-output='decode-rows' --start-position=159512534 --stop-position=159512838 -vv mysql-bin.000079 >binlog.txt
4.查看主库/从库events scheduler信息
show variables like 'event_scheduler';
show events;
select EVENT_SCHEMA,EVENT_NAME,STATUS ,EXECUTE_AT,INTERVAL_VALUE from events;
这里可以看到events scheduler
5.禁用从库的events scheduler
set global event_scheduler=0;或者在主库创建时加入DISABLE ON SLAVE
在从库my.cnf配置文件中加入set global event_scheduler=0
6.重新完成数据同步
四、总结和知识扩展
含有scheduler事件的风险项：
1）在主从切换时，新主库需要启用scheduler events
2）含有scheduler的数据库搭建从库时，需要特别注意从库的scheduler events需要被禁用
1.创建mysql events scheduler
语法：
本文档主要讲述的是Android平台ROM的定制及精简教程；本教程主要内容有：Android系统文件夹结构解析、应用软件说明、定制精简、ROM签名把包等内容。本教程测试平台为HTC G2、G3这两个型号，其它机型可以借鉴，刷机有风险，出问题自负。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
CREATE [DEFINER = { user | CURRENT_USER }] EVENT [IF NOT EXISTS] event_name ON SCHEDULE schedule [ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE | DISABLE ON SLAVE] [COMMENT 'string'] DO event_body;
schedule: AT timestamp [+ INTERVAL interval] ... | EVERY interval [STARTS timestamp [+ INTERVAL interval] ...] [ENDS timestamp [+ INTERVAL interval] ...]
interval: quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE | WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE | DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND}
实例：
CREATE EVENT myevent ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR DO UPDATE myschema.mytable SET mycol = mycol + 1;
2.删除mysql events scheduler
语法：
DROP EVENT [IF EXISTS] event_name
3.更改mysql events scheduler
语法：
ALTER [DEFINER = { user | CURRENT_USER }] EVENT event_name [ON SCHEDULE schedule] [ON COMPLETION [NOT] PRESERVE] [RENAME TO new_event_name] [ENABLE | DISABLE | DISABLE ON SLAVE] [COMMENT 'string'] [DO event_body]
实例：
ALTER EVENT no_such_event ON SCHEDULE EVERY '2:3' DAY_HOUR;
五、案例回放测试
| 名称 | 主库 | 备库 |
|---|---|---|
| IP地址 | 192.168.1.1 | 192.168.1.2 |
| OS | RHEL6.6 | RHEL6.6 |
| MySQL | 5.7.21-20 | 5.7.21-20 |
1.部署主从（略）
2.检查主从scheduler是否开启（mysqladmin var |grep event_scheduler）
主：
从：
3.主库创建scheduler相关信息
(root:localhost:Fri Jul 27 14:32:52 2018)[dbtest]>create table t(id int primary key,name varchar(30));
CREATE EVENT ev_test ON SCHEDULE EVERY 1 MINUTE STARTS '2018-07-27 15:58:00' ON COMPLETION PRESERVE ENABLE DO BEGIN insert into t values(1,'N1'),(2,'N2'),(3,'N3');END
4.主从数据检查
show slave status \G
select * from t;
主从状态正常，数据正常。
这里发现并无异常，原因是在主从状态本身存在的情况下，在主库新建scheduler时，从库的scheduler event会被默认设置为disable。
主库：
(root:localhost:Fri Jul 27 16:29:12 2018)[dbtest]>show events;
从库：
(root:localhost:Fri Jul 27 16:29:49 2018)[dbtest]>show events;
5.调整从库的schedule为enable状态
(root:localhost:Fri Jul 27 16:31:37 2018)[dbtest]>alter event ev_test enable;Query OK, 0 rows affected (0.00 sec)此时从库的scheduler也会被执行，如果因为时间等原因的关系，从库先执行了scheduler events，主库再执行然后传输binlog到从库再次执行会导致主从数据不一致，进而导致复制失败，这也就是为什么含有scheduler event的主从架构需要特别注意的原因了。
