mysql server id长度_MySQL Server-id踩到的坑

司马自明
2023-12-01

标签:

最近踩到一个说大不大,说小不小的坑,在此分享出来给各位同学。事情是这样的,线上有2台服务器,1主1从。A -> B,B服务器从A服务器同步数据。每天使用xtrabackup在B服务器上面进行全备。某天A服务器挂了,后来由于某种原因无法进入系统了,只有重装了系统,那么此时要恢复A服务器的步骤就是在A服务器部署mysql实例,从B服务器上面拿备份恢复到A,再根据POS点change到B服务器,让A服务器从B服务器同步。此时是B -> A。相信熟悉MySQL的人都知道步骤是没有问题的。

但在这过程中还是出问题了,在A服务器从新从B服务器同步完成以后,确认没有延时以后,此时把A重新恢复成了原来的角色,也就是主库,架构又变回了A -> B。恢复完成以后询问开发说没有异常。到第二天的时候有玩家反馈数据不正确。此时进行数据差异的查找。最后发现A的数据比B的数据少。在经过几番查找以及回忆操作步骤以后,发现踩了大坑。那就是我们安装mysql实例的时候,server-id是根据服务器ip地址的后2位生成的,比如ip地址是:192.168.5.6,那么server-id就是56。

有同学会问了,和server-id有毛关系啊。大家仔细想想mysql的双主是怎样确定binlog是否需要应用的?没错,那就是server-id,如果server-id是自己的就不再应用binlog,那么我踩的坑就是当A再次重新向B同步的时候,A的server-id还是老的,没有修改,B服务器的binlog里面记录的server-id就是A服务器的server-id,最后导致有一部分binlog没有应用。原理已经说明了,那么接下来进行简单的实验就可以论证了。

环境:

自己搭建一个测试环境,简单的1主1从。

我主库的server-id是

mysql> show variables like ‘%server_id%‘;+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| server_id | 25152 |

+---------------+-------+

1 row in set (0.00 sec)

从库的server-id是

mysql> show variables like ‘%server_id%‘;+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| server_id | 25250 |

+---------------+-------+

1 row in set (0.00 sec)

主库建库,建表,插入数据:

mysql> create databaseyayun;

Query OK,1 row affected (0.00sec)

mysql> create table yayun.tb1 ( id int, age int, name char(20), primary key(id) );

Query OK,0 rows affected (0.07sec)

mysql> useyayunDatabasechanged

mysql> insert into tb1 (id,age,name)values(1,18,‘aa‘);

Query OK,1 row affected (0.00sec)

mysql> insert into tb1 (id,age,name)values(2,18,‘bb‘);

Query OK,1 row affected (0.00sec)

mysql> select * fromtb1;+----+------+------+

| id | age | name |

+----+------+------+

| 1 | 18 | aa |

| 2 | 18 | bb |

+----+------+------+

2 rows in set (0.00sec)

mysql>

从库查询:

mysql> select * fromtb1;+----+------+------+

| id | age | name |

+----+------+------+

| 1 | 18 | aa |

| 2 | 18 | bb |

+----+------+------+

2 rows in set (0.00sec)

mysql>

此时数据是一致的。

接下来在从库备份数据,并且记录pos点。(这里模拟的是从库每天进行的备份)

mysqldump -uroot -p --master-data=2 yayun > /tmp/backup_yayun.sql

下面在主库继续进行insert,update操作。

mysql> insert into tb1 (id,age,name)values(3,19,‘cc‘);

Query OK,1 row affected (0.00sec)

mysql> update tb1 set name=‘yayun‘ where id=1;

Query OK,1 row affected (0.00sec)

Rows matched:1 Changed: 1 Warnings: 0mysql> select * fromtb1;+----+------+-------+

| id | age | name |

+----+------+-------+

| 1 | 18 | yayun |

| 2 | 18 | bb |

| 3 | 19 | cc |

+----+------+-------+

3 rows in set (0.00sec)

mysql>

查询从库记录:

mysql> select * fromtb1;+----+------+-------+

| id | age | name |

+----+------+-------+

| 1 | 18 | yayun |

| 2 | 18 | bb |

| 3 | 19 | cc |

+----+------+-------+

3 rows in set (0.00sec)

mysql>

可以看到此时主从数据是一致的。接下来我们就当主库挂了。重新需要拉取备份,然后向从库同步数据。

1. 把备份文件backup_yayun.sql拉到主库。

2. 把从库的同步断掉,清掉同步信息。

从库操作:

mysql> stop slave;reset slave all;

Query OK,0 rows affected (0.03sec)

Query OK,0 rows affected (0.05sec)

mysql>

主库操作:

mysql -uroot -p yayun < backup_yayun.sql

查看pos点:

[root@mdw ~]# grep -i change backup_yayun.sql-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000004‘, MASTER_LOG_POS=4070;

[root@mdw~]#

主库change到原来的从库

mysql> CHANGE MASTER TO MASTER_HOST=‘10.36.25.250‘,MASTER_USER=‘repl‘,MASTER_PASSWORD=‘123‘,MASTER_LOG_FILE=‘mysql-bin.000004‘,MASTER_LOG_POS=4070;

Query OK,0 rows affected (0.10sec)

mysql>start slave;

Query OK,0 rows affected (0.00 sec)

查询数据:

如果查询出来的数据是下面的数据,那么就是正确的:

+----+------+-------+

| id | age | name |

+----+------+-------+

| 1 | 18 | yayun |

| 2 | 18 | bb |

| 3 | 19 | cc |

+----+------+-------+

我们实际查询一下:

mysql> select * fromtb1;+----+------+------+

| id | age | name |

+----+------+------+

| 1 | 18 | aa |

| 2 | 18 | bb |

+----+------+------+

2 rows in set (0.00sec)

mysql>

卧槽,发生了什么,怎么数据少了,而且id等于1的name字段结果也不一样?

下面我们看看原来老的从库的binlog

#160908 13:45:57 server id 25152 end_log_pos 4239 Query thread_id=16 exec_time=0 error_code=0SET TIMESTAMP=1473313557/*!*/;

insert into tb1 (id,age,name)values(3,19,‘cc‘)/*!*/;

# at4239#160908 13:45:57 server id 25152 end_log_pos 4266 Xid = 160COMMIT/*!*/;

# at4266#160908 13:46:20 server id 25152 end_log_pos 4325 Query thread_id=16 exec_time=0 error_code=0SET TIMESTAMP=1473313580/*!*/;

BEGIN/*!*/;

# at4325#160908 13:46:20 server id 25152 end_log_pos 4427 Query thread_id=16 exec_time=0 error_code=0SET TIMESTAMP=1473313580/*!*/;

update tb1 set name=‘yayun‘ where id=1

/*!*/;

# at4427#160908 13:46:20 server id 25152 end_log_pos 4454 Xid = 162COMMIT/*!*/;

DELIMITER ;

可以看见有insert,update,但是server id都是25152,也就是主库的。这也就是为什么少了数据的原因。开头也提到过了。

如果我们在新的主库上面进行update,如果这条记录在从库没有存在,而且主从的binlog是row模式,那么就会触发1032错误,复制将中断,由于我的是mixed模式,同步一直没有报错,没有早发现问题。我update语句加limit就会触发row模式,下面我们试试。

主库:

mysql> update tb1 set name=‘abcd‘ where id=3 limit 1;

Query OK,1 row affected (0.00sec)

Rows matched:1 Changed: 1 Warnings: 0mysql>

从库:

mysql>show slave status\G*************************** 1. row ***************************Slave_IO_State: Waitingfor master tosend event

Master_Host:10.36.25.250Master_User: repl

Master_Port:3306Connect_Retry:60Master_Log_File: mysql-bin.000004Read_Master_Log_Pos:4653Relay_Log_File: relaylog.000002Relay_Log_Pos:253Relay_Master_Log_File: mysql-bin.000004Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno:1032Last_Error: Couldnot execute Update_rows event on table yayun.tb1; Can‘t find record in‘tb1‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql-bin.000004, end_log_pos 4626Skip_Counter:0Exec_Master_Log_Pos:4454Relay_Log_Space:601Until_Condition: None

Until_Log_File:

Until_Log_Pos:0Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master:NULLMaster_SSL_Verify_Server_Cert: No

Last_IO_Errno:0Last_IO_Error:

Last_SQL_Errno:1032Last_SQL_Error: Couldnot execute Update_rows event on table yayun.tb1; Can‘t find record in‘tb1‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql-bin.000004, end_log_pos 4626Replicate_Ignore_Server_Ids:

Master_Server_Id:25250

1 row in set (0.00 sec)

可以看见抛1032错误,主库有这条记录,从库没有,同时触发了row模式,就会导致复制中断。

结论:

1. 在重新搭建复制关系的时候一定注意server-id。

2. 线上对数据一致性要求比较高的一定要使用row模式。

标签:

 类似资料: