主从复制与高可用 - MySQL 教程

讲解

主从复制的原理一句话：主库把变更写进 binlog，从库的 IO 线程把 binlog 拉过去存成 relay log，SQL 线程再逐条重放，于是从库数据跟着主库走。默认是异步复制——主库写完就返回，不等从库确认，所以主从之间永远存在一点延迟（Seconds_Behind_Source）；半同步复制要求至少一个从库收到日志才算提交成功，数据更安全但写入变慢。GTID 给每个事务一个全局唯一编号，让从库定位和故障切换不再需要记「文件名 + 位置」，现代部署建议开启。

复制解决了三类问题：读写分离（写走主库、报表和只读查询走从库）、备份卸载（备份任务在从库上跑，不拖累主库）、灾备（主库挂了把从库提升为主）。再往上是完整的高可用方案：MySQL 官方的 InnoDB Cluster（基于组复制 MGR）提供自动选主和故障转移，业界也有 Orchestrator 这类第三方切换工具。它们都建立在复制之上。

搭建的核心动作：主库确认 binlog 开启并建复制专用账号（只需 REPLICATION SLAVE 权限）；从库执行 CHANGE REPLICATION SOURCE TO 指定主库地址、账号和起始位点（开了 GTID 就用 SOURCE_AUTO_POSITION=1），然后 START REPLICA；日常巡检看 SHOW REPLICA STATUS 里的 Replica_IO_Running、Replica_SQL_Running 是否都是 Yes，以及延迟。本章在同一实例上演示配置命令（真实环境是两台机器），配置完复位清理。

示例

主库侧的准备：确认 binlog 状态，创建只有复制权限的专用账号：

SHOW MASTER STATUS;

SHOW BINARY LOGS;

CREATE USER IF NOT EXISTS repl@'%' IDENTIFIED BY 'Repl#Strong2026';

GRANT REPLICATION SLAVE ON *.* TO repl@'%';

SHOW GRANTS FOR repl@'%';

从库侧的配置（真实环境中这在另一台机器上执行，位点来自主库的 SHOW MASTER STATUS）：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'db-master',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'Repl#Strong2026',
  SOURCE_LOG_FILE = 'binlog.000001',
  SOURCE_LOG_POS = 4;

SHOW REPLICA STATUS\G

演示完毕，复位复制配置并清理账号（生产上 START REPLICA 之后才正式开始同步）：

RESET REPLICA ALL;

DROP USER IF EXISTS repl@'%';

常见坑

从库被人写入：从库本该只读，一条误写入让主从数据分叉，之后重放冲突、复制中断。从库务必设 read_only（管理账号另设 super_read_only）。
server_id 撞车：每个实例的 server_id 必须全局唯一，从库镜像克隆主库配置时最容易带着相同的 server_id，复制直接起不来。
无视延迟做读写分离：刚下单立刻查从库查不到——延迟窗口内的强一致读必须回主库。用 SHOW REPLICA STATUS 的 Seconds_Behind_Source 监控延迟。
脑裂双写：故障切换后老主库没下线又恢复服务，两个「主库」同时收写入，数据彻底乱套。切换流程必须有围栏（fence）机制保证旧主停写。

小结

复制 = 主库 binlog → 从库 relay log → 重放；异步为主、GTID 简化位点管理；用于读写分离、备份卸载、灾备，高可用方案（InnoDB Cluster 等）构建其上。下一章把零散的安全纪律汇总成清单。