正文

【版本更新】PolarDB-X V2.4 列存引擎开源正式发布

admin
admin V管理员 /0 评论 /167 阅读
0515
此篇文章发布距今已超过193天，您需要注意文章的内容或图片是否可用！

开源中国社区团队直播首秀，以分享为名讲述开源中国社区背后的故事”

PolarDB 分布式版 (PolarDB for Xscale，以下简称“PolarDB-X”) 是阿里云自主设计研发的高性能云原生分布式数据库产品，为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务。

架构简介

PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由5个核心组件组成。

PolarDB分布式 架构图

  • 计算节点（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日志，基于对象存储介质构建列存索引，能满足实时更新的需求、以及结合计算节点可提供列存的快照一致性查询能力

开源地址：https://github.com/polardb/polardbx-sql

版本说明

梳理下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一体化的体验和效果。

01 列存索引

随着云原生技术的不断普及，以Snowflake为代表的新一代云原生数仓、以及数据库HTAP架构不断创新，可见在未来一段时间后行列混存HTAP会成为一个数据库的标配能力，需要在当前数据库列存设计中面相未来的低成本、易用性、高性能上有更多的思考

PolarDB-X在V2.4版本正式发布列存引擎，提供列存索引的形态（Clustered Columnar Index，CCI），行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（覆盖行存所有列），一张表可以同时具备行存和列存的数据。

PolarDB-X 列存索引

相关语法

索引创建的语法：

列存索引创建的DDL语法

  • CLUSTERED COLUMNAR：关键字，用于指定添加的索引类型为CCI。
  • 索引名：索引表的名称，用于在SQL语句中指定该索引。
  • 排序键：索引的排序键，即数据在索引文件中按照该列有序存储。
  • 索引分区子句：索引的分区算法，与CREATE TABLE中分区子句的语法一致。

实际例子：

 # 先创建表 CREATE TABLE t_order (   `id` bigint(11) NOT NULL AUTO_INCREMENT,   `order_id` varchar(20) DEFAULT NULL,   `buyer_id` varchar(20) DEFAULT NULL,   `seller_id` varchar(20) DEFAULT NULL,   `order_snapshot` longtext DEFAULT NULL,   `order_detail` longtext DEFAULT NULL,   PRIMARY KEY (`id`),   KEY `l_i_order` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(`order_id`) partitions 16; # 再创建列存索引 CREATE CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16;
  • 主表："t_order" 是分区表，分区的拆分方式为按照 "order_id" 列进行哈希。
  • 列存索引："cc_i_seller" 按照 "seller_id" 列进行排序，按照 "order_id" 列进行哈希。
  • 索引定义子句：CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash(order_id) partitions 16。

原理简介

列存索引的数据结构：

列存数据结构

列存索引是由列存引擎（Columnar）节点来构造的，数据结构基于Delta+Main(类LSM结构)二层模型，实时更新采用了标记删除的技术(update转化为delete标记 + insert)，确保了行存和列存之间实现低延时的数据同步，可以保证秒级的实时更新。数据实时写入到MemTable，在一个group commit的周期内，会将数据存储到一个本地csv文件，并追加到OSS上对应csv文件的尾部，这个文件称为delta文件。OSS对象存储上的.csv文件不会长期存在，而是由compaction线程不定期地转换成.orc文件。

列存索引的数据流转：

数据流转

列存索引，构建流程：

  1. 数据通过CN写入到DN（正常的行存数据写入）
  2. CDC事务日志，提供实时提取逻辑binlog（获取事务日志）
  3. Columnar实时消费snapshot数据和cdc 增量binlog流，构建列存索引（异步实现行转列）

列存索引，查询流程：

  1. CN节点，基于一套SQL引擎提供了统一入口
  2. CN 从GMS获取当前最新的TSO(事务时间戳)
  3. CN基于TSO获取当前列存索引的快照信息（GMS中存储了列存索引的元数据）
  4. 从DN或者OSS扫描数据，拉到CN做计算（行列混合计算）

tips. 更多列存引擎相关的技术原理文章，后续会逐步发布，欢迎大家持续关注。

性能体验

测试集：TPC-H 100GB 硬件环境：

机器用途 机型 规格
压力机 ecs.hfg7.6xlarge 24c96g
数据库机器 ecs.i4.8xlarge * 3 32c256g + 7TB的存储，单价：7452元/月

按照正常导入TPC-H 100GB数据后，执行SQL创建列存索引：

 create clustered columnar index `nation_col_index` on nation(`n_nationkey`) partition by hash(`n_nationkey`) partitions 1; create clustered columnar index `region_col_index` on region(`r_regionkey`) partition by hash(`r_regionkey`) partitions 1; create clustered columnar index `customer_col_index` on customer(`c_custkey`) partition by hash(`c_custkey`) partitions 96; create clustered columnar index `part_col_index` on part(`p_size`) partition by hash(`p_partkey`) partitions 96; create clustered columnar index `partsupp_col_index` on partsupp(`ps_partkey`) partition by hash(`ps_partkey`) partitions 96; create clustered columnar index `supplier_col_index` on supplier(`s_suppkey`) partition by hash(`s_suppkey`) partitions 96; create clustered columnar index `orders_col_index` on orders(`o_orderdate`,`o_orderkey`) partition by hash(`o_orderkey`) partitions 96; create clustered columnar index `lineitem_col_index` on lineitem(`l_shipdate`,`l_orderkey`) partition by hash(`l_orderkey`) partitions 96;

场景1：单表聚合场景( count 、 groupby)

场景 列存 （单位秒） 行存 （单位秒） 性能提升
tpch-Q1 2.98 105.95 35.5 倍
select count(*) from lineitem 0.52 19.85 38.1 倍

tpch-Q1的行存和列存的效果对比图：

tpch-Q1

select count的行存和列存的效果对比图：

count查询

场景2：TPC-H 22条query

基于列存索引的性能白皮书，开源版本可以参考：TPC-H测试报告

TPC-H 100GB，22条query总计25.76秒

详细数据如下：

查询语句 耗时（单位秒）
Q1 2.59
Q2 0.80
Q3 0.82
Q4 0.52
Q5 1.40
Q6 0.13
Q7 1.33
Q8 1.15
Q9 3.39
Q10 1.71
Q11 0.53
Q12 0.38
Q13 1.81
Q14 0.41
Q15 0.46
Q16 0.59
Q17 0.32
Q18 3.10
Q19 0.88
Q20 0.81
Q21 1.84
Q22 0.79
Total 25.76 秒

02 兼容MySQL 8.0.32

PolarDB-X V2.3版本，推出了集中式和分布式一体化架构（简称集分一体），在2023年10月公共云和开源同时新增集中式形态，将分布式中的DN多副本单独提供服务，支持Paxos多副本、lizard分布式事务引擎，可以100%兼容MySQL。 所谓集分一体化，就是兼具分布式数据库的扩展性和集中式数据库的功能和单机性能，两种形态可以无缝切换。在集分一体化数据库中，数据节点被独立出来作为集中式形态，完全兼容单机数据库形态。当业务增长到需要分布式扩展的时候，架构会原地升级成分布式形态，分布式组件无缝对接到原有的数据节点上进行扩展，不需要数据迁移，也不需要应用侧做改造。

回顾下MySQL 8.0的官方开源，8.0.11版本在2018年正式GA，历经5年左右的不断演进，修复和优化了众多稳定性和安全相关的问题，2023年后的8.0.3x版本后逐步进入稳态。 PolarDB-X在V2.4版本，跟进MySQL 8.0的官方演进，分布式的DN多副本中全面兼容MySQL 8.0.32，快速继承了官方MySQL的众多代码优化：

  • 更好用的DDL能力，比如：Instant DDL（加列、减列）、Parallel DDL（并行索引创建）
  • 更完整的SQL执行能力，比如：Hash Join、窗口函数等

标准版架构

PolarDB-X标准版，采用分层架构：

  • 日志层：采用Paxos的多数派复制协议，基于Paxos consensus协议日志完全兼容MySQL binlog格式。相比于开源MySQL主备复制协议（基于binlog的异步或半同步），PolarDB-X标准版可以金融级容灾能力，满足机房级故障时，不丢任何数据，简称RPO=0。
  • 存储层：自研Lizard事务系统，对接日志层，可以替换传统MySQL InnoDB的单机事务系统，分别设计了 SCN 单机事务系统和 GCN 分布式事务系统来解决这些弊端，可以满足集中式和分布式一体化的事务优化，同时PolarDB-X标准版基于SCN 单机事务系统可以提供完全兼容MySQL的事务隔离级别。
  • 执行层：类似于MySQL的Server层，自研xRPC Server可以对接PolarDB-X企业版的分布式查询。同时为完全兼容MySQL，也提供兼容MySQL Server的SQL执行能力，对接存储层的事务系统来提供数据操作。

性能体验

硬件环境：

机器用途 机型 规格
压力机 ecs.hfg7.6xlarge 24c96g
数据库机器 ecs.i4.8xlarge * 3 32c256g + 7TB的存储，单价：7452元/月

TPCC场景：对比开源MySQL（采用相同的主机硬件部署）

场景 并发数 MySQL 8.0.34
主备异步复制		 PolarDB-X 标准版 8.0.32
Paxos多数派		 性能提升
TPCC 1000仓 300并发 170882.38 tpmC 236036.8 tpmC ↑38%

03 全球数据库 GDN

数据库容灾架构设计是确保企业关键数据安全和业务连续性的核心。随着数据成为企业运营的命脉，任何数据丢失或服务中断都可能导致重大的财务损失。在规划容灾架构时，企业需要考虑数据的恢复时间目标（RTO）和数据恢复点目标（RPO），以及相关的成本和技术实现的复杂性。

03 全球数据库 GDN

数据库容灾架构设计是确保企业关键数据安全和业务连续性的核心。随着数据成为企业运营的命脉，任何数据丢失或服务中断都可能导致重大的财务损失。在规划容灾架构时，企业需要考虑数据的恢复时间目标（RTO）和数据恢复点目标（RPO），以及相关的成本和技术实现的复杂性。

常见容灾架构

异地多活，主要指跨地域的容灾能力，可以同时在多地域提供读写能力。金融行业下典型的两地三中心架构，更多的是提供异地容灾，日常情况下异地并不会直接提供写流量。但随着数字化形式的发展，越来越多的行业都面临着容灾需求。比如，运营商、互联网、游戏等行业，都对异地多活的容灾架构有比较强的诉求。 目前数据库业界常见的容灾架构：

  • 同城3机房，一般是单地域多机房，无法满足多地域多活的诉求
  • 两地三中心，分为主地域和异地灾备地域，流量主要在主地域，异地主要承担灾备容灾，异地机房日常不提供多活服务。
  • 三地五中心，基于Paxos/Raft的多地域复制的架构
  • Geo-Partitioning，基于地域属性的partition分区架构，提供按用户地域属性的就近读写能力
  • Global Database，构建全球多活的架构，写发生在中心，各自地域提供就近读的能力

总结一下容灾架构的优劣势：

容灾架构 容灾范围 最少机房要求 数据复制 优缺点
同城3机房 单机房级别 3机房 同步 比较通用，业务平均RT增加1ms左右
两地三中心 机房、地域 3机房 + 2地域 同步 比较通用，业务平均RT增加1ms左右
三地五中心 机房、地域 5机房 + 3地域 同步 机房建设成本比较高，业务平均RT会增加5~10ms左右（地域之间的物理距离）
Geo-Partitioning 机房、地域 3机房 + 3地域 同步 业务有适配成本（表分区增加地域属性），业务平均RT增加1ms左右
Global Database 机房、地域 2机房 + 2地域 异步 比较通用，业务就近读+ 远程转发写，适合异地读多写少的容灾场景

 

PolarDB-X的容灾能力

PolarDB-X 采用数据多副本架构（比如3副本、5副本），为了保证副本间的强一致性（RPO=0），采用Paxos的多数派复制协议，每次写入都要获得超过半数节点的确认，即便其中1个节点宕机，集群也仍然能正常提供服务。Paxos算法能够保证副本间的强一致性，彻底解决副本不一致问题。

PolarDB-X V2.4版本以前，主要提供的容灾形态：

  • 单机房（3副本），能够防范少数派1个节点的故障
  • 同城3机房（3副本），能够防范单机房故障
  • 两地三中心（5副本），能够防范城市级的故障

阿里集团的淘宝电商业务，在2017年左右开始建设异地多活的架构，构建了三地多中心的多活能力，因此在PolarDB-X V2.4我们推出了异地多活的容灾架构，我们称之为全球数据库（Global Database Network，简称GDN）。 PolarDB-X GDN 是由分布在同一个国家内多个地域的多个PolarDB-X集群组成的网络，类似于传统MySQL跨地域的容灾（比如，两个地域的数据库采用单向复制、双向复制 ， 或者多个地域组成一个中心+单元的双向复制等）。

常见的业务场景：

  1. 基于GDN的异地容灾

异地容灾

业务默认的流量，读写都集中在中心的主实例，异地的从实例作为灾备节点，提供就近读的服务能力 PolarDB-X 主实例 和 从实例，采用双向复制的能力，复制延迟小于2秒，通过备份集的异地备份可以快速创建一个异地从实例。 当PolarDB-X 中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例

2. 基于GDN的异地多活

异地多活

业务适配单元化分片，按照数据分片的粒度的就近读和写，此时主实例和从实例，均承担读写流量 PolarDB-X 主实例 和 从实例，采用双向复制的能力，复制延迟小于2秒 当PolarDB-X 中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例

使用体验

PolarDB-X V2.4版本，暂时仅提供基于GDN的异地容灾，支持跨地域的主备复制能力（异地多活形态会在后续版本中发布)。GDN是一个产品形态，其基础和本质是数据复制，PolarDB-X提供了高度兼容MySQL Replica的SQL命令来管理GDN，简单来说，会配置MySQL主从同步，就能快速的配置PolarDB-X GDN。

1. 可以使用兼容MySQL的CHANGE MASTER命令，搭建GDN复制链路

 CHANGE MASTER TO option [, option] ... [ channel_option ] option: {     MASTER_HOST = 'host_name'   | MASTER_USER = 'user_name'   | MASTER_PASSWORD = 'password'   | MASTER_PORT = port_num   | MASTER_LOG_FILE = 'source_log_name'   | MASTER_LOG_POS = source_log_pos   | MASTER_LOG_TIME_SECOND = source_log_time   | SOURCE_HOST_TYPE = {RDS|POLARDBX|MYSQL}   | STREAM_GROUP = 'stream_group_name'   | WRITE_SERVER_ID = write_server_id   | TRIGGER_AUTO_POSITION = {FALSE|TRUE}   | WRITE_TYPE = {SPLIT|SERIAL|TRANSACTION}   | MODE = {INCREMENTAL|IMAGE}   | CONFLICT_STRATEGY = {OVERWRITE|INTERRUPT|IGNORE|DIRECT_OVERWRITE}   | IGNORE_SERVER_IDS = (server_id_list) } channel_option:     FOR CHANNEL channel server_id_list:     [server_id [, server_id] ... ]

2. 可以使用兼容MySQL的SHOW SLAVE STATUS命令，监控GDN复制链路

 SHOW SLAVE STATUS [ channel_option ] channel_option:     FOR CHANNEL channel

3. 可以使用兼容MySQL的CHANGE REPLICATION FILTER命令，配置数据复制策略

 CHANGE REPLICATION FILTER option [, option] ... [ channel_option ] option: {     REPLICATE_DO_DB = (do_db_list)   | REPLICATE_IGNORE_DB = (ignore_db_list)   | REPLICATE_DO_TABLE = (do_table_list)   | REPLICATE_IGNORE_TABLE = (ignore_table_list)   | REPLICATE_WILD_DO_TABLE = (wild_do_table_list)   | REPLICATE_WILD_IGNORE_TABLE = (wile_ignore_table_list)   | REPLICATE_SKIP_TSO = 'tso_num'   | REPLICATE_SKIP_UNTIL_TSO = 'tso_num'   | REPLICATE_ENABLE_DDL = {TRUE|FALSE} } channel_option:     FOR CHANNEL channel

4. 可以使用兼容MySQL的START SLAVE 和 STOP SLAVE命令，启动和停止GDN复制链路

 START SLAVE [ channel_option ] channel_option:     FOR CHANNEL channel STOP SLAVE [ channel_option ] channel_option:     FOR CHANNEL channel

5.可以使用兼容MySQL的RESET SLAVE，删除GDN复制链路

 RESET SLAVE ALL [ channel_option ] channel_option:     FOR CHANNEL channel

拥抱生态，提供兼容MySQL的使用方式，可以大大降低使用门槛，但PolarDB-X也需要做最好的自己，我们在兼容MySQL的基础上，还提供了很多定制化的功能特性。

功能特性 功能描述
一键创建多条GDN复制链路 在 CHANGE MASTER 语句中，指定 STREAM_GROUP 选项，即PolarDB-X多流binlog集群的流组名称，可以一键创建多条复制链路(具体取决于binlog流的数量)，带来极简的使用体验。什么是多流binlog？参见binlog日志服务
基于时间戳的复制链路搭建 在 CHANGE MASTER 语句中，指定 MASTER_LOG_TIME_SECOND 选项，可以基于指定的时间点，来构建复制链路，相比通过指定file name和file positiion的方式，更加灵活。

比如在搭建GDN时，一般的流程为先通过全量复制或备份恢复的方式准备好从实例，然后启动增量复制链路，通过指定 MASTER_LOG_TIME_SECOND 显然更加简便。尤其是当对接的是PolarDB-X多流binlog时，为每条链路分别指定file name和file position，相当繁琐，而结合STREAM_GROUP和MASTER_LOG_TIME_SECOND，则相当简便。
多种模式的 DML 复制策略 在 CHANGE MASTER 语句中，指定 WRITE_TYPE 选项，可以指定DML的复制策略，可选策略如下
- TRANSACTION：严格按照binlog中的事务单元，进行原样回放，适用于对数据一致性、事务完整性有高要求的场景
- SERIAL：打破binlog中的事务单元，重新组织事务单元，进行串行回放，适用于对事务完整性要求不高，但仍需要串行复制的场景
- SPLIT：打破binlog中的事务单元，依赖内置的数据冲突检测算法，进行全并行回放，适用于高吞吐、高并发的场景
全量增量一体化复制搭建 谁说 CHANGE MASTER 只能创建增量同步？在 CHANGE MASTER 语句中，指定 MODE 选项，可以指定链路的搭建模式
- INCREMENTAL: 直接创建增量复制链路
- IMAGE: 先完成全量复制，再基于全量复制开始的时间点，启动增量复制链路
原生的轻量级双向复制能力 在 CHANGE MASTER 语句中，组合使用 WRITE_SERVER_ID 和 IGNORE_SERVER_IDS 选项，可配置基于server_id的防流量回环双向复制链路，相比需要额外引入事务表的方案，不仅使用简单，而且性能无损。

原生的轻量级双向复制能力，举例来说：

  1. PolarDB-X实例 R1 的server_id为100
  2. PolarDB-X实例 R2 的server_id为200
  3. 构建 R1 到 R2的复制链路时，在R2上执行CHANGE MASTER并指定WRITE_SERVER_ID = 300、IGNORE_SERVER_IDS = 400
  4. 构建R2 到 R1的复制链路时，在R1上执行CHANGE MASTER并指定WRITE_SERVER_ID = 400、IGNORE_SERVER_IDS = 300

GDN场景下，保证主从实例之间的数据一致性是最为关键的因素，提供便捷的数据校验能力则显得尤为关键，V2.4版本不仅提供了完善的主从复制能力，还提供了原生的数据校验能力，在从实例上执行相关SQL命令，即可实现在线数据校验。V2.4版本暂时只支持直接校验模式(校验结果存在误报的可能)，基于sync point的快照校验能力(校验结果不会出现误报)，会在下个版本进行开源。

 #开启校验 CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`}  [MODE='direct' | 'tso']  FOR CHANNEL xxx; #查看校验进度 CHECK REPLICA TABLE [`test_db`.`test_tb`] | [`test_db`] SHOW PROGRESS; #查看差异数据 CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} SHOW DIFFERENCE;

此外，数据的一致性不仅体现在数据内容的一致性上，还体现在schema的一致性上，只有二者都保证一致，才是真正的一致，比如即使丢失一个索引，当发生主从切换后，也可能引发严重的性能问题。PolarDB-X GDN支持各种类型的DDL复制，基本覆盖了其所支持的全部DDL类型，尤其是针对PolarDB-X特有schema的DDL操作，更是实现了充分的支持，典型的例子如：sequenc、tablegroup等DDL的同步。

除了数据一致性，考量GDN能力的另外两个核心指标为RPO和RTO，复制延迟越低则RPO越小，同时也间接影响了RTO，本次V2.4版本提供了RPO <= 2s、RTO分钟级的恢复能力，以Sysbench和TPCC场景为例，GDN单条复制链路在不同网络延迟条件(0.1ms ~ 20ms之间)下可以达到的最大RPS分布在2w/s 到 5w/s之间。当业务流量未触达单条复制链路的RPS瓶颈时，用单流binlog + GDN的组合来实现容灾即可，而当触达瓶颈后，则可以选择多流binlog + GDN的组合来提升扩展性，理论上只要网络带宽没有瓶颈，不管多大的业务流量，都可实现线性扩展，PolarDB-X GDN具备高度的灵活性和扩展性，以及在此基础之上的高性能表现。

04 开源生态完善

快速运维部署能力

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

部署方式 说明 安装工具的快速安装 依赖项
RPM包 零组件依赖，手工快速部署 RPM下载、RPM安装 rpm
PXD 自研快速部署工具，通过yaml文件配置快速部署 PXD安装 python3、docker
K8S 基于k8s operator的快速部署工具 K8S安装 k8s、docker

polardbx-operator是基于k8s operator架构，正式发布1.6.0版本，提供了polardb-x数据库的部署和运维能力，生产环境优先推荐，可参考polardbx-operator运维指南。

polardbx-operator 1.6.0新版本，围绕数据安全、HTAP、可观测性等方面完善集中式与分布式形态的运维能力，支持标准版的备份恢复，透明加密（TDE），列存只读（HTAP）、一键诊断工具、CPU 绑核等功能。同时兼容了8.0.32 新版本内核，优化了备份恢复功能的稳定性。详见：Release Note。

pxd 是基于开源用户物理机裸机部署的需求，提供快速部署和运维的能力, 可参考pxd运维。

发布pxd 0.7新版本，围绕版本升级、备库重搭，以及兼容8.0.32新版本内核。

标准版生态

V2.3版本开始，为方便用户进行快速体验，提供rpm包的下载和部署能力，可以一键完成标准版的安装，参考链接：

  • 基于rpm包部署polardbx-标准版 （https://doc.polardbx.com/zh/deployment/topics/deploy-by-rpm-std.html）
  • 【PolarDB-X开源】基于Paxos的MySQL三副本（https://zhuanlan.zhihu.com/p/669301230）

PolarDB-X标准版，基于Paxos协议实现多副本，基于Paxos的选举心跳机制，MySQL自动完成节点探活和HA切换，可以替换传统MySQL的HA机制。如果PolarDB-X替换MySQL，作为生产部署使用，需要解决生产链路的HA切换适配问题，开发者们也有自己的一些尝试（比如HAProxy 或 自定义proxy）。 在V2.4版本，我们正式适配了一款开源Proxy组件。

 

ProxySQL作为一款成熟的MySQL中间件，能够无缝对接MySQL协议支持PolarDB-X，并且支持故障切换，动态路由等高可用保障，为我们提供了一个既可用又好用的代理选项，更多信息可参考文档：使用开源ProxySQL构建PolarDB-X标准版高可用路由服务

ZhouSa.com-宙飒天下网