MySQL 配置延迟从库（master_delay）及疑似BUG

MySQL配置延迟从库，可以在从库设置master_delay参数，单位为秒：
change master to master_delay=86400;
执行之前在需要先stop slave，否则会报错，无法执行；
设置master_delay并重新开启复制start slave后，MySQL从库会清空原有的relay log，并根据上一次的应用位置，重新从主库拉取binlog。所以如果从库原本已经是延迟从库了，需要重新设置延迟数值时，重启从库复制以后，会发现原有的relay log被清空了，并重新生成了序号从1开始的relay log。但不用担心复制会被影响，因重新生成的relay log,是根据上一次从库停止时所应用到的主库log pos重新从主库拉取binlog的。
在5.7版本以后，设置master_delay可以不用完全停止从库复制，只需停止sql thread即可，即stop slave sql_thread，通过这种方式，从库就不会清空relay log并重新拉取主库binlog了。这样可以节省一些网络流量和IO资源。

延迟从库也可以在配置主从复制时指定，如：

change master to 
master_host='',
master_port=3306,
master_user='',
master_password='',
master_delay=86400,
master_auto_position=1;

从我的实践，有遇到延迟复制和并行复制同时开启的BUG，当延迟数值设置较大，同时开启并行复制，过一段时间之后，MySQL从库对延迟时间的判断就会出现异常，会超过所设置的延迟数值很长一段时间后，才应用一个relay log，然后停止，再等待一段比延迟数值大很多的时间，再应用relay log，导致从库复制的延迟越来越大，而且这些情况是已经确认没有大事务的影响。而且出现这种情况之后，无法进行从库复制的任何操作，例如stop slave也会无限期的hang住。最终是通过将slave_parallel_workers设为0，暂时规避了这种问题。上述情况在5.6，5.7版本都有出现。