MySQL Scheduler Events带来的风险(2)

五、案例回放测试

名称   主库   备库  
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.检查主从scheduer是否开启（mysqladmin var |grep event_scheduler）

主：

从：

3.主库创建schedure相关信息

(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)
此时从库的scheduer也会被执行，如果因为时间等原因的关系，从库先执行了scheduler events，主库再执行然后传输binlog到从库再次执行会导致主从数据不一致，进而导致复制失败，这也就是为什么含有scheduer event的主从架构需要特别注意的原因了。

Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx