20181204 MySQL 双主复制是如何避免回环复制的

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了20181204 MySQL 双主复制是如何避免回环复制的相关的知识,希望对你有一定的参考价值。

问题原因

想要了解这个问题的原因在于有一次面试的时候,面试官问我一个问题,就是mysql的双主复制的时候是如何避免回环复制这个问题的,说老实话在基于GTID复制的时候我还是比较了解的,因为GTID复制是MySQL本身是不会执行已经执行过的GTID事务,即使MySQL本身并不会执行已经执行过的GTID事务,但是还是会形成一个回环复制。那么MySQL到底是如何解决回环复制的呢?

猜想

  1. 在我们搭建主从的时候我们可以清楚的知道,要想成功的搭建主从,那么主从的server_id必须不能一模一样的,所以猜想可能是因为server_id的原因。
  2. 在MySQL 5.5以及一切,我们搭建一主多从的时候,假如slave使用了相同的server_id就会发现在master和slave上面发现slave会经常的断开重连,这个是因为slave在注册的时候会去比对server_id,假如server_id存在的话则会有一个删除操作,但是MySQL 5.6的版本以后引入了uuid,它会优先去比对uuid,假如不存在的话则会去比对server_id。所以在MySQL5.6以及以后是因为uuid的原因呢。

实验

A. 搭建双主。非gtid模式(具体过程不在描述)
master 1

........
........
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 2175
               Relay_Log_File: rep_relay_log.000004
                Relay_Log_Pos: 283
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
........

master 2

                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3385
               Relay_Log_File: rep_relay_log.000004
                Relay_Log_Pos: 1235
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

B . master 1 上面执行创建表语句

mysql> show create table test G
*************************** 1. row ***************************
       Table: test
Create Table: CREATE TABLE `test` (
  `class_num` int(11) NOT NULL AUTO_INCREMENT,
  `class_name` varchar(25) DEFAULT NULL,
  PRIMARY KEY (`class_num`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

C. master 1和2上面分别插入部分数据进行验证。

+-----------+------------+
| class_num | class_name |
+-----------+------------+
|         4 | 物理       |
|         5 | 化学       |
|         6 | 生物       |
|         7 | 体育       |
|         8 | 123        |
+-----------+------------+

D. master 1 上面执行

mysql> stop slave;
mysql> set global server_id=3306;
mysql> start slave;

E. master 2上面执行

mysql> stop slave;
mysql> set global server_id=3307;
mysql> start slave;

F. master 1 上面执行

mysql> insert into test(class_name) values(‘321‘);

G. master 1上面观察

mysql > show slave status;
   ......
     Last_SQL_Error: Error ‘Duplicate entry ‘9‘ for key ‘PRIMARY‘‘ on query. Default database: ‘test‘. Query: ‘insert into test(class_name) values(‘321‘)‘
     Replicate_Ignore_Server_Ids: 
     ......

H. master 1上面执行下面命令,你会发现还是会有这个错误。

mysql> delete from test where class_num=9;
mysql> start slave;
mysql> show slave status;
   ......
     Last_SQL_Error: Error ‘Duplicate entry ‘9‘ for key ‘PRIMARY‘‘ on query. Default database: ‘test‘. Query: ‘insert into test(class_name) values(‘321‘)‘
   ......

I. 解析binlog日志信息:

#181204 16:15:00 server id 3306  end_log_pos 2762 CRC32 0xad6f9e83  Intvar
SET INSERT_ID=9/*!*/;
#181204 16:15:00 server id 3306  end_log_pos 2878 CRC32 0x5cf6d5f2  Query   thread
_id=54  exec_time=124   error_code=0
SET TIMESTAMP=1543911300/*!*/;
insert into test(class_name) values(‘321‘)
/*!*/;
# at 2878
#181204 16:15:00 server id 3306  end_log_pos 2909 CRC32 0x9ccd43ee  Xid = 139
COMMIT/*!*/;
# at 2909
#181204 16:30:52 server id 52213306  end_log_pos 2988 CRC32 0xc9831ff7  Query   thread
_id=54  exec_time=0 error_code=0
SET TIMESTAMP=1543912252/*!*/;
BEGIN
/*!*/;
# at 2988
#181204 16:30:52 server id 52213306  end_log_pos 3096 CRC32 0x37f9c65e  Query   thread
_id=54  exec_time=0 error_code=0
SET TIMESTAMP=1543912252/*!*/;
delete from test where class_num=9
/*!*/;
# at 3096
#181204 16:30:52 server id 52213306  end_log_pos 3127 CRC32 0xc68f6eae  Xid = 151
COMMIT/*!*/;
# at 3127
#181204 16:15:00 server id 3306  end_log_pos 3206 CRC32 0xd5fc40b3  Query   thread
_id=54  exec_time=959   error_code=0
SET TIMESTAMP=1543911300/*!*/;
BEGIN
/*!*/;
# at 3206
# at 3238
#181204 16:15:00 server id 3306  end_log_pos 3238 CRC32 0x52663932  Intvar
SET INSERT_ID=9/*!*/;
#181204 16:15:00 server id 3306  end_log_pos 3354 CRC32 0xc642ad10  Query   thread
_id=54  exec_time=959   error_code=0
SET TIMESTAMP=1543911300/*!*/;
insert into test(class_name) values(‘321‘)
/*!*/;
# at 3354
#181204 16:15:00 server id 3306  end_log_pos 3385 CRC32 0xd5e2ad2a  Xid = 155
COMMIT/*!*/;
DELIMITER ;
# End of log file

可以明显得看得到 insert into test(class_name) values(‘321‘); 这条SQL执行了好多次,这个时候明显可以验证在非GTID复制得情况下面是由于server_id才避免了回环复制。

结论

在进行修改uuid得时候发现这是一个只读参数,不能在修改。并且uuid是MySQL初始化得时候先去auto.cnf文件里面查找,若不存在则会随机生成一串随机码,所以可以直接去除这个。再上面得实验中可以获取得到MySQL再非GTID下面是由server_id得原因才避免了回环复制的,但是GTID环境下面会不会也是因为server_id的原因呢,暂时就没有去验证了。不过我还是认为gtid下面也是因为GTID的原因。

以上是关于20181204 MySQL 双主复制是如何避免回环复制的的主要内容,如果未能解决你的问题,请参考以下文章

MySQL双主复制

Mysql双主互备+keeplived高可用架构(部分)

MySQL双主环境复制延时故障处理

mysql主主复制(双主复制)配置步骤

Mysql主从复制,双主热备

MySQL的主从复制+双主模式