好的 MySQL 兼容性可以做到什么程度？ PolarDB-X 如何做生态兼容

Posted 2022-06-18 阿里云云栖号

好的 MySQL 兼容性可以做到什么程度

PolarDB-X 如何做生态兼容

——吴学强（燧木）阿里云数据库高级技术专家

了解更多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 分支 AliSQL 来替换 IOE 组合。这套架构在 2011 年双 11 大促的时候，成功接管了交易的核心库之一——商品库，从而验证了 TDDL +AliSQL 方案的可行性。

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

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

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

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

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

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

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

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

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

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

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

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 连接演示——双十一交易大屏模拟

https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/d/ud/363370843639.mp4

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

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

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

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

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

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

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

Replication 演示：
https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/d/ud/362371229925.mp4

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

以上，这两个例子就是 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 数据库更多能力的增强或新增。比如并发的读/写、存储容量、单表的容量、弹性、高可用和容灾、HTAP 、企业级特性等能力，相对 MySQL 都有了非常大的增强。

四、进入 Kubernetes 生态

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

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

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

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

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

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

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

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

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

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

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

原文链接

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