last_io_error表明从库无法连接主库或读取binlog，需优先排查网络、权限、binlog存在性及server-uuid/server-id冲突；执行show slave status\g后若slave_io_running为no或connecting，则属io层问题，应直接查看last_io_error字段定位根因。
Last_IO_Error 说明从库连不上主库，或读不到主库的 binlog，不是数据冲突问题，不用查表、不用修 SQL —— 先盯住网络、权限、binlog 存在性、UUID/server-id 这四点。
怎么看是 Last_IO_Error 而不是 Last_SQL_Error
执行 SHOW SLAVE STATUS\G 后，重点看这两行：
-
Slave_IO_Running: No或Connecting→ 就是Last_IO_Error问题 -
Slave_SQL_Running: No→ 才是Last_SQL_Error，和本文无关
只要 Slave_IO_Running 不是 Yes，就别急着 RESET SLAVE，先看 Last_IO_Error 字段里那句原始报错——它直接告诉你卡在哪一环。
常见 Last_IO_Error 类型及对应动作
错误信息不是模糊提示，而是明确指向某个失败环节。按出现频率排序：
-
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs→ 修改从库/var/lib/mysql/auto.cnf中的server-uuid值（不能只改文件，必须重启 mysqld 或执行SELECT UUID()验证生效） -
Last_IO_Error: error connecting to master→ 检查从库能否telnet 主库IP 3306；确认主库bind-address没写成127.0.0.1；检查主库是否给了REPLICATION SLAVE权限且 host 匹配（如用'%'而非'192.168.1.%'） -
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log→ 分两种：
•Could not find first log file name in binary log index file：主库 binlog 被删了，从库记录的Master_Log_File已不存在，需重做同步（CHANGE MASTER TO指向当前SHOW MASTER STATUS的文件+pos）
•master has purged binary logs containing GTIDs that the slave requires：GTID 模式下主库已清理旧 binlog，从库缺失 GTID，只能跳过（SET GLOBAL gtid_purged = '...'）或重搭
为什么改完 auto.cnf 还不生效
MySQL 启动时会读取 auto.cnf 并缓存 server_uuid 到内存，但不会自动刷新。容易踩的坑：
- 改完
auto.cnf没重启 mysqld →SELECT @@server_uuid仍显示旧值 - 误删或覆盖了
auto.cnf文件 → MySQL 启动时会自动生成新 UUID，但下次重启又变，必须保留该文件 - 容器化部署中挂载了空目录覆盖
/var/lib/mysql→auto.cnf被清空，每次启动都生成新 UUID，导致“看似不同实则不稳定”
真正生效的标志只有两个：SELECT @@server_uuid 返回新值，且 SHOW SLAVE STATUS\G 中 Last_IO_Error 消失、Slave_IO_Running 变为 Yes。
磁盘坏道导致的 Last_IO_Error 怎么识别
如果 Last_IO_Error 里出现 I/O error、Input/output error、Bad file descriptor，别急着调 MySQL 参数 —— 这是硬件级问题：
- 立刻查 MySQL 错误日志（通常是
/var/log/mysql/error.log或datadir/hostname.err），搜OS error code 5或sector - 运行
sudo dmesg -T | grep -i "ata\|nvme\|sd\|I/O"，看内核是否已上报磁盘读写失败 - 不要尝试
RESET SLAVE或START SLAVE，IO 线程会反复失败，加重磁盘损伤
这类错误本质不是配置问题，而是存储介质失效。修复前务必先备份还能读出的数据，再换盘重建实例 —— 在坏扇区上硬扛复制，只会让同步延迟越来越不可控。
