杭州做网站的公司有哪些,郴州市网站建设科技,绍兴市建设银行网站,能够做冶金工程毕业设计的网站简介#xff1a; PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力#xff0c;该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力#xff0c;包括一致性备份恢复、表回收…简介 PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。
背景
我们作为开发者都了解或熟悉后台系统后台系统可以抽象为两个组成部分一个是业务系统该部分负责处理系统的业务逻辑在现代化的架构中该部分通常设计成可水平扩展的无状态节点另一个是数据库系统该部分负责存储系统的状态这其中便包括最核心的业务数据。 站在数据库的视角数据的流入包括两个部分一个是业务系统的实时写入这是核心数据来源的主要部分另一个是从上游数据系统一次性或周期性导入的数据。因为这些核心数据在这里首次产生所以这个数据库也被称为 SSOTSingle 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 的实时数据同步这样的机制也称为 CDCChange 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 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 条件中忘了加 nameRalph 导致名字为 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 条件中忘了加 nameRalph导致所有职位是 Developer 的记录都被更新成了 CTO。这些变更都会记录在版本为 Vn1 的 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 还在持续打造更多产品能力敬请期待~
原文链接
本文为阿里云原创内容未经允许不得转载。
