开源新发布｜PolarDB-X v2.4.1 重点增强企业级运维能力

近日，开源PolarDB-X 正式发布2.4.1版本，重点增强企业级运维能力，面向DBA的数据库运维和数据管理需要，新增云备份转储恢复、在线DDL、数据库扩缩容、数据TTL等特性，全面提升 PolarDB-X 在多云部署、以及分布式大规模下的可运维性。

• 2021年10月在云栖大会上，阿里云正式对外开源了云原生分布式数据库PolarDB-X，采用全内核开源的模式，开源内容包含计算引擎、存储引擎、日志引擎、Kube等。
• 2022年1月，正式发布 2.0.0 版本，新增集群扩缩容、以及binlog生态兼容等特性，兼容 maxwell 和 debezium 增量日志订阅，以及新增其他众多新特性和修复若干问题。 
• 2022年3月，正式发布 2.1.0 版本，全面提升 PolarDB-X 稳定性和生态兼容性，其中包含基于Paxos的三副本共识协议。
• 2022年5月，正式发布2.1.1 版本，重点推出冷热数据新特性，可以支持业务表的数据按照数据特性分别存储在不同的存储介质上。
• 2022年10月，正式发布2.2.0版本，重点推出符合分布式数据库金融标准下的企业级和国产ARM适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。
• 2023年3月， 正式发布2.2.1版本，在金融标准能力基础上，重点加强了生产级关键能力，全面提升面向数据库生产环境的易用性和安全性。
• 2023年10月份，正式发布 2.3.0版本，重点推出PolarDB-X标准版（集中式形态），将PolarDB-X分布式中的DN节点提供单独服务，支持paxos协议的多副本模式、lizard分布式事务引擎，同时可以100%兼容MySQL。

• 2024年4月份，正式发布2.4.0版本，重点推出列存节点Columnar，可以提供持久化列存索引（Clustered Columnar Index，CCI），一张表可以同时具备行存和列存的数据，结合计算节点CN的向量化计算，可以满足分布式下的查询加速的诉求，实现HTAP一体化的体验和效果。

从2021年10月首次开源发布，PolarDB-X一直坚持采用全内核开源的模式，开源版本全面继承了商业版本的生产级别的稳定性验证，同时开源和商业版在数据文件的物理格式上是互通的。因此，基于开源版本，可以作为商业版本的backup，参考文档：基于商业备份集恢复[1]。

PolarDB-X发布Operator v1.7.0 版本，开始支持从阿里云PolarDB-X实例商业备份集中恢复出 PolarDB-X 集群。

基于商业备份集恢复主要为了满足如下需求：

• 多云冗灾。生产实例在阿里云上，但是希望自建该实例的从实例。

• 线下测试使用。虽然已经在阿里云公有云上开通PolarDB-X实例，但是有些客户仍然有一部分线下的自建机器可用于日常测试使用。

总体步骤分为两部分：导入备份集 和 发起恢复任务。

比如：运行的导入备份集工具，需要三个配置文件放在工具的配置目录下：

• 备份集元数据，可以通过商业备份集的OpenAPI DescribeOpenBackupSet[2]，按要求输入接口参数 RegionId、DBInstanceName、RestoreTime，发起调用后可以获得完整的配置文本，比如包含备份集的物理文件、增量文件各自的下载地址。

• 备份存储地址，目前可以支持SFTP/MinIO/S3/Aliyun OSS 等常见的备份存储介质，参考类似的备份元数据配置[3]。

运行备份转储的命令：

docker run  -d -v /root/config:/config --network=host  \--name=polardbx-backupset-importer \--entrypoint="/backupset-importer" polardbx-opensource-registry.cn-beijing.cr.aliyuncs.com/polardbx/backupset-importer:v1.7.0 \-conf=/config

另外，可以通过PolarDB-X Operator，基于k8s实现通过导入的备份集直接创建实例，参考基于导入的备份集做恢复[4]。

通过备份集的转储、以及备份集的恢复能力，业务上可以在线下IDC自建、以及多云ECS环境，快速创建PolarDB-X的备份容灾环境。

在数据库运维过程中，对字段类型做变更是令人非常头痛的一件事，在传统MySQL中，一般需要借助外部的Online DDL工具（比如pt-osc、gh-ost）来实现无锁变更。

目前，有许多开源的无锁变更工具为用户提供了平滑进行列类型变更的解决方案，有效规避了锁表问题。其中较为知名的工具包括 GitHub 开源项目 gh-ost 以及 Percona Toolkit 中的 pt-online-schema-change（简称 pt-osc）工具，它们的工作流程类似，都包含了以下几个步骤：

1. 创建一张与原表结构一样的临时表
2. 将具体变更操作应用到临时表上
3. 将存量数据拷贝到临时表中
4. 同步增量修改数据到临时表中

5. 交换原表和临时表，完成变更

在增量数据同步方面，gh-ost 与 pt-osc 实现的方式有所不同，gh-ost 采用 binlog 订阅进行回放，而 pt-osc 采用的是利用触发器进行增量双写，但两种增量方案都并不完美。

比如：gh-ost增量回放和存量数据拷贝共用一个线程，速度慢，但侵入性小，在业务流量较大时会出现binlog追不上，导致永远无法完成。

比如：pt-osc引入触发器会增加死锁风险，一旦遇到DDL执行中断退出，存在触发器残留，触发器无法暂停等问题。

PolarDB-X v2.4.1版本，全面提供了内核原生的无锁变更能力，可以更好的支持类似字段类型变更的场景，重点在增量数据同步、智能限速、多版本元数据切换上，提供了更多不一样的设计。

PolarDB-X 新增DDL算法类型，OMC算法（全称为：Online Modify Column，在线变更列类型）。

语法格式：

ALTER TABLE tbl_name    alter_option [, alter_option] ...    ALGORITHM = OMC

实际demo例子：

# 创建测试表CREATE TABLE t1(a int primary key, b tinyint, c varchar(10)) partition by key(a);
# 修改t1表中b列和c列的列类型ALTER TABLE t1 MODIFY COLUMN b int, MODIFY COLUMN c varchar(30), ALGORITHM=OMC;
# 修改t1表中b列的名称和类型，并在该列后面增加一个bigint类型的e列ALTER TABLE t1 CHANGE COLUMN b d int, ADD COLUMN e bigint AFTER d, ALGORITHM=OMC;

我们也为PolarDB-X OMC算法，与gh-ost/pt-osc做了完整的性能对比：
比如：以sysbench oltp_read_write压测为背景流量，执行在线列变更。
ALTER TABLE MODIFY COLUMN `sbtest1` MODIFY COLUMN k bigint;

• 随着背景流量并发量的攀升，使用 gh-ost 工具的变更耗时显著增长，且当并发量达到 50 时，其增量回放已经没办法追上流量的修改，无法顺利完成变更；

• 即便在面临 50 并发的背景流量，pt-osc 工具依旧能够保证变更任务成功完成，但是变更时间会有所增加；

• PolarDB-X 对分区表执行无锁列类型变更操作时，展现出了较高的稳定性与效率，其变更时长几乎不受背景流量波动的影响，并且所耗费的时间仅为 pt-osc 工具所需时间的三分之一；

• PolarDB-X 对单表执行无锁列类型变更操作时，尽管其变更时长同样会随背景流量并发量的提升而有所增加，但相比与 pt-osc 与 gh-ost，依然展现出的较高的变更效率，耗时大幅缩减；

在变更操作期间，由于涉及一些资源的竞争，sysbench oltp_read_write 工作负载会受到一定的影响，导致 TPS 会有所下滑，具体下降比率详情请参见下表：

在单表场景下，尽管 PolarDB-X 的无锁列类型变更相较于 gh-ost 和 pt-osc 工具表现出更快的执行速度，但它对背景流量的暂时性影响要略显显著，这也反映了单个 DN 高并发操作下的一定局限性。

而在分区表场景下，PolarDB-X 的无锁列类型变更展现了极佳的性能：不仅变更过程迅速无比，而且其对背景流量的影响控制得与 gh-ost 工具相当，实现了速度与稳定性兼顾的优越成效。

分布式数据库，其中一个重要能力就是水平线性扩展，通过增加分布式的节点来提升整体的性能，其中就会涉及到数据库的扩容和缩容。

分布式数据库扩缩容的本质，就是数据分片的腾挪，整个过程涉及了全量+增量的组合。PolarDB-X v2.4.1版本，针对扩缩容能力做了全新的升级，数据腾挪的全量迁移方式，从原先默认的逻辑数据迁移演进到了基于物理文件迁移。

比如：逻辑数据的全量迁移，是通过TableScan的算子读取需要腾挪分片的所有行记录，然后通过新的Insert算子写入到指定的新节点分片中，这种方式的弊端比较明显：

• 需要读取Leader节点，保证数据迁移的一致性，虽然仅是TableScan的读操作，也会对原节点有一定的CPU开销；
• 写入目标节点，采用了逻辑Insert的方式，虽然可以走Batch批量处理优化提交，但本质上还是需要逻辑迭代执行，CPU开销比较大，执行的效率不够快；

• 逻辑迁移，在分布式下的整体并行度不够大，没有充分发挥分布式多节点的效果，比如50个节点，一次性扩容25个节点，容易出现扩容耗时过长的问题。

PolarDB-X v2.4.1版本，引入新的物理文件的全量迁移，可以很大程度上改善以前逻辑迁移方案的弊端：

• 数据读取，首先可以访问Follower节点，不对在线业务有影响，同时通过直接访问物理文件，不做逻辑解析，直接实现二进制的读取；
• 写入目标节点，同样采用物理写入，将数据读取的二进制流直接写入目标节点，实现类似物理文件二进制拷贝的效果，CPU仅需要处理网络转发和IO落盘的操作，并不需要处理逻辑迭代；

• 更大的并行度规划，引入了更确定的物理复制任务，可以将分布式的扩缩容拆分为多个物理复制的拷贝子任务的组合，通过MPP并行计算调度到多个节点，实现分布式的并行扩缩容。

我们针对不同场景，测试了物理复制迁移的效果，比如：大blob字段、宽表、sysbench、tpcc等多种场景，均有5~10倍左右的速度提升。

# 开启物理复制迁移set global physical_backfill_enable=true;
# 关闭物理复制迁移set global physical_backfill_enable=false;

• DN缩容，70节点缩容为40节点，涉及总数据量19.53TB，总耗时80分5秒，总的迁移速度4096MB/s，平均单节点135.6MB/s 。

• DN扩容，40节点扩容为70节点，涉及总数据量17.51TB，总耗时68分6秒，总的迁移速度4439.4MB/s，平均单节点149.8MB/s。

整个扩缩容期间，核心的CN/DN组件的资源水位线均正常，无CPU/内存/IOPS显著高出预期的现象。

在实际生产中，有些业务只希望保留最近一段时间的数据（热数据），并对于使用频率很低且不断积累的过期数据（冷数据）采用存储成本更低的方式保存，同时又可以利用这些冷数据进行分析统计业务。

综上所述，业务对处理冷数据，主要有以下需求：

• 可以定时清理冷数据。
• 更低的冷数据存储成本。

• 归档后仍然可以供后台业务进行分析统计。

PolarDB-X v2.4.1提供了全新的数据TTL能力，结合列存索引适配oss对象存储，可以提供更灵活的数据TTL。

整个TTL的使用可以分为三部分：

• 已有的数据表，配置TTL策略，比如：指定TTL的时间列及其数据的存活时间；
• 定义TTL的清理任务，比如：主动清理或者定时自动清理，以及关注清理任务的状态；

• 定义数据归档，比如：TTL默认可以只做数据清理，但也可以额外配置被清理的数据进行转储归档。

配置TTL策略，操作例子：

# 针对已有的数据表，动态配置TTLALTER TABLE `orders_test`MODIFY TTLSETTTL_EXPR = `date_field` EXPIRE AFTER 2 MONTH TIMEZONE '+08:00';

指定 orders_test表的date_field列为TTL定义的时间列，只保存最近两个月的数据（数据过期时间为2个月），定时清理任务执行的时区为东八区。

定义TTL的清理任务，操作例子：

• 手动执行

# 手动执行ALTER TABLE `orders_test` CLEANUP EXPIRED DATA;

• 定时自动执行

# 定时执行，指定为每天的凌晨2点运行数据清理ALTER TABLE `orders_test` MODIFY TTL \SET TTL_JOB = CRON '0 0 2 */1 * ? *' TIMEZONE '+08:00';

定义数据归档，操作例子：

# 创建数据归档的数据空间CREATE TABLE `orders_test_archive`LIKE `orders_test`ENGINE = 'Columnar' ARCHIVE_MODE = 'TTL';

注意：

• ENGINE的值必须为'Columnar'，不允许其他值，代表使用列存引擎。

• 如果对原主库执行了DDL变更，比如加列，数据归档表也会自动执行加列，可以确保后续的归档任务不中断。

更多使用和原理，请参考文档：

• TTL原理概述[5]
• TTL表的定义与创建[6]
• TTL表的过期数据清理[7]

• 归档表语法说明[8]

PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由5个核心组件组成，提供金融级高可用、透明分布式、HTAP一体化、集中式和分布式一体化体验和功能特性。

• 计算节点（CN, Compute Node）

计算节点是系统的入口，采用无状态设计，包括 SQL 解析器、优化器、执行器等模块。负责数据分布式路由、计算及动态调度，负责分布式事务 2PC 协调、全局二级索引维护等，同时提供 SQL 限流、三权分立等企业级特性。 

• 存储节点（DN, Data Node）

存储节点负责数据的持久化，基于多数派 Paxos 协议提供数据高可靠、强一致保障，同时通过 MVCC 维护分布式事务可见性。 

• 元数据服务（GMS, Global Meta Service）

元数据服务负责维护全局强一致的 Table/Schema, Statistics 等系统 Meta 信息，维护账号、权限等安全信息，同时提供全局授时服务（即 TSO）。 

• 日志节点（CDC, Change Data Capture）

日志节点提供完全兼容 MySQL Binlog 格式和协议的增量订阅能力，提供兼容 MySQL Replication 协议的主从复制能力。 

• 列存节点 (Columnar)

列存节点提供持久化列存索引，实时消费分布式事务的binlog日志，基于对象存储介质构建列存索引，能满足实时更新的需求、以及结合计算节点可提供列存的快照一致性查询能力。

PolarDB-X支持多种形态的快速部署能力，可以结合各自需求进行选择。

（项目地址：https://github.com/polardb/polardbx-sql）

PolarDB-X Operator 1.7.0新版本，重点适配了多云的部署能力，比如支持阿里云PolarDB-X商业备份集恢复、备份适配aws S3协议，融合了商业、开源与多云之间的关系，详见：ChangeLog[10]。

PolarDB-X v2.4.1版本，重点增强企业级运维能力，面向DBA的数据库运维和数据管理，提供了更多有价值的能力，可以查看更多详细的 Changelog[11]。

另外重要时刻：2024-09-30，中国信息安全测评中心发布安全可靠测评结果公告（2024年第2号），PolarDB-X【阿里云PolarDB数据库管理软件（分布式版）V2.0（简称：PolarDB 分布式版）】，首批通过分布式的安全可靠测评[12]。

PolarDB-X 采用 Shared-nothing 与存储分离计算架构，支持集中式和分布式一体化形态，提供：标准版（集中式）和企业版（分布式），同时具备金融级数据高可用、分布式水平扩展、混合负载、低成本存储和极致弹性等能力，坚定以兼容MySQL开源生态构建分布式能力，为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务，更多详情可以访问 安全可靠的国产自研分布式数据库PolarDB[13]。

参考链接：

[1]https://doc.polardbx.com/zh/operator/ops/backup-restore/restore-business-backupset.html

[2]https://next.api.aliyun.com/api/polardbx/2020-02-02/DescribeOpenBackupSet

[3]https://doc.polardbx.com/zh/operator/ops/backup-restore/1-backup-storage-configure.html

[4]https://doc.polardbx.com/zh/operator/ops/backup-restore/restore-business-backupset.html#%E5%9F%BA%E4%BA%8E%E5%AF%BC%E5%85%A5%E7%9A%84%E5%A4%87%E4%BB%BD%E9%9B%86%E5%81%9A%E6%81%A2%E5%A4%8D

[5]https://help.aliyun.com/zh/polardb/polardb-for-xscale/principle-overview