大厂如何基于binlog解决多机房同步mysql数据?

Posted 享学课堂online

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大厂如何基于binlog解决多机房同步mysql数据?相关的知识,希望对你有一定的参考价值。

前言

在前一篇文章中,老顾介绍了如何基于binlog实现多机房mysql同步的方案;在这篇文章最后遗留了回环问题,今天这篇文章我们就来看看如何解决回环的问题。

问题本质

大厂如何基于binlog解决多机房同步mysql数据(二)?

所有产生的回环问题,就是北京DB产生了binlog;更新到了上海DB,上海DB又产生了binlog,北京的订阅服务又订阅到了此binlog;但此时由上海DB产生的binlog应该要过滤掉,而不是执行。

问题的本质只要我们能够过滤掉回环过来的binlog或者即使执行了回环过来的binlog也不会产生数据的更新即可。

我们先来看看,现在大家都用了哪些方案去解决此类问题。

往目标库插入不生成binlog

此方案的想法是就是让上海DB不产生binlog;设置参数set sql_log_bin=0,这样就不会产生binlog。

我们先看一下当前的binlog;

show binlog events

大厂如何基于binlog解决多机房同步mysql数据(二)?

插入一条语句,再次查看binlog;的确没有产生新的binlog事件

大厂如何基于binlog解决多机房同步mysql数据(二)?

通过这种方式,貌似可以解决数据回环问题。目标库不产生binlog,就不会被北京订阅组件同步到binlog。

但是这种方案是不可行的,因为我们上海的DB也是集群部署,如:一主多从;如果我们往master节点插入数据,如果不产生binlog,那么slave节点也无法同步数据。这个不是我们想要的。

控制binlog同步方向

既然不产生binlog不能解决问题。那我们控制回环过来binlog不执行,插入某个库之前,我们先判断这条记录是不是原本就是这个库产生的,如果是,那么就抛弃,也可以避免回环问题。

那我们看看如何给binlog加个标记,标记出来源哪个mysql集群。

ROW模式下记录sql

mysql主从同步,binlog复制一般有3种模式。STATEMENT,ROW,MIXED。默认情况下,STATEMENT模式只记录SQL语句,ROW模式只记录字段变更前后的值,MIXED模式是二者混合。binlog同步一般使用的都是ROW模式,高版本Mysql主从同步默认也是ROW模式。

我们想采取的方案是,在执行的SQL之前加上一段特殊标记,表示这个SQL的来源。例如

/*IDC1:DB1*/insert into users(namevalues("gujiachun")

其中/IDC1:DB1/是一个注释,表示这个SQL原始是在IDC1的DB1中产生的。之后,在同步的时候,解析出SQL中的IDC信息,就能判断出是不是自己产生的数据。

然而,ROW模式下,默认只记录变更前后的值,不记录SQL。所以,我们要通过一个开关,让Mysql在ROW模式下也记录INSERT、UPDATE、DELETE的SQL语句。具体做法是,在mysql的配置文件中,添加以下配置:

binlog_rows_query_log_events =1

这个配置可以让mysql在binlog中产生ROWS_QUERY_LOG_EVENT类型的binlog事件,其记录的就是执行的SQL。

通过这种方式,我们就记录下的一个binlog最初是由哪一个集群产生的,之后在同步的时候,判断目标机房和当前binlog中包含的机房相同,则抛弃这条数据,从而避免回环。

这种思路,功能上没问题,但是在实践中,确实非常麻烦。首先,让业务对执行的每条sql都加上一个这样的标识,几乎不可能。另外,如果忘记加了,就不知道数据的来源了。

如果采用这种方案,可以考虑在数据库访问层中间件层面添加支持在sql之前增加/../的功能,统一对业务屏蔽。即使这样,也不完美,不能保证所有的sql都通过中间件来来写入,例如DBA的一些日常运维操作,或者手工通过mysql命令行来操作数据库时,肯定会存在没有添加机房信息的情况。

总的来说,这个方案没有落地执行。

通过附加表记录binlog产生源集群信息

这种方案目前很多公司使用。大致思路是,在db中都加一张额外的表,例如叫direction,记录一个binlog产生的源集群的信息。例如

CREATE TABLE `direction` (  `idc` varchar(255not null,  `db_cluster` varchar(255not null,) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

idc字段用于记录某条记录原始产生的IDC,db_cluster用于记录原始产生的数据库集群(注意这里要使用集群的名称,不能是server_id,因为可能会发生主从切换)。

假设用户在IDC1的库A插入的一条记录(也可以在事务中插入多条记录,单条记录,即使不开启事务,mysql默认也会开启事务):

BEGIN;insert into users(namevalues("gujiachun”);COMMIT;

那么A库数据binlog通过更新数据同步到目标库B时,可以提前对事务中的信息可以进行一些修改,如下所示:

BEGIN;#往目标库同步时,首先额外插入一条记录,表示这个事务中的数据都是A产生的。insert into direction(idc,db_cluster) values("IDC1”,"DB_A”)#插入原来的记录信息insert into users(namevalues("tianshouzhi”);COMMIT;

之后B库的数据往A同步时,就可以根据binlog中的第一条记录的信息,判断这个记录原本就是A产生的,进行抛弃,通过这种方式来避免回环。这种方案已经已经过很多的公司的实际验证。

通过GTID

Mysql 5.6引入了GTID(全局事务id)的概念,极大的简化的DBA的运维。在数据同步的场景下,GTID依然也可以发挥极大的威力。

GTID 由2个部分组成:

server_uuid:transaction_id

其中server_uuid是mysql随机生成的,全局唯一。transaction_id事务id,默认情况下每次插入一个事务,transaction_id自增1。我们看看如何避免回环、数据重复插入的问题。

GTID提供了一个会话级变量gtid_next,指示如何产生下一个GTID。可能的取值如下:

AUTOMATIC:自动生成下一个GTID,实现上是分配一个当前实例上尚未执行过的序号最小的GTID。

ANONYMOUS:设置后执行事务不会产生GTID,显示指定的GTID。

默认情况下,是AUTOMATIC,也就是自动生成的,例如我们执行sql:

insert into users(namevalues("tianbowen”);

产生的binlog信息如下:

大厂如何基于binlog解决多机房同步mysql数据(二)?

可以看到,GTID会在每个事务(Query->...->Xid)之前,设置这个事务下一次要使用到的GTID。

从源库订阅binlog的时候,由于这个GTID也可以被解析到,之后在往目标库同步数据的时候,我们可以显示的的指定这个GTID,不让目标自动生成。也就是说,往目标库,同步数据时,变成了2条SQL:

SET GTID_NEXT= '09530823-4f7d-11e9-b569-00163e121964:1’insert into users(name) values("tianbowen")

由于我们显示指定了GTID,目标库就会使用这个GTID当做当前事务ID,不会自动生成。同样,这个操作也会在目标库产生binlog信息,需要同步回源库。再往源库同步时,我们按照相同的方式,先设置GTID,在执行解析binlog后得到的SQL,还是上面的内容

SET GTID_NEXT= '09530823-4f7d-11e9-b569-00163e121964:1'insert into users(name) values("tianbowen")

由于这个GTID在源库中已经存在了,插入记录将会被忽略,演示如下:

大厂如何基于binlog解决多机房同步mysql数据(二)?

注意这里,对于一条insert语句,其影响的记录函数居然为0,也就会插入并没有产生记录,也就不会产生binlog,避免了循环问题。

如何做到的呢?mysql会记录自己执行过的所有GTID,当判断一个GTID已经执行过,就会忽略。通过如下sql查看:

大厂如何基于binlog解决多机房同步mysql数据(二)?

上述value部分,冒号":"前面的是server_uuid,冒号后面的1-5,是一个范围,表示已经执行过1,2,3,4,5这个几个transaction_id。这里就能解释了,在GTID模式的情况下,为什么前面的插入语句影响的记录函数为0了。

显然,GTID除了可以帮助我们避免数据回环问题,还可以帮助我们解决数据重复插入的问题,对于一条没有主键或者唯一索引的记录,即使重复插入也没有,只要GTID已经执行过,之后的重复插入都会忽略。

当然,我们还可以做得更加细致,不需要每次都往目标库设置GTID_NEXT,这毕竟是一次网络通信。在往目标库插入数据之前,先判断目标库的server_uuid是不是和当前binlog事务信息携带的server_uuid相同,如果相同,则可以直接丢弃。查看目标库的gtid,可以通过以下sql执行:

大厂如何基于binlog解决多机房同步mysql数据(二)?

GTID应该算是一个终极的数据回环解决方案,mysql原生自带,比添加一个辅助表的方式更轻量,开销也更低。需要注意的是,这倒并不是一定说GTID的方案就比辅助表好,因为辅助表可以添加机房等额外信息。在一些场景下,如果下游需要知道这条记录原始产生的机房,还是需要使用辅助表。

总结

讲到这里关于多机房同步mysql数据的方案已经介绍完整;当然具体用哪些开源组件在这些方面做的比较好。建议的首选,是canal/otter组合。

canal的作用就是类似于前面所述的binlog订阅组件,拉取解析binlog。otter是canal的客户端,专门用于进行数据同步,类似于前文所讲解的更新数据组件。并且,canal的最新版本已经实现了GTID。

当然现在最新的canal客户端,提供了client.adapter同步组件,只要简单的配置,就能达到数据同步。小伙伴们可以自行尝试。以后老顾也会介绍canal的实战。谢谢!!!

大厂如何基于binlog解决多机房同步mysql数据(二)?

分享、在看与点赞都在这儿
点下给小编加点料

以上是关于大厂如何基于binlog解决多机房同步mysql数据?的主要内容,如果未能解决你的问题,请参考以下文章

MYSQL主从不同步延迟原理分析及解决方案

MySQL中主从复制不同步?

Mysql基于binlog方式进行数据同步常见问题解决方案汇总

mysql跨机房异地区的主从数据库同步备份业务实现解决方案

Mysql binlog 详细解读

MySQL 5.7基于GTID及多线程主从复制