MySQL 主从延时备份配置指南

原理与目标

传统的 AB 复制（主从复制）流程中，从服务器会尽可能快地执行中继日志中的事件。当使用延时备份策略时，pt-slave-delay 工具通过拦截 SQL 线程的执行，强制从库暂停同步，直到达到设定的时间差后才重新开启同步。这种机制确保了即使主库数据被清空，延时从库上仍保留着几小时或几天前的完整数据副本。

第1步：准备环境与网络拓扑

为实现主从延时同步，建议采用一主两从的架构，其中一台为即时同步，另一台为延时同步。假设环境如下：

• 主服务器 (Master): IP 192.168.1.11，作为所有读写操作的入口。
• 及时从服务器 (Slave1): IP 192.168.1.18，保持毫秒级同步，用于实时读取或报表查询。
• 延时从服务器 (Slave2): IP 192.168.1.19，配置为落后主库一定时间的备份节点。

操作系统建议使用 RHEL 或 CentOS 64位版本，数据库版本以 MySQL 5.5 为例，需确保各服务器间网络互通。

第2步：基础主从环境搭建

首先，需完成标准的主从复制配置，确保两台从库都能正常同步主库数据。主要步骤包括修改配置文件、创建授权账号及启动 Slave 服务。

1. 配置文件修改
在每台服务器的 /etc/my.cnf 中确保 server-id 唯一且不为0：

# 主服务器 (serv01)
server-id = 1

# 及时从库 (serv08)
server-id = 2

# 延时从库 (serv09)
server-id = 3

2. 重置并清理日志
为避免历史 Binlog 冲突，建议在新环境测试开始时重置主库日志，并从库也重置以确保干净的状态：

mysql> reset master;
mysql> show binary logs;

3. 创建授权用户
在主服务器 192.168.1.11 上创建一个具有复制权限的用户：

mysql> grant replication client, replication slave on *.* to 'larry'@'192.168.1.%' identified by 'larry';

4. 启动从库复制
分别在 serv08 和 serv09 上执行相同的变更主库设置，并启动 Slave：

mysql> change master to
-> master_host='192.168.1.11',
-> master_user='larry',
-> master_password='larry',
-> master_port=3306,
-> master_log_file='mysql-bin.000001',
-> master_log_pos=107;

mysql> start slave;
mysql> show slave status G;

确认输出中 Slave_IO_Running: Yes 且 Slave_SQL_Running: Yes，即表示基础主从环境搭建成功。

第3步：安装 Percona Toolkit

pt-slave-delay 是 Percona Toolkit 的核心组件之一，负责管理从库的延迟行为。需要在执行命令的机器（通常选主库或专门的运维机）上安装该工具包。

可以通过 RPM 包直接安装：

scp percona-toolkit-2.1.7-1.noarch.rpm root@192.168.1.11:/opt
yum install percona-toolkit-2.1.7-1.noarch.rpm -y

第4步：配置延时从库

要使 pt-slave-delay

在延时从库 serv09 (192.168.1.19) 上创建专用账户：

mysql> grant all on *.* to 'rep'@'192.168.1.%' identified by 'larry';

风险提示：grant all 权限过大，生产环境中建议仅授予必要的管理权限或使用 sudo 机制。同时，请确认密码安全。

第5步：启用延时同步功能

在主服务器或其他安装了 Toolkit 的机器上运行 pt-slave-delay。该命令将持续监控指定的从库，并在达到预设延迟后暂停 SQL 线程执行。

pt-slave-delay \
--user='rep' \
--password='larry' \
--delay=3m \
--interval=20s \
--run-time=30m \
192.168.1.19

参数说明：

• --delay=3m: 设定从库落后主库的时间为 3 分钟。单位支持 s(秒), m(分), h(时), d(天)。
• --interval=20s: 工具检查同步状态的间隔频率。
• --run-time=30m: 工具运行的总时长，超时后退出。这对于测试非常重要。
• 192.168.1.19: 延时从库的地址。

运行后，控制台会输出一系列日志，显示 Slave 何时停止 (STOP SLAVE)，何时因新日志到达而重新开始 (START SLAVE)。正常情况下，你应该看到类似 slave stopped at master position... 的提示，这表明延迟正在生效。

第6步：验证延时效果

为了确认配置是否生效，我们在主库进行数据修改，观察即时从库和延时从库的反应差异。

1. 主库写入测试数据：

use justdb;
create table test(id int);
insert into test values(1);

2. 查看即时从库 (serv08)：

select * from justdb.test;
-- 结果: id 1

此时即时从库应当已经能看到新数据。

3. 查看延时从库 (serv09)：

select * from justdb.test;
-- 结果: ERROR 1146 (42S02): Table 'justdb.test' doesn't exist

由于处于延迟期间，延时从库暂时看不到这张表或这条记录，这证明延时缓冲机制已起作用。等待约 3 分钟后，再次查询即可看到数据出现，完成了补落。

排错与维护

常见异常处理

1. 从库报错 (Last_Errno != 0)
如果延时过程中从库发生复制错误，pt-slave-delay 可能会失效。
处理方法：登录从库，手动 stop slave;，检查错误日志修复问题后 start slave;，再重新运行延时脚本。

2. 主从断连
如果在延迟设置期间网络波动导致连接断开，当网络恢复后，工具应能自动检测到并完成追赶。可观察日志中是否有 slave running 0 seconds behind 的重启信息。

自动化部署脚本示例

为了实现开机自启或更便捷的管理，可以将上述命令封装为 System V 风格的 Shell 脚本。

#!/bin/bash
# chkconfig: - 88 12
# description: the mysql ab delay scripts

host=192.168.1.19
user=rep
password=larry
delay=3m
in=15s
prog=/usr/bin/pt-slave-delay

. /etc/init.d/functions

start() {
    echo -n "Starting `basename $prog`..."
    daemon $prog --host=$host --user=$user --password=$password --delay=$delay --interval=$in --daemonize --log=/var/log/mysql-delay.log
    echo
}

stop() {
    echo -n "Stopping `basename $prog`..."
    killproc $prog
    echo
}

case "$1" in
    start)
        start
    stop)
        stop
    restart)
        stop
        start
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

保存为 /etc/init.d/mysqldelay 并添加执行权限，即可通过 service mysqldelay start 进行管理。

总结

通过在 MySQL 主从架构中引入 pt-slave-delay，我们成功构建了抵御人为误操作的一道防火墙。这种方法不仅有效缓解了高并发下的同步压力，更为核心数据提供了关键的时间容错空间。在实际生产部署前，务必先在测试环境充分验证延迟时间与同步稳定性的平衡点。以上就是 MySQL 主从延时备份配置的详细内容，更多关于数据库备份的资料请关注本站其它相关文章！