server-id必须全局唯一且不能为0，否则主从复制启动失败、I/O线程卡在Connecting状态或报错1236；同时需确保server-uuid也唯一，避免GTID模式下连接拒绝。
server-id 必须全局唯一，不能为 0
MySQL 主从复制启动时，server-id 是识别每台实例身份的硬性标识。如果两台机器配置相同 server-id（比如都设为 1），从库连接主库会直接报错：ERROR 1236 (HY000): A slave with the same server_uuid/server_id as this slave has connected to the master。这个错误不仅出现在真实从库，也会出现在 Flink CDC、Canal 等基于 binlog 的同步客户端上——它们本质上也是“逻辑从库”。server-id 必须是 1–4294967295 范围内的非零整数，且在整个复制拓扑中不能重复。
auto.cnf 中的 server-uuid 决定了 GTID 唯一性
MySQL 5.7 启动时自动生成 server-uuid 并写入数据目录下的 auto.cnf 文件（路径如 /var/lib/mysql/auto.cnf）。这个值是 128 位 UUID，用于 GTID 复制和事务溯源。如果你用克隆镜像或备份恢复方式部署多台 MySQL 实例，auto.cnf 文件极大概率被一并复制，导致所有实例拥有相同的 server-uuid。一旦启用 GTID 模式（gtid_mode=ON），主从将无法建立连接，报错信息中会明确提示 server_uuid 冲突。
- 检查命令：
cat /var/lib/mysql/auto.cnf - 重生成方法：停库 → 删除
auto.cnf→ 启动 mysqld，MySQL 会自动生成新 UUID - 注意：不要手动编辑
auto.cnf，MySQL 启动时会校验并拒绝非法格式
主从配置前必须人工核对并隔离 server-id 和 server-uuid
仅靠“不同机器自然不同”不可靠。云服务器重装系统、Docker 容器反复创建、甚至同一台物理机跑多个 MySQL 实例，都可能让 server-id 或 server-uuid 发生碰撞。实操中建议：
- 主库
server-id固定为1，从库依次设为2、3……避免用随机数； - 所有节点在首次启动 MySQL 前，确认
/var/lib/mysql/auto.cnf不存在或内容唯一； - 若使用自动化部署脚本（Ansible / Shell），必须加入
rm -f /var/lib/mysql/auto.cnf步骤； -
server-id和server-uuid是两个独立约束项，缺一不可：前者控制复制链路注册，后者保障 GTID 全局事务不混淆。
常见误操作：复制完配置就以为万事大吉
很多人改完 /etc/my.cnf 里的 server-id 就重启 MySQL，却忘了 auto.cnf 还躺在那里。更隐蔽的是：某些云平台一键部署的 MySQL 镜像，会在初始化阶段预生成 auto.cnf 并固化进镜像层，导致所有实例 UUID 相同。这种问题不会在配置检查阶段暴露，而是在开启 GTID 或添加第二个从库时突然爆发。真正安全的做法是——每次部署新实例，都执行一次 mysqld --initialize 或至少确保 auto.cnf 是首次启动时生成的。
