关于sql:PolarDBX-20-全局-Binlog-和备份恢复能力解读

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

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

背景

咱们作为开发者都理解或相熟后盾零碎，后盾零碎能够形象为两个组成部分：一个是业务零碎，该局部负责解决零碎的业务逻辑，在现代化的架构中，该局部通常设计成可程度扩大的无状态节点；另一个是数据库系统，该局部负责存储系统的状态，这其中便包含最外围的业务数据。
站在数据库的视角，数据的流入包含两个局部，一个是业务零碎的实时写入，这是外围数据起源的次要局部；另一个是从上游数据系统一次性或周期性导入的数据。因为这些外围数据在这里首次产生，所以这个数据库也被称为 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 能力绝对于单机有更高的复杂度。一个分布式数据库通常蕴含多个节点，这些节点会产生多个增量日志队列，那么上游如果要生产多个队列会波及几个问题。

1. 因为是多个队列，那么上游生产时多个队列内变更事件的程序如何确定？
2. 分布式事务的变更可能波及多个队列，如果要保障生产时事务的完整性，那么如何发现并合并同一个事务的变更事件？
3. 零碎产生了扩缩容（也就是队列的增减）上游如何正确处理？
4. 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 的生成过程可分为三个阶段：

1. CDC 组件从每个 DN 拉取其增量日志，也就是物理 Binlog，之后进行单队列排序、外部事件过滤、DDL 相干的整形等操作，以便为下一阶段提供一个“洁净”的增量事件队列，同时若零碎产生了扩缩容，CDC 组件会在该阶段主动感知并做相干解决；
2. CDC 组件将所有“洁净”的增量事件队列进行合并，期间会对属于同一分布式事务的事件进行合并，并会依据事务工夫戳进行全局排序，这样便失去一个全局有序的保障事务完整性的事件队列，同时该阶段还会解决好 DDL 在队列中的地位。之后 CDC 组件会将该队列生成兼容 MySQL Binlog 格局的文件，即全局 Binlog 文件；
3. CN 组件在收到上游订阅全局 Binlog 申请后，会依照 MySQL DUMP 协定将全局 Binlog 发送给上游生产。

通过下面三个阶段，PolarDB-X 2.0 实现了齐全兼容 MySQL Binlog 的全局 Binlog 能力。如果对具体的实现原理感兴趣，欢送关注咱们的知乎专栏《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 还在继续打造更多产品能力，敬请期待~

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。