Mysql删除数据库之通过binlog恢复数据

已于 2023-12-11 11:53:11 修改
阅读量478 收藏 3
点赞数
文章标签： 数据库 mysql java
于 2023-05-04 11:28:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43217042/article/details/130483471
版权

背景

记录一次自身的误操作，将Mysql数据库中某系统数据库删库后的恢复步骤，以示警戒!

说明：20多天前本人将生产环境数据库导出备份过一次。数据库是8.0版本，只记录最近30天binlog日志。故本篇文章是以备份的数据+binlog一起恢复数据，备份数据是25天前数据，binlog是记录最近30天内的日志记录。综上已备份数据导入后，在采用binlog日志恢复上次导出时间到当前时间内的数据，完成数据恢复。下面内容本机会复现上述场景，实现数据恢复。

前置条件

查看数据库是否开启binlog

mysql> show variables like '%log_bin%';
+---------------------------------+----------------------------------------------------------------------+
| Variable_name                   | Value                                                                |
+---------------------------------+----------------------------------------------------------------------+
| log_bin                         | ON                                                                   |
| log_bin_basename                | C:\ProgramData\MySQL\MySQL Server 8.0\Data\DESKTOP-PNQ97MJ-bin       |
| log_bin_index                   | C:\ProgramData\MySQL\MySQL Server 8.0\Data\DESKTOP-PNQ97MJ-bin.index |
| log_bin_trust_function_creators | OFF                                                                  |
| log_bin_use_v1_row_events       | OFF                                                                  |
| sql_log_bin                     | ON                                                                   |
+---------------------------------+----------------------------------------------------------------------+

说明：

log_bin : ON表示当前数据库已开启binlog日志，OFF则表示未开启

log_bin_basename：这是binlog日志文件存放的目录和名称，可以从上面查看的结果中看出，这里的没有配置binlog日志文件的后缀名。因为binlog日志是一个一直滚动追加的日志文件，当超过一个指定的默认值（通常是1GB大小）之后，他会自动切分为一个新的binlog日志文件。文件的后缀名就是它滚动增长的标识符。它是一个有规律增长的序列，000001,000002,000003…999999

log_bin_index：这是binlog日志文件的索引文件目录和名称

查看数据库binlog日志存放时间

1.Mysql8.0以下版本，查看当前数据库日志binlog保存时效 以天为单位，默认0 永不过期，最多只能设置99天

mysql> show variables like 'expire_logs_days';   #查看binlog日志保存时间
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 0     |
+------------------+-------+

2.Mysql8.0以上版本，通过全局参数binlog_expire_logs_seconds查看binlog保存时间 以秒为单位；默认2592000=30天 14400=4小时；86400=1天；259200=3天

mysql> show variables like '%binlog_expire_logs_seconds%';   #查看binlog日志保存时间
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 2592000 |
+----------------------------+---------+
mysql> set global binlog_expire_logs_seconds=2592000;    #可修改默认保存时间（单位:秒）

场景模拟

首先使用如下命令刷新binlog，后续的所有操作将使用新的binlog文件记录

mysql> show binary logs;     #查看binlog文件列表
+----------------------------+------------+-----------+
| Log_name                   | File_size  | Encrypted |
+----------------------------+------------+-----------+
| DESKTOP-PNQ97MJ-bin.000176 |     853166 | No        |
| DESKTOP-PNQ97MJ-bin.000177 |       2938 | No        |
| DESKTOP-PNQ97MJ-bin.000178 |       1290 | No        |
| DESKTOP-PNQ97MJ-bin.000179 |       5293 | No        |
+----------------------------+------------+-----------+
mysql> flush logs;       	 #刷洗binlog,生成新文件记录最近的后续操作
Query OK, 0 rows affected (0.06 sec)
mysql> show binary logs;     #查看最新binlog文件列表，发现已生成最新的.000180文件，那么后续的数据操作将会记录在此文件中
+----------------------------+------------+-----------+
| Log_name                   | File_size  | Encrypted |
+----------------------------+------------+-----------+
| DESKTOP-PNQ97MJ-bin.000176 |     853166 | No        |
| DESKTOP-PNQ97MJ-bin.000177 |       2938 | No        |
| DESKTOP-PNQ97MJ-bin.000178 |       1290 | No        |
| DESKTOP-PNQ97MJ-bin.000179 |       5293 | No        |
| DESKTOP-PNQ97MJ-bin.000180 |        156 | No        |
+----------------------------+------------+-----------+

建库建表

mysql> CREATE DATABASE IF NOT EXISTS db_test  DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;   #创建数据库
Query OK, 1 row affected (0.01 sec)

mysql> use db_test;   #进入创建的数据库db_test内
Database changed

mysql> CREATE TABLE `blog_user` (
   `userid` int NOT NULL AUTO_INCREMENT COMMENT '用户ID',
   `username` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '用户名',
   `password` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '密码',
   `userphone` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '手机号',
   `userstate` int DEFAULT NULL COMMENT '状态',
   `createtime` datetime DEFAULT NULL COMMENT '创建时间',
   `uptime` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
   `remark` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '备注',
   `userimg` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '用户头像',
    PRIMARY KEY (`userid`) USING BTREE
   ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;
Query OK, 0 rows affected (0.05 sec)

mysql> show tables;  #查看到已创建的数据表
+-------------------+
| Tables_in_db_test |
+-------------------+
| blog_user         |
+-------------------+
1 row in set (0.00 sec)

mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (1, 'admin', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);   #添加第一条数据
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (2, 'zhangsan', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);  #添加第二条数据
Query OK, 1 row affected (0.00 sec)

mysql> select * from blog_user;  #查询发现数据已添加
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
2 rows in set (0.00 sec)

模拟备份数据导出

说明：当前环节模拟提前备份导出的数据，后续新追加的数据，不在导出，采用binlog恢复

使用mysqldump命令导出需要备份的数据库

mysqldump --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=OFF  -uroot -p123456 db_test --hex-blob > E:/mysql/db_test.sql

注：db_test就是本次备份的数据库

–default-character-set：设置字符编码，和数据库保持一致

–single-transaction：在备份前设置事务隔离级别为REPEATABLE READ并向server发送START TRANSACTION语句

–set-gtid-purged：确定是否在结果中添加SET @@GLOBAL.GTID_PURGED。若为ON但在server中没有开启GTID则发生错误。若OFF则什么都不做。若AUTO则server中开启GTID那么添加上述语句，反之不加。

-u：后面跟用户名

-p：后面跟密码

–hex-blob：将二进制列，如，BINARY,VARBINARY,BLOB,BIT备份为十六进制形式。

E:/mysql/db_test.sql：备份数据的文件地址

模拟多个binlog文件记录信息

说明：生产环境中会有大数据量的录入修改等操作，当一个binlog文件达到1GB(默认)大小后，会自动拆分生成新的binlog文件，此处为了模拟真实场景，使用命令手动进行拆分，生成新的binlog文件记录日志。拆分前，上述的建库建表插入数据的日志都记录在了.000180文件中。拆分后在模拟一些数据插入会记录在.000181的binlog文件中

mysql> flush logs;  #刷洗binlog,生成新文件记录最近的后续操作
Query OK, 0 rows affected (0.04 sec)

mysql> show binary logs;  #查看最新binlog文件列表，发现已生成最新的.000181文件，那么后续的数据操作将会记录在此文件中
+----------------------------+------------+-----------+
| Log_name                   | File_size  | Encrypted |
+----------------------------+------------+-----------+
| DESKTOP-PNQ97MJ-bin.000176 |     853166 | No        |
| DESKTOP-PNQ97MJ-bin.000177 |       2938 | No        |
| DESKTOP-PNQ97MJ-bin.000178 |       1290 | No        |
| DESKTOP-PNQ97MJ-bin.000179 |       5350 | No        |
| DESKTOP-PNQ97MJ-bin.000180 |       3336 | No        |
| DESKTOP-PNQ97MJ-bin.000181 |        156 | No        |
+----------------------------+------------+-----------+
6 rows in set (0.00 sec)

#模拟继续插入第三，第四条数据，当前数据不再上述的备份sql中，后续采用binlog恢复，当前这些数据记录在.000181文件中
mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (3, 'admin2', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (4, 'zhangsan2', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);
Query OK, 1 row affected (0.00 sec)

mysql> select * from blog_user; 
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username  | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin     | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan  | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      3 | admin2    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      4 | zhangsan2 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------

mysql> flush logs;  #刷洗binlog,生成新文件记录最近的后续操作
Query OK, 0 rows affected (0.04 sec)

mysql> show binary logs;  #查看最新binlog文件列表，发现已生成最新的.000182文件，那么后续的数据操作将会记录在此文件中
+----------------------------+------------+-----------+
| Log_name                   | File_size  | Encrypted |
+----------------------------+------------+-----------+
| DESKTOP-PNQ97MJ-bin.000176 |     853166 | No        |
| DESKTOP-PNQ97MJ-bin.000177 |       2938 | No        |
| DESKTOP-PNQ97MJ-bin.000178 |       1290 | No        |
| DESKTOP-PNQ97MJ-bin.000179 |       5350 | No        |
| DESKTOP-PNQ97MJ-bin.000180 |       3336 | No        |
| DESKTOP-PNQ97MJ-bin.000181 |        932 | No        |
| DESKTOP-PNQ97MJ-bin.000182 |        156 | No        |
+----------------------------+------------+-----------+
7 rows in set (0.00 sec)

#模拟继续插入第五，第六条数据，当前数据不再上述的备份sql中，后续采用binlog恢复，当前这些数据记录在.000182文件中
mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (5, 'admin5', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO `db_test`.`blog_user`(`userid`, `username`, `password`, `userphone`, `userstate`, `createtime`, `uptime`, `remark`, `userimg`) VALUES (6, 'zhangsan6', '123456', '17371431054', 1, '2020-12-24 19:22:25', NULL, NULL, NULL);
Query OK, 1 row affected (0.00 sec)

mysql> select * from blog_user;  已
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username  | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin     | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan  | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      3 | admin2    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      4 | zhangsan2 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      5 | admin5    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      6 | zhangsan6 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------

模拟删除数据库db_test

mysql> drop database db_test;   #删除数据库
Query OK, 1 row affected (0.03 sec)

mysql> show databases;          #查看当前数据库列表
+--------------------------+
| Database                 |
+--------------------------+
| information_schema       |
| innovation_demonstration |
| mysql                    |
| performance_schema       |
+--------------------------+
Query OK, 4 row affected (0.03 sec)

恢复实践

说明：

  1. 通过场景模拟，得到一个备份的数据库，备份数据记录中blog_user表只有id为1和2的数据记录，对应.000180的binlog文件
  2. 备份后新追加的id为3和4的数据记录，对应.000181的binlog文件
  3. 后续在追加的id为5和6得数据记录，以及删库的操作记录对应存放在.000182的binlog文件

通过备份数据库恢复部分数据

说明：当前环节也可通过binlog恢复id为1和2的数据，因为binlog文件都在，之所以使用备份数据库恢复是因为我们生产环境的binlog只保留30天的，之的前数据和操作已丢失。因此使用之前备份的数据库进行部分恢复，最近的没有丢失的binlog数据采用binlog文件恢复。

mysql> CREATE DATABASE IF NOT EXISTS db_test  DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;   #先手动创建一个相同名称的空数据库
Query OK, 1 row affected (0.00 sec)

mysql> source E:/mysql/db_test.sql;   #使用source命令导入之前备份的数据先恢复部分数据
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> show databases;          #查看当前数据库列表
+--------------------------+
| Database                 |
+--------------------------+
| db_test                  |
| information_schema       |
| innovation_demonstration |
| mysql                    |
| performance_schema       |
+--------------------------+
Query OK, 5 row affected (0.03 sec)

mysql> use db_test;     #进入db_test数据库
Database changed
mysql> select * from blog_user;   #查看通过备份数据恢复的数据，当前已恢复id为1和2的数据，后续数据通过binlog恢复
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+----------+----------+-------------+-----------+---------------------+--------+--------+---------+
2 rows in set (0.00 sec)

通过binlog恢复数据

说明：首先需要进入到binlog文件存放的所在目录，通过log_bin_basename参数可以查看

mysql> show variables like '%log_bin_basename%';
+------------------+----------------------------------------------------------------+
| Variable_name    | Value                                                          |
+------------------+----------------------------------------------------------------+
| log_bin_basename | C:\ProgramData\MySQL\MySQL Server 8.0\Data\DESKTOP-PNQ97MJ-bin |
+------------------+----------------------------------------------------------------+
注：C:\ProgramData\MySQL\MySQL Server 8.0\Data 下就是binlog的文件存放地址，已DESKTOP-PNQ97MJ-bin开头.00000X为后缀的都是binlog文件。DESKTOP-PNQ97MJ-bin每个机器的这个名称都不一致。

进入到C:\ProgramData\MySQL\MySQL Server 8.0\Data目录下执行如下命令：

mysqlbinlog -vv --base64-output=decode-rows DESKTOP-PNQ97MJ-bin.000181 > E:/mysql/181.txt
#将.000181的二进制文件转换为可读性的文本文件

查看181.txt文件内容，找到新增id为3和4新增数据的记录。开始：321，结束：875
在这里插入图片描述在这里插入图片描述

使用binlog命令进行数据恢复：

mysqlbinlog --start-position=321 --stop-position=875 --database=db_test DESKTOP-PNQ97MJ-bin.000181 | mysql -uroot -p123456

–start-position：开始行号，需要恢复数据的开始行号。不设置则从binlog文件开头恢复

–stop-position：结束行号，需要恢复数据的结束行号。不设置则恢复到binlog文件末尾处

–database：恢复指定的数据库，一个binlog文件中可能不只有一个数据的日志记录，因此需要指定。不设置则恢复所有数据库

DESKTOP-PNQ97MJ-bin.000181：需要恢复的指定binlog文件名

恢复后效果如下：

mysql> select * from blog_user;
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username  | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin     | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan  | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      3 | admin2    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      4 | zhangsan2 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
4 rows in set (0.00 sec)

进入到C:\ProgramData\MySQL\MySQL Server 8.0\Data目录下执行如下命令：

mysqlbinlog -vv --base64-output=decode-rows DESKTOP-PNQ97MJ-bin.000182 > E:/mysql/182.txt
#将.000182的二进制文件转换为可读性的文本文件

查看182.txt文件内容，找到删除数据库前最近的commi的操作记录。结束行号：875
在这里插入图片描述

再次使用binlog命令进行数据恢复，恢复到删除数据库的操作前那时候的数据：

mysqlbinlog  --stop-position=875 --database=db_test DESKTOP-PNQ97MJ-bin.000182 | mysql -uroot -p123456

恢复后效果如下：

mysql> select * from blog_user;
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
| userid | username  | password | userphone   | userstate | createtime          | uptime | remark | userimg |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
|      1 | admin     | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      2 | zhangsan  | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      3 | admin2    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      4 | zhangsan2 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      5 | admin5    | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
|      6 | zhangsan6 | 123456   | 17371431054 |         1 | 2020-12-24 19:22:25 | NULL   | NULL   | NULL    |
+--------+-----------+----------+-------------+-----------+---------------------+--------+--------+---------+
6 rows in set (0.00 sec)

综上述发现，数据已恢复到删除数据库前的那个步骤的数据，已实现删库后的数据恢复。

意见建议

  1. 生产环境若每天数据量增量较大，建议每天定时备份一个全库
  2. 保留最近7天的全库备份记录即可
  3. 数据恢复时采用全库恢复，加上全库备份之后新的binlog日志结合实现数据恢复
  4. 综上是自身系统的一个恢复模拟案例，若有不足请指出
褪去一身骄傲
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
使用binlog日志恢复MySQL数据库删除数据的方法
01-11
本文主要通过实际操作说明对binlog日志恢复MySQL数据库删除数据的方法进行说明，内容主要包括MySQL数据库binlog日志查询、恢复等相关介绍，希望对大家在工作及生活中遇到的此类问题有所帮助，如需操作指导，可留言！
Mysql的Binlog数据恢复:不小心删除数据库详解
12-16
Mysql的Bin log数据恢复:不小心删除数据库 前言：因为不小心删除了测试机器上Mysql的一整个数据库Schema，因为是测试机所以没有做备份，现在通过MySQL的Bin log方式恢复到删除以前的数据库。 当然做Bin log的数据恢复前提是已经打开Bin log的功能，如果又没做数据备份，又没打开Bin log日志，那你就可能需要考虑快照等其它方式从系统的角度去恢复。 Bin log 常用于数据增量备份和恢复，以及数据库主从复制。如果没有开启，可以通过如下方式打开： 1、打开mysql的binlog功能 mysql是支持增量备份，但要打开mysql的bin log功能。 修改mys
Windows环境MySQL8.0使用binlog恢复
最新发布
qq_74770105的博客
02-25 1285
binlog 是记录所有数据库表结构变更以及表数据修改的二进制日志（不会记录 select和show这类操作）binlog 是逻辑日志,记录语句的原始逻辑。数据恢复: 可以通过 mysqlbinlog工具进行数据恢复。
使用 mysqlbinlog 分析 binlog 恢复误删除或修改的数据
小毕超博客
03-13 6957
一、mysqlbinlog 在 mysql 中binlog 记录着所有的DDL 和 DML，前提是开启了 binlog，这个时候如果我们误删除了数据或者误修改了数据，就可以通过 binlog 日志文件进行查找恢复。但是 binlog 是以二进制的方式进行存储的，我们直接查看的话并不能看到我们想要的数据，而 mysqlbinlog 就是提供给我们方便查询binlog的工具，我们借助它可以根据时间段或者位置进行快速定位，并且还可以连接远程服务器的 mysql 查看 binlog 信息。 首先在开始实验前，请确
mysql通过binlog恢复数据的几种情况
飞龙在天的博客
07-13 6753
binlog恢复数据的几种情况 1.数据库丢失或者drop 1）恢复系统自动备份 2）用binlog恢复系统备份时间到此刻的的数据（drop操作需要binlog删除drop记录） 2.误操作update，delete 1）恢复系统自动备份 2）在binlog日志中删除误操作的操作语句，执行binlog恢复其他的数据 或者 在binlog中找到误操作的记录，用脚本反生成sql，进行恢
MySQL主从搭建和性能优化（二）——binlog 恢复数据、备份数据的一致性、主从数据一致性、表分区（分区的两种方式、5种分区、常见分区命令）、事务的两阶段提交、小表驱动大表
qq_41824825的博客
03-16 2296
MySQL主从搭建和性能优化（二）——binlog 恢复数据、备份数据的一致性、主从数据一致性、表分区（分区的两种方式、5种分区、常见分区命令）、事务的两阶段提交、小表驱动大表
mysql误删数据后，从binlog中进行恢复删除数据（拯救手残，不跑路）
mu_yu_xi的博客
03-28 9880
通过mysql的binlog日志，对误删数据进行恢复
【江湖救急】通过mysqlbinlog恢复误删除数据
Sebastien23的博客
07-01 1838
🐬数据库版本：MySQL 8.0.30。
mysql根据mysqlbinlog恢复找回被勒索删除的数据库
07-31 199
年初和朋友一起做了个项目，到现在还没收到钱呢，今天中午时候突然听说之前的数据库被攻击了，业务数据库全部被删除。看有没有什么办法恢复，要是恢复不了，肯定也别想拿钱了吧？ 勒索表 README FOR RECOVERY DATA内容如下 README FOR RECOVERY DATA All your databases was backed up. You need to emai...
使用mysqlbinlog 回滚误删的数据
TSOHD的博客
05-19 510
使用mysqlbinlog 回滚误删的数据
再来谈谈如何从binlog文件恢复误update的数据，模拟Oracle的闪回功能
SUOYUEのBLOG
10-02 637
再来谈谈如何从binlog文件恢复误update的数据，模拟Oracle的闪回功能
详解如何通过Mysql的二进制日志恢复数据库数据
12-16
所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据。 系统环境： 操作系统：CentOS 6.5 X64 (虚拟机)； WEB服务：PHP+Mysql+apache； 网站：为方便，直接在本地用蝉知系统搭建一个...
MySQL使用mysqldump+binlog完整恢复被删除的数据库原理解析
12-14
在日常MySQL数据库运维过程中，可能会遇到用户误删除数据，常见的误删除数据操作有： 用户执行delete，因为条件不对，删除了不应该删除的数据(DML操作)； 用户执行update，因为条件不对，更新数据出错（DML操作）...
MySQL通过binlog进行数据恢复
An丶的博客
05-23 606
采用binlog恢复数据的两种情况1.数据库丢失或者drop    1）恢复系统自动备份    2）用binlog恢复系统备份时间到此刻的的数据（drop操作需要binlog删除drop记录）2.误操作update，delete    1）恢复系统自动备份    2）在binlog日志中删除误操作的操作语句，执行binlog恢复其他的数据或者在binlog中找到误操作的记录，用脚本回滚生成sql，...
程序员保命技能，Mysql bin_log数据恢复，你还不知道吗？
迷途的博客
05-26 3378
使用mysql的bin_log日志文件，对操作数据进行恢复、主从备份，本文主要讲解数据恢复。根据操作时间段进行恢复，根据某个操作动作进行数据恢复。
误删数据库的数据后怎么办？
qq_35107993的博客
05-19 1482
以 MySQL 为例，这里对删库语句做下分类： 1. 使用 delete 语句误删数据行，通过闪回 +binlog 可以找回； 2. 使用 drop table/database 或者 truncate table 语句误删数据库/表，通过全量数据定期备份 +binlog 可以找回； 3. 使用 rm -rf 命令误删整个 MySQL 实例，只要还有备份节点就可以找回。 ...
MySQL——通过binlog恢复数据
热门推荐
醉酒的戈多的专栏
04-07 3万+
二进制日志(binnary log)以事件形式记录了对MySQL数据库执行更改的所有操作。binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE、DROP等）以及表数据修改（INSERT、UPDATE、DELETE、TRUNCATE等）的二进制日志。不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但可以通过查询通用日志来查看MySQL执行过的所有语句。
MySQL找回误删的数据，数据恢复
玉龙（支付宝， 小微金服， 高级产品开发工程师）
10-04 673
mysql数据被物理删除，如何通过binlog找回误删除的数据； mysql数据修复；
MySQL BinLog 恢复误更新删除数据
niaonao
11-30 2347
MySQL BinLog 恢复误更新删除数据
mysql 如何通过binlog 来恢复删除的数据
05-10
使用 MySQL 的 binlog 可以恢复删除的数据，可以按照以下步骤进行操作： 1. 确认 MySQL 是否启用了 binlog，可以在 my.cnf 文件中查看是否开启了 binlog。 2. 找到需要恢复的数据所在的时间点，可以通过 mysqlbinlog 工具来查看 binlog，例如： ``` mysqlbinlog mysql-bin.000001 --start-datetime="2022-01-01 00:00:00" --stop-datetime="2022-01-01 01:00:00" > binlog.sql ``` 这将输出在 2022 年 1 月 1 日 0 点到 1 点之间的 binlog 内容到 binlog.sql 文件中。 3. 在 binlog.sql 文件中查找删除数据的语句，可以使用文本编辑器或者 grep 命令来查找。 4. 将找到的语句拷贝到一个新的 SQL 文件中，并在语句前加上 "SET SESSION sql_log_bin=0;"，以禁止将这些语句再次写入 binlog。 5. 执行新的 SQL 文件，以恢复删除的数据。 需要注意的是，使用 binlog 恢复数据有一定的风险，因为 binlog 中包含了数据库的所有修改操作，如果不小心执行了错误的语句，可能会导致数据库的数据不一致。建议在进行操作前，先备份数据库，以防万一。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值