有朋友的一对 MySQL 出现远大于其他类似实例的大量更新。因为开启了主备双向复制和 log_slave_updates，所以首先猜测是不是有循环复制，主 stop slave 后暂时正常。看了下主上的 relay_log，验证了这一点。幸而来回复制的只是监控用的心跳更新，不会搞坏数据。

但是 MySQL 会比较 server_id ，一般情况下是不会出问题的。于是又仔细看了下主上不正常的 relay_log ，发现其中 event 的 server_id 和当前的都不同。 问下来确实曾经在线改过 server_id。

想了下怎么触发这个问题，在自己的实例上复现了一把

1. 开启 主->备 的复制
2. 主上插入若干记录
3. 更改主的server_id
4. 开启 备->主 的复制
5. 轰！

实际操作中，由于存在复制延时，即使没有先停止备->的复制也有可能触发问题。

然后就是怎么拆掉这个雷了。由于来回复制的只是心跳更新，所以只需要跳过就行，其实如果不是的话也已经完蛋没法救了。首先想到的是 binlog_ignore_db 和 replicate_ignore_db 。但是这两个不是动态变量，重启一次服务代价太大。同事 @Tachikoma 提醒我 change master 还有个 ignore_server_ids 选项。于是就只需要 change master to ignore_server_ids (1,2) 忽略之前的 server_id 就行。待复制正常，change master to ignore_server_ids () 就可以解除掉了。