MySQL Binlog 闪回与分析

文章目录

  • 前言
  • 1. 修改 event 实现闪回
    • 1.1 binlog 结构
    • 1.2 闪回案例
    • 1.3 方法总结
  • 2. 解析文本闪回
    • 2.1 mysqlbinlog
    • 2.2 闪回案例
    • 2.3 方法总结
  • 3. 在线订阅闪回
    • 3.1 mysql-replication
    • 3.2 binlog2sql
    • 3.3 方法总结
  • 4. Binlog 分析方法
    • 4.1 分析场景
    • 4.2 辅助定位事务
    • 4.3 方法总结
  • 5. 平台化的解决方案
    • 5.1 数据追踪
    • 5.2 方法总结
  • 总结

前言

由于误操作、代码 bug 或平台误点，我们在操作数据时难免会遇到数据丢失的情况，比如一条 delete 删除了预期之外的数据。早期想要恢复数据，只能通过 全量备份 + 日志备份 恢复数据或业务人员通过日志以及业务逻辑进行手动订正，这些恢复数据的方法影响其恢复速度的变量很多，全量备份如果数据量很大，上传和解压缩的耗时很久，还要考虑增量日志应用。手动订正数据量大业务逻辑复杂的话，是一件非常消耗人力的事情，且容易出错。直到出现 Binlog 闪回技术，大大的提升了 DML 造成数据丢失的恢复速度。

本篇文章，将带你了解 SQL 闪回的三种方法，以及 Binlog 分析方法等。

1. 修改 event 实现闪回

这是一种可以将 delete 操作转换为 insert 操作的一种方法。MySQL binlog 中使用 type_code 来标记 binlog 的事件，例如一个 delete 操作会使用 32 来标记，一个 insert 操作会使用 30 来标记。通过将 delete 事件 type_code 32 修改为 30 就可以将一个删除操作转换为插入操作，就可以回滚 delete 误操作的数据。

该方法需要对 Binlog 的结构有了解，下面介绍一些相关知识。

PS：本文所有的演示，要求的 Binlog 参数配置如下：
binlog_format = ROW
binlog_row_image = FULL

1.1 binlog 结构

binlog 日志为 MySQL 记录数据库变化的日志，主要应用于主从复制和配合其它工具实现数据恢复。binlog 文件分为两类，其中一类为 mysql-bin.00000n 里面记录的是 binlog 事件，另一类为 mysql-bin.index 为 MySQL 二进制日志的索引文件，负责跟踪服务器上所有的 binlog 文件以便必要时可以正确的创建新的 binlog 文件。

每一个 binlog 文件由若干个 binlog 事件组成，以 Format_description（格式描述事件）作为文件头，以 Rotate（日志轮换事件）作为文件尾。除了控制事件，binlog 中其它事件被分为组，在事务存储引擎中，每个事务就是一个组，但是对于非事物存储引擎每条 SQL 语句就是一个组。

从 MySQL 5+ 版本开始，Binlog 采用的是 v4 版本。事件的类型根据 MySQL 的内部文档，有下面 36 类：

enum Log_event_type { UNKNOWN_EVENT= 0, START_EVENT_V3= 1, QUERY_EVENT= 2, STOP_EVENT= 3, ROTATE_EVENT= 4, INTVAR_EVENT= 5, LOAD_EVENT= 6, SLAVE_EVENT= 7, CREATE_FILE_EVENT= 8, APPEND_BLOCK_EVENT= 9, EXEC_LOAD_EVENT= 10, DELETE_FILE_EVENT= 11, NEW_LOAD_EVENT= 12, RAND_EVENT= 13, USER_VAR_EVENT= 14, FORMAT_DESCRIPTION_EVENT= 15, XID_EVENT= 16, BEGIN_LOAD_QUERY_EVENT= 17, EXECUTE_LOAD_QUERY_EVENT= 18, TABLE_MAP_EVENT = 19, PRE_GA_WRITE_ROWS_EVENT = 20, PRE_GA_UPDATE_ROWS_EVENT = 21, PRE_GA_DELETE_ROWS_EVENT = 22, WRITE_ROWS_EVENT = 23, UPDATE_ROWS_EVENT = 24, DELETE_ROWS_EVENT = 25, INCIDENT_EVENT= 26, HEARTBEAT_LOG_EVENT= 27, IGNORABLE_LOG_EVENT= 28,ROWS_QUERY_LOG_EVENT= 29,WRITE_ROWS_EVENT = 30,UPDATE_ROWS_EVENT = 31,DELETE_ROWS_EVENT = 32,GTID_LOG_EVENT= 33,ANONYMOUS_GTID_LOG_EVENT= 34,PREVIOUS_GTIDS_LOG_EVENT= 35, ENUM_END_EVENT /* end marker */ 
};

Binlog 日志由多个 event 组成，一个 event 分为 header 和 data 两部分，通过解析 header 事件就可以知道该事件的类型和长度。

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    |
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    |
|        +----------------------------+
|        | next_position    13 : 4    |
|        +----------------------------+
|        | flags            17 : 2    |
|        +----------------------------+
|        | extra_headers    19 : x-19 |
+=====================================+
| event  | fixed part        x : y    |
| data   +----------------------------+
|        | variable part              |
+=====================================+

下面为我们使用 mysqlbinlog --hexdump 转换为十六进制的 binlog 可以看到 event_type 为 1e 转换为十进制为 1e(十六进制) = 30(十进制) 表明该事件为写入事件。

# at 355
#201209 17:01:52 server id 33061  end_log_pos 410 CRC32 0x31c97555
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags
#      163 80 92 d0 5f   1e   25 81 00 00   37 00 00 00   9a 01 00 00   00 00
#      176 ee 00 00 00 00 00 01 00  02 00 04 ff f0 02 30 33 |..............03|
#      186 06 e5 ad 99 e9 a3 8e 99  46 a8 00 00 03 e7 94 b7 |........F.......|
#      196 55 75 c9 31                                      |Uu.1|
# 	Write_rows: table id 238 flags: STMT_END_F

所以，通过修改 event_type 实现数据恢复的原理，就是定位到数据的 event_type 位置，将 DELETE_ROWS_EVENT 替换为 WRITE_ROWS_EVENT 实现回滚 SQL。

1.2 闪回案例

执行一个 delete 删除操作。

delete from student where SId = 04

准备一个简单的 Python 脚本，修改 Event_type。

import sysif len(sys.argv) != 3:sys.exit()inputType = open(sys.argv[1], "rb")
changedType = open(sys.argv[2], "wb")changedType.write(inputType.read(359))
changedType.write(chr(30).encode())
inputType.seek(1, 1)while True:line = inputType.readline()if not line:breakchangedType.write(line)inputType.close()
changedType.close()

执行脚本程序，执行完成之后会生成一个 bak 文件，是替换过 event code 的 binlog 文件。

python chtype.py mysql-bin.000001 mysql-bin.000001-bak

使用 mysqlbinlog 对比两个 binlog 文件内容，下方是原文件的内容。

BEGIN
/*!*/;
# at 293
#201201 11:13:06 server id 33061  end_log_pos 355 CRC32 0xfc95f44d 	Table_map: `school`.`student` mapped to number 238
# at 355
#201201 11:13:06 server id 33061  end_log_pos 410 CRC32 0x6912246f 	Delete_rows: table id 238 flags: STMT_END_F
### DELETE FROM `school`.`student`
### WHERE
###   @1='04'
###   @2='李云'
###   @3='1990-12-06 00:00:00'
###   @4='男'
# at 410
#201201 11:13:06 server id 33061  end_log_pos 441 CRC32 0x24c5d71c 	Xid = 4363
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

下方是经过篡改过 event code 后的 binlog 文件。

BEGIN
/*!*/;
# at 293
#201201 11:13:06 server id 33061  end_log_pos 355 CRC32 0xfc95f44d 	Table_map: `school`.`student` mapped to number 238
# at 355
#201201 11:13:06 server id 33061  end_log_pos 410 CRC32 0x6912246f 	Write_rows: table id 238 flags: STMT_END_F
### INSERT INTO `school`.`student`
### SET
###   @1='04'
###   @2='李云'
###   @3='1990-12-06 00:00:00'
###   @4='男'
# at 410
#201201 11:13:06 server id 33061  end_log_pos 441 CRC32 0x24c5d71c 	Xid = 4363
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

现在拿着替换后的 binlog 到数据库中执行一下，这条记录就可以恢复。

1.3 方法总结

这种直接修改 Binlog Event 的方法虽然可以将 delete 操作转换为 insert 操作，但较难实现 update 闪回（能实现但是更复杂）且计算 type_cdoe 需要对 Binlog 的结构非常熟悉。经过我们的统计，生产环境中 delete 误删事件只约占 10%，因为数据一般不会真正删除，而是表中有一个字段，用来标记删除，所以 update 导致的数据 “丢失” 占比较高有 80%，剩下的就是 drop 或者 truncate DDL 这种 binlog 不可逆的 DDL 操作，只能通过全量备份恢复。

由于操作复杂，且应对场景有限，这种恢复数据的方式，就没有继续探索下去了，不过是一个学习 binlog 非常好的案例。

PS：美团数据库团队，开源了一款 SQL 闪回工具，MyFlash 基于修改 Binlog Event 结构的方式回滚事务。其中 delete/insert 回滚的方法，与本小节介绍的方法相同。

2. 解析文本闪回

通过 mysqlbinlog 可以将 binlog 文件解析成文本，可以通过对内容进行文本处理正则匹配和替换，从而实现闪回。

2.1 mysqlbinlog

下方是使用 mysqlbinlog 将 binlog 文件解析成文本的命令，还可以添加时间范围 position 位点等过滤条件。

mysqlbinlog -vv --base64-output=decode-rows ./mysqlbin.003626 > all.sql

mysqlbinlog 解析后的内容，多余内容已删除。

### UPDATE `test`.`test_semi`
### WHERE
###   @1=10 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
###   @3=10 /* INT meta=0 nullable=1 is_null=0 */
### SET
###   @1=10 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
###   @3=111 /* INT meta=0 nullable=1 is_null=0 */

这是一个 update 事件，通过 mysqlbinlog 就可以将 binlog 解析成文本，分为两部分 WHERE 表示修改前的内容，既 before_values，SET 表示修改后的内容，既 after_values。此时还不能直接使用，需要将 update 中的 before_values 与 after_values 进行互换，或者直接根据 before_values 转换为 replace into 操作。

delete 事件原理也相同，通过正则匹配进行文本操作，转换为 insert 语句，再放到数据库中执行。

2.2 闪回案例

接下来，用一个生产环境遇到的案例，带大家了解整个数据恢复的过程。

记得当时是一个晚上八点左右时间，正当我准备探索提瓦特大陆的时候，收到研发经理的电话，其实看到这个来电人，以及这个来电的时间，我就心头一紧，准没好事…

他告诉我刚才有研发执行了一个 SQL 脚本，由于执行前没检查，谁知 SQL 文件中，有一条 update 没有带 where 条件，导致整张表被更新了，相当于更新了预期外的数据，产生了数据错乱，需要尽快修复。

让研发经理拉群，找那名研发确认操作时间，误操作的 SQL 语句，以及大致的影响行数。得到如下信息：

  • 误操作时间：19:30 分左右，具体时间不详。
  • 误操作的 SQL 语句：
    -- SQL 是脱敏后的，当时也是更新全表
update test_semi set c = 111;
  • 影响行数：约 1.7w 行。

第一步，定位事务的 position 位点：最原始方法是通过 mysqlbinlog 命令，指定时间范围，导出文本，如果打开文本文件，搜索关键字，匹配误操作的记录。

mysqlbinlog -vv --base64-output=decode-rows --start_datetime='2024-04-18 19:25:00' --stop_datetime='2024-04-18 19:45:00' --database='op_service_db_bak' ./mysql-bin.000014 > all.sql

通过不断缩小时间范围，搜索事务的 position 位点，下图为事务开始的位点。

PS：以下演示使用的是模拟数据，所以日志中的行数与案例描述不一致。

在这里插入图片描述
下图为事务结束的位点。

在这里插入图片描述目前已经在 Binlog 中定位到误操作 position 位置，接下来需要使用脚本解析 update 语句将 WHERE 数据部分转换为 replace into 操作。

mysqlbinlog --base64-output=decode-rows -vvv --start-position=291 --stop-position=240425 ./mysql-bin.000002 | perl parse_binlog_preimage.pl > recover.sql

输出：

--table: `test`.`test_semi`
-- DML type: UPDATE, num of cols: 3
replace into `test`.`test_semi` values ( 10 , 1, 10);
--table: `test`.`test_semi`
-- DML type: UPDATE, num of cols: 3
replace into `test`.`test_semi` values ( 11 , 2, 0);
--table: `test`.`test_semi`
-- DML type: UPDATE, num of cols: 3
replace into `test`.`test_semi` values ( 12 , 1, 10);
--table: `test`.`test_semi`
-- DML type: UPDATE, num of cols: 3
replace into `test`.`test_semi` values ( 13 , 2, 0);
--table: `test`.`test_semi`
-- DML type: UPDATE, num of cols: 3
replace into `test`.`test_semi` values ( 14 , 1, 10);

脚本的作用是通过正则匹配到 binlog 文本 update 中的 WHERE 数据部分，然后转换为 replace into，这样做的好处是，导出的 SQL 研发可以先插入到测试表检查一遍数据，特别是回滚的行数较多的时候。

2.3 方法总结

这种方法适用于回滚数据量较小的场景，影响行数很大的话，解析效率远小于直接修改 Binlog event 的方法。

定位事务 Position 的方法，非常原始，全凭使用者的经验，而且在某些场景文本解析的方法的兼容性有待商榷。优点是脚本写起来比较简单，不需要学习 Binlog 结构就可以上手。

3. 在线订阅闪回

该方法是基于类 python-mysql-replication 库，伪装成一个 binlog dump 线程，实时订阅 MySQL Binlog 日志生成，从而实现闪回。从上文可以看到，binlog 中的字段是使用 @1 这种形式标记的，只有顺序没有字段名称，所以不能实现字段过滤。这种在线订阅 Binlog 的方法，因为需要连接数据库，所以可以基于 MySQL 元数据补充字段名称，从而实现字段过滤。

3.1 mysql-replication

之前文章中有详细介绍并演示过该模块，感兴趣的朋友可以根据文章的案例进行测试。

推荐阅读：MySQL 如何从 Binlog 找出变更记录并回滚

文章中，利用了在线订阅 Binlog 可以获得字段信息的优势，实现了事务过滤，通过写 if 条件过滤到我们需要定位的事务。

3.2 binlog2sql

基于 mysql-replication 模块，实现的一个 SQL 闪回工具，使用起来非常简单。通过在线拉取 binlog 获得 event 数据，拼接为 SQL 语句，支持将语句反转。我自己也写过类似的工具，叫 COOHSQL。

项目地址：binlog2sql github

一些开源的审核工具，比如 Archary，内置的闪回功能就是通过 binlog2sql 实现的。如果一条工单执行后，需要闪回，就可以利用该功能实现闪回。

3.3 方法总结

由于原生 Binlog 中没有字段信息，只有 Table_map 中的字段列表，所以只解析原生 Binlog 无法实现字段过滤，一个 Binlog 文件可能存着几百万个事务，人工定位误操作的事务是一件比较吃经验方法，不太通用。

现在通过在线订阅 Binlog 可以基于 MySQL 元数据库，补充字段信息，利于实现条件过滤，至少可以很大程度缩小搜索范围。

4. Binlog 分析方法

Binlog 中记录了数据库中的数据变动，除了用于增量恢复和 SQL 闪回（包含数据订正）场景外，还有一个数据生命周期管理场景，让 DBA 从更高的一个角度来看待所管理的数据。

4.1 分析场景

这里列举几个场景：

  1. 了解数据库中，每天有多少张表是通过后端自动删除重建的，有多少次 DDL 变更？记得有一次迁移场景，通过某云的 DTS 进行全量数据迁移，业务每小时都会对一张表进行 truncate，这个信息提前没有了解到，结果因为 DTS 迁移任务产生 MDL 锁争用，引发了一次小范围的故障。如果提前了解到业务规律，那么就可以协调停掉相关业务。这些信息可以从 Binlog 中的 Query Event 中分析得到。

  2. 引入数据的变更频率，把 DML 的频率量化出来，就可以知道数据库中的 DML 操作的比例，哪些是热点表，帮助 DBA 落实数据冷热分离。在一套 MySQL 集群中，如果 DML 变更频繁，可能会造成主从延迟，此时通过分析 Binlog 就可以快速定位到原因，精确到哪张表，有没有大事务？哪种类型的操作造成集群延迟？都可以通过分析 Binlog 得到答案。

在这里插入图片描述

上图，是我自研的一个 Binlog 分析工具，将分析结果通过 Tableau 甘特图进行展示，可以清晰的看到每张表在各个时间段的 DML 情况。例如上图 sku_store update 操作量很大，其次是一些日志表，多为一些写入操作。

4.2 辅助定位事务

Binlog 分析工具，我已经开源，可以参考我之前的文章。

推荐阅读：MySQL Binlog 分析方法 - 自研分析工具 BinlogShow

请添加图片描述
该工具会扫描 Binlog 中的事务，然后生成一个事务列表。

在实际生产中，该工具可以帮助我们定位闪回事务的位点。这时候可能你会想：只有一个事务列表又不能使用字段过滤，为什么可以帮助定位闪回事务呢？

我们通过该工具分析了多个业务系统的 DML 规律，绝大部分表，每次更新的量基本都是一样的，误差不会很大，所以 event 日志量的大小也基本一致，一个误操作影响行数往往和业务 DML 的量不同，所以从 binlog 中事务大小，也有可能定位到误操作的 Position。

这里列举一个生产环境的案例：一张 user 表的用户状态被误更新了，影响行数大约是 10w 行。业务 SQL 一般只会更新一行，所以在 Binlog 中的事务大小也就几 KB，误操作影响行数是 10w 行，在 Binlog 中的事务大小是 30MB，定位该事务只需要使用我写的 Binlog 分析工具，拿到事务列表，然后对事务大小进行降序排序，就可以很明显的看出来误更新事务对应的 Position 位点。

4.3 方法总结

通过分析 Binlog 可以了解数据中的数据流动情况，也可用于某种场景下的 position 定位，定位到 position 位点后，可以搭配第 1 小节或第 2 小节的方法进行数据回滚。

5. 平台化的解决方案

上文，我们介绍了三种数据回滚的方法，其中在线订阅的方法，是可以实现字段过滤的，也是我个人常用的方法。生产上除了需要通过 Binlog 进行回滚外，也会有订正数据的需求，比如业务 bug 导致一行记录出现预期外的更新。数据库侧能提供的帮助就是解析 Binlog 追踪到相关记录，帮助研发订正数据。

工作至今，也参与过二十余数据恢复，有特别严重的直接惊动高层的故障，也有影响很小的的事件，研发要求能恢复就行。我个人从通过使用 SQL 文本搜索定位事务，再到 binlog 订阅自动化定位事务，一直在探索如何快速便捷的处理数据丢失事故。也在思考如何尽可能避免此类事故发生，于是分析了公司知识库中记录的所有数据故障（约 40 起）案例。

下图为导致数据丢失事件操作类型的分类，平台误点指在云平台 DROP DATABASE 或者数据库中执行 DROP TABLE。SQL 写错是指研发人员在数据库中执行 SQL 任务时，SQL 语句错误导致的效果未取得预期且对原数据造成伤害。
请添加图片描述

其中，暴露出来的问题如下：

  1. 平台误点，背后的问题是权限管控不到位，这种 drop 权限只能掌握在少数可靠的人手里。

  2. SQL 写错，暴露的问题是，一条 SQL 语句对线上环境的影响，无人评估。

  3. SQL 变更无管控审核，多次发生 SQL 忘记带 WHERE 条件、SQL 写错等失误，造成数据丢失。

如何应对这类问题呢？答案就是数据库管控平台化，SQL 任务变更走审核流程。另外还有一组数据，在多起数据丢失事件中，团队是否使用了审核流程和故障数量是否有关系呢？
请添加图片描述

从上图，可以看出没有使用审核流程的团队，故障（数据丢失故障）占比最高。使用了审核流程的团队，数据丢失故障仅占 8%，由此可以看出使用审核流程，能够很大程度减少数据丢失故障数量。

另外，在有审核流程的团队，如果没有重视或者严格遵守审核流程的话，故障数量占比依旧比较高。为什么有审核流程，却不全面使用呢？我采访了相关的研发团队，首先研发 leader 是知道审核流程的重要性，但是总会以太忙（发版着急，懒得提工单）为由，跳过审核流程，直接拿 SQL 到环境里面执行，从而导致生产环境的数据安全存在隐患。造成研发团队不重视审核流程的原因我总结有如下几个：

  1. 研发团队针对数据库的安全意识不够强，需要数据库团队多宣传和培训。
  2. 审核平台使用起来不顺手，一些开源的审核平台，用户体验上其实并不好，导致研发团队潜意识抵触审核流程。
  3. 研发团队对数据库平台化的技术发展不太关注，不了解目前数据库 DevOPS 发展程度，有多少可以提升研发效率和数据安全的技术，只有在出问题的时候，被动了解一部分。这也需要数据库团队潜移默化的传递。

总结一下，数据安全防护的尽头，是平台化，平台不仅要好用也要用好。

5.1 数据追踪

刚才有提到数据库 DevOPS 领域中也有很多提升研发效率和数据安全的技术，这里分享一个我个人非常喜欢的一款数据库平台 NineData。本文主题是数据恢复，那么我就带大家一起看看 NineData 是如何帮助用户快速追踪到误操作记录并完成回滚。

NineData 为用户提供了一个数据追踪的功能，可用于 SQL 闪回和数据订正场景。它是基于在线订阅 Binlog 的方式实现的，支持字段过滤，自动化的程度非常高，大大降低了使用门槛，即使不是 DBA 也能通过数据追踪功能快速恢复数据。

话不多说，一起从 0 开始测试一下该功能，首先需要注册一个账号：

NineData 注册地址

注册完成后，进入控制台，可以免费申请数据源，便于快速测试。

在这里插入图片描述

申请的测试数据源中，已经提供了测试的数据集。我们使用 sample_employees_8064 库中的 employees 员工表，模拟一次数据误更新故障。

请添加图片描述

性别为男的员工有 79973 条记录，使用下方 SQL 将所有男性员工的名字修改为 Bing，影响行数为 79973。

请添加图片描述
现在所有男性员工的名字，出现了数据错误，现在需要立即恢复数据，该怎么做呢？
在这里插入图片描述

创建一个数据追踪任务，指定误操作的环境信息以及大致的时间范围，还有误操作的过滤条件即可。

从任务提交审批到 Binlog 解析完成，只花费了 2 分钟，就得到误操作的追踪记录。速度如此之快的原因可能也与是测试环境，数据库中几乎没有 DML 有关。不过即便如此，假如使用上方介绍的方法，两分钟我可能还没有把 Binlog 从环境中下载下来用于解析… 这也是平台化的魅力。
在这里插入图片描述

从上图，可以看到追踪出来的记录是 79973 条，与刚才执行窗口中的影响行数一致。

点击详情，就可以看到每行记录的变更记录。
在这里插入图片描述

如果需要恢复到数据库，可以点击下载回滚 SQL 的选项，就可以拿到回滚 SQL 到环境中执行。

-- 这里只展示部分，SQL 通过主键字段进行数据回滚
update `sample_employees_8067`.`employees` set `first_name`='JoAnne' where `emp_no`='266818' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Akeno' where `emp_no`='266821' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Fumitake' where `emp_no`='266823' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Munehiko' where `emp_no`='266824' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Karlis' where `emp_no`='266825' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Conal' where `emp_no`='266826' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Tua' where `emp_no`='266829' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Mitchel' where `emp_no`='266832' limit 1 ;
update `sample_employees_8067`.`employees` set `first_name`='Gaurav' where `emp_no`='266833' limit 1 ;

在 NineData 中，可以提交一个 SQL 导入任务：

在这里插入图片描述
下图为 SQL 数据导入的流程，将回滚 SQL 导入到环境中执行。

在这里插入图片描述
到目标环境中抽样检查数据，刚才所有男性的名字被修改为了 Bing，现在已完成回滚。

在这里插入图片描述

5.2 方法总结

NineData 结合平台化的优势，极大的提升数据追踪的自动化程度和任务效率。当故障（指数据丢失）发生的时候，运维人员往往需要在高压的环境下迅速做出决策，而自动化程度的提升则能大大减轻他们的负担，从而保障故障有条不紊的恢复，尽可能的减少 RTO 让业务快速恢复。

除了数据追踪功能外，NineData 还有很多耳目一新且非常实用的功能，感兴趣的朋友可以 注册 账号去体验。

总结

本文详尽地介绍了三种 Binlog 回滚方法，它们分别是修改 Binlog Event、文本解析以及 Binlog订阅。基本覆盖了 Binlog 解析的大部分内容。除此之外，还列举了定位事务 Position 的有效方法，为实际操作提供了有力指导。同时，文章也探讨了如何减少数据丢失故障的重要性，并强调了审核流程在保障数据安全与完整性中的不可或缺性。通过本文的阅读，可以全面了解 Binlog 回滚的方法与技巧，为日常的数据管理与维护工作提供有力支持。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/830289.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【C/C++笔试练习】OSI分层模型、源端口和目的端口、网段地址、SNMP、状态码、tcp报文、域名解析、HTTP协议、计算机网络、美国节日、分解因数

【C/C++笔试练习】OSI分层模型、源端口和目的端口、网段地址、SNMP、状态码、tcp报文、域名解析、HTTP协议、计算机网络、美国节日、分解因数

文章目录 C/C笔试练习选择部分（1）OSI分层模型（2）源端口和目的端口（3）网段地址（4）SNMP（5）状态码（6）tcp报文（7）域…
阅读更多...
美国站群服务器上常见的操作系统选择指南

美国站群服务器上常见的操作系统选择指南

美国站群服务器上常见的操作系统选择指南 美国站群服务器的选择操作系统对于服务器的性能和功能至关重要。本文将为您介绍在美国站群服务器上常见的操作系统选择指南，以帮助您做出明智的决策。 在选择美国站群服务器时，选择合适的操作系统是至关重要的…
阅读更多...
鸿蒙OpenHarmony【标准系统 烧录】（基于RK3568开发板）

鸿蒙OpenHarmony【标准系统 烧录】（基于RK3568开发板）

烧录 烧录是指将编译后的程序文件下载到芯片开发板上的动作，为后续的程序调试提供基础。DevEco Device Tool提供一键烧录功能，操作简单，能快捷、高效的完成程序烧录，提升烧录的效率。 RK3568的镜像烧录通过Windows环境进行烧录&…
阅读更多...
pytorch库 01 安装Anaconda、Jupyter，Anaconda虚拟环境连接pycharm

pytorch库 01 安装Anaconda、Jupyter，Anaconda虚拟环境连接pycharm

文章目录 一、安装Anaconda1、卸载Anaconda（可选）2、下载并安装Anaconda3、配置环境变量4、桌面快捷方式 二、安装 PyTorch（GPU 版）库1、创建虚拟环境，并安装一些常用包2、GPU 基础3、检查驱动4、安装CUDA（…
阅读更多...
Spring Boot | Spring Security ( SpringBoot安全管理 )、Spring Security中 的 “自定义用户认证“

Spring Boot | Spring Security ( SpringBoot安全管理 )、Spring Security中 的 “自定义用户认证“

目录 : Spring Boot 安全管理 ：一、Spring Security 介绍二、Spring Security 快速入门2.1 基础环境搭建 :① 创建Spring Boot 项目② 创建 html资源文件③ 编写Web控制层 2.2 开启安全管理效果测试 :④ 添加 spring-boot-starter-security 启动器⑤ 项目启动测试 三…
阅读更多...
YOLOv5模型使用云服务器autoDL训练

YOLOv5模型使用云服务器autoDL训练

本篇内容讲述如何租用autoDL云服务器，以及使用vscode的ssh远程连接服务器和文件上传方法 目录 一、进入autoDL二、VSCode连接三、文件上传 一、进入autoDL 地址：https://www.autodl.com/home 第一步：进入autoDL地址后，首先进行…
阅读更多...
linux进入单用户模式指引

linux进入单用户模式指引

文章目录 引言I 通过GRUB进入单用户模式1.1 倒计时界面的操作1.2 GRUB1.3 内核参数编辑界面1.4 更多内核参数编辑界面II 预备知识：Linux用户模式引言 应用场景： root密码重置: 用passwd命令修改root修复登录相关的配置：/etc/pam.d/login 和 /etc/pam.d/sshd 案例：Centos6进…
阅读更多...
文件上传复习（upload-labs18-19关）

文件上传复习（upload-labs18-19关）

Pass-18&#xff08;条件竞争&#xff09; 代码和第17关大差不差&#xff0c;所以查看提示 需要用到代码审计 上传图片木马配合解析漏洞进行getshell 新建一句话木马 18.php&#xff0c;代码为&#xff1a; <?php fputs(fopen(../upload/shell18.php,w),<?php phpin…
阅读更多...
Unreal Engine添加UGameInstanceSubsystem子类

Unreal Engine添加UGameInstanceSubsystem子类

点击C类文件夹&#xff0c;在右边的区域点击鼠标右键&#xff0c;在弹出的菜单中选择“新建C类”在弹出的菜单中选中“显示所有类”&#xff0c;选择GameInstanceSubsystem作为父类, 点击“下一步”按钮输入子类名称“UVRVIUOnlineGameSubsystem”&#xff0c;选择插件作为新类…
阅读更多...
【大数据与云计算】虚拟机安装Linux

【大数据与云计算】虚拟机安装Linux

前言&#xff1a;使用Linux系统对大数据学习必不可少&#xff0c;本文主要介绍虚拟机安装linux的流程 文章目录 一、 下载VMware二、下载Linux三、安装Linux 一、 下载VMware 官网链接 下载VMware-player&#xff0c;一直下一步安装即可。 二、下载Linux 点击链接直接下载&…
阅读更多...
第一个大型汽车ITU-T车载语音通话质量实验室投入使用

第一个大型汽车ITU-T车载语音通话质量实验室投入使用

中国汽车行业蓬勃发展&#xff0c;尤其是新能源汽车风起云涌&#xff0c;无论是国内还是海外需求旺盛的趋势下&#xff0c;除乘用车等紧凑型车外&#xff0c;中型汽车如MPV、小巴、小型物流车&#xff0c;大型汽车如重卡、泥头车等亦加入了手机互联、智驾的科技行列&#xff0c…
阅读更多...
PD虚拟机（Parallels Desktop）2024mac苹果电脑19免费版下载

PD虚拟机（Parallels Desktop）2024mac苹果电脑19免费版下载

PD虚拟机&#xff08;Parallels Desktop 虚拟机&#xff09;是一款知名的系统虚拟化软件&#xff0c;PD虚拟机允许用户在一个操作系统中同时运行另一个或者多个操作系统。这种技术在多种场景中非常有用&#xff0c;比如程序开发、专业研究、游戏对战等&#xff0c;尤其是对于需…
阅读更多...
Kafka 3.x.x 入门到精通（03）——Kafka基础生产消息

Kafka 3.x.x 入门到精通（03）——Kafka基础生产消息

Kafka 3.x.x 入门到精通&#xff08;03&#xff09;——对标尚硅谷Kafka教程 2. Kafka基础2.1 集群部署2.2 集群启动2.3 创建主题2.4 生产消息2.4.1 生产消息的基本步骤2.4.2 生产消息的基本代码2.4.3 发送消息2.4.3.1 拦截器2.4.3.1.1 增加拦截器类2.4.3.1.2 配置拦截器 2.4.3…
阅读更多...
LangChain之各个输出解析器的使用

LangChain之各个输出解析器的使用

Model I/O 在LangChain中&#xff0c;Model I/O被称为&#xff1a;模型的输入与输出&#xff0c;其有输入提示(Format)、调用模型(Predict)、输出解析(Parse)等三部分组成。 makefile 复制代码 1.提示模板: LangChain的模板允许动态选择输入&#xff0c;根据实际需求调整输入内…
阅读更多...
从业务经营到企业战略，构建制药企业数字化应用新能力

从业务经营到企业战略，构建制药企业数字化应用新能力

我国医药的消费正处在一个高速增长的阶段&#xff0c;人口增长、老龄化加剧、经济总体增长、人均消费增长、农村收入提高&#xff0c;这五大因素是医药市场蓬勃发展的动力。在这五大因素的驱动下&#xff0c;我国的医药市场需求将会在未来相当长的时间内保持高速增长。从多个环…
阅读更多...
（三）登录和注册(handle_auto.go)

（三）登录和注册(handle_auto.go)

登录和注册(handle_auto.go) 文章目录 登录和注册(handle_auto.go)一、所需要的结构体信息二、注册三、登录四、退出 一、所需要的结构体信息 type UserAuth struct{}type LoginReq struct {Username string json:"username" binding:"required"Password …
阅读更多...
错误代码126：加载xinput1_3.dll失败如何解决？8个解决方法分享

错误代码126：加载xinput1_3.dll失败如何解决？8个解决方法分享

xinput1_3.dll是Windows操作系统中一个非常关键的动态链接库&#xff08;Dynamic Link Library, DLL&#xff09;文件&#xff0c;它是微软DirectX软件开发包的组成部分&#xff0c;专门用于支持游戏控制器和其它输入设备在游戏及多媒体应用程序中的交互。下面是对xinput1_3.dl…
阅读更多...
封装 H.264 视频为 FLV 格式然后推流

封装 H.264 视频为 FLV 格式然后推流

封装 H.264 视频为 FLV 格式并通过 RTMP 推流 flyfish 协议 RTMP (Real-Time Messaging Protocol) RTSP (Real Time Streaming Protocol) SRT (Secure Reliable Transport) WebRTC RTMP&#xff08;Real Time Messaging Protocol&#xff09;是一种用于实时音视频流传输的协…
阅读更多...
qt安装历史版本5.15.2

qt安装历史版本5.15.2

0 背景 因为需要&#xff0c;所以需要安装qt5的最后一个版本qt5.15.2&#xff0c;但是下载qt安装器后&#xff0c;发现没有想要的版本。后面才发现&#xff0c;可以筛选历史版本进行安装。 1 解决 1&#xff0c;打开qt安装程序&#xff0c;勾选Archive后&#xff0c;点击筛选…
阅读更多...
Python实现自动化的服务器部署和配置管理库之pyinfra使用详解

Python实现自动化的服务器部署和配置管理库之pyinfra使用详解

概要 在现代软件开发中，自动化部署和配置管理变得越来越重要。Python pyinfra库是一个强大的工具，可以帮助开发者实现自动化的服务器部署和配置管理。本文将介绍pyinfra库的安装、特性、基本功能、高级功能、实际应用场景以及总结。 安装 首先，来看一下如何安装pyinfra库。…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023