背景

有开发找过来说，RDS实例同一个binlog中的server id错乱，影响他们消费binlog，需要排查下原因。

server_id

从 https://dev.mysql.com/doc/refman/5.6/en/replication-options.html#sysvar_server_id 官方文档可知，server id是用来唯一标示MySQL服务的ID。即使是主实例和灾备实例的ID也要是不一样的。虽然server_id动态可改，但在阿里云的实例中没把这个参数透露出来，用户也不能修改。

server id唯一，可以在双主复制模式中用来避免binlog的双向复制。因为这个有部分用户可能会在消费binlog时，用server_id来区分binlog的最初来源，这是不可取的。因为随着实例切换，server_id也会变。比如升级大版本、迁移可用区或备库重搭等操作，server_id就会变了。如果消费binlog建议采用gtid作为binlog的标点，这是唯一的。

binlog记录的正常逻辑

下面是主实例的binlog，server id是主实例的server id：

slave上的server_id Previous-GTIDs是它自己的，后面的都是主实例的server id：

binlog是谁写的，用的谁的server_id，复制的过程中server_id不变，所以对于前几个的event，master是一样的，slave是不一样的。但如果客户消费binlog时，没有区分主备，以server-id为准来判断的话，是不满足的。

参考

https://dev.mysql.com/doc/refman/8.0/en/replication-options.html#sysvar_server_id