MySQL数据库恢复是数据运维中的核心操作，当遇到数据误删、表结构损坏、服务器宕机导致数据丢失等情况时，需要结合已有的备份资源和日志文件完成数据还原，不同的故障场景对应不同的恢复策略。
常见的MySQL数据库恢复场景
实际运维中需要恢复数据库的场景主要分为以下几类：
- 误执行了
DELETE、DROP、TRUNCATE等破坏性语句，导致部分或全部数据丢失 - 服务器硬件故障、系统崩溃，导致数据库文件损坏无法启动
- 迁移数据库时数据出现丢失或错乱，需要还原到迁移前的状态
- 测试环境需要同步生产环境的历史数据，需要恢复指定时间点的数据库
基于mysqldump备份的全量恢复
如果之前使用mysqldump工具做过全量备份，那么恢复操作相对简单，适合数据量不大、备份时间较近的场景。
备份文件生成示例
首先回顾下mysqldump生成备份文件的命令，备份文件是后续恢复的基础：
-- 备份单个数据库，包含建库语句 mysqldump -u root -p --databases test_db > /backup/test_db_20240501.sql -- 备份所有数据库 mysqldump -u root -p --all-databases > /backup/all_db_20240501.sql
全量恢复操作步骤
拿到备份文件后，恢复操作分为两种情况：
恢复单个数据库
如果备份时使用了--databases参数，备份文件里已经包含了CREATE DATABASE和USE语句，直接执行即可：
-- 登录MySQL后执行 source /backup/test_db_20240501.sql; -- 或者在系统命令行直接执行 mysql -u root -p < /backup/test_db_20240501.sql
恢复所有数据库
如果是全库备份文件，直接导入即可恢复所有数据库：
mysql -u root -p < /backup/all_db_20240501.sql
基于binlog日志的增量恢复
如果数据丢失的时间点在全量备份之后，仅靠全量备份无法还原最新数据，这时候需要结合binlog二进制日志做增量恢复，binlog记录了数据库所有的增删改操作，适合恢复指定时间段的增量数据。
开启binlog配置
首先需要确保MySQL已经开启了binlog功能，修改my.cnf配置文件：
[mysqld] log-bin=mysql-bin -- 开启binlog，日志文件前缀为mysql-bin server-id=1 -- 主从复制需要配置，单实例也需要设置唯一id expire_logs_days=7 -- 日志保留7天，可根据需求调整
重启MySQL后，执行以下命令查看binlog状态：
SHOW VARIABLES LIKE 'log_bin'; -- 结果为ON表示已经开启
查看binlog日志内容
可以使用mysqlbinlog工具查看binlog文件的具体内容，找到需要恢复的操作记录：
-- 查看所有binlog文件列表 mysql -u root -p -e "SHOW BINARY LOGS;" -- 查看指定binlog文件的内容，转换为可读的SQL语句 mysqlbinlog /var/lib/mysql/mysql-bin.000001 -- 查看指定时间段的binlog内容 mysqlbinlog --start-datetime="2024-05-01 08:00:00" --stop-datetime="2024-05-01 10:00:00" /var/lib/mysql/mysql-bin.000001
增量恢复操作步骤
假设我们在2024-05-01 09:30:00误删了test_db库的user表数据，全量备份是2024-05-01 08:00:00做的，恢复步骤如下：
- 先恢复全量备份到数据库，此时数据库状态回到08:00:00
- 导出08:00:00到09:30:00之间的binlog增量操作：
mysqlbinlog --start-datetime="2024-05-01 08:00:00" --stop-datetime="2024-05-01 09:30:00" /var/lib/mysql/mysql-bin.000001 > /backup/increment.sql
- 将增量SQL文件导入数据库，完成增量数据恢复：
mysql -u root -p test_db < /backup/increment.sql
不同恢复场景的方案选择
可以根据实际情况选择合适的恢复方案，以下是常见场景的对应策略：
| 故障场景 | 推荐恢复方案 | 注意事项 |
|---|---|---|
| 全量数据丢失，有近期全量备份 | mysqldump全量恢复 | 恢复前先备份当前残留数据，避免二次丢失 |
| 全量备份后有新增数据丢失 | 全量备份+binlog增量恢复 | 需要确认binlog日志没有被清理，保留完整操作记录 |
| 单表误删，表结构还在 | 从全量备份中提取单表数据恢复 | 可以用sed命令从全量备份文件中提取对应表的语句 |
| 数据库文件损坏无法启动 | 替换损坏文件+备份恢复 | 先尝试修复ibdata、表空间文件，不行再走备份恢复 |
恢复操作的注意事项
- 恢复操作前一定要对当前数据库做一次全量备份，避免恢复失败导致数据彻底丢失
- 如果是生产环境恢复，建议先在测试环境验证恢复流程，确认无误再操作生产库
- binlog恢复时要准确核对时间点，避免恢复到误操作之后的状态，导致数据错误
- 恢复完成后要校验数据完整性，比如核对表数量、核心数据条数、关键业务数据是否正确
数据库恢复的核心是提前做好备份策略，建议采用全量备份+增量备份的组合方式，定期校验备份文件的可用性，避免故障时备份文件无法使用。