ROW 格式binlog 在MySQL5.6上的数据恢复实验

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

ROW 格式的binlog 在MySQL5.6上的数据恢复实验


5.6和5.7版本的MySQL,有个参数binlog_row_image,默认值为FULL,表示记录的是全部的binlog操作日志(仅在binlog_format=ROW时候生效)。此外binlog_row_image还可以是minimal,表示binlog记录的就只是影响后的行。如此一来使用ROW格式就能节约很多的磁盘空间。

因此,我们服务器上就可以直接设置binlog_format=ROW格式了,至于binlog_row_image设置为FULL还是minimal,各位就自行考虑了。


环境版本如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
> SELECT @@version
+-------------+
| @@version   |
|-------------|
| 5.6.34-log  |
+-------------+
 
> SELECT @@binlog_format;
+-------------------+
| @@binlog_format   |
|-------------------|
| ROW               |
+-------------------+


假设我们的操作都是在一个库里面执行的,MySQL服务器上只跑了这一个hellodb业务的数据库。

如果数据库多的话,还会增大恢复的难度,如下事例(下面的grant操作实例不够明显,但是差不多就是那个操作步骤):


step1  准备一个全量备份:

1
mysqldump --flush-logs -A >  /root/all .sql


step2  手工误操作删除部分数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
> use hellodb;
> delete from scores where `StuID`=8 AND `ID`=14;
# 模拟误操作删了1条用户数据,然后上报需要回滚操作。
 
此时还有个线程,执行了 grant all on *.* to  'abc' @ '%' ; 假设这个grant操作的是管理员正常的操作。
 
> delete from scores where `StuID`=5 AND `ID`=10;
# 模拟再次误操作删了1条用户数据,然后上报需要回滚操作。
 
........
........
在我们发现操作错了,到汇报这期间,还要很多用户的正常操作,也造成了数据库的一些更新。例如下面这条插入的记录。
........
INSERT INTO students VALUES(100, 'www' ,100, 'F' ,3,5);
........
........


step3  mysql停机

1
/etc/init .d /mysql  stop


step4 导出相关的binlog

1
cd  /data/mysql

看下最近的binlog文件,假如我这里看到的是 mysql.0000010 这个文件。


1
2
# 先导出一份binlog文件,
mysqlbinlog --base64-output=decode-rows -vv mysql.000010 >  /root/1 .sql

vi /root/1.sql 找到刚才我们误操作的部分,类似如下(下面被我添加了部分注释):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
BEGIN  ---> 这个BEGIN-COMMIT要删除
/*!*/;
# at 662771   --->  注意这个Postion,回滚要用到
#170116 15:21:31 server id 106  end_log_pos 662826 CRC32 0xc2733cd6     Table_map: `hellodb`.`scores` mapped to number 156
# at 662826
#170116 15:21:31 server id 106  end_log_pos 662873 CRC32 0x0d302d22     Delete_rows: table id 156 flags: STMT_END_F
### DELETE FROM `hellodb`.`scores`
### WHERE
###   @1=14 /* INT meta=0 nullable=0 is_null=0 */
###   @2=8 /* INT meta=0 nullable=0 is_null=0 */
###   @3=4 /* SHORTINT meta=0 nullable=0 is_null=0 */
###   @4=57 /* TINYINT meta=0 nullable=1 is_null=0 */
# at 662873
#170116 15:21:31 server id 106  end_log_pos 662904 CRC32 0x7bda6198     Xid = 1136
COMMIT/*!*/;
 
 
# at 662904  ---> 这个BEGIN COMMIT要保留,这个是用户的正常操作的sql
#170116 15:21:42 server id 106  end_log_pos 663027 CRC32 0xa7dc153b     Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1484551302/*!*/;
grant all on *.* to  'abc' @ '%'
/*!*/;
# at 663027
#170116 15:21:49 server id 106  end_log_pos 663102 CRC32 0xa7570f25     Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1484551309/*!*/;
 
 
BEGIN  ---> 这个BEGIN-COMMIT要删除
/*!*/;
# at 663102  --->  注意这个Postion,回滚要用到
#170116 15:21:49 server id 106  end_log_pos 663157 CRC32 0x20b81986     Table_map: `hellodb`.`scores` mapped to number 156
# at 663157
#170116 15:21:49 server id 106  end_log_pos 663204 CRC32 0x26d9f8b8     Delete_rows: table id 156 flags: STMT_END_F
### DELETE FROM `hellodb`.`scores`     
### WHERE
###   @1=10 /* INT meta=0 nullable=0 is_null=0 */
###   @2=5 /* INT meta=0 nullable=0 is_null=0 */
###   @3=7 /* SHORTINT meta=0 nullable=0 is_null=0 */
###   @4=63 /* TINYINT meta=0 nullable=1 is_null=0 */
# at 663204
#170116 15:21:49 server id 106  end_log_pos 663235 CRC32 0x81f9c1d6     Xid = 1138
COMMIT/*!*/;
# at 663235
#170116 15:22:59 server id 106  end_log_pos 663310 CRC32 0xb3b0508d     Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1484551379/*!*/;
 
 
BEGIN ---> 这个BEGIN-COMMIT要保留,这个是用户的正常操作的sql
/*!*/;
# at 663310   --->  注意这个Postion,回滚要用到
#170116 15:22:59 server id 106  end_log_pos 663373 CRC32 0x17a48bfc     Table_map: `hellodb`.`students` mapped to number 152
# at 663373
#170116 15:22:59 server id 106  end_log_pos 663424 CRC32 0x0acbd405     Write_rows: table id 152 flags: STMT_END_F
### INSERT INTO `hellodb`.`students`
### SET
###   @1=100 /* INT meta=0 nullable=0 is_null=0 */
###   @2='www' /* VARSTRING(150) meta=150 nullable=0 is_null=0 */
###   @3=100 /* TINYINT meta=0 nullable=0 is_null=0 */
###   @4=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @5=3 /* TINYINT meta=0 nullable=1 is_null=0 */
###   @6=5 /* INT meta=0 nullable=1 is_null=0 */
# at 663424
#170116 15:22:59 server id 106  end_log_pos 663455 CRC32 0x1f37c970     Xid = 1139
COMMIT/*!*/;


step5 准备恢复的数据

1
2
3
mysqlbinlog mysql.000010 --stop-position=662771 >  /root/22 .sql                             # 导出step2中第一个DELETE前的数据
mysqlbinlog mysql.000010 --start-position=662904  --stop-position=663027 >  /root/33 .sql    # 导出step2中这个正常的grant授权操作语句
mysqlbinlog mysql.000010 --start-position=663310  >  /root/44 .sql                           # 导出step2中的那个正常的INSERT操作及其后面的全部SQL操作


step6 开始恢复数据

1
2
3
4
5
/etc/init .d /mysql  start 
mysql <  /root/all .sql 
mysql <  /root/22 .sql
mysql <  /root/33 .sql
mysql <  /root/44 .sql


step7 检查恢复后结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
> use hellodb;
> SELECT * from students where `StuID`=100 AND `Name`= 'www' ;
+---------+--------+-------+----------+-----------+-------------+
|   StuID | Name   |   Age | Gender   |   ClassID |   TeacherID |
|---------+--------+-------+----------+-----------+-------------|
|     100 | www    |   100 | F        |         3 |           5 |
+---------+--------+-------+----------+-----------+-------------+
> SELECT * from scores where `StuID`=8 AND `ID`=14;
+------+---------+------------+---------+
|   ID |   StuID |   CourseID |   Score |
|------+---------+------------+---------|
|   14 |       8 |          4 |      57 |
+------+---------+------------+---------+
> SELECT * from scores where `StuID`=5 AND `ID`=10;
+------+---------+------------+---------+
|   ID |   StuID |   CourseID |   Score |
|------+---------+------------+---------|
|   10 |       5 |          7 |      63 |
+------+---------+------------+---------+


可以看到恢复的效果不错。











本文转自 lirulei90 51CTO博客,原文链接:http://blog.51cto.com/lee90/1892434,如需转载请自行联系原作者
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2天前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
148 90
|
3月前
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
102 6
|
1月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
105 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
1月前
|
存储 SQL 关系型数据库
服务器数据恢复—云服务器上mysql数据库数据恢复案例
某ECS网站服务器,linux操作系统+mysql数据库。mysql数据库采用innodb作为默认存储引擎。 在执行数据库版本更新测试时,操作人员误误将在本来应该在测试库执行的sql脚本在生产库上执行,导致生产库上部分表被truncate,还有部分表中少量数据被delete。
65 25
|
19天前
|
SQL 关系型数据库 MySQL
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。
|
3月前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE &#39;log_%&#39;;`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
139 2
|
3月前
|
SQL 关系型数据库 MySQL
数据库数据恢复—Mysql数据库表记录丢失的数据恢复方案
Mysql数据库故障: Mysql数据库表记录丢失。 Mysql数据库故障表现: 1、Mysql数据库表中无任何数据或只有部分数据。 2、客户端无法查询到完整的信息。
|
3月前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。
|
3月前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
4月前
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的binlog日志文件
MySQL的binlog日志记录了所有对数据库的更改操作(不包括SELECT和SHOW),主要用于主从复制和数据恢复。binlog有三种模式,可通过设置binlog_format参数选择。示例展示了如何启用binlog、设置格式、查看日志文件及记录的信息。
528 6