消费RDS MySQL binlog时以server_id为准不可取-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

消费RDS MySQL binlog时以server_id为准不可取

简介: RDS实例同一个binlog中的server id错乱,影响他们消费binlog,需要排查下原因。

背景

有开发找过来说,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:

image


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

image

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
最新文章
相关文章
链接