server-id重复会导致主从复制直接失败，因主库在io线程握手阶段即拒绝server-id相同的从库连接，报错1236等；必须设为1–4294967295内全局唯一非零整数，修改my.cnf[mysqld]段后重启并执行stop slave; reset slave all; change master to master_server_id=主库值; start slave。
server-id 必须全局唯一，主从重复会导致复制直接失败，不是延迟或报错，而是从库拒绝连接主库。
为什么 server-id 重复会出问题
MySQL 主从复制靠 server-id 区分每个节点身份。IO 线程连接主库时，主库会检查从库传来的 server-id 是否与自己相同——如果一样，主库直接断连，日志里出现 Got fatal error 1236 from master 或 Could not find first log file name in binary log index file；GTID 模式下更严格，直接启动失败。
常见误操作是：主库设为 1，所有从库也设成 1，或者用默认值没改；多从库之间互相设成相同 ID（比如都用 2）。
怎么设置才安全有效
不是“随便填个非零整数就行”，要兼顾可读性、扩展性和运维习惯：
-
server-id必须是1–4294967295范围内的正整数，不能为0 - 主库推荐设为
1，从库建议用有意义的编号，比如101、102（百位代表角色，个位代表序号） - 修改后必须重启 MySQL 服务，
SET GLOBAL server_id = 101;只临时生效，重启即丢 - 确认是否生效，别只看配置文件，登录 MySQL 执行
SELECT @@server_id;查实时值 - 多个从库之间绝对不能重复——哪怕只是暂时测试，也要避免冲突
容易被忽略的细节
server-id 不只是“设个数字”，它和复制行为深度绑定：
- 在级联复制（A→B→C）中，B 既是 A 的从库，又是 C 的主库，它的
server-id必须唯一且不能和 A/C 冲突 - 启用
log_slave_updates = 1（让从库把收到的变更再写进自己的 binlog）时，server-id更关键，否则可能造成日志循环或丢失 - Docker 容器部署时，别依赖镜像默认
server-id = 1，必须在启动时注入或挂载配置覆盖 - Ansible/Terraform 自动化部署时，确保模板里
server-id是变量而非硬编码，否则批量建实例会撞 ID
真正麻烦的不是第一次配对成功，而是扩容新从库或切换主库时，忘了查已有节点的 server-id 分布——线上环境里，一个重复 ID 就能让整个复制链停摆十几分钟。
