——吴学强（ 燧木 ）

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

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

众所周知，数据库是基础的软件系统，而基础的软件都有自己的生态。生态的构建有两种范式，第一种范式是从  0  到  1  的构建，第二种是基于已有的生态继续演化。

分布式数据库是数据库领域的热门方向，目前已有非常多的开源项目。这些开源的项目大多都选择了第二种方式，即从已有的   MySQL  或  Oracle  生态进行自己的生态构建。

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

一、为什么要兼容 MySQL 

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

为了解决这两个问题，  2009  年，淘宝发起了“去   IOE ” 运动，其目标是用自研的分库分表中间件  TDDL   加自己维护的  MySQL  分支  Ali SQL  来替换   IOE   组合。这套架构在  2011  年双  11  大促的时候，成功接管了交易的核心库之一——商品库，从而验证了   TDDL  + Ali SQL  方案的可行性。

伴随着此套方案的普及，“去 IOE” 活动在 2013 年正式结束， TDDL  + Ali SQL  组合成为了阿里巴巴所有业务接入数据库的标准。

同时因为   TDDL  + Ali SQL  组合，即分库分表中间件+  MySQL  方式在阿里的成功验证，其他国内互联网厂商也都紧随其后，分库分表中间件的方案在国内得到了普及。

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

此后， DRD S   继续迭代。迭代过程中，也尝试解决了中间件形态几个比较大的问题。  2016  年 ，通过外部系统来尝试解决此形态下扩容的问题。 2017  年 ，基于  MySQL  X A  实现了内置的分布式事务能力。 2018  年 ，为了解决此组合的运维复杂度，进行了产品形态上一体化设计的尝试。 2019  年 ，阿里对过去  10  年的技术实践和  5  年的上云经验进行了重新思考，并对产品架构做了全新的梳理和设计。

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

回顾产品发展的历史，可以得出两个显而易见的结论： PolarDB-X  产品的出发点就是  MySQL  ，因此产品后续的迭代都是以兼容  MySQL  作为目标之一；

第二，通过近 10 年的不断探索，从中间件形态到分布式数据库形态，并没有不可跨越的技术鸿沟。

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

CDC （ C hange Data  C apture ）   即 增量数据捕捉，用来解决一些特定的业务问题。

后台系统一般可以分为上层业务系统和下层数据库系统。业务最原始的数据都存在数据库系统中。一份重要数据有很多问题需要考虑，其中之一便是如何解决数据孤岛的问题——如果想进一步挖掘这份数据的价值，如何将它与其他生态系统进行互通？

MySQL  通过  Binlog  特性来打通与下游工具 或 系统的互通。 Bin log  可以简单地理解为单一的队列，队列按照时间顺序严格记录了  MySQL  里面所有数据的变更过程。下游工具 或 系统通过消费队列来实时获取到  MySQL  里数据的变更。

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

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

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

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

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

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

针对以上问题进行非常详细的分析之后，我们最终得出的结论是：这些问题可解，但代价较高，而最终工程量在可接受范围之内。因此，我们将  CDC  这项能力的目标设计为保持与  MySQL Binlog  的体验完全一致。

实现此功能后，  MySQL  能够订阅  Binlog  的工具 或 系统，可以从  MySQL  无缝 切换到   PolarDB-X， 这项能力被称为   G lobal Binlog  (全局  Binlog )。

  全局 Binlog 能力已于 2021 年云栖大会发布。此后我们进行了持续迭代，包括稳定性相关的继续优化、性能的优化且验证了更多下游工具 或 系统。

以   Flink CDC 为例， Flink CDC  已经提供了  MySQL  C onnect or   的连接方式。因为   PolarDB-X  提供了一种与  MySQL Binlog  完全兼容的全局  Binlog  能力，所以可以将  Flink CDC  的  MySQL Connector  直接与   PolarDB-X   进行互通。

最终，从产生接入的想法，到   Flink  CDC  的  github  上出现支持   PolarDB-X  数据库作为源端，整个过程只花费不到一周的时间，充分证明了做到与  MySQL  Bin log  完全兼容之后带来的便利性。

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

去年在云栖大会开源之后到现在，我们的工作又有了一些进展。上图橙色部分是已经在  2.1  版本里实现的新功能，主要是对下游工具 或 系统的验证。

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

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

分布式数据库是用来处理特定的情况下，比如其高并发 或 扩展性遇到问题的数据库类型，这也意味着业务在上线之初，通常采用单机形态的数据库。而从原来的单机数据库往分布数据库迁移 或 切换时，如何平滑、有效地完成迁移，也是不得不考虑的问题。

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

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

经过分析之后，我们认为可行，但有一定的工程量。因此，最后结论依然是提供与  MySQL  完全兼容的复制能力，称为   R eplica  。

Replication   演示

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

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

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 吗

MySQL  是非常复杂的系统，可以将其拆解为若干特性 或 功能项，再进行逐项分析。

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

上图显示了评估后的结果。可以看出   PolarDB-X   在基础能力的兼容性上总体表现不错；高级特性也兼容了很大一部分，但是有部分特性依然不兼容。

PolarDB-X   的目标并不是完全兼容  MySQL ，而在于上 图的下半部分圆——   PolarDB-X   对  MySQL  数据库更多能力的增强 或 新增。比如并发的读/写、存储容量 、 单表的容量、弹性、高可用和容灾、 H TAP   、企业级特性等能力，相对  MySQL  都有了非常大的增强。

四、进入 Kubernetes 生态

PolarDB-X  也是云原生的数据库，而云原生以  K8S  为底座 。

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

2021年云栖大会，我们开放了最基础的  PolarDB-X  O perator  能力。而  PolarDB-X 2.1  最新版新增了基于 Prometheus+Grafana 监控的系统，增强了可观测性。

上图为监控系统页面截图，展示了系统的资源、 QPS 等丰富的监控维度。用户可以在  github  仓库上下载、安装和体验。

另外，我们对   O perator  也进行了持续迭代。此前提供的   O perator  只具备基本实例生命周期的管理能力，比如实例的创建、销毁等。后续已新增比如扩缩容、升降配、数据自动  rebalance  等能力。

在  K8S  方向上，我们还有丰富的规划。上图展示了后续计划的工作。

绿色部分是目前已经完成的，用户可以通过开源仓库进行体验：

• 生命周期管理上，提供实例的创建、删除、升降级等；
• 弹性上，支持实例的水平扩缩容、垂直扩缩容、数据 rebalance  等；
• 高可用和容灾上，支持 CN 高可用、 DN 高可用、GMS 高可用、CDC 高可用等；
• 监控上：支持支持 CN 监控、 DN 监控、GMS 监控等。

黄色部分代表当前正在研发的能力，比如备份恢复、 SQL 审计、   D ashboard  、 数据透视等。

白色部分代表未来更长期的规划，比如国产化、参数设置功能等。

以上就是我们在云原生能力上的一个规划，后续也会有节奏的开放给用户使用。