MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ，用于衡量主备之间的复制延迟，但是 今天碰到了一个场景，发现 Seconds_Behind_Master 为 0 ， 备库的 show slave status 显示 IO/SQL 线程都是正常的 ， MySQL 的主库上的变更却长时间无法同步到备库上。如果没有人为干预，直到一个小时以后， MySQL 才会自动重连主库，继续复制主库的变更。

影响范围： MySQL ， Percona ， MariaDB 的所有版本。

虽然这种场景非常特殊，遇到的概率并不高，但是个人觉得有必要提醒一下使用 MySQL 的 DBA 们。通过对这个场景的分析，也有助于我们更加深入的理解 MySQL replication 重试机制。

一、重现步骤

搭建主备的复制，临时断开主库的网络，并 kill 掉主库 MySQL 的 binlog dump 线程。

此时观察备库的复制情况， show slave status 中： …