MySQL数据备份恢复实战：mysqldump逻辑备份与binlog增量恢复

MySQL数据备份与恢复是数据库运维的底线，备份做没做、能不能恢复，全看恢复演练过没过。这篇按逻辑备份、物理备份、binlog增量恢复三条路线展开，给出常用命令、参数要点和恢复步骤，覆盖单机到主从环境下最常见的备份恢复场景。

一、备份方案选型：逻辑、物理与增量

• 逻辑备份：mysqldump导出SQL，跨版本、跨平台迁移方便，数据量大时慢。
• 物理备份：Xtrabackup直接拷贝数据文件，秒级快照，恢复速度快。
• 增量备份：基于binlog（或Xtrabackup的增量链），配合全备实现时间点恢复。

生产环境普遍组合：每日物理全备 + 实时binlog，既能快速恢复，又能精确到误操作时间点。

二、mysqldump逻辑备份与恢复

常用参数组合：

# 全库备份（InnoDB一致性快照）
mysqldump -uroot -p --single-transaction --master-data=2 \
  --routines --triggers --events --set-gtid-purged=OFF \
  -A > full_backup.sql
# 单库备份
mysqldump -uroot -p --single-transaction --set-gtid-purged=OFF \
  --databases kou5 > kou5.sql

–single-transaction利用MVCC取一致快照，不锁业务表；–master-data=2在备份文件头记录binlog坐标（不锁表），用于接增量。恢复时：

mysql -uroot -p < full_backup.sql
# 仅恢复单库
mysql -uroot -p kou5 < kou5.sql

三、binlog增量备份与基于时间点的恢复

binlog前提：log_bin=ON，推荐row格式，binlog_format=ROW。恢复流程是把全备恢复到备份点，再用mysqlbinlog回放备份点之后的binlog。误删数据场景示例：

# 1. 找出误操作前后的日志位置
mysqlbinlog --no-defaults --base64-output=DECODE-ROWS -v \
  /var/log/mysql/binlog.000012 | grep -n "DELETE FROM kou5"

# 2. 回放到误操作前的pos
mysqlbinlog --stop-position=1876530 /var/log/mysql/binlog.000012 | mysql -uroot -p

# 3. 或按时间点回放
mysqlbinlog --stop-datetime="2026-08-21 03:00:00" binlog.000012 | mysql -uroot -p

注意row格式下日志里有UPDATE/DELETE产生的undo内容，可以用–include-gtids过滤，也可以用mysqlbinlog的–row2参数减少数据量。

四、XtraBackup物理备份与恢复

大库场景物理备份：

# 全备
extrabackup --backup --target-dir=/backup/full_20260821 \
  --user=root --password=xxx

# 增量
xtrabackup --backup --target-dir=/backup/incr1 \
  --incremental-basedir=/backup/full_20260821

# 恢复：先prepare（合并日志），再copy-back
xtrabackup --prepare --target-dir=/backup/full_20260821
xtrabackup --copy-back --target-dir=/backup/full_20260821

恢复前记得停掉mysqld并清空datadir；恢复后检查权限（chown mysql:mysql）再启动。

五、备份校验与恢复演练

备份文件本身不校验，等于没备份。每周抽一次备份在独立实例上做恢复演练，验证表数量、行数、最新事务点。脚本里加check：mysqldump后grep -c插入语句条数，XtraBackup备份后校验xtrabackup_checkpoints文件。恢复时间目标（RTO）和丢失容忍（RPO）要按业务写清楚：生产库一般RTO<1小时、RPO<5分钟，达不到就补增量或binlog。