开源 PolarDB-X 正式发布 2.4.1 版本，重点增强企业级运维能力

新版本发布

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

开源脉络

• 2021年10月，在云栖大会上，阿里云正式对外开源了云原生分布式数据库PolarDB-X，采用全内核开源的模式，开源内容包含计算引擎、存储引擎、日志引擎、Kube等。
• 2022年1月，PolarDB-X 正式发布 2.0.0 版本，继 2021 年 10 月 20 号云栖大会正式开源后的第一次版本更新，更新内容包括新增集群扩缩容、以及binlog生态兼容等特性，兼容 maxwell 和 debezium 增量日志订阅，以及新增其他众多新特性和修复若干问题。
• 2022年3月，PolarDB-X 正式发布 2.1.0 版本，包含了四大核心特性，全面提升 PolarDB-X 稳定性和生态兼容性，其中包含基于Paxos的三副本共识协议。
• 2022年5月，PolarDB-X正式发布2.1.1 版本，重点推出冷热数据新特性，可以支持业务表的数据按照数据特性分别存储在不同的存储介质上，比如将冷数据存储到Aliyun OSS对象存储上。
• 2022年10月，PolarDB-X 正式发布2.2.0版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产ARM适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。
• 2023年3月，PolarDB-X 正式发布2.2.1版本，在分布式数据库金融标准能力基础上，重点加强了生产级关键能力，全面提升PolarDB-X面向数据库生产环境的易用性和安全性，比如：提供数据快速导入、性能测试验证、生产部署建议等。
• 2023年10月份，PolarDB-X 正式发布 2.3.0版本，重点推出PolarDB-X标准版（集中式形态），将PolarDB-X分布式中的DN节点提供单独服务，支持paxos协议的多副本模式、lizard分布式事务引擎，同时可以100%兼容MySQL，对应PolarDB-X公有云的标准版。
• 2024年4月份，PolarDB-X 正式发布2.4.0版本，重点推出列存节点Columnar，可以提供持久化列存索引（Clustered Columnar Index，CCI）。PolarDB-X的行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（默认覆盖行存所有列），一张表可以同时具备行存和列存的数据，结合计算节点CN的向量化计算，可以满足分布式下的查询加速的诉求，实现HTAP一体化的体验和效果。

开源PolarDB-X V2.4.1 重要特性

云备份集转储恢复

PolarDB-X开源版本全面继承了商业版本的生产级别的稳定性验证，同时开源和商业版在数据文件的物理格式上是互通的。因此，基于开源版本，可以作为商业版本的backup，参考文档：基于商业备份集恢复

PolarDB-X发布Operator v1.7.0 版本，开始支持从阿里云PolarDB-X实例商业备份集中恢复出 PolarDB-X 集群。基于商业备份集恢复主要为了满足如下需求：

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

总体步骤分为两部分： 导入备份集 和 发起恢复任务。比如：运行的导入备份集工具，需要三个配置文件放在工具的配置目录下：

• 备份集元数据，可以通过商业备份集的OpenAPI DescribeOpenBackupSet，按要求输入接口参数 RegionId、DBInstanceName、RestoreTime，发起调用后可以获得完整的配置文本，比如包含备份集的物理文件、增量文件各自的下载地址
• 备份存储地址，目前可以支持SFTP/MinIO/S3/Aliyun OSS 等常见的备份存储介质，参考类似的备份元数据配置

运行备份转储的命令：

实际demo例子：

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

对应的测试结果如下：

• 随着背景流量并发量的攀升，使用 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并行计算调度到多个节点，实现分布式的并行扩缩容

同时，我们设计了分布式大规模的扩缩容实验，实例规格：35个CN（8C32G） + 70个DN（8C32G），TPCC 50万仓（总计约45TB）

• 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显著高出预期的现象。

数据TTL

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

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

• 可以定时清理冷数据。
• 更低的冷数据存储成本。
• 归档后仍然可以供后台业务进行分析统计。

PolarDB-X v2.4.1提供了全新的数据TTL能力，支持行级、分区级的数据过期清理、归档等，可以结合列存索引适配oss对象存储，可以提供更灵活的数据TTL。

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

• 已有的数据表，配置TTL策略，比如：指定TTL的时间列及其数据的存活时间
• 定义TTL的清理任务，比如：主动清理或者定时自动清理，及关注清理任务的状态
• 定义数据归档，比如：TTL默认可以只做数据清理，但也可以额外配置被清理的数据进行转储归档

配置TTL策略，操作例子：

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

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

• 手动执行

• 定时自动执行

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

注意：

• ENGINE的值必须为’Columnar’，不允许其他值，代表使用列存引擎
• 如果对原主库执行了DDL变更，比如加列，数据归档表也会自动执行加列，可以确保后续的归档任务不中断

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

• TTL原理概述
• TTL表的定义与创建
• TTL表的过期数据清理
• 归档表语法说明

PolarDB 架构简介

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支持多种形态的快速部署能力，可以结合各自需求进行选择。（项目地址）

PolarDB-X Operator是基于K8S Operator架构，正式发布1.7.0版本，提供了PolarDB-X 数据库的部署和运维能力，生产环境优先推荐，可参考 PolarDB-X Operator运维指南。

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