MySQL如何快速搭建主从复制环境_使用xtrabackup实现物理备份恢复

陆砚码

2026-09-10 • 👁 1人浏览过

主从搭建前必须确认主库server_id唯一且非1、log_bin=ON、binlog_format=ROW；从库datadir必须为空；xtrabackup备份需加--slave-info、--no-timestamp或--target-dir，GTID模式还需--gtid。主从搭建前必须确认的 3 个检查点不验证这三项，

xtrabackup

恢复后大概率从库起不来或数据不一致。主库

server_id

必须唯一且非 1（从库不能和主库相同），

log_bin

必须为

ON

，否则

SHOW MASTER STATUS

会报错或返回空主库需开启

binlog_format = ROW

，

MIXED

在某些 DDL 场景下会导致从库解析失败，

STATEMENT

则无法支持部分函数和 UDF 从库的

datadir

必须为空，且不能残留

ibdata1

、

ib_logfile*

等文件——

xtrabackup

的

--apply-log

不会覆盖已有 InnoDB 文件，强行恢复会卡在崩溃恢复阶段用 xtrabackup 备份时最容易漏掉的参数只跑

xtrabackup --backup

是不够的；缺了关键参数，备份出来的数据无法用于主从搭建。必须加

--slave-info

：它会在备份目录里生成

xtrabackup_slave_info

，里面包含

CHANGE MASTER TO

所需的

MASTER_LOG_FILE

和

MASTER_LOG_POS

必须加

--no-timestamp

或明确指定

--target-dir

，否则默认按时间戳建子目录，后续

--prepare

和拷贝容易路径出错如果主库用了

gtid_mode = ON

，还得加

--gtid

，否则

xtrabackup_slave_info

不会写入

Executed_Gtid_Set

，从库启动后无法自动定位同步位点示例命令：

xtrabackup --backup --slave-info --no-timestamp --target-dir=/backup/full --user=backup --password=xxx

恢复到从库后 set global read_only=on 不生效？这是常见假象——

read_only

确实生效了，但复制线程（

SQL_THREAD

）被允许绕过它。真正要防写入的是

super_read_only

。 MySQL（Linux） MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。下载

read_only=ON

只限制普通用户，

replication slave

权限用户（如复制账号）仍可执行

INSERT/UPDATE

必须设

super_read_only=ON

，它会同时锁住所有用户（包括拥有

SUPER

权限的用户），但注意：MySQL 5.7.20+ 才支持该变量，低版本只能靠权限控制设完别忘了

STOP SLAVE; START SLAVE;

，否则已有的 SQL 线程可能还在跑旧任务，导致位点错乱从库启动后 Seconds_Behind_Master 一直为 NULL 不是延迟高，而是复制根本没跑起来。最常卡在两个地方：

SHOW SLAVE STATUS\G

中

Slave_IO_Running: No

→ 检查主库网络连通性、复制账号权限（至少需要

REPLICATION SLAVE

）、主库

bind_address

是否监听了从库可访问的 IP

Slave_SQL_Running: No

且

Last_SQL_Errno: 1062

→ 多半是备份时主库有未提交事务，

--apply-log

后残留了部分 binlog event，导致从库重放时主键冲突；此时应清空从库

datadir

，重新

--prepare

并

START SLAVE

如果

Seconds_Behind_Master

显示为

NULL

且

Slave_IO_Running

和

Slave_SQL_Running

都是

Yes

，说明复制已就绪但尚未开始追赶（比如主库当前没新写入），可手动在主库执行

INSERT INTO test.t1 VALUES (now());

触发一次日志写入观察变化物理备份恢复主从，最难的从来不是命令怎么敲，而是每一步的“状态是否真的符合预期”——

SHOW SLAVE STATUS

要逐字段看，

SELECT @@global.gtid_executed

和

SELECT @@global.gtid_purged

在 GTID 模式下必须对得上，差一个字符都会让 START SLAVE 失败。

相关文章