MySQL Scheduler Events带来的风险

定时任务是开发和运维人员常用的工具，例如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

语法：

来福FM

来福 - 你的私人AI电台

243

查看详情

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;

五、案例回放测试

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的主从架构需要特别注意的原因了。

以上就是MySQL Scheduler Events带来的风险的详细内容，更多请关注php中文网其它相关文章！