server_id相同会导致I/O线程卡在Connecting状态，主库握手时校验发现ID重复即拒绝binlog流，I/O线程反复重试但不报连接失败，Last_IO_Error明确提示server_id与主库相同，这是防循环复制的静默丢弃机制。
server_id相同会导致I/O线程卡在Connecting状态
MySQL主从握手时，主库会校验连接方的server_id。如果从库和主库server_id一样，主库直接拒绝提供binlog流，但不会报“连接失败”，而是让I/O线程反复重试——现象是SHOW SLAVE STATUS\G里Slave_IO_Running: Connecting，Last_IO_Error明确提示The server_id value is the same as the master's。
这不是网络或权限问题，是MySQL内建的防循环复制机制：它默认认为“ID相同的节点发来的事件，就是我自己刚写进去的”，必须跳过，否则A写→B执行→B再发回A就成死循环。
- 即使配置文件写了不同值，也要执行
SELECT @@server_id;确认运行时值——动态改过没持久化、重启没生效都会导致假象 -
server_id = 0在5.7中可能启动成功但复制失败；8.0启用log-bin时强制拒绝 - 错误日志里常出现
Failed to request binary log from master: Host 'x.x.x.x' is blocked...，其实是ID冲突的伪装提示
级联复制中重复server_id会让事件被静默丢弃
在旧主→新主→新从这种三级链路里，server_id必须三者互异。如果新从和旧主都是1，新主（server_id=2）执行完事件后生成的新binlog里，事件原始server_id仍是1。新从收到后一看“这ID和我一样”，立刻丢弃，不报错、不写relay log、Relay_Log_Pos不增长，Seconds_Behind_Master停滞——表面正常，实则断流。
- 这种丢弃是MySQL底层行为，
SHOW PROCESSLIST或抓包都看不到异常流量 - 多从库共用一个
server_id更危险：主库binlog只记录第一个连上的从库ID，后续同ID从库收不到自己该处理的事件 - Flink CDC、Canal等binlog客户端也受此约束，它们本质是“逻辑从库”，
server_id必须和所有MySQL实例+其他CDC作业全局不重
server_uuid重复会让GTID模式直接拒绝连接
启用了gtid_mode = ON时，除了server_id，server_uuid也必须唯一。这个值存在/var/lib/mysql/auto.cnf里，MySQL启动时自动生成。用镜像克隆、备份恢复部署多实例时，auto.cnf常被一起复制，导致所有实例server_uuid相同——主从连接瞬间报错：A slave with the same server_uuid/server_id as this slave has connected to the master，错误码1236。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 不能手动编辑
auto.cnf，MySQL启动时会校验格式并拒绝非法内容 - 正确做法：停库 → 删除
auto.cnf→ 启动mysqld，让它自动生成新UUID -
server_id和server_uuid是两套独立校验，缺一不可；哪怕server_id唯一，server_uuid重复照样失败
配置文件里写对位置和格式才能生效
server-id = 1必须放在[mysqld]段内，且只能是纯数字。写错位置或格式，MySQL会静默忽略，运行时值仍是默认1，极易埋下隐患。
- 错误示例：
server-id = "1"（加引号→解析为字符串→转成0）、server-id = 01（前导零→八进制→实际是1）、server-id = 1 # master（注释紧贴→部分版本截断失败） - 写在
[client]、[mysqld_safe]或无节名区域，完全不生效 - 用
!includedir引入多个配置文件时，要检查是否某个被包含文件里也定义了server-id，造成覆盖却不易察觉 - 改完必须重启
mysqld，且从库需重新执行CHANGE MASTER TO——旧复制上下文缓存了初始连接时的server_id信息
真正容易被忽略的是：server_id不是“设了就行”，而是一旦进入复制链路，它就参与每一行binlog事件的标记与过滤。冲突不会炸出来，只会让数据在某一层悄无声息地消失。
