mysql主从复制原理详解

周三下午四点二十，业务在群里发了张截图，订单列表刷出来还是半小时前的状态。主库 10.30.4.11，一主两从，MySQL 8.0.32，读流量走从库。登上 10.30.4.12 看状态。

mysql> SHOW SLAVE STATUS\G
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
                  Last_IO_Errno: 1236
                  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'
               Master_Log_File: binlog.000187
        Read_Master_Log_Pos: 4

SQL 线程还在啃 relay log，IO 线程已经取不到主库的 binlog。先看数据盘：

/dev/vdb1       500G  122G  353G  26% /var/lib/mysql

还剩 353G，relay_log_space_limit 是 0，relay_log 目录里最大的文件 148M。

上主库看二进制日志列表：

mysql> SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000191 | 268435456 | No        |
| binlog.000192 | 104858012 | No        |
+---------------+-----------+-----------+

binlog.000187 不见了。主库上 binlog_expire_logs_seconds 配的是 259200，binlog.000187 的 mtime 是三天前 23:41，凌晨那次自动清理把它删了。10.30.4.12 的 IO 线程上周因为网络抖动断过一次，恢复后一直在补，补到 187 的时候文件已经没了。主从复制原理详解里最容易跳过的一环就在这——IO 线程不是订阅一条变更流，它拿着 Master_Log_File 和 Read_Master_Log_Pos 这对坐标去主库 dump 线程要数据，坐标对应的文件被 purge 掉，dump 线程直接回 1236。

想过在从库上 CHANGE MASTER TO 到 binlog.000191 的某个 position 直接跳过去，也想过开 slave_skip_errors 把中间的事务吞掉。gtid_mode 是 OFF，两个从库都停在同一个位置，跳过去等于默认丢掉这三天的订单写入，没动。

从主库重做全量。xtrabackup：

xtrabackup --backup --host=10.30.4.11 --user=bkp --password=xxx \
  --target-dir=/data/bkp/full_20260715
[01] Copying ./ibdata1 to /data/bkp/full_20260715/ibdata1
[01] Finished backing up non-InnoDB files
[00] Writing /data/bkp/full_20260715/xtrabackup_binlog_info
xtrabackup: Transaction log of lsn (45283174621) to (45283178004) was copied.

cat xtrabackup_binlog_info 拿到坐标 binlog.000192 104857712。`xtrabackup –prepare –target-dir=/data/bkp/full_20260715` 跑完 rsync 到从库，chown -R mysql:mysql /var/lib/mysql，起 mysqld。

mysql> CHANGE MASTER TO MASTER_HOST='10.30.4.11', MASTER_USER='repl',
    -> MASTER_PASSWORD='xxx', MASTER_LOG_FILE='binlog.000192', MASTER_LOG_POS=104857712;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0

vdb1 用量从 122G 涨到 178G。主库 binlog_expire_logs_seconds 从 259200 调到 604800，另外挂了个每分钟采一次 Seconds_Behind_Master 的脚本，超过 600 秒直接打告警电话。

参考：MySQL 8.0 复制官方文档 dev.mysql.com/doc/refman/8.0/en/replication.html