MySQL 主从复制的原理是什么？主从延迟怎么处理？

详细解析#

复制的流程#

主库：事务提交 → 写 binlog → binlog dump 线程
                                   │ 网络
                                   ▼
从库：I/O 线程（receiver）→ 写入 relay log
        → SQL 线程（applier）读 relay log 回放，写入从库数据
          多线程复制时：coordinator 线程按依赖关系分发给 worker 1..N 并行回放

1. 主库提交事务时写 binlog，提交过程见 两阶段提交
2. 从库执行 START REPLICA 后，I/O 线程连接主库，主库为它启动一个 binlog dump 线程，把 binlog 事件发送过来
3. I/O 线程把收到的事件写进 relay log
4. SQL 线程读 relay log 并回放。MySQL 8.0.27 起 replica_parallel_workers 默认是 4，从库默认就是多线程回放

MySQL 8.0.22 起，START SLAVE、SHOW SLAVE STATUS 这类语句改名为 START REPLICA、SHOW REPLICA STATUS，输出里的延迟字段也从 Seconds_Behind_Master 改叫 Seconds_Behind_Source；MySQL 8.4 已经不再支持旧语句。

复制用的 binlog 格式默认是 ROW，记录每一行修改前后的值，从库回放的结果是确定的；STATEMENT 格式下 UUID() 这类结果不确定的语句会让主从不一致，三种格式的对比见 binlog 的格式。MySQL 8.0.34 起 binlog_format 变量已标为弃用，方向是只保留 ROW，新搭建的复制都应该用 ROW。

异步、半同步和 GTID#

半同步等待超时（rpl_semi_sync_source_timeout，默认 10 秒）后会自动退化为异步，有从库追上后再恢复，所以它保证的是"尽量不丢"，不是绝对不丢。

GTID（全局事务 ID）的格式是 源服务器 UUID:事务序号，比如 3E11FA47-71CA-11E1-9E33-C80AA9429562:23。开启 gtid_mode = ON 和 enforce_gtid_consistency = ON 后，每个从库都记录自己执行过哪些 GTID，主从切换时，从库连上新主库用 SOURCE_AUTO_POSITION = 1 自动协商从哪里继续，不用人工去找 binlog 文件名和位点。

延迟的原因和处理#

监控延迟看 SHOW REPLICA STATUS 的 Seconds_Behind_Source：它是从库当前时间减去正在回放的事件在主库上的时间戳。SQL 线程没运行时它是 NULL；它只反映 relay log 已收到部分的回放进度，网络慢时 I/O 线程落后，它却可能显示 0。更准确的做法是用 pt-heartbeat 这类心跳表：主库定时写入当前时间，从库读出来和自己的时间比较。MySQL 8.0 的 performance_schema.replication_applier_status_by_worker 还记录了每个 worker 最近回放的事务在源库的提交时间和在从库回放完成的时间，两者相减就是这个事务实际的延迟。

读写分离读到旧数据怎么办#

1. 关键读走主库：支付结果、库存这类必须最新的读，直接查主库
2. 写后一段时间读主库：用户写完后的几秒内，他的读请求都路由到主库，比如在会话或缓存里记一个时间戳，时长参考监控到的延迟
3. 等待 GTID：写完拿到事务的 GTID，读之前在从库执行 WAIT_FOR_EXECUTED_GTID_SET(gtid, timeout)，返回 0 说明已经回放，返回 1 说明超时，超时就改读主库
4. 剔除延迟大的从库：中间件或代理定期检查延迟，超过阈值的从库暂时不分配读请求

代码示例#

方案 3 的实现（Node.js + mysql2，主从都要开启 GTID）：

// 在主库执行写事务，返回这个事务的 GTID
async function writeOnPrimary(primary, sql, params) {
  const conn = await primary.getConnection()
  try {
    await conn.query("SET SESSION session_track_gtids = 'OWN_GTID'")
    await conn.beginTransaction()
    await conn.query(sql, params)
    const [ok] = await conn.query('COMMIT') // 服务端在 COMMIT 的 OK 包里带回 GTID
    // stateChanges 是 mysql2 对 OK 包里会话跟踪信息的解析结果，源码里有，文档和类型定义里没写
    // 取不到时返回 null，后面的读请求直接走主库
    return ok.stateChanges?.gtids?.[0] || null
  } catch (err) {
    await conn.rollback()
    throw err
  } finally {
    conn.release()
  }
}

// 写后读：让从库最多等 1 秒，等不到或出错就读主库
async function readAfterWrite(primary, replica, gtid, sql, params) {
  if (gtid) {
    let conn
    try {
      conn = await replica.getConnection()
      const [[{ r }]] = await conn.query('SELECT WAIT_FOR_EXECUTED_GTID_SET(?, 1) AS r', [gtid])
      if (r === 0) {
        const [rows] = await conn.query(sql, params)
        return rows
      }
    } catch {
      // 从库连不上、没开 GTID 等情况，降级读主库
    } finally {
      conn?.release()
    }
  }
  const [rows] = await primary.query(sql, params)
  return rows
}

跨请求使用时，把 GTID 放进用户会话，后续请求带着它去从库读。等待会占用从库连接，超时时间要设得短。驱动拿不到 OK 包里的 GTID 时，也可以在提交后查主库的 @@GLOBAL.gtid_executed，让从库等这整个集合，会多等一些，但同样能读到自己的写入。

面试官可能追问#

易错点#

• 半同步只保证从库收到了 binlog，不保证已经回放，读从库仍然可能读到旧数据
• Seconds_Behind_Source 为 0 不代表没有延迟，为 NULL 往往是复制线程停了，都要结合线程状态一起看
• binlog 是主库写的，relay log 是从库上的；从库能否把回放的事务再写进自己的 binlog（级联复制要用到）由 log_replica_updates 控制
• 并行复制对单个大事务没有帮助，大事务只能拆小