Skip to main content

QA MySQL主从复制了解吗

面试中问到“MySQL主从复制了解吗”，通常会考察你对复制原理、用途、常见模式及潜在问题的理解。以下是一个可供参考的完整回答思路：

1. 基本概念​

MySQL 主从复制是指数据可以从一个 MySQL 数据库服务器（主库，Master）复制到一个或多个 MySQL 数据库服务器（从库，Slave）。默认采用异步复制方式，主库执行事务后不等待从库确认就直接返回，从库通过读取主库的 binlog（二进制日志）来重放操作，从而实现数据同步。

2. 复制原理（三个核心线程）​

  • 主库：Binlog Dump 线程
    主库将数据库更改记录到二进制日志（binlog）中；当从库连接时，主库为该从库创建一个线程，负责读取 binlog 中的事件并发送给从库。

  • 从库：I/O 线程
    从库通过 CHANGE MASTER TO 配置主库信息，然后启动 I/O 线程。该线程连接到主库并请求 binlog 内容，接收到后将事件写入从库的 中继日志（relay log）。

  • 从库：SQL 线程
    从库的 SQL 线程读取中继日志中的事件，并在从库上执行这些操作，从而实现数据同步。

流程图可简述为：
Master 提交事务 → 写入 binlog → Slave I/O 线程拉取并写入 relay log → Slave SQL 线程回放 relay log

3. 复制模式​

  • 异步复制（默认）
    主库提交事务后立即返回客户端，不关心从库是否已接收或重放。性能最好，但若主库故障且数据未同步到从库，可能丢失数据。

  • 半同步复制（需安装插件）
    主库提交事务后，至少等待一个从库确认已收到并写入了 relay log 后才返回。保证至少一个从库有完整日志，降低数据丢失风险。

  • 全同步复制（极少用，如 Group Replication 的某些模式）
    主库需要等待所有从库都执行完事务才返回，数据一致性最高，但性能最低。

  • 组复制（MGR）（高可用方案，可选补充）
    基于 Paxos 协议，保证数据强一致，不是传统主从但面试可拓展。

4. 常见用途​

  • 读写分离：主库处理写操作，从库处理读操作，提升系统并发能力。
  • 数据备份：从库可做热备份，不影响主库性能。
  • 高可用：主库故障时快速切换到从库（配合 MHA、Orchestrator 等工具）。
  • 报表/分析查询：将复杂查询分流到从库，避免阻塞主库业务。

5. 可能存在的问题与解决思路​

  • 复制延迟（Seconds_Behind_Master 较大）

    • 原因：从库硬件差、执行大事务、从库有复杂查询、网络延迟等。
    • 解决：优化从库配置（并行复制、提高磁盘性能）、拆分大事务、使用中间件/数据库代理。

  • 主从数据不一致

    • 原因：异步复制丢数据、误操作从库写了数据、主库 binlog 格式设置不当等。
    • 解决：开启半同步复制、设置 read_only 和 super_read_only、定期校验（如 pt-table-checksum）。

  • 主库故障切换数据丢失

    • 解决：半同步 + 配合可靠故障转移工具（如 MGR、Orchestrator、ProxySQL）。

6. 扩展：GTID 与并行复制​

  • GTID（全局事务标识符）：使主从复制更易维护，故障切换时不需要找 binlog 文件名和位置，自动跳过已执行事务。
  • 并行复制：MySQL 5.7+ 支持基于逻辑时钟的并行回放，可大幅降低延迟。

面试时可以这样说（精简版）​

“MySQL 主从复制通过主库的 binlog 记录所有变更，从库的 I/O 线程拉取日志写入中继日志，再由 SQL 线程重放来实现。

常见的有异步、半同步两种模式。

主要用来做读写分离、数据备份和高可用。

但需要注意复制延迟和数据一致性问题，生产上一般会开启 GTID 和并行复制，并配合半同步减少数据丢失风险。”

如果你想重点考察某个细节（比如 binlog 的三种格式 ROW/STATEMENT/MIXED，或者如何监控延迟），可以继续追问。