nand.bin还原 PolarDB-X 20 全局 Binlog 和备份恢复能力解读

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

作者： 燧木

背景

我们作为开发者都了解或熟悉后台系统，后台系统可以抽象为两个组成部分：一个是业务系统，该部分负责处理系统的业务逻辑，在现代化的架构中，该部分通常设计成可水平扩展的无状态节点；另一个是数据库系统，该部分负责存储系统的状态，这其中便包括最核心的业务数据。

站在数据库的视角，数据的流入包括两个部分，一个是业务系统的实时写入，这是核心数据来源的主要部分；另一个是从上游数据系统一次性或周期性导入的数据。因为这些核心数据在这里首次产生，所以这个数据库也被称为 SSOT（Single Source of Truth）。

SSOT 是后台系统中最重要的数据资产，那么随之便产生两个问题需要妥善处理。第一个问题是，作为最重要的资产，通常我们需要将这些数据实时同步到其他系统进行 BI 分析等进一步的处理，如果没有这样的实时同步机制，那么这份数据将成为数据孤岛。第二个问题是，这份数据可能因为各种原因遭到破坏，比如硬件故障或软件 Bug 导致的数据损坏、不当操作引起的数据损坏、错误 SQL 引起的数据错乱等，提供多种机制保障这份数据的安全显得非常必要。

全局 Binlog

PolarDB-X 是一款高度兼容 MySQL 生态的分布式数据库产品，所以我们首先来看下 MySQL 是如果解决数据孤岛问题的。

从 DB-Engines 排行榜可以看出，MySQL 的流行度比其他开源数据库的总和还要高，这意味着 MySQL 的生态非常繁荣，比如 MySQL 的下游系统有 Kafka、MySQL 备节点、Canal 多种数据同步工具、Pulsar 等等。MySQL 通过 Binlog 机制实现了与下游系统的实时增量数据同步。Binlog 可以看做是一个消息队列，队列中按顺序保存了 MySQL 中详细的增量变更信息，通过消费这个队列，下游系统或工具实现了与 MySQL 的实时数据同步，这样的机制也称为 CDC（Change Data Capture），即增量数据捕捉。

分布式数据库提供 CDC 能力相对于单机有更高的复杂度。一个分布式数据库通常包含多个节点，这些节点会产生多个增量日志队列，那么下游如果要消费多个队列会涉及几个问题。

因为是多个队列，那么下游消费时多个队列内变更事件的顺序如何确定？分布式事务的变更可能涉及多个队列，如果要保证消费时事务的完整性，那么如何发现并合并同一个事务的变更事件？系统发生了扩缩容（也就是队列的增减）下游如何正确处理？DDL 会涉及多个队列，下游如何精确识别出每个队列 Schema 变化前后的位置并协调好消费进度？

面对这些问题，分布式数据库的 CDC 能力需要在实现难度、支持特性、易用性等方面做 trade-off。通常来说，给下游提供多个队列、不保障事务完整性仅提供最终一致性、提供自定义格式的增量日志是一种较易实现的方案，但该方案会对下游消费提出更高的要求，比如要开发相应的消费代码或工具、需要考虑多个队列的协同问题等。一种体验更友好的方式是，通过提供与 MySQL Binlog 完全一致体验的 CDC 能力，让下游可以像消费 MySQL Binlog 一样透明的消费分布式数据库的增量变更，从而极大降低数据同步链路的搭建成本，这也是 PolarDB-X 2.0 采用的方案，我们称为全局 Binlog。

PolarDB-X 2.0 采用的是可水平扩展的 Share-Nothing 架构，系统基本组成单位是节点（即 Node），每个节点又可分为计算节点（即CN）和数据节点（即DN）两个部分。如上图所示，为提供全局 Binlog 能力，PolarDB-X 2.0 在此基础上增加了 CDC 组件，CDC 是一个具备弹性能力的集群。

全局 Binlog 的生成过程可分为三个阶段：

CDC 组件从每个 DN 拉取其增量日志，也就是物理 Binlog，之后进行单队列排序、内部事件过滤、DDL 相关的整形等操作，以便为下一阶段提供一个“干净”的增量事件队列，同时若系统发生了扩缩容，CDC 组件会在该阶段自动感知并做相关处理；CDC 组件将所有“干净”的增量事件队列进行合并，期间会对属于同一分布式事务的事件进行合并，并会根据事务时间戳进行全局排序，这样便得到一个全局有序的保障事务完整性的事件队列，同时该阶段还会处理好 DDL 在队列中的位置。之后 CDC 组件会将该队列生成兼容 MySQL Binlog 格式的文件，即全局 Binlog 文件；CN 组件在收到下游订阅全局 Binlog 请求后，会按照 MySQL DUMP 协议将全局 Binlog 发送给下游消费。

经过上面三个阶段，PolarDB-X 2.0 实现了完全兼容 MySQL Binlog 的全局 Binlog 能力。如果对详细的实现原理感兴趣，欢迎关注PolarDB-X的知乎专栏：PolarDB-X - 知乎

备份恢复

对于数据损坏问题，PolarDB-X 2.0 提供不同粒度的数据恢复能力，包括实例级的一致性备份恢复能力、表级的表回收站能力、SQL 级的 SQL 闪回能力、行级的 Flashback Query 能力等。下面分别介绍这四项能力的特点和使用场景。

一致性备份恢复

首先来看下一致性备份恢复，该能力的特点是可以提供实例级任意时间点的历史数据恢复能力，这个时间点可以精确到秒级。

单机数据库中，可以认为全量数据和增量日志都存储在一台机器上，实现一致性备份和恢复的话，只需要将全量数据和增量日志备份就好。分布式数据库中若要做到一致性备份恢复，因为全量数据和增量日志都存储在多台机器上的缘故，实现上会有额外的复杂度。

PolarDB-X 2.0 中通过将所有 DN 做全量备份+全局 Binlog 的方式实现了一致性备份恢复能力。

以上图为例，比如我们有一个 PolarDB-X 2.0 实例每周一、周二和周五的零点进行备份，某天产生一个需求，需要将数据恢复到周日的 14:25:26，那么我们的系统会选择离恢复点最近的一个全量备份集---- 也就是周五零点点这份，并从周五零点开始重放全局 Binlog，直到周日 14:25:26 结束，这样我们便得到了想要的快照。

PolarDB-X 2.0 的一致性备份恢复能力备份期间不会锁库，该能力依赖全局 Binlog，也就是可恢复的区间是全局 Binlog 的保存区间。该能力目前有几个限制，比如备份期间不能进行扩缩容、仅支持同构恢复等。

表回收站

PolarDB-X 2.0 提供的第二项数据恢复能力叫做表回收站。顾名思义，我们会将 DROP 的表临时放入一个回收站，若两小时内发现需要恢复该表，那么可以在回收站中找回。

表回收站提供了完整的管理功能，比如查看回收站中所有的表、彻底删除某张表、恢复某张表等。回收站目前仅缓存两小时内删除的表，并且不支持找回通过 TRUNCATE TABLE 删除的表。

SQL 闪回（即将上线）

PolarDB-X 2.0 提供的第三项数据恢复能力叫做 SQL 闪回。该能力可精确恢复一条误操作 SQL 影响的数据。PolarDB-X 1.0 中同样提供了该能力，上线以来，该能力帮助众多误删数据的用户找回了数据，是一项被广泛认可的数据恢复能力。下面我们以一个例子来介绍这项能力的具体使用过程。

如上图所示，在 T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录删掉，但 WHERE 条件中忘了加 "name='Ralph'" ，导致名字为 "Mary" 的记录被一同删掉了。这两个删除事件以及对应 SQL 的 ID 会被记录在全局 Binlog 中。

T2 时，我们发现了误删问题，并通过 PolarDB-X 的审计功能找到了对应的 SQL 和 ID。

T3 时，我们通过 SQL ID 和 SQL 闪回能力生成了恢复 SQL。SQL 闪回的原理是，在拿到 SQL ID 后，通过在全局 Binlog 中进行搜索，找到该 SQL 对应的所有变更事件（此处为两个删除事件），并逐个生成逆向恢复 SQL。

T4 时，我们将恢复 SQL 执行后得到了被误删的两条数据。

SQL 闪回针对 SQL 误操作场景可提供精确的数据恢复能力，可以看出，能够恢复的时间区间依赖于全局 Binlog 的保存区间。

Flashback Query（即将上线）

PolarDB-X 2.0 提供的第四项数据恢复能力叫做 Flashback Query。该能力可提供一定时间范围内行级的数据精确恢复能力。下面我们仍以 SQL 误操作场景为例。

如上图所示，T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录职位更新为 "CTO"，但 WHERE 条件中忘了加 "name='Ralph'"，导致所有职位是 "Developer" 的记录都被更新成了 "CTO"。这些变更都会记录在版本为 Vn+1 的 undo log 中（undo log 是数据库中的一个基础数据结构，里面详细的记录了每行数据的变更内容，可简单类比成 GIT commit log）。

T2 时，我们马上发现了误改问题并确定了误操作时间和影响的数据范围。

T3 时，我们通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值。

T4 时，我们根据 Flashback Query 返回的正确值对数据进行了订正。

可以看出，Flashback Query 能力依赖 undo log 的保存时长。与 SQL 闪回相比，该能力可提供更快速、精确到行级的恢复能力，但 undo log 通常不如全局 Binlog 保存的时间长，所以可恢复区间上弱于 SQL 闪回。

总结

PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。PolarDB-X 2.0 还在持续打造更多产品能力，敬请期待~

【相关阅读】

PolarDB-X：使用一个透明的分布式数据库是一种什么体验

#阿里云# #数据库#

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

简介： PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。

发布会传送门：https://yqh.aliyun.com/live/polardbx2021

背景

我们作为开发者都了解或熟悉后台系统，后台系统可以抽象为两个组成部分：一个是业务系统，该部分负责处理系统的业务逻辑，在现代化的架构中，该部分通常设计成可水平扩展的无状态节点；另一个是数据库系统，该部分负责存储系统的状态，这其中便包括最核心的业务数据。站在数据库的视角，数据的流入包括两个部分，一个是业务系统的实时写入，这是核心数据来源的主要部分；另一个是从上游数据系统一次性或周期性导入的数据。因为这些核心数据在这里首次产生，所以这个数据库也被称为 SSOT（Single Source of Truth）。

全局 Binlog

PolarDB-X 是一款高度兼容 MySQL 生态的分布式数据库产品，所以我们首先来看下 MySQL 是如果解决数据孤岛问题的。

全局 Binlog 的生成过程可分为三个阶段：

经过上面三个阶段，PolarDB-X 2.0 实现了完全兼容 MySQL Binlog 的全局 Binlog 能力。如果对详细的实现原理感兴趣，欢迎关注我们的知乎专栏《PolarDB-X 知乎专栏》。

备份恢复

一致性备份恢复

首先来看下一致性备份恢复，该能力的特点是可以提供实例级任意时间点的历史数据恢复能力，这个时间点可以精确到秒级。单机数据库中，可以认为全量数据和增量日志都存储在一台机器上，实现一致性备份和恢复的话，只需要将全量数据和增量日志备份就好。分布式数据库中若要做到一致性备份恢复，因为全量数据和增量日志都存储在多台机器上的缘故，实现上会有额外的复杂度。PolarDB-X 2.0 中通过将所有 DN 做全量备份+全局 Binlog 的方式实现了一致性备份恢复能力。以上图为例，比如我们有一个 PolarDB-X 2.0 实例每周一、周二和周五的零点进行备份，某天产生一个需求，需要将数据恢复到周日的 14:25:26，那么我们的系统会选择离恢复点最近的一个全量备份集---- 也就是周五零点点这份，并从周五零点开始重放全局 Binlog，直到周日 14:25:26 结束，这样我们便得到了想要的快照。PolarDB-X 2.0 的一致性备份恢复能力备份期间不会锁库，该能力依赖全局 Binlog，也就是可恢复的区间是全局 Binlog 的保存区间。该能力目前有几个限制，比如备份期间不能进行扩缩容、仅支持同构恢复等。

表回收站

PolarDB-X 2.0 提供的第二项数据恢复能力叫做表回收站。顾名思义，我们会将 DROP 的表临时放入一个回收站，若两小时内发现需要恢复该表，那么可以在回收站中找回。表回收站提供了完整的管理功能，比如查看回收站中所有的表、彻底删除某张表、恢复某张表等。回收站目前仅缓存两小时内删除的表，并且不支持找回通过 TRUNCATE TABLE 删除的表。

SQL 闪回（即将上线）

PolarDB-X 2.0 提供的第三项数据恢复能力叫做 SQL 闪回。该能力可精确恢复一条误操作 SQL 影响的数据。PolarDB-X 1.0 中同样提供了该能力，上线以来，该能力帮助众多误删数据的用户找回了数据，是一项被广泛认可的数据恢复能力。下面我们以一个例子来介绍这项能力的具体使用过程。如上图所示，在 T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录删掉，但 WHERE 条件中忘了加 "name='Ralph'" ，导致名字为 "Mary" 的记录被一同删掉了。这两个删除事件以及对应 SQL 的 ID 会被记录在全局 Binlog 中。T2 时，我们发现了误删问题，并通过 PolarDB-X 的审计功能找到了对应的 SQL 和 ID。T3 时，我们通过 SQL ID 和 SQL 闪回能力生成了恢复 SQL。SQL 闪回的原理是，在拿到 SQL ID 后，通过在全局 Binlog 中进行搜索，找到该 SQL 对应的所有变更事件（此处为两个删除事件），并逐个生成逆向恢复 SQL。T4 时，我们将恢复 SQL 执行后得到了被误删的两条数据。SQL 闪回针对 SQL 误操作场景可提供精确的数据恢复能力，可以看出，能够恢复的时间区间依赖于全局 Binlog 的保存区间。

Flashback Query（即将上线）

PolarDB-X 2.0 提供的第四项数据恢复能力叫做 Flashback Query。该能力可提供一定时间范围内行级的数据精确恢复能力。下面我们仍以 SQL 误操作场景为例。如上图所示，T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录职位更新为 "CTO"，但 WHERE 条件中忘了加 "name='Ralph'"，导致所有职位是 "Developer" 的记录都被更新成了 "CTO"。这些变更都会记录在版本为 Vn+1 的 undo log 中（undo log 是数据库中的一个基础数据结构，里面详细的记录了每行数据的变更内容，可简单类比成 GIT commit log）。T2 时，我们马上发现了误改问题并确定了误操作时间和影响的数据范围。T3 时，我们通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值。T4 时，我们根据 Flashback Query 返回的正确值对数据进行了订正。可以看出，Flashback Query 能力依赖 undo log 的保存时长。与 SQL 闪回相比，该能力可提供更快速、精确到行级的恢复能力，但 undo log 通常不如全局 Binlog 保存的时间长，所以可恢复区间上弱于 SQL 闪回。

总结

本文为阿里云原创内容，未经允许不得转载。

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

背景

全局 Binlog

备份恢复

总结

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

背景

全局 Binlog

备份恢复

一致性备份恢复

表回收站

SQL 闪回（即将上线）

Flashback Query（即将上线）

总结

关于我们

产品中心

服务与支持