server-id必须全局唯一且不能为0，否则从库i/o线程卡在connecting状态、sql线程静默跳过事件，导致seconds_behind_master停滞、relay_log_pos不增长；重复时主库binlog记录混乱，多从库共用id则事件分发不可预测。
server-id 必须全局唯一且不能为 0，否则从库 I/O 线程直接卡在 Connecting 状态，根本拉不到 binlog。
为什么 server-id 冲突会导致复制静默失败
MySQL 用 server-id 区分复制链中每个节点身份，不是“随便设个数字就行”。主库和从库 server-id 相同，I/O 线程能连上主库，但 SQL 线程会跳过所有事件——因为它认为“这是我自己刚写进去的日志”，防止循环复制。现象是：SHOW SLAVE STATUS\G 里 Seconds_Behind_Master 停滞、Relay_Log_Pos 不增长、错误日志里没报错，只有静默丢弃。
多个从库共用一个 server-id 更危险：主库 binlog 里记录的 server-id 是第一个连上的那个从库的 ID，后续同 ID 的从库收不到自己应得的事件，行为不可预测。
- 常见错误提示：
The server_id value is the same as the master's、Got fatal error 1236 from master - 别信配置文件写了什么，必须执行
SELECT @@server_id;确认运行时值 -
server-id = 0是非法值，MySQL 启动会失败，错误日志明确提示server_id cannot be 0
怎么安全生成和验证唯一的 server-id
别手填 1、2、100 这类小整数——容易重复，也难追溯。推荐用强绑定实例身份的方式：
- 物理机：用 MAC 地址哈希取低 4 字节转十进制，例如
printf '%s' 'eth0' | md5sum | cut -c1-8 | xargs printf '%d\n' 0x - Docker/K8s：拼接
hostname+pod UID哈希，避免同名 Pod 复用 ID - 云环境：取 instance-id 数字部分（如 AWS
i-0abc123def456789a→ 取456789a转十进制），比私网 IP 稳定得多 - 务必避开
0和1：1是传统 master 默认值，容易被误认；0被 MySQL 当作未设置
验证方式：登录 MySQL 执行 SELECT @@server_id; 和 SHOW VARIABLES LIKE 'server_id';，两者必须一致且非 0。
改完 server-id 后复制还是连不上？重置上下文才生效
server-id 改了但从库还是连不上主库？不是 ID 本身的问题，而是旧连接带着老 ID 的元信息没清理干净。MySQL 不会自动刷新已建立的复制连接。
- 先停复制：
STOP SLAVE; - 清空现有复制配置：
RESET SLAVE ALL;（删掉master.info和relay-log.info，但不删 relay log 文件） - 重新配置主库信息：
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_SERVER_ID=xxx（注意这里MASTER_SERVER_ID是主库的server-id，不是本机的） - 再启动：
START SLAVE;
验证不能只看 Slave_IO_Running: Yes，必须检查 Seconds_Behind_Master 是否开始下降、Relay_Log_Pos 是否增长。
my.cnf 里 server-id 怎么写才不被忽略
server-id 必须写在 [mysqld] 段内，只认纯数字，任何格式错误都会导致被静默忽略或解析失败：
- ✅ 正确：
server-id = 1001003 - ❌ 错误：
server-id = "1"（加引号 → 解析为字符串，转成 0） - ❌ 错误：
server-id = 01（前导零 → 可能被当八进制，实际变成 1） - ❌ 错误：
server-id = 1 # master（注释紧跟值后 → 部分版本截断失败）
改完必须重启 MySQL：systemctl restart mysqld，仅 SET GLOBAL server_id = N 临时生效，重启即丢失；my.cnf 中的值是启动时读取的硬性配置。
真正麻烦的不是配错，而是克隆虚拟机、Docker 容器反复启停、自动化脚本硬编码 server-id = 1 这些场景下，ID 冲突往往藏在 auto.cnf 和 my.cnf 两层配置里，漏查一层就白调。
