MYSQL-利用Binlog日志恢复数据

运维小路

发布于 2025-09-30 15:42:52

2040

文章被收录于专栏：运维小路运维小路

作者介绍：简历上没有一个精通的运维工程师，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

数据库是一个系统（应用）最重要的资产之一，所以我们的数据库将从以下几个数据库来进行介绍。

MySQL（本章节）

PostgreSQL

MongoDB

Redis

Etcd

上个小节我们设计了的一个场景，如果真的发生了故障，我们应该怎么来恢复数据，这个就是我们本小节的介绍（希望大家用于不会有用到的机会）。

1.定时备份的数据（有备份才是恢复的基础）

这里的数据选择的是最简单mysqldump备份，并且是只针对特定的库备份，并且添加了参数：--master-data=2，将binlog位置信息以注释形式写入备份文件，这样恢复的时候，我们能够准确知道从哪里开始读取数据。

mysqldump -u root -p \
--databases your_db \
--master-data=2 > backup_with_binlog.sql

2.查看备份

可以看到我们的备份截止的binglog日志是mysql-bin.000003，位置是2184259，这个也是我们恢复的开始位置。

[root@localhost ~]# head -50 backup_with_binlog.sql | grep "CHANGE MASTER TO"
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=2184259;

3.恢复备份

这里我使用新创建的一个库来进行恢复，真正的生产环境也建议先到测试库确认没问题再到生产库进行还原。

3.1 导入数据

把数据库备份文件复制到新服务器进行导入，需要先进行初始化操作。

[root@localhost ~]# mysql -uroot -p <./backup_with_binlog.sql 
Enter password: 
#手工输入密码，这里不需要提前创建库

3.2检查数据

这里只有导入的数据，没有备份以后生成的数据，当然真实服务器故障以后可能无法执行该步骤，我这里为了演示所以记录差异方便比对。

#新服务器
mysql> select count(*) from test_data;
+----------+
| count(*) |
+----------+
|  8463168 |
+----------+
1 row in set (39.46 sec)

#旧服务器 
mysql> select count(*) from test_data;
+----------+
| count(*) |
+----------+
|  8466248 |
+----------+
1 row in set (9.65 sec)

我们发现导入的数据缺少了8466248-8463168=3080条数据，这个就是我们需要从mysql里面的binlog日志里面恢复的数据。

根据前面的我们的备份包含是是从mysql-bin.000003，位置是2184259

开始的，所以我们需要把这个文件及后面的文件复制到新服务器进行还原。

4.还原

首先，从从mysql-bin.000003，位置是2184259进行还原，当然由于我这个备份完成以后刚好没有写入数据，而且隔了一天再来启动，所以这里实际没有导入任何文件，具体以现场为准。

[root@localhost ~]# mysqlbinlog --start-position=2184259 ./mysql-bin.000003 | mysql -u root -p
Enter password:

然后从后面的mysql-bin.000004完整导入，我这里只有这个文件，如果有多个，则需要挨个导入。

[root@localhost ~]# mysqlbinlog  ./mysql-bin.000004 | mysql -u root -p
Enter password: 
[root@localhost ~]#

最后再核对数据是否一致，也可以同时对比表记录数量，当然我这里只有一个表，真实环境往往需要结合业务来处理，我这里只是为演示功能，所以考虑比较简单。

#旧库
mysql> SELECT * FROM test_data ORDER BY id DESC LIMIT 1;
+---------+-----------------+---------------------+---------------+
| id      | value           | created_at          | random_number |
+---------+-----------------+---------------------+---------------+
| 8466248 | Test value 3079 | 2025-09-24 23:43:26 |           549 |
+---------+-----------------+---------------------+---------------+
1 row in set (0.00 sec)

#新库
mysql> SELECT * FROM test_data ORDER BY id DESC LIMIT 1;
+---------+-----------------+---------------------+---------------+
| id      | value           | created_at          | random_number |
+---------+-----------------+---------------------+---------------+
| 8466248 | Test value 3079 | 2025-09-24 23:43:26 |           549 |
+---------+-----------------+---------------------+---------------+
1 row in set (0.00 sec)

这样我们就通过定期备份+Binlog日志恢复了业务数据，但是他只仅限于单机版，并且业务也会中断，真实的场景往往需要考虑更多，下个小节我们将介绍主从，这个是数据库高可用广泛采用（甚至是必须采用的）的措施。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2025-09-25，如有侵权请联系 cloudcommunity@tencent.com 删除

数据