参数 server_id 的潜在重要性

一般情况下，server_id 被设置为一个随机数字，只是与其他副本上配置的数字不同，而且一旦设置好，以后一般就不会再查看或更改，通常这没什么问题，但如果忽略了 server_id，就可能导致在下面描述的恢复场景中出现不必要的事务跳过。

 

假设我们有以下拓扑结构：

?

1 2	db2 - primary - server_id = 82 db1 - replica - server_id = 81

 

一旦主数据库（db1）上的流量被转移，我们就可以开始对其进行维护。在维护过程中，磁盘出现了问题，导致 MySQL 中的数据不一致。别担心，我们有当天早些时候从 db2 上获取的备份，让我们使用它吧

?

1 2 3 4

·使用 rsync 将备份从 db2 复制到 db1。 ·使用 xtrabackup 还原数据 ·使用与 db1 崩溃前相同的配置启动 MySQL。(server_id=81）。 ·在设置复制时，可以使用来自 xtrabackup_binlog_info 的复制位置，因为我们需要一致备份是来自 db2 的日志位置。

 

在备份和还原之间，生成了许多需要应用的 binlog，因此我们预计复制需要一些时间才能完全赶上主系统。

复制配置完成后，却发现 binlog 的进度太快。

 

假设使用以下位置配置复制：

?

1 2 3 4 5 6 7

mysql> CHANGE MASTER TO     -> MASTER_HOST='10.10.10.10',     -> MASTER_USER='repluser',     -> MASTER_PASSWORD='XXXXXXXXXXXXXXXX',     -> MASTER_LOG_FILE='mysql-bin.034322',     -> MASTER_LOG_POS=375677230; Query OK, 0 rows affected, 2 warnings (0.36 sec)

 

查看一下复制的状态：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

*************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 10.10.10.10                   Master_User: repluser                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.034324               Read_Master_Log_Pos: 3898727534                Relay_Log_File: mysql-relay-bin.000006               Relay_Log_Pos: 369         Relay_Master_Log_File: mysql-bin.034324              Slave_IO_Running: Yes             Slave_SQL_Running: Yes ...           Exec_Master_Log_Pos: 3898727534 ...         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 2002                   Master_UUID: 94318777-57fe-11ee-a884-b496916f3834              Master_Info_File: mysql.slave_master_info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates            Master_Retry_Count: 86400

注意到奇怪的事情了吗？是的，Seconds_behind_master： 0，即使有大约 40 多个 binlog 需要应用。

它一直以"快节奏"运行；在几分钟内就推进了 40 个 binlog，直到失败：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

mysql> show slave statusG *************************** 1. row ***************************                Slave_IO_State:                   Master_Host: 10.10.10.10                   Master_User: repluser                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.034372           Read_Master_Log_Pos: 107962899                Relay_Log_File: mysql-relay-bin.000086                 Relay_Log_Pos: 6294         Relay_Master_Log_File: mysql-bin.034364              Slave_IO_Running: No             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: 1032                    Last_Error: Could not execute Update_rows event on table test.mysql1; Can't find record in mysql1, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.034364, end_log_pos 123596930

 

怎么回事？我们的备份坏了吗？

检查 binlog 后发现，"处理速度过快"由 server_id=81 导致的，而 server_id=81 与当前副本相同（因为这些记录是在 db1 上生成的，备份时 db1 是主服务器）。一旦尝试在具有相同 server_id 的服务器上应用这些记录，就会跳过这些记录。

然后，一旦完成故障转移，binlogs 事件就会以 server_id=82 (db2)生成。这时它开始实际应用事件，但由于它跳过了来自同一 server_id 的多个事件，因此错过了对数据库的许多更新和插入，导致数据库处于不一致状态。在这种情况下，别无他法，只能重试还原，这次要在开始复制前更改还原服务器上的 server_id 值。

 

除更改 server_id 外，另一种可行的方法是启用选项 replicate-same-server-id。根据文档："该选项用于复制。默认值为 0（FALSE）。将该选项设置为 1（TRUE）后，副本不会跳过具有自己 server ID 的事件。此设置通常只在罕见配置中有用"。

 

提醒了我们，在复制环境中执行还原时要检查 server_id。这可以避免令人头疼的问题！

 

需要提醒的是，除非我们确定自己在做什么，否则不建议使用 "replicate-same-server-id "参数。