2022 年云栖大会上，PolarDB-X 发布 2.2.0 版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产化适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。

架构简介

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

• 计算节点（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 协议的主从复制能力。

版本说明

梳理下 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 年 9 月份，PolarDB-X 数据库高分通过分布式数据库金融标准验证，共进行了 337 个检测项的验证工作，涉及：架构、运维、安全、容灾、性能等。经专家评审后，PolarDB-X 判定符合的检测项为 323 项，整体测试结果表现优异。

2022 年 10 月份，PolarDB-X 正式发布 2.2.0 版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产化适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。

01 国产 ARM 适配

目前市场上对于国产服务器的适配有比较强的需求，常见的需求就是兼容 CPU ARM 架构，除了数据库能正常运行在 ARM 架构上，还需要结合国产 ARM 架构优化数据库的性能。

参考文档：主流CPU性能摸底(Intel/AMD/鲲鹏/海光/飞腾)

PolarDB-X V2.2.0 版本开始，同时发布兼容 X86/ARM 架构的二进制版本，另外配套的数据库部署工具，也会支持 ARM 架构下的 numa 绑核能力，提升数据库的性能。

执行 docker mainfest inspect(查看对应的二进制版本)

02 全新读写分离架构

MySQL 生态里读写分离是一种比较常见的技术，除了用于解决写少读多场景的优化，也经常用于 OLTP/OLAP 业务隔离的典型场景，比如考虑在线数据库的稳定性，通过读写分离将个别复杂查询发送给 MySQL 的备库。

传统 MySQL 的读写分离：

存在的问题：

1. 需要有额外的 Proxy 组件 或者 业务代码路由，实现可控的读写分离路由

2. 备库读存在数据一致性问题，比如请求 A 在主库完成写入，然后立马到备库读数据因为复制延迟，可能读不到刚写入的数据

3. 需要额外的 OLAP 的列存数据 + 外置的复制同步(比如类 canal 的视线)，支持更复杂的报表查询

PolarDB-X 的读写分离架构：

1. 计算节点(CN)承当读写分离的路由组件，无需引入额外组件，多个 CN 节点需配置一个负载均衡设备(比如 LVS)

2. 提供全局一致性读，在读写分离路由到备库上的请求，保证业务写后读的数据一致性，提供更易用的读写分离能力

3. 提供 HTAP 行列混存架构，多份数据+一套 SQL 引擎，提供 HTAP 混合负载能力

强一致读写分离

分布式数据库，天然具备多副本的能力，PolarDB-X 采用了 Paxos 多数派共识协议，借助于 Paxos 协议的日志流 LogIndex(全局递增的唯一序列，记录 Paxos 日志下标)，PolarDB-X 可以基于 LogIndex 实现多副本的全局一致性读，达到读写分离的效果。

PolarDB-X 在传统的 MySQL 读写分离架构基础上，引入了 Paxos Learner 节点作为只读 RO 节点(不参与 Paxos 三副本投票，仅异步复制数据，RO 节点 CPU 跑满不会影响三副本多数派的写入)。在读写分离模式下，路由到只读 RO 节点的流量，PolarDB-X 会优先获取主库的 LogIndex，确保 RO 副本的 LogIndex 超过该值，同时利用分布式事务 MVCC 的 TSO 时间戳版本，可以实现满足 RC/RR 隔离级别下的强一致读写分离。

1、 强一致读写分离测试：模拟业务先写后读的场景，写发生在 RW 库、读发生在 RO 库

从这个测试来看，模拟业务的先写后读的模式，会出现读不到数据的情况。

2、sysbench 压测，验证强一致读写分离模式下的性能扩展

CN 节点规格：2*16C128G，DN 节点规格：RW 主实例 2*4C32G、RO 只读实例 2*4C32G

sysbench oltp_read_only 场景：

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all' --tables='16' --table-size='10000000' --range-size=5 --threads=512 oltp_read_only run

从测试结果看：

1. 在强一致性读下，在 OLTP 读场景下流量从主实例切换到只读实例上吞吐的性能衰减 20～30%，但是通过添加只读实例个数，性能可以做到一定的线性增加；

2.在弱一致性读下，在 TP 读场景下流量从主实例切换到只读实例上吞吐的性能未衰减，且通过添加只读实例的个数，性能可以做到线性增加；

HTAP 混合负载

HTAP 架构的核心目标是帮助用户降低成本：运维成本、使用成本。比如：传统的 OLTP + ETL + OLAP 的解决方案，最大的挑战在于运维成本的复杂性和稳定性，HTAP 数据库的一体化架构可以有效降低外置的运维成本。

目前，市面上的 HTAP 架构形态多种多样，总结一下核心技术三要素：

• MPP 并行计算，基于并行能力提升数据分析场景的线性扩展性，这是基本架构要求

• 资源隔离，确保数据分析查询不影响在线业务，常见的单进程逻辑隔离有局限性，推荐物理多副本的隔离

• 列存副本，降低数据分析查询的资源使用成本，利用列存的紧凑型编码非常适合 AP 查询，更好的性价比

PolarDB-X 在开源 V2.2.0 版本里，提供了如下能力：

1. 资源隔离，基于 Paxos 多副本 + 读写分离，实现在线业务和数据分析业务的物理隔离

2. MPP 并行计算，结合读写分离架构，针对路由到只读节点的请求，默认采用 MPP 并行查询计划，提升查询性能

3. 列存能力，当前 PolarDB-X 在 SQL 引擎中引入了 chunk-at-a-time 的内存列式结构，有效提升单核查询效率，但存在物理数据的行结构动态转为列存的开销，有一定的优化空间。未来，PolarDB-X 正在开发列式存储引擎，预计在 2023 年的中旬会正式开源，形成行列混存的统一架构。

HTAP 架构即使存在资源隔离，但如果业务在使用中将数据分析查询如果跑到了主库上，也会影响了在线业务的性能，因此对于业务请求如何正确使用多副本也非常重要。

从易用性和稳定性的角度，PolarDB-X 提供了基于优化器 cost 代价的智能读写分离。 PolarDB-X 优化器会基于代价分析出查询物理扫描行数、CPU、内存、IO、网络等核心资源消耗量，将请求区分为 TP 与 AP 负载，如果在集群地址上开启了智能路由，会主动识别 SQL 的工作负载类型来做路由，比如将识别为 AP 负载的流量路由给只读 RO 副本。可以通过 explain cost 指令查看 SQL 工作负载类型的识别情况。例如以下查询，该查询涉及到物理扫描行数 rowcount 很小，计算资源（CPU&Memory）也消耗比较少，所以这个查询被识别为 TP 负载。

以 TPCH Q13 为例来演示下执行器在不同场景下的加速效果，为了方便截图在 Q13 后面都加了 limit

对应 CN/DN 节点规格：2*16C64G 单机单线程下运行，耗时 3min31s

使用 Parallel Query 加速，既单机多线程执行，耗时 23.3s

使用 MPP 加速，既同时利用两个 CN 节点的资源计算，耗时 11.4s

03 MySQL 生态兼容性

MySQL 数据库除了基本的 SQL DML/DDL/DAL 以外，还有许多高级特性，比如锁系统、binlog 协议、主备 replication、存储过程、触发器、外键、视图等。

传统的分布式中间件或分布式数据库，标榜的高度 MySQL 兼容性，更多是在 SQL 的功能语法上，比如 DML/DDL/DAL，但在性能兼容、生态兼容上还是有蛮多的差异性，带来了使用上的复杂性。

举几个例子：

1. MySQL 的事务隔离级别，普遍采用的是 RC/RR，在事务模型上有其独特的地方，比如 MySQL update v=v+1 是一个典型的悲观事务模型，区别于 Google Percolator 的乐观事务模型。另外，MySQL 常用的 select for update 用法，是一个典型的 B+Ttree 下 GAP 锁场景，目前市面上 NewSQL 基于 LSM-Tree 架构的几乎没有兼容该特性。

2. MySQL binlog 组件作为数据库 CDC(change data capture)架构的典型设计，也是解决下游生态兼容的重要能力，很多 NewSQL 更多还是从外置的数据同步组件提供了一定的 CDC 能力，但并没有兼容 binlog 协议。

PolarDB-X 在 22 年 3 月份开源的版本中，已经很好的支持 MySQL 隔离级别、以及 MySQL binlog 生态兼容的能力，本次 V2.2.0 的开源版本，重点加强了几项新的兼容能力：

存储过程

存储过程（Stored Procedure）是一组为了完成特定功能的 SQL 语句集，业务在实现某些需求时，需要编写一组复杂的 SQL 语句才能实现的时候，很多资深数据库用户习惯使用存储过程。

使用存储过程能带来如下好处：

• 复用性高。存储过程可以重复使用，从而减少数据库开发人员的工作量，同时降低业务出错概率。

• 效率高。存储过程编译一次后，就会存到数据库，每次调用时都直接执行。

• 降低网络流量。存储过程编译好会放在数据库，我们在远程调用时，不会传输大量的字符串类型的 SQL 语句。

• 安全性高。完成某个特定功能的存储过程一般只有特定的用户可以使用，具有使用身份限制，更安全。

当然存储过程也存在一些缺点：

• 跨平台可移植性差

• 复杂 ETL 带来更多资源开销，比如内存/CPU 等

• 容易产生大事务和长事务

PolarDB-X 基于 GMS 存储，全面兼容了 MySQL 存储过程语法，支持存储过程的创建、修改、删除等管理操作。同时引入了 PL Engine 引擎支持存储过程的运行、以及运行的内存管理，支持 GB 级别的大事务和 2 小时的长事务等。

CREATE PROCEDURE pro_test()  BEGIN  DECLARE a CHAR(16);  DECLARE b, c int;  DECLARE cur1 CURSOR FOR SELECT data, id FROM t1 order by id;  DECLARE cur2 CURSOR FOR SELECT id FROM t2 order by id;  DECLARE CONTINUE HANDLER FOR NOT FOUND begin LEAVE read_loop; end;
  OPEN cur1;  OPEN cur2;
  read_loop: LOOP    FETCH cur1 INTO a, b;    FETCH cur2 INTO c;    IF b < c THEN    INSERT INTO t3 VALUES (b, a);    ELSE    INSERT INTO t3 VALUES (c, a);    END IF;  END LOOP;
  CLOSE cur1;  CLOSE cur2;  END;|

具体详情可以参见：https://help.aliyun.com/document_detail/452384.html

Auto Increment 自增约束

分布式数据库提供全局唯一数字序列的主要目的是为了生成全局唯一和有序递增的数字序列，常用于主键列、唯一索引列等列值的生成。

相比于目前绝大部分的 NewSQL 仅提供了全局唯一但不连续的自增 ID，PolarDB-X v2.2 提供了全局唯一、连续、单调递增的 Auto Increment 兼容能力，简称：New Sequence，产生的值是默认从 1 开始的自然数序列。在 AUTO 模式库中建表时，指定 AUTO_INCREMENT 自增列，将默认自动为该表创建并关联一个 New Sequence 对象，用于在 INSERT 时自动填充自增列的值。

	# 兼容MySQL的建表create table test (   id bigint not null AUTO_INCREMENT,    number INT NOT NULL,  primary key(id))
# 兼容MySQL的SQL操作INSERT INTO test (number) VALUES (1);INSERT INTO test (number) VALUES (null, 2);INSERT INTO test (number) VALUES (0, 3);INSERT INTO test (number) VALUES (null, 4),(null,5)… ;SELECT LAST_INSERT_ID();
# 兼容Oracle Sequence语法CREATE NEW SEQUENCE newseq START WITH 1000;SELECT SEQ.NEXTVAL ;SELECT SEQ.CURRVAL ;SELECT SEQ.NEXTVAL FROM DUAL WHERE COUNT = 100;ALTER TABLE test_pxc AUTO_INCREMENT = 200;

Demo 视频：

https://link.zhihu.com/?target=https%3A//www.zhihu.com/video/1527649701381365760

具体详情可以参见：PolarDB-X 与 MySQL AUTO_INCREMENT 完全兼容

04 数据库安全

在 IT 圈内，“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话，却反映了数据库对企业的重要性，在提升数据库安全性上，除了做好网络隔离、权限管理外，还需要再全链路中做好审计，确保有查比有果。同时在面向数据丢失的情况下，做好应急恢复的能力。

全量 SQL 审计

传统的数据库审计，一般采用网络旁路的方式，通过外置组件集中收集所有网络流量，从中采集到对应的 SQL 审计，另外提供一个审计查询的入口进行快速检索。

PolarDB-X V2.2.0 版本，通过数据库内置的 SQL 审计能力，可以快速且完整的记录所有 SQL 日志，PolarDB-X 通过 Logstash 组件作为日志的解析和上报组件，默认准实时采集全量 SQL 的文本，通过 logstash 的投递组件的扩展，比如可以对接 ElasticSearch 组件 或者 自定义扩展组件，实现 SQL 审计持久化存储和白屏化 SQL 审计查询。

具体详情可参见：https://doc.polardbx.com/operator/ops/logcollector/1-logcollector.html

SQL 日志格式：https://doc.polardbx.com/operator/ops/logcollector/2-logfield.html

Flashback Query

删库跑路事件不常有，但因粗心导致的误删数据却屡见不鲜，比如手误执行了一个错误的 DML，导致数据被误删。首先，我们以一个实际误删数据的事故开场。

我们来梳理下事故的时间线：

• T1：小明维护了一张员工表，里面记录着公司的员工信息。

• T2：小明需要删除 Mary 的记录，因此他到数据库里面执行了一条 DELETE 语句，本意是想删除用户 Mary 的记录，但是因为手贱，漏了一个 and 语句， 导致员工 Ralph 的数据也被意外删除

• T3：此时业务仍在继续，John 被删除， Tim 和 Jose 被插入到表中。而此时粗心的小明发现了数据被误删，迫切希望恢复数据。

围绕这一次的数据误删事故，看看是 PolarDB-X 是如何拯救粗心的小明的？

PolarDB-X 在新版本提供 Flashback Query 功能，针对行级误删场景，提供短时间内误操作的快速回退能力。

通过 Flashback Query 的 AS OF TIMESTAMP 'xx'可以快速查询数据误删前的数据版本记录

# SQL例子select title from employee where id in (2,3) AS OF TIMESTAMP '2022-11-11 00:00:00'

原理解读：错误 SQL 发生时，变更都会记录在版本为 Vn+1 的 undo log 中；T2 时，发现了误改问题并确定误操作时间和影响的数据范围；通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值；根据 Flashback Query 返回的正确值对数据进行了订正。

05 分布式数据管理

分布式数据库中，数据需要按照一定的策略分布到多个节点中，对数据的可管理性是数据库的一个重要能力维度，在保证数据库线性水平扩展下，基于数据管理来达到业务的诉求。

数据管理的典型业务场景：

1. 交易和日志类业务，有按照时间维度的归档属性，期望数据一级分区按照用户做 hash 分布，二级分区按照 range 做时间滚动

2. 多租户的业务场景，比如政务系统的省地市业务，期望一张表的数据按照 list 做分布，同时指定分区互相隔离，每个分区单独分配一个存储节点

3. 冷热数据分离的场景，比如近期写入的属于热数据，优先放置在 SSD 盘的节点中，将历史数据动态调度到 HDD 盘的节点中，历史数据可以做一定的压缩，从而降低存储成本

PolarDB-X 在 V2.2.0 版本中，进一步增强了分区表的管理能力以及基于 Locality 的调度。

分区表管理

传统的数据分区策略，一般仅在数据表第一次创建时定义了分布规则，事后的分区新增、修改、删除一般不支持数据搬迁。PolarDB-X 在分区表的变更能力上，在满足分布式数据不均衡性上做了更多灵活的变更管理。

1. hash/key 分区分裂

比如一张表 orders

CREATE TABLE orders(a int) PARTITIONBY key(a) partitions 3;

默认的这三个分区的名字依次是 p1，p2，p3，可以通过以下语法，将 p1 分裂成两个分区，这两个新分区是在原 p1 的 hash 空间范围内将其按 hash 空间范围一分为二：

ALTERTABLE tb1 SPLIT PARTITION p1; // p2/p3的数据分区不需要移动

1. hash/key 分区的热点提取

在 orders 表的基础上，做一个变更：

ALTER TABLE orders (a int, b int)PARTITION BY key(a, b) PARTITIONS BY 3;

执行以下 SQL，将拆分键值为(a=88,b=10)的数据，提取到一个单独的新分区：

ALTER TABLE tb1 EXTRACT TO PARTITION p_hot88 BY HOT VALUE(88,10);

1. 分区迁移

继续沿用 orders 表，拆分键值为(a=88,b=10)的数据分区，单独迁移到一个独立的 DN 节点上，对应的 DN 名字为 DN_VIP88。

ALTER TABLE orders MOVE PARTITIONS p_hot88 to 'DN_VIP88';

除了例子中的 hash 分区外，range/list 等分区均支持类似的分裂、合并、迁移、重命名等管理。

更多内容可以参考文档：

1. 表级分区变更语法
   

2. PolarDB-X 热点优化系列 （二）：如何支持淘宝大卖家分区热点
   

Locality 调度

PolarDB-X 在 V2.2.0 版本中，提供一种更灵活的 Locality 定义能力，可以针对数据库的不同对象进行定义，从而去实现数据存储的有效管理。

1. database 对象，指定 locality 可以限制库下对应的表只分布在 dn=polardbx-dn-0000

CREATE DATABASE db1 LOCALITY='dn=polardbx-dn-0000' MODE = 'auto';

1. table 对象，指定 loality 可以将不同的单表分布到不同的 DN 节点中

# 0号DNCREATE TABLE tableA(a int) single locality = 'dn=polardbx-dn-0000';
# 1号DNCREATE TABLE tableB(a int) single locality = 'dn=polardbx-dn-0001';

1. partition 对象，可以在分区级别进行精细化分区管理，实现细粒度的管理。

比如针对一张表，北京数据可以分布在 3 个 DN 节点、上海分布在 2 个 DN 节点，新疆和西藏共用一个 DN 节点

CREATE TABLE orders_region( order_id int AUTO_INCREMENT primary key, city varchar(64))PARTITION BY LIST(city)(  PARTITION p1 VALUES IN ('北京') LOCALITY = 'dn=polardbx-dn-beijin01,polardbx-dn-beijin02,polardbx-dn-beijin03',  PARTITION p2 VALUES IN ('上海') LOCALITY = 'dn=polardbx-dn-shanghai01,polardbx-dn-shanghai02',  PARTITION p3 VALUES IN ('新疆'、'西藏') LOCALITY = 'dn=polardbx-dn-west',) ;

冷热数据分离

降本增效目前是数据库的一个主要技术方向，结合 PolarDB-X V2.1.1 提供的 OSS 提供冷热数据分离存储，以及分区和 Locality 调度，可以有如下的想象空间：

1. DBA 部署了 PolarDB-X，对应服务器有 SSD 或者 HDD 的硬盘，通过定义分区 locality，可以将不同的数据分区进行有效的成本化管理。比如按照 range 分区，将历史数据定期设置 locality。

2. DBA 在阿里云环境上部署了 PolarDB-X，并且开启了 OSS 对象存储，可以通过 PolarDB-X 自带的数据归档能力，通过 TTL(Time-To-Live)分区能力，自动将数据归档到 OSS 存储中。

更多内容可以参考文档：

1. 通过LOCALITY指定存储位置
   

2. PolarDB-X On OSS QuickStart
   

3. PolarDB-X on OSS: 冷热数据分离存储
   

06 开源相关配套工具

数据库的生态建设，除了 MySQL 内核和协议的兼容性外，最重要的就是配套的生态工具，比如常见的就是面向数据库的导入导出工具。

PolarDB-X 在 V2.2.0 版本中，开源了在分布式数据库金融标准中所使用的几款生态工具，帮助大家更好的使用 PolarDB-X。

polardbx-backup

PolarDB-X Operator 中提供了强一致的备份恢复，内部最重要的就是 backup 工具。我们选择基于 Pecona XtraBuckup 源码基础上，扩展了分布式数据库的部分特性：

1. 兼容自研存储引擎 Lizard，扩展了 InnoDB 的数据格式，增加了 SCN/GCN 的扩展槽位

2. 兼容分布式事务日志，比如 XA 的 prepare/commit 事件、以及 timestamp 事件等

3. 分布式一致性日志裁剪，多个物理文件因备份完成时间有差异，需要拉齐多个物理文件之间的事务一致性

更多详情，可以参考开源代码：https://github.com/ApsaraDB/polardbx-backup

benchmark-boot

PolarDB-X 提供了一款白屏化的数据库压测工具，融合了常见的 sysbench、TPC-C、TPC-H 的压测脚本，可以帮助大家快速完成数据库的性能测试。

工具特性：

1. 提供内置 benchmark 压测脚本，并调整 bechmark 的最佳参数，比如 sysbench/TPC-C/TPC-H

2. 提供白屏化能力，支持一键安装、压测、日志、监控展示等

3. 提供数据库的常见调优能力，比如参数管理、执行计划 hint 等

更多详情，可以参考文档：使用Benchmark Boot进行压测

batch-tool

Batch Tool 工具是专为 PolarDB-X 数据库提供数据导入导出服务的工具。 其结合分布式数据库特点实现一站式且高效地从文件导入、导出到文件以及跨库的离线数据迁移(MySQL / PolarDB-X)等功能， 在此基础上，还支持基于文本文件批量更新、删除等功能 (实验特性)。

导出方法对比

测试方法以 PolarDB-X 导出 1000w 行数据为例，数据量大概 2GB 左右。

导入方法对比

测试方法以 PolarDB-X 导入 1000w 行数据为例，源数据是上一个测试中导出的数据，数据量大概 2GB 左右。

数据导入导出工具小结：

1. mysql -e/source/mysqldump，这类原生工具的原理上主要是单线程操作，性能差距不明显。比如，数据导入实际上是发送了 Batch Insert 语句，Batch size 大小会影响导入性能，可以通过设置"net-buffer-length"参数进行调优，一般建议该参数不超过 256K。

2. load data 语句虽然是单线程操作，但优化了数据文本的编码格式，性能优于 mysql 命令和 source 语句

3. PolarDB-X 原生的 batch-tool 工具支持多线程导入，且贴合 PolarDB-X 分布式多分片的操作方式，性能打到了最优

更多详情，可以参考文档：

1. 使用Batch Tool工具导入导出数据
   

2. 如何优化数据导入导出
   

07 轻量化部署和运维

PolarDB-X Operator 是一个基于 Kubernetes 的 PolarDB-X 集群管控系统，希望能在原生 Kubernetes 上提供完整的生命周期管理能力，满足用户的轻量化部署。

在 PolarDB-X V2.2.0 版本，我们进一步完善了众多面向生产运维的企业级功能。

强一致备份恢复

数据库通过备份恢复来保障数据安全，用户在运维误操作、或删库跑路等重大故障的情况下，可以采用备份集恢复的方式来快速恢复业务数据，减少业务损失。

分布式数据库在面向备份恢复场景中，有几方面的挑战：

1. 数据存储普遍比较大，传统的单机备份模式受限于单机 IO，备份速度是一个重大挑战。比如一个 100TB 的数据库，传统单机 MySQL 是 300MB/s 备份速度，差不多需要 100 个小时，需要通过分布式多机备份提升性能

2. 数据备份的一致性，分布式数据库天然物理多节点分布，基于分布式的一致性快照做备份是基本诉求。传统基于分布式事务的 SELECT 查询获取一致性快照，采用逻辑数据导出的方式性能瓶颈比较明显，差不多是百 MB/s，需要通过物理备份提升性能

PolarDB-X V2.2.0 中采用了分布式多机+物理备份的方式，提供了强一致备份恢复的能力。 PolarDB-X 是基于 MySQL 的原生分布式数据库，底下数据存储格式和 MySQL 接近，因此我们选择基于 Pecona XtraBuckup 定制实现 PolarDB-X 的物理备份，多个 DN 节点并行进行物理备份恢复，结合备份一致性算法处理分布式事务在物理备份过程中的差异数据。

详情可以参考文档：

1. PolarDB-X Buckup工具 (基于XtraBuckup改造而来)
   

2. PolarDB-X 是如何拯救误删数据的你（二）：备份恢复
   

参数模板

PolarDB-X 参考公有云数据库的最佳实践，提供了参数模板的管理能力，包括参数模板的创建、变更、批量应用等，可以有效帮助大家更好的管理在线数据库。

常见的参数模板，一般分为高安全模式和高性能模式，可以方便大家在数据库 POC 和生产参数之间做好差异化管理。

详情可以参考文档：

1. 参数模版
   

容灾部署

PolarDB-X Operator 结合 K8S POD 的调度能力，推出基于 k8s selectors 的集群部署规则。

首先，定义机房 selector

selectors:  - name: zone-a    nodeSelector:      nodeSelectorTerms:      - matchExpressions:        - key: topology.kubernetes.io/zone          operator: In          values:          - cn-hangzhou-a	- name: zone-b    nodeSelector:      nodeSelectorTerms:      - matchExpressions:        - key: topology.kubernetes.io/zone          operator: In          values:          - cn-hangzhou-b	- name: zone-c    nodeSelector:      nodeSelectorTerms:      - matchExpressions:        - key: topology.kubernetes.io/zone          operator: In          values:          - cn-hangzhou-c

最后，定义集群部署规则 (每个机房均匀部署)

// 计算节点在A/B/C机房内均匀分布cn:  - name: zone-a    replicas: 1 / 3    selector:      reference: zone-a  - name: zone-b    replicas: 1 / 3    selector:      reference: zone-b  - name: zone-c    replicas: 1 / 3    selector:      reference: zone-c
// 存储节点的三副本分别部署在A/B/C机房dn:  nodeSets:  - name: cand-zone-a    role: Candidate    replicas: 1    selector:      reference: zone-a  - name: cand-zone-b    role: Candidate    replicas: 1    selector:      reference: zone-b  - name: log-zone-c    role: Voter    replicas: 1    selector:      reference: zone-c

基于 k8s 灵活的 yaml 配置，大家可以发挥下想象空间：

1. 同城 3 机房下，如何定义部署为 5 副本

2. 两地三中心，如何定义部署，3 副本 or 5 副本

3. 三地五中心，如何定义部署

详情可以参考文档：

1. 集群拓扑规则-容灾部署
   

2. 配置参数定义
   

更多更详细的文档，可以参考：PolarDB-X Operator运维指南

08 全面的性能优化和提升

PolarDB-X 作为一款分布式数据库，除了企业级特性外，数据库的整体性能也一直是重要的演进方向，常规的 benchmark 场景优化，比如：RPC 协议优化、分布式事务 1PC 优化等。

更小的起步规格

分布式数据库因为天生分布式多组件，导致起步的规格配置要求比较高，业务在发展初期并不需要 16core64GB 以上的大规格，更多还是在公有云主流的 2core/4core/8core 规格，在降本增效的大环境下，分布式数据库也需要贴合业务诉求，支持可小可大，实现更极致的线性扩展性。

目前 PolarDB-X 的最小起步规格情况：

1. 支持在一个 2c8g 的 ECS 节点中部署单机版的 PolarDB-X，包含完整的 GMS/CN/DN/CDC 组件，通过 quick start 的方式，方便大家快速体验分布式数据库的特性。

2. 支持单节点 2c8g 的起步规格，目前 PolarDB-X 在公有云上支持的最小规格，提供高可用能力，2c8g 的最小规格可以有效支撑 sysbench read_write 为 1 万+QPS、以及 TPC-C 2 万+的 tpmC 的，满足基本业务的诉求。

全方位的性能优化

分布式关系型数据库中，常见的 benchmark 主要是 sysbench 和 TPC-C，用来评价 OLTP 场景的基本能力，这类 benchmark 的典型特征是偏 TP 类的小查询为主，重点关注吞吐量，核心的优化思路是从代码简化、网络传输、以及事务优化等方向。

PolarDB-X V2.2.0 版本，在 OLTP 场景有 3 个核心优化：

1. RPC 协议优化，提升 CN 和 DN 之间的请求效率。主要在 DN 端实现基于原生 epoll 的网络执行框架，抛弃 MySQL 官方的 x-protocol 网络框架，在 1000+的高并发下，新版 RPC 在查询性能提升 60%以上

2. 分布式事务 1PC 优化，重点优化单分片读写场景下的事务优化。比如，sysbench、TPC-C 场景里有 90%的比例都是单分片的读写操作，写入事务可以利用 XA ONE PHASE COMMIT 的 1PC 写入进行分布式事务优化，可以将传统 2PC 的 3 次 RTT，优化为 1 次 RTT。同时，针对简单主键的点查场景，可以利用 HLC 混合逻辑时钟的思路，在单个 DN 节点维护一个本地化时间戳，查询仅读取一个 DN 分片时可以不主动获取全局时间戳 TSO，减少 1 次网络交互

3. 存储引擎 GCN 缓存优化，分布式事务获取 TSO 后会写入存储引擎的 GCN(Global Commit Number)，GCN 的写入和读取是一个高频操作，在新版本中增加 GCN 系统缓存最近提交(或访问)的 GCN 事务信息，可大大降低通过 UBA 访问持久化事务信息带来的时间和空间开销，提升系统性能。

初步测试的高并发情况：3 * 16C64G (CN)、3 * 16c128g (DN)

除此之外，也在面向业务场景上做了更多能力上的提升，比如：冷数据归档的数据分析、以及数据跑批的并行 DML、大事务优化等，因为篇幅的关系不再详述，欢迎大家交流。

更实时的 CDC 能力

PolarDB-X CDC 组件，主要提供全局 binlog 的相关能力，基于 CDC 可以实现 PolarDB-X 与 MySQL 之间构建 MySQl replication 复制协议，同时兼容市面上流行的 binlog 解析工具，比如 canal/flink cdc/maxwell 等。

CDC 的增量日志，比较重要的指标就是增量延迟 (数据写入数据库到下游拿到该记录的变更，对应的时间差称之增量延迟)，分布式数据库下需要考虑高并发下的增量延迟数据。

PolarDB-X V2.2.0 中，在 CDC 同步性能实现翻倍，最大 EPS 能力从 100w/s 提升至 200w/s，最大写入吞吐能力从 250M/s 提升至 500M/s，核心性能指标如下（参考：PolarDB-X 全局Binlog解读之性能篇）：

总结，CDC 在 16 核的规格下，可以支持 100 万 tpmC、sysbench oltp_write_only 场景 qps 30 万、以及 GB 级大事务，满足增量延迟<1 秒，可以满足绝大部分的业务诉求。未来，PolarDB-X 也会支持 binlog 多流，实现更大千万级别规模的线性扩展。

结尾

PolarDB-X 是由阿里自主研发的原生 MySQL 分布式数据库，坚持以全内核开源的方式，保持开源的持续迭代。本次重磅发布 V2.2.0 版本，是一个重要的里程碑，重点推出符合分布式数据库金融标准下的企业级和国产化适配的产品能力，期望 PolarDB-X 未来能作为国内原生 MySQL 分布式数据库的开源领导者，持续做好开源！