您的位置:首页 > 数据库 > > 正文

mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

更多 时间:2021-10-27 10:12:22 类别:数据库 浏览量:668

mysql 双主双备

MySQL配置了双主,是如何避免出现数据回环冲突的

不知道大家想过这个问题没有?如果配置了双主,是如何避免出现数据回环冲突的,因为在数据双活的设计方案中,这可以算是方案的核心设计思想之一。

如果主库触发sql语句:

  • ?
  • 1
  • insert into test_data(name) values(‘aa');
  • 那么master1生成binlog,推送数据变化到master2,在master2上面生成relay log,然后交由sql thread进行变更重放,反之也是类似的流程,整个流程可以这样描述。

    mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

    如果master2消费了relay的数据,然后会产生binlog(log_slave_updates默认开启),这个时候产生的binlog会继续推送到master1消费,然后来来回回推送,一套insert语句就无穷无尽了,显然这种设计是不合理的,mysql也肯定不会这么做。

    那么问题的关键的部分就是:master2是否推送了先前的binlog到master1?

    a) 如果推送了,master1是如何过滤,避免后续无限循环

    b) 如果没有推送,master2是如何过滤的

    如果要理解这个过程,我们就需要模拟测试,查看数据流转过程中的binlog情况,可以参考这个流程。

    1) master1的binlog

    2) master2的 relay log

    3) master的binlog

    很快就部署好了一套主从环境,然后添加change master to 就快速搭建好了一套测试的双主环境。

    为了尽可能看到完整的binlog事件信息,我们开启参数binlog_rows_query_log_events

    在master1触发语句:

  • ?
  • 1
  • insert into test_data(name) values(‘gg');
  • 得到的binlog事件如下,可以清楚的看到相关的sql语句。

    mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

    在master2端,我们查看binlog的情况,在开启binlog_rows_query_log_events的前提下会看到明显少了事件:rows_query.

    mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

    此时需要思考的是,在这个过程中偏移量是否发生了变化,从master1产生的binlog到master的relay log,如果通过mysqlbinlog去解析,得到的偏移量情况都是一模一样,而在master2消费后,产生了相关的binlog信息。

    问题的关键就在这里,在maser2里面是通过server_id来标注了数据的源头,所以在这里就称为整个数据流转的终点了,也就意味着数据复制的时候是按照server_id来进行u过滤的,每个master端只会传送自己相关的binlog信息。

    如果从这个角度来说,mysql对于复制中的server_id如此重要的一个原因就是基于此。

    而如果换一个角度,看待基于偏移量的异步复制,其实也可以得到类似的信息。

    这是master1触发insert语句后的binlog细节。

    mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

    这是master2接受实时数据后的binlog细节。

    mysql 双主双备(MySQL配置了双主,是如何避免出现数据回环冲突的)

    其实看到这里,还存在一个问题,那就是在偏移量模式下,如果需要一个数据变更操作在master2丢失了,那么是没有办法进行回溯的。

    而基于gtid模式可以唯一性标识全局事务,那么哪怕对这个操作进行了重复应用,哪怕是ddl语句,操作的影响行数也是0.

    我们对一个已经执行的操作进行再次应用,看看mysql是否会自动舍弃该类操作。

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • mysql> set @@session.gtid_next= '6fb744dd-05dd-11ea-ada7-52540043a8b5:6';
  •  
  • query ok, 0 rows affected (0.00 sec)
  •  
  • mysql> use `test`; create table test_data (id int primary key auto_increment,name varchar(30));
  •  
  • database changed
  •  
  • query ok, 0 rows affected (0.00 sec)
  • 查看show binlog events发现这个过程不会产生额外的binlog。

    所以基于此,我们也基本明确了数据回环解决方法的一个设计思想,那就是如何让mysql能够识别出那些已经应用的事务数据,我想gtid是一个答案,而且分布式id不用,这是mysql内部的处理机制,而且是mysql能够识别的方式。

    以上就是mysql配置了双主,是如何避免出现数据回环冲突的的详细内容,更多关于mysql 避免数据回环冲突的资料请关注开心学习网其它相关文章!

    原文链接:https://cloud.tencent.com/developer/article/1538796

    您可能感兴趣