错误1593是因主从server-uuid相同所致，与SSL无关；需删除从库datadir下的auto.cnf文件并重启MySQL，使其自动生成新UUID，再启动复制。
1593 报错和 SSL 证书配置完全无关 —— 这是 UUID 冲突，不是证书问题。
为什么 Last_IO_Error 明确说 “equal MySQL server UUIDs” 却有人查 SSL？
因为错误日志里混着 Master_SSL_* 字段（比如 Master_SSL_Verify_Server_Cert: No），容易让人误以为和证书链、CA 配置有关。但注意：错误码 1593 的触发条件只有一条 —— 主库和从库的 server-uuid 相同。SSL 字段只是状态快照，不参与该错误判定。
- MySQL 启动时自动生成并写入
auto.cnf，内容形如[auto]\nserver-uuid=6e8a2b1c-4d5f-11ec-90b8-080027a2b9e8 - 克隆虚拟机、冷备份恢复、Docker 容器未清数据卷 —— 这些操作都会让多个实例共用同一份
auto.cnf -
server-id不同 ≠server-uuid不同；改了server-id但没删auto.cnf，照样报 1593
如何确认确实是 UUID 冲突？
在主库和出问题的从库分别执行：
SELECT @@server_uuid;
如果返回值完全一致，就是它了。别信 show slave status\G 里显示的 Master_UUID 字段为空 —— 那是因为 I/O 线程根本没连上，还没来得及读取主库 UUID。
- 主库查：
SELECT @@server_uuid;→ 得到真实值，比如5a1b2c3d-... - 从库查：
SELECT @@server_uuid;→ 如果也返回5a1b2c3d-...，冲突坐实 - 检查文件：
cat /var/lib/mysql/auto.cnf（路径以datadir为准），看是否被复制过
修复步骤：删 auto.cnf + 重启，不是改配置
不能靠修改 my.cnf 或 SQL 变量解决 —— server-uuid 是只读变量，无法运行时 SET。唯一可靠方式是让 mysqld 在启动时重新生成。
- 停止从库 MySQL：
systemctl stop mysqld（或service mysql stop） - 删除
auto.cnf：rm -f /var/lib/mysql/auto.cnf（路径需匹配你的datadir） - 确认
server-id已设为唯一值（比如主库是1，从库必须不是1） - 启动 MySQL：
systemctl start mysqld→ 启动后自动重建auto.cnf，生成新 UUID - 验证：
SELECT @@server_uuid;应返回新值；再执行START SLAVE;，Slave_IO_Running: Yes
为什么多源复制或 Docker 场景更容易踩这个坑？
因为这些环境天然倾向“复制整套数据目录”，而 auto.cnf 就藏在 datadir 根目录下，极易被一并复制过去，且用户通常不会特意检查它。更隐蔽的是：有些自动化部署脚本会保留原 auto.cnf 并跳过初始化逻辑，导致新实例“带旧身份上线”。
真正需要同步的只有 binlog 位置和 relay log 状态，UUID 必须各管各的 —— 这个边界感，比 SSL 证书的 PEM 路径还刚性。
