PolarDB-X内核新版本：将MySQL进行到底

1. 概览

在过去的3个月中，我们发布上线了冷热数据分离存储等功能。今天很高兴和大家交流PolarDB-X最新的内核版本5.4.15。在最新版本中，提供诸多新的功能：存储过程，读写分离优化，表级分区管理，密码、审计优化等。

除此之外，在这一版本中相较于前序版本也有了长足的进步，修复了 15个 Issues，并融入了26个增强特性。我们会不断地将新版本的功能，开放同步到开源社区。

另外，我们将在近期推出PolarDB-X标准版，满足小规模部署要求，降低分布式数据库的使用门槛，未来更加顺滑的过度到分布式数据库，欢迎大家到公共云进行使用。

2. MySQL生态

PolarDB-X坚持MySQL生态，在内核新版本中支持存储过程功能。

2.1 存储过程

在实现某些需求时，需要编写一组复杂的SQL语句才能实现的时候，很多资深数据库用户习惯使用存储过程。很显然存储过程能带来如下好处：

1. 复用性高。存储过程可以重复使用，从而减少数据库开发人员的工作量，同时降低业务出错概率。
2. 效率高。存储过程编译一次后，就会存到数据库，每次调用时都直接执行。
3. 降低网络流量。存储过程编译好会放在数据库，我们在远程调用时，不会传输大量的字符串类型的SQL语句。
4. 安全性高。完成某个特定功能的存储过程一般只有特定的用户可以使用，具有使用身份限制，更安全。

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

1. 可移植性差。
2. 如果使用大量的存储过程，使用这些存储过程的每个连接的内存使用量将大大增加。

在PolarDB-X中我们对内存进行了严格管理。

原理简介

存储过程会被持久化到Meta center中，按需加载到计算节点中执行，SQL相关的执行逻辑会发送到SQL engine中执行，然后获取执行结果，存储过程的控制流程等相关的逻辑会在PL engine中执行。

存储过程在真正执行前会注册到运行时存储过程管理中心，同时整个执行过程中存储过程所占用的内存大小会被严格限制。

存储过程内存管理

存储过程执行过程中的内存占用主要为缓存的cursor，因此我们对单个cursor所能使用的最大内存以及整个存储过程在执行时占用的内存进行了限制，由两个参数控制，PL_CURSOR_MEMORY_LIMIT和PL_MEMORY_LIMIT。

其中，变量PL_CURSOR_MEMORY_LIMIT用于控制每个Cursor所占用的内存，超过该阈值时会spill到硬盘中；变量PL_MEMORY_LIMIT用于控制每个存储过程所能使用的最大内存。

3. 易用性优化3.1 读写分离优化

PolarDB-X配置了多种读写策略，提供了透明的强一致的读写分离能力。其特点有：

• 无论什么状况都不用担心误写了“备副本或只读副本”，因为它不支持写，写操作会被路由到主副本；
• 无论什么时候不用担心“备副本或只读副本”故障，因为它会自动路由给其他正常的副本或者切回主副本；
• 无论什么场景不用担心 “备副本或只读副本”读不到最新的数据，因为它提供的是强一致的读写能力；
• 大查询不用担心打爆“主副本”，因为它支持将大查询路由给”备副本或只读副本“，避免对主副本造成压力。

PolarDB-X会基于CTS+Log 在主副本和只读副本间做一致性复制，基于CTS+TSO确保在只读副本上读到已经提交的最新数据。在一致性读的能力上，配置了规则读写分离和智能读写分离的能力，业务可以更加透明的使用。

强一致性读

RW节点会维护好自身MAX CTS（全局一致性日志位点），RO节点通过日志回放，也会不断更新当前自身的CTS。路由到RO节点的强一致性读查询过程如下：

1. 客户端把请求发送到计算节点；
2. 计算节点识别到请求会发送给RO，首先会从RW节点获取当前最大CTS；
3. 计算节点把CTS /TSO /请求一起发送给RO；
4. RO节点根据接收到的CTS判断是否等到RO节点事务状态回放到相应位点；根据TSO判断数据可见性，给CN返回结果。

规则读写分离

用户不需自己做业务改造，去支持读写分离场景。PolarDB-X支持业务透明使用读写分离能力，用户只需要配置读写分离权重，内核自己会将部分读请求发送给主副本，部分读请求发送给只读副本。此外其相比于传统的读写分离，还有如下优势：

• 如果存在多个只读副本，会把请求调度到延迟更低的只读副本上；
• 支持只读副本异常或者延迟过大，自动将流量切回主副本。

智能读写分离

PolarDB-X 提供的只读实例具有MPP查询加速的能力，在内核上我们提供了基于查询代价智能识别工作负载。将AP类查询转发给只读实例计算层CN，在只读实例CN上做MPP查询后，将结果返回给主实例CN。这类读写分离主要针对于混合负载场景。

3.2 表级分区精细化管理

在数据库使用过程中，原来预想的数据分区和实际的数据分布不匹配，导致数据分布不均匀，或者需要进行迁移，那么如何进行调整呢。

分区分裂

当一个分区数据出现倾斜的时候，可以将表的一个分区分裂成多个分区。

原表定义将数据分成P1和P2

CREATE TABLE Table1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(100))

那么我们可以通过以下SQL将P1分裂成P10,P11,P12

ALTER TABLE Table1 SPLIT PARTITION p1 INTO (PARTITION p10 VALUES LESS THAN (8), PARTITION p11 VALUES LESS THAN(15), PARTITION p12 VALUES LESS THAN(20))

分区合并

将多个分区（两个或者两个以上）合并成一个分区。

对于Hash/Key/Range/Range column分区，只能将相邻的分区合并，对于List/List column分区，可以将任意分区合并在一起。

例如表tb1的定义如下：

CREATE TABLE tb1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(40), PARTITION p3 VALUES LESS THAN(100))

可以通过以下SQL将p1和p2合并：

ALTER TABLE tb1 MERGE PARTITIONS p1,p2 to p12

需要注意的是不能将不相邻的两个分区，例如p1和p3合并到一起。

分区迁移

将分区迁移到指定的存储节点

例如表tb1的定义如下：

CREATE TABLE tb1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(40), PARTITION p3 VALUES LESS THAN(100))

可以通过以下SQL将p1，p3迁移到指定的存储节点DN2（其中DN2是存储节点的ID）中

ALTER TABLE tb1 MOVE PARTITIONS p1,p3 to 'DN2'3.3 密码、审计优化

当前，对于数据库安全性要求越来越高，尤其在等保、合规方面，通常都会对密码复杂度、密码是否能定期修改、或者是否配置密码自动过期策略有严格要求。避免出现过于简单的密码或相同密码长期未修改被暴力破解，降低数据库的安全风险。

在新版本中新增支持了以下安全审计功能：

1、基于正则表达式规则来配置密码复杂度；(?=.*[0-9])(?=.*[A-Z])(?=.*[a-z]).{8,20}配置了密码必须包含大小写字母和数字，且长度在8~20个字符之间；

如果您采用了11位组合字符密码，那在现有技术条件下，需要400年才能破解。

2、为不同账户配置不同的密码自动过期策略。当系统时间到达指定日期时间（可精确到秒），对应账户将无法登录数据库。

注意，在开启密码自动过期策略后，用户需要定期检查密码是否即将过期，并及时进行修改，避免影响业务。

4. 展望

越来越多的业务需要弹性，灵活而有效的应对突发情况。如何快速适应业务形态的变化，对云原生分布式数据库提出了更高的要求。我们在细细打磨产品的深度上下功夫的同时，对于这种广度的延伸一致保持着敏锐的洞察。非常期待和大家一起，将分布式数据库对业务的覆盖广度更加延伸，我们将在近期推出PolarDB-X 标准版，满足分布式数据库小规模部署要求，敬请期待。