简介： 2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、 Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。

好的 MySQL 兼容性能够做到什么水平
PolarDB-X 如何做生态兼容

——吴学强（燧木）

阿里云数据库高级技术专家

理解更多PolarDB-X 内容：https://developer.aliyun.com/...

家喻户晓，数据库是根底的软件系统，而根底的软件都有本人的生态。生态的构建有两种范式，第一种范式是从 0 到 1 的构建，第二种是基于已有的生态持续演变。

分布式数据库是数据库畛域的热门方向，目前已有十分多的开源我的项目。这些开源的我的项目大多都抉择了第二种形式，即从已有的 MySQL 或 Oracle 生态进行本人的生态构建。

而采纳第二种形式，就不得不思考与已有生态的兼容性。兼容性并不是0 和 1 的二分区别，用兼容度来表白会更主观。作为新的数据库，更应该关注的是它解决了什么新的问题或是带来了什么新的个性。

一、为什么要兼容 MySQL
image.png

2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、 Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。

为了解决这两个问题， 2009 年，淘宝发动了“去 IOE” 静止，其指标是用自研的分库分表中间件 TDDL 加本人保护的 MySQL 分支 AliSQL 来替换 IOE 组合。这套架构在 2011 年双 11 大促的时候，胜利接管了交易的外围库之一——商品库，从而验证了 TDDL +AliSQL 计划的可行性。

随同着此套计划的遍及，“去 IOE” 流动在 2013 年正式完结，TDDL +AliSQL 组合成为了阿里巴巴所有业务接入数据库的规范。

同时因为 TDDL +AliSQL 组合，即分库分表中间件+ MySQL 形式在阿里的胜利验证，其余国内互联网厂商也都紧随其后，分库分表中间件的计划在国内失去了遍及。

2015 年，TDDL 以中间件的状态在阿里云上公布，名为 DRDS ，即分布式关系型数据库。

image.png

尔后，DRDS 持续迭代。迭代过程中，也尝试解决了中间件状态几个比拟大的问题。 2016 年，通过内部零碎来尝试解决此状态下扩容的问题。2017 年，基于 MySQL XA 实现了内置的分布式事务能力。2018 年，为了解决此组合的运维复杂度，进行了产品状态上一体化设计的尝试。2019 年，阿里对过来 10 年的技术实际和 5 年的上云教训进行了从新思考，并对产品架构做了全新的梳理和设计。

2020 ，阿里公布了全新一代的产品架构，并将 DRDS 产品品牌降级到了 PolarDB-X。在 2021 年云栖大会，PolarDB-X 正式对外开源。

回顾产品倒退的历史，能够得出两个不言而喻的论断：PolarDB-X 产品的出发点就是 MySQL ，因而产品后续的迭代都是以兼容 MySQL 作为指标之一；

第二，通过近 10 年的一直摸索，从中间件状态到分布式数据库状态，并没有不可逾越的技术鸿沟。

二、怎么做兼容：以 CDC 为例
image.png

CDC（Change Data Capture） 即增量数据捕获，用来解决一些特定的业务问题。

后盾零碎个别能够分为下层业务零碎和上层数据库系统。业务最原始的数据都存在数据库系统中。一份重要数据有很多问题须要思考，其中之一便是如何解决数据孤岛的问题——如果想进一步开掘这份数据的价值，如何将它与其余生态系统进行互通？

image.png

MySQL 通过 Binlog 个性来买通与上游工具或零碎的互通。Binlog 能够简略地了解为繁多的队列，队列依照工夫程序严格记录了 MySQL 外面所有数据的变更过程。上游工具或零碎通过生产队列来实时获取到 MySQL 里数据的变更。

image.png

PolarDB-X 提供 CDC 能力，首先须要思考是否提供齐全兼容 MySQL Binlog 的 CDC 能力。在分布式系统中提供上述能力，会面临若干问题，而这些问题都由同一个起因引起。

分布式数据库系统中通常有多个计算节点和存储节点，如上图所示的 CN 和 DN 节点。多个节点会产生多个事件队列，会面临以下几个问题：

① 在不同队列里，事件之间的程序如何确定？

② 通常分布式事务会波及到多个队列，如何找到散布事务蕴含的所有增量事件，以保障分布式事务的完整性？

③ 分布式系统中， DDL 操作不可能在所有 CN 或 DN 节点中同时失效，也就意味着在若干个增量的事件队列里，可能会存在不同版本的 schema ，如何解决？

④ 分布式系统很大的特点就是弹性，主动扩缩容所引发的事件队列的增减问题如何解决？

针对以上问题进行十分具体的剖析之后，咱们最终得出的论断是：这些问题可解，但代价较高，而最终工程量在可承受范畴之内。因而，咱们将 CDC 这项能力的指标设计为放弃与 MySQL Binlog 的体验完全一致。

实现此性能后， MySQL 可能订阅 Binlog 的工具或零碎，能够从 MySQL 无缝切换到 PolarDB-X，这项能力被称为 Global Binlog (全局 Binlog)。

全局 Binlog 能力已于 2021 年云栖大会公布。尔后咱们进行了继续迭代，包含稳定性相干的持续优化、性能的优化且验证了更多上游工具或零碎。

以 Flink CDC 为例，Flink CDC 曾经提供了 MySQL Connector 的连贯形式。因为 PolarDB-X 提供了一种与 MySQL Binlog 齐全兼容的全局 Binlog 能力，所以能够将 Flink CDC 的 MySQL Connector 间接与 PolarDB-X 进行互通。

最终，从产生接入的想法，到 Flink CDC 的 github 上呈现反对 PolarDB-X 数据库作为源端，整个过程只破费不到一周的工夫，充分证明了做到与 MySQL Binlog 齐全兼容之后带来的便利性。

Global Binlog 与 Flink CDC 连贯演示——双十一交易大屏模仿

image.png

去年在云栖大会开源之后到当初，咱们的工作又有了一些停顿。上图橙色局部是曾经在 2.1 版本里实现的新性能，次要是对上游工具或零碎的验证。

下一步，咱们会验证更多工具，尝试反对 GTID，以及实现 Binlog 多流的能力。

image.png

前文解决了数据库上游的问题，上游的问题也不可漠视。

分布式数据库是用来解决特定的状况下，比方其高并发或扩展性遇到问题的数据库类型，这也意味着业务在上线之初，通常采纳单机状态的数据库。而从原来的单机数据库往散布数据库迁徙或切换时，如何平滑、无效地实现迁徙，也是不得不思考的问题。

MySQL 实现平滑迁徙，次要通过其原生的主备复制能力，以放弃主节点和备节点之间的实时增量同步，即 replication 能力。它所用的 SQL 指令为change master 。

而如果 PolarDB-X 提供同样的能力，是否可行？

通过剖析之后，咱们认为可行，但有肯定的工程量。因而，最初论断仍然是提供与 MySQL 齐全兼容的复制能力，称为 Replica 。

Replication 演示

本次演示以 MySQL 为主,PolarDB-X 为备，搭建一条主备同步链路，以展现 PolarDB-X 的 Replica 能力。

以上，这两个例子就是 PolarDB-X 开源后在 MySQL 兼容方向上新退出的一些能力。

image.png

PolarDB-X Replication 领有如下个性：

① 产品体验上，可能反对 MySQL 原生的 change master 指令，即能够在 PolarDB-X 里间接输出 change master 指令来搭建 MySQL 到 PolarDB-X 主备同步链路。

源端也反对以 PolarDB-X 作为主库，意味着可搭建 PolarDB-X 到 PolarDB-X 主备同步的链路。反对 DDL 同步，以及反对事务复制、行级复制，用户能够在性能和事务的完证性两个方面进行抉择。

② 性能方面，单条复制链路目前反对 1.5 万 RPS ，没有大事务等非凡场景下，反对 1 秒以内的同步提早。

③ 目前已验证的上游零碎包含 MySQL/ MariaDB 和 PolarDB-X，后续会尝试验证其余零碎。

下一步，咱们的工作次要将围绕以下三方面发展：接入多流能力，使得PolarDB-X 和 PolarDB-X 之间的同步链路有更强的性能加强；适配 global Binlog 的 GTID 能力，使得同步链路在事务复制时能够反对并行复制能力；适配更多源端。

三、齐全兼容 MySQL 吗
image.png

MySQL 是非常复杂的零碎，能够将其拆解为若干个性或性能项，再进行逐项剖析。

首先，个性的重要性如何？上图中以扇形对应的角度来示意；其次，PolarDB-X 在这项能力上对 MySQL 的兼容水平有多少？上图中以扇形半径来示意。如果 PolarDB-X 做到了与 MySQL 个性齐全兼容，扇形的半径应该与里面圆的半径相等；如果只做到局部兼容，则扇形离圆的边缘有一部分空白；如果目前 PolarDB-X 还不反对此个性，则对应的扇形为空白。

上图显示了评估后的后果。能够看出 PolarDB-X 在根底能力的兼容性上总体体现不错；高级个性也兼容了很大一部分，然而有局部个性仍然不兼容。

PolarDB-X 的指标并不是齐全兼容 MySQL，而在于上图的下半局部圆—— PolarDB-X 对 MySQL 数据库更多能力的加强或新增。比方并发的读/写、存储容量、单表的容量、弹性、高可用和容灾、HTAP 、企业级个性等能力，绝对 MySQL 都有了十分大的加强。

四、进入 Kubernetes 生态
PolarDB-X 也是云原生的数据库，而云原生以 K8S 为底座。

因而， PolarDB-X 在 K8S 上也做了十分多工作，比方基于 K8S 进行了资源的编排、构建了 CICD 流程、进行混沌测试等。

2021年云栖大会，咱们凋谢了最根底的 PolarDB-X Operator 能力。而 PolarDB-X 2.1 最新版新增了基于 Prometheus+Grafana 监控的零碎，加强了可观测性。

image.png

上图为监控零碎页面截图，展现了零碎的资源、QPS等丰盛的监控维度。用户能够在 github 仓库上下载、装置和体验。

另外，咱们对 Operator 也进行了继续迭代。此前提供的 Operator 只具备根本实例生命周期的治理能力，比方实例的创立、销毁等。后续已新增比方扩缩容、升降配、数据主动 rebalance 等能力。

image.png

在 K8S 方向上，咱们还有丰盛的布局。上图展现了后续打算的工作。

绿色局部是目前曾经实现的，用户能够通过开源仓库进行体验：

生命周期治理上，提供实例的创立、删除、升降级等；
弹性上，反对实例的程度扩缩容、垂直扩缩容、数据rebalance 等；
高可用和容灾上，反对 CN 高可用、 DN 高可用、GMS 高可用、CDC 高可用等；
监控上：反对反对 CN 监控、 DN 监控、GMS 监控等。

黄色局部代表以后正在研发的能力，比方备份复原、SQL审计、 Dashboard 、数据透视等。

红色局部代表将来更长期的布局，比方国产化、参数设置性能等。

以上就是咱们在云原生能力上的一个布局，后续也会有节奏的凋谢给用户应用。

原文链接：http://click.aliyun.com/m/100...

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