mysql主从复制原理_mysql高可用基础

来源：这里教程网时间：2026-02-28 20:38:54 作者：

主从复制靠的是 binlog + relay log 两级日志流转

MySQL 主从复制不是实时内存同步，而是基于日志的异步（或半同步）重放。主库把所有写操作记录到

binlog

，从库通过 I/O 线程拉取并存为

relay log

，再由 SQL 线程顺序执行其中的事件。

关键点在于：binlog 格式必须为

ROW

或

MIXED

（不推荐

STATEMENT

，因函数、临时表、非确定性语句易导致主从不一致）；主库需开启

log-bin

，从库需设置

server-id

且唯一。

binlog_format = ROW
是生产环境事实标准，能精确捕获行级变更从库的
relay_log
文件默认命名规则是
hostname-relay-bin.xxxxxx
，不建议手动修改其路径，否则
CHANGE MASTER TO
可能失效 SQL 线程单线程回放 relay log，这是传统主从的性能瓶颈，MySQL 5.7+ 的
slave_parallel_workers > 0
可按库/事务分发，但需配合
slave_parallel_type = LOGICAL_CLOCK

START SLAVE 启动失败常见原因和检查项

执行

START SLAVE

后，

SHOW SLAVE STATUS\G

中

Slave_IO_Running

或

Slave_SQL_Running

为

No

，说明链路中断。不能只看

Seconds_Behind_Master

是否为

NULL

。

IO 线程失败：检查主库网络可达性、复制用户权限（
REPLICATION SLAVE
）、主库
binlog
文件是否被清理（
show master logs
对比
Master_Log_File
）、主库磁盘满导致
binlog
写入失败 SQL 线程失败：最常见于主从数据不一致引发的唯一键冲突、表结构不一致（如从库少字段）、DDL 执行失败（如
DROP TABLE
在从库不存在）、或
binlog_format = STATEMENT
下调用
NOW()
/
UUID()
导致时间/值不一致跳过错误需谨慎：
SET GLOBAL sql_slave_skip_counter = 1
仅对
STATEMENT
格式有效；
mysqlbinlog --stop-never
解析 relay log 定位具体出错 SQL 更可靠

GTID 模式让主从切换更可控，但要求全集群统一开启

启用 GTID（

gtid_mode = ON

enforce_gtid_consistency = ON

）后，每个事务有全局唯一标识，不再依赖

File/Position

。故障切换时，新主库可直接告诉从库“从这个 GTID 集合之后开始同步”，避免找错 binlog 偏移量。

GTID 开启必须重启 MySQL 实例，且主从必须同时开启，混合模式不可行 使用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1
替代手工指定
MASTER_LOG_FILE
和
MASTER_LOG_POS
GTID 不保证事务执行顺序完全一致（例如跨库并发事务在主库提交顺序与从库回放顺序可能不同），但能确保最终一致性 慎用
RESET MASTER
：它会清空所有 binlog 并重置 GTID_EXECUTED，若从库尚未消费完，会导致无法继续同步

主从延迟大不只是网络问题，要盯住 Seconds_Behind_Master 的真实含义

Seconds_Behind_Master

显示的是 SQL 线程执行位置距离当前时间的秒数，不是 IO 线程拉取延迟。它为

仅表示“已执行完当前 relay log 中所有事件”，不代表没有积压——如果 IO 线程卡住，这个值可能长时间为

，但实际已落后。

真正判断延迟要看：
Relay_Master_Log_File
和
Exec_Master_Log_Pos
是否追上主库的
File
/
Position
（用
SHOW MASTER STATUS
对比）大事务是最大延迟源：一个耗时 30 分钟的
UPDATE
在从库单线程回放，就会卡住后续所有事务从库负载过高（如慢查询、备份、统计分析）也会拖慢 SQL 线程，建议从库关闭
query_cache_type
，避免缓存锁竞争监控不能只看
Seconds_Behind_Master
，应结合
Seconds_Behind_Master IS NULL
（线程异常）、
Retrieved_Gtid_Set
与
Executed_Gtid_Set
差集大小（GTID 模式下更准）

SELECT 
  @@global.gtid_mode AS gtid_mode,
  @@global.enforce_gtid_consistency AS enforce_gtid_consistency,
  @@global.binlog_format AS binlog_format,
  @@global.log_bin AS log_bin;

主从复制看似配置简单，但 binlog 格式、GTID 开关时机、SQL 线程卡点、以及监控指标的真实含义，这几处一旦设错或忽略，高可用就变成高不可靠。