卡塔尔世界杯排名_98世界杯决赛 - dylfjc.com

MySQL 数据库备份与恢复实战：mysqldump、binlog 与定时脚本

博客 › 数据备份

MySQL 数据库备份与恢复实战：mysqldump、binlog 与定时脚本

作者：GcmodAi · 2026-08-10 · 数据备份 · 约 8 分钟阅读 · 阅读 0 · GcmodAi

数据库备份这件事，平时毫无存在感，出事时才知道它的分量。误删数据、升级失败、磁盘损坏，任何一个场景下，"有备份"和"能恢复"是两个完全不同的概念。本文介绍 MySQL 最实用的备份体系：每日全量 + binlog 增量，并附一套可直接使用的定时备份脚本。

一、先理清备份类型

逻辑备份（mysqldump）：导出为 SQL 文本，可读、可跨版本迁移，适合中小库，恢复速度较慢。

物理备份（xtrabackup）：直接拷贝数据文件，速度快、适合大库，但依赖工具且版本兼容性要求高。

增量备份（binlog）：记录所有变更，配合全量备份可实现"恢复到任意时间点"。

中小业务最经济的组合是：每日凌晨 mysqldump 全量 + 开启 binlog 保留近期变更，既简单又可控。

二、开启 binlog（增量恢复的基础）

编辑 MySQL 配置 /etc/my.cnf：

[mysqld]

server-id = 1

log-bin = mysql-bin

binlog_format = ROW

expire_logs_days = 7 # 保留 7 天 binlog，按需调整

max_binlog_size = 256M

重启 MySQL 后，SHOW MASTER STATUS; 可以看到当前 binlog 文件名与位置，这是后续增量恢复的起点。

三、mysqldump 全量备份

基本命令与常用参数：

mysqldump -uroot -p --single-transaction --routines --triggers --events \

--databases your_db > /backup/your_db_$(date +%F).sql

--single-transaction：InnoDB 下不加锁获得一致性快照，不影响线上写入。

--routines --triggers --events：把存储过程、触发器、事件一起导出，缺了恢复后会报错。

--databases：导出时带上 CREATE DATABASE 语句，恢复更省事。

四、一套完整的定时备份脚本

把以下脚本存为 /opt/backup/mysql_backup.sh，赋予执行权限：

#!/bin/bash

# MySQL 每日全量备份脚本

set -euo pipefail

DB_USER="backup_user"

DB_PASS="你的密码"

DB_NAMES="your_db"

BACKUP_DIR="/backup/mysql"

KEEP_DAYS=14

DATE=$(date +%F)

mkdir -p "$BACKUP_DIR"

mysqldump -u"$DB_USER" -p"$DB_PASS" --single-transaction \

--routines --triggers --events --databases $DB_NAMES \

| gzip > "$BACKUP_DIR/${DB_NAMES}_${DATE}.sql.gz"

# 清理过期备份

find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$KEEP_DAYS -delete

# 记录日志

echo "[$(date '+%F %T')] backup ok: ${DB_NAMES}_${DATE}.sql.gz" >> /var/log/mysql_backup.log

加入 crontab（建议错开业务高峰，凌晨 2-4 点）：

0 3 * * * /bin/bash /opt/backup/mysql_backup.sh

生产环境建议单独建一个最小权限的备份账号（只授 SELECT、LOCK TABLES、SHOW VIEW 等），避免备份脚本使用 root 密码。

五、恢复演练：从全量 + binlog 恢复到指定时刻

先恢复全量备份：

gunzip -c /backup/mysql/your_db_2026-08-10.sql.gz | mysql -uroot -p

再应用 binlog 增量，恢复到误操作前的时间点：

# 找出误操作发生的时间，然后用 --stop-datetime 精确截止

mysqlbinlog --stop-datetime="2026-08-10 10:00:00" \

/var/lib/mysql/mysql-bin.000012 | mysql -uroot -p

mysqlbinlog 还支持 --start-position / --stop-position，用"位置"恢复比时间更精确，适合误删的 DROP/UPDATE 语句正好落在 binlog 中的场景——先 mysqlbinlog ... | grep -n "误操作关键字" 定位语句，再按位置截断恢复。

补充：大库场景用物理备份（xtrabackup）

如果数据库已经几十 G 甚至更大，mysqldump 的恢复速度会慢到无法接受，这时改用 Percona XtraBackup 做物理备份更合适：它直接拷贝 InnoDB 数据文件，并利用 redo log 保证备份时刻的数据一致性，备份与恢复都是文件级速度。核心流程：

xtrabackup --backup --target-dir=/backup/full

xtrabackup --prepare --target-dir=/backup/full

xtrabackup --copy-back --target-dir=/backup/full

无论哪种方案，都要坚持两条底线：一是备份文件与服务器分离（至少传一份到对象存储），二是定期做"备份校验 + 恢复演练"双重验证。只备份不验证，等于没有备份。

六、验证备份是否可用

备份了不等于安全。每月至少做一次恢复演练：在测试库（或临时 Docker 容器）里完整恢复一遍，对比行数与关键表数据。恢复演练脚本可以做成与备份脚本配套的自动化任务，核心指标是"恢复耗时"和"数据一致性"。

# 快速校验备份文件完整性

gzip -t /backup/mysql/your_db_2026-08-10.sql.gz

# 对比生产与测试库行数

mysql -e "SELECT COUNT(*) FROM your_db.orders;"

备份策略小结

一个合格的备份体系至少包含：每日全量、binlog 增量、异地或对象存储留存一份、周期性恢复演练。备份文件的存放位置与数据库分离（比如传到对象存储），防止磁盘故障时备份一起丢失。把这套脚本加入 crontab 后，再配合监控告警检查备份产物是否按时生成，才算闭环。

相关文章

Linux 定时任务与 Shell 自动化运维实战

Linux 服务器监控与告警实战：用脚本守住每一台机器

云服务器首次上线配置指南：从安全组到基础环境

← 返回博客列表