数据库（五）MySQL的数据备份

---

前言

数据库备份是任何生产环境中不可或缺的重要环节。无论是人为操作失误、硬件故障还是自然灾害，都可能导致数据丢失，给企业带来无法估量的损失。MySQL作为最流行的开源关系型数据库之一，提供了多种备份与恢复方案。本文将全面介绍MySQL的备份策略、备份类型、常见备份方法以及详细的实战案例，帮助您构建完善的数据库备份恢复体系。

一、数据备份的重要性

1. 备份的主要目的是灾难恢复
2. 在生产环境中，数据的安全性至关重要
3. 任何数据的丢失都可能产生严重的后果
4. 造成数据丢失的原因包括：
   • 程序错误
   • 人为操作错误
   • 运算错误
   • 磁盘故障
   • 灾难（如火灾、地震）和盗窃

二、数据库备份类型

2.1 物理备份

物理备份是对数据库操作系统的物理文件（如数据文件、日志文件等）的备份，适用于需要快速恢复的大型重要数据库。

2.1.1 冷备份（脱机备份）

• 在关闭数据库时进行（使用tar命令）
• 优点：简单全面且无需额外资源
• 缺点：必须在数据库脱机情况下进行

2.1.2 热备份（联机备份）

• 数据库处于运行状态，依赖于日志文件
• 优点：可24x7服务，不影响业务
• 缺点：复杂，消耗系统资源

2.1.3 温备份

• 数据库锁定表格（不可写入但可读）状态下进行
• 优点：可不停机备份
• 缺点：无法提供全天候备份服务

2.2 逻辑备份

逻辑备份是对数据库逻辑组件的备份，表示为逻辑数据库结构，适用于可以编辑数据值或表结构的情况。

2.2.1 完全备份

• 每次对数据进行完整备份
• 优点：恢复操作简单
• 缺点：占用大量空间，备份时间长

2.2.2 差异备份

• 备份自上次完全备份后被修改的文件
• 优点：存储需求和恢复时间介于全量和增量之间
• 缺点：备份数据量会越来越大

2.2.3 增量备份

• 仅备份自上次备份后被修改的文件
• 优点：备份量小，速度快
• 缺点：恢复需要所有备份，中间损坏会导致数据丢失

三、常见的备份方法

3.1 物理冷备

• 关闭数据库后直接打包文件
• 优点：速度快，恢复简单

3.2 专用备份工具

• mysqldump：常用逻辑备份工具
• mysqlhotcopy：仅支持MyISAM和ARCHIVE表

3.3 二进制日志增量备份

• 需启用二进制日志
• 提供复制和恢复所需信息

3.4 第三方工具备份

• Percona XtraBackup等热备份软件

四、MySQL完全备份

4.1 特点

• 备份整个数据库、结构和文件
• 保存备份完成时刻的数据库状态
• 是差异和增量备份的基础

4.2 优缺点

• 优点：操作简单方便
• 缺点：数据重复多，占用空间大，时间长

五、数据库完全备份分类

5.1 物理冷备份与恢复

1. 关闭MySQL服务
2. 使用tar打包数据库文件夹
3. 恢复时直接替换MySQL目录

5.2 mysqldump备份与恢复

1. MySQL自带工具，可导出为SQL脚本
2. 恢复时使用mysql命令导入

六、实战案例

6.1 MySQL完全备份与恢复

6.1.1 物理冷备份与恢复

systemctl stop mysqld
tar zcvPf /opt/mysql_all_$(date +%F).tar.gz /usr/local/mysql/data/

# 恢复,启动数据库后可以重新正常进入
tar zxvPf /opt/mysql_all_2025-09-16.tar.gz -C /usr/local/mysql/

6.1.2 mysqldump备份

1. 备份整个库：

    mysqldump -u root -p[密码] --databases 库名1 [库名2] ... > /备份路径/备份文件名.sql   #导出的就是数据库脚本文件
   mysqldump -u root -p --databases szsxjd > /opt/szsxjd.sql
   

   

2. 备份所有库：

   mysqldump -u root -p[密码] --all-databases > /备份路径/备份文件名.sql
   mysqldump -u root -p --all-databases > /opt/all.sql
   

   

3. 备份指定表：

   mysqldump -u root -p[密码] 库名 [表名1] [表名2] ... > /备份路径/备份文件名.sql
   mysqldump -u root -p 库名 表名1 表名2 > /opt/表名1.sql
   mysqldump -u root -p [-d]  newclass info info_2 > /opt/szsxjd_info1.sql #使用“-d”选项，说明只保存数据库的表结构
   #不使用“-d"选项，说明表数据也进行备份
   #做为一个表结构模板 
   mysqldump -u root -p [-d]  newclass > /opt/szsxjd_info1.sql 
   #不加--databases仅加库名
   

   

4. 查看备份内容：

   grep -v "^--" /opt/szsxjd_info1.sql | grep -v "^/" | grep -v "^$"
   

6.1.3 备份恢复

MySQL 数据库的完全恢复主要依赖于使用 mysqldump 导出的备份文件。以下是两种常用的恢复方法：

6.1.3.1 使用 source 命令恢复

登录到 MySQL 数据库后，可以直接执行 source 命令来恢复备份文件：

mysql> source /backup/szsxjd.sql

这种方法适用于交互式环境，恢复过程直观可见。

6.1.3.2 使用 mysql 命令恢复

通过命令行直接导入备份文件，适用于脚本或非交互式环境：

mysql -uroot -p123456 szsxjd < /opt/info1.sql

此方法可以快速恢复特定数据库或表，适合自动化操作。

6.1.3.3 备份与恢复注意事项

使用 mysqldump 备份时，是否包含 --databases 参数会影响恢复方式：

• 包含 --databases 参数的备份会包含创建数据库的语句，恢复时无需预先创建数据库：

  mysqldump -uroot -p123456 --databases szsxjd > /opt/szsxjd_01-all.sql
  mysql -uroot -p123456 < /opt/szsxjd_01.sql
  

• 不包含 --databases 参数的备份仅针对表，恢复时需要先创建数据库：

  mysqldump -uroot -p123456 szsxjd > /opt/szsxjd_all.sql
  mysql -uroot -p123456 -e "create database szsxjd;"
  mysql -uroot -p123456 szsxjd < /opt/szsxjd_02.sql
  

6.1.3.4 自动化备份脚本

对于生产环境，可以设置定时任务自动执行备份：

0 3 * * 6 /usr/local/mysql/bin/mysqldump -uroot -p123456 szsxjd > ./szsxjd_infol_$(date +%Y%m%d).sql ;/usr/local/mysql/bin/mysqladmin -u root -p flush-logs

此脚本每周六凌晨3点执行备份，并刷新日志文件。

6.2 MySQL增量备份与恢复

在MySQL中，增量备份是指只备份发生变化的数据，而不是整个数据库。在增量备份中，可以使用基于语句（Statement）或基于行（Row）的方式来记录和复制这些变化。

基于语句的增量备份（Statement-Based Incremental Backup）：

• 通俗解释：
  就像记录每一步操作一样，基于语句的增量备份会记录每个SQL语句的变化，而不是具体的数据行。当备份时，只需要记录执行过的SQL语句，而不是具体的数据内容。
• **适用场景：**适用于简单的SQL语句操作，如INSERT、UPDATE、DELETE等，可以通过记录SQL语句来还原数据变化。

基于行的增量备份（Row-Based Incremental Backup）：

• 通俗解释： 就像记录每个人的变化一样，基于行的增量备份会记录每个数据行的变化情况，而不是SQL语句。当备份时，只需要记录哪些数据行发生了变化，而不是具体的SQL语句。
• **适用场景：**适用于复杂的数据变化情况，如涉及多个表之间关联的操作，可以通过记录数据行的变化来还原数据。

在增量备份中，选择基于语句或基于行的方式取决于您对数据变化的关注点和备份恢复的需求。基于语句的增量备份更注重SQL操作的记录，而基于行的增量备份更注重数据行的变化情况。根据具体情况选择合适的备份方式可以更有效地保护和恢复数据。

6.2.1 配置二进制日志

[mysqld]
log-bin=mysql-bin
binlog_format = MIXED
server-id = 1

binlog_format = MIXED：

① STATEMENT（基于SQL语句）:
每一条涉及到被修改的sql 都会记录在binlog中
缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、主从复制等架构记录日志时会出现问题

增删改查通过sql语句来实现记录，如果用高并发可能会出错，可能时间差异或者延迟，可能不是我们想想的恢复可能你先删除或者在修改，可能会倒过来。准确率底

② ROW(基于行)
只记录变动的记录，不记录sql的上下文环境
缺点:如果遇到update…set…where true 那么binlog的数据量会越来越大

update、delete以多行数据起作用，来用行记录下来，
只记录变动的记录，不记录sql的上下文环境，比如sql语句记录一行，但是ROW就可能记录10行，但是准确性高，高并发的时候由于操作量比较大，性能变低，所以记录都记下来。

③ MIXED 推荐使用
一般的语句使用statement，函数使用ROW方式存储。

可以将解码后的文件导出为txt格式，方便查阅
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002 > /opt/mysql-bin.000002.txt
例如，STATEMENT模式记录量较少，但有可能会因为没有记录下所有细节而产生问题；ROW模式可以记录下所有细节，但是记录量可能会非常大。所以在实际使用中需要根据情况选择适合的模式。

6.2.2 增量备份操作

1. 刷新日志生成新文件：

   mysqladmin -u root -p flush-logs
   

2. 查看日志内容：

cp /usr/local/mysql/data/mysql-bin.000001 /opt/ #将log文件放到指定opt内查看
mysqlbinlog --no-defaults  /opt/mysql-bin.000001
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000001

• --base64-output=decode-rows：使用64位编码机制去解码（decode）并按行读取（rows）
• -v: 显示详细内容
• --no-defaults : 默认字符集（不加会报UTF-8的错误）

6.2.3 增量恢复

1. 一般恢复：
   将所有备份的二进制日志内容全部恢复，恢复备份的文件中不能有删除操作，也不能和现在的数据库存在数据冲突。

   mysqladmin -u root -p flush-logs
   mysqlbinlog --no-defaults /opt/mysql-bin.000008 | mysql -u root -p
   

2. 基于位置点恢复：
   数据库在某一时间点可能既有错误的操作也有正确的操作
   可以基于精准的位置跳过错误的操作
   发生错误节点之前的一个节点，上一次正确操作的位置点停止

   cp /usr/local/mysql/data/master-bin.000010 /opt/
   mysqlbinlog --no-defaults --start-position='2332' --stop-position='3199' /opt/mysql-bin.0000010 | mysql -uroot -p
   

3. 基于时间点恢复：
   跳过某个发生错误的时间点实现数据恢复
   在错误时间点停止，在下一个正确时间点开始

   mysqlbinlog --no-defaults --start-datetime='2025-09-16 19:43:42' --stop-datetime='2025-09-16 19:43:46'/opt/master-bin.0000010 | mysql -uroot -p
   

七、慢查询日志

7.1 开启慢查询

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = ON

7.2 分析慢查询

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
pt-query-digest /var/log/mysql/mysql-slow.log

八、总结

MySQL备份与恢复是数据库管理中的核心技能。通过本文我们了解到：

1. 备份类型选择：

   • 物理备份适合大规模数据快速恢复
   • 逻辑备份适合小规模灵活备份
   • 完全+增量组合是常见策略

2. 备份策略建议：

   • 生产环境推荐每周全备+每日增量
   • 备份时间安排在业务低峰期

3. 恢复注意事项：

   • 测试恢复流程的可靠性
   • 记录关键位置点和时间点
   • 大库恢复前评估时间窗口

4. 监控优化：

   • 定期检查备份完整性
   • 分析慢查询持续优化性能

完善的备份策略需要结合业务需求、数据重要性和恢复时间目标来制定。建议至少保留两份不同介质的备份，并定期演练恢复流程，确保在真正需要时能够快速可靠地恢复数据。