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 协定的主从复制能力。
    开源地址：[https://github.com/ApsaraDB/g...]

版本阐明

梳理下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(查看对应的二进制版本)

为了更简略的体验PolarDB-X的X86/ARM部署，通过阿里云提供ARM芯片架构的ECS服务器，云起实验室体验地址：如何在ARM平台部署 PolarDB-X

02 全新读写拆散架构

MySQL生态里读写拆散是一种比拟常见的技术，除了用于解决写少读多场景的优化，也常常用于OLTP/OLAP业务隔离的典型场景，比方思考在线数据库的稳定性，通过读写拆散将个别简单查问发送给MySQL的备库。

传统MySQL的读写拆散：

存在的问题：

须要有额定的Proxy组件 或者 业务代码路由，实现可控的读写拆散路由
备库读存在数据一致性问题，比方申请A在主库实现写入，而后立马到备库读数据因为复制提早，可能读不到刚写入的数据
须要额定的OLAP的列存数据 + 外置的复制同步(比方类canal的眼帘)，反对更简单的报表查问
PolarDB-X的读写拆散架构：

计算节点(CN)承担读写拆散的路由组件，无需引入额定组件，多个CN节点需配置一个负载平衡设施(比方LVS)
提供全局一致性读，在读写拆散路由到备库上的申请，保障业务写后读的数据一致性，提供更易用的读写拆散能力
提供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节点规格：216C128G，DN节点规格：RW主实例 24C32G、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版本里，提供了如下能力：

资源隔离，基于Paxos多正本 + 读写拆散，实现在线业务和数据分析业务的物理隔离
MPP并行计算，联合读写拆散架构，针对路由到只读节点的申请，默认采纳MPP并行查问打算，晋升查问性能
列存能力，以后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，但在性能兼容、生态兼容上还是有蛮多的差异性，带来了应用上的复杂性。

举几个例子：

MySQL的事务隔离级别，广泛采纳的是RC/RR，在事务模型上有其独特的中央，比方MySQL update v=v+1是一个典型的乐观事务模型，区别于Google Percolator的乐观事务模型。另外，MySQL罕用的select for update用法，是一个典型的B+Ttree下GAP锁场景，目前市面上NewSQL基于LSM-Tree架构的简直没有兼容该个性。
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小时的长事务等。

#存储过程 demoCREATE 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/docum...

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视频：两分钟演示PolarDB-X与MySQL兼容的auto_increment694

具体详情能够参见：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/oper...

SQL日志格局：https://doc.polardbx.com/operat

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的数据分区不须要挪动

2. 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);

3. 分区迁徙

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

ALTER TABLE orders MOVE PARTITIONS p_hot88 to 'DN_VIP88';
除了例子中的hash分区外，range/list等分区均反对相似的决裂、合并、迁徙、重命名等治理。

更多内容能够参考文档：

表级分区变更语法
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调度，能够有如下的设想空间：

DBA部署了PolarDB-X，对应服务器有SSD或者HDD的硬盘，通过定义分区locality，能够将不同的数据分区进行无效的老本化治理。比方依照range分区，将历史数据定期设置locality。
DBA在阿里云环境上部署了PolarDB-X，并且开启了OSS对象存储，能够通过PolarDB-X自带的数据归档能力，通过TTL(Time-To-Live)分区能力，主动将数据归档到OSS存储中。
更多内容能够参考文档：

通过LOCALITY指定存储地位
PolarDB-X On OSS QuickStart
PolarDB-X on OSS: 冷热数据拆散存储

06 开源相干配套工具

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

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

polardbx-backup

PolarDB-X Operator中提供了强统一的备份复原，外部最重要的就是backup工具。咱们抉择基于Pecona XtraBackup源码根底上，扩大了分布式数据库的局部个性：

兼容自研存储引擎Lizard，扩大了InnoDB的数据格式，减少了SCN/GCN的扩展槽位
兼容分布式事务日志，比方XA的prepare/commit事件、以及timestamp事件等
分布式一致性日志裁剪，多个物理文件因备份实现工夫有差别，须要拉齐多个物理文件之间的事务一致性
更多详情，能够参考开源代码：https://github.com/ApsaraDB/p...

benchmark-boot

PolarDB-X 提供了一款白屏化的数据库压测工具，交融了常见的sysbench、TPC-C、TPC-H的压测脚本，能够帮忙大家疾速实现数据库的性能测试。

工具个性：

提供内置benchmark压测脚本，并调整bechmark的最佳参数，比方sysbench/TPC-C/TPC-H
提供白屏化能力，反对一键装置、压测、日志、监控展现等
提供数据库的常见调优能力，比方参数治理、执行打算hint等
更多详情，能够参考文档：应用Benchmark Boot进行压测

batch-tool

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

导出办法比照

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

导入办法比照

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

数据导入导出工具小结：

mysql -e/source/mysqldump，这类原生工具的原理上次要是单线程操作，性能差距不显著。比方，数据导入实际上是发送了Batch Insert语句，Batch size大小会影响导入性能，能够通过设置"net-buffer-length"参数进行调优，个别倡议该参数不超过256K。
load data语句尽管是单线程操作，但优化了数据文本的编码格局，性能优于mysql命令和source语句
PolarDB-X原生的batch-tool工具反对多线程导入，且贴合PolarDB-X分布式多分片的操作形式，性能打到了最优
更多详情，能够参考文档：

应用Batch Tool工具导入导出数据
如何优化数据导入导出

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 XtraBackup定制实现PolarDB-X的物理备份，多个DN节点并行进行物理备份复原，联合备份一致性算法解决分布式事务在物理备份过程中的差别数据。

详情能够参考文档：

PolarDB-X Backup工具 (基于XtraBackup革新而来)
PolarDB-X 是如何援救误删数据的你（二）：备份复原

参数模板

PolarDB-X 参考私有云数据库的最佳实际，提供了参数模板的治理能力，包含参数模板的创立、变更、批量利用等，能够无效帮忙大家更好的治理在线数据库。

常见的参数模板，个别分为高平安模式和高性能模式，能够不便大家在数据库POC和生产参数之间做好差异化治理。

创立参数模版 (kubectl apply -f {参数模板文件名称}.yaml)

## 参数模板示例apiVersion: polardbx.aliyun.com/v1kind: PolarDBXParameterTemplatemetadata:  name: parameterTemplatespec:  nodeType:    cn:      # 参数列表      paramList:        - name: CONN_POOL_BLOCK_TIMEOUT          defaultValue: "5000"          mode: read-write          restart: false          unit: INT          divisibilityFactor: 1          optional: "[1000-60000]"        - ...    dn:      name: dnTemplate      paramList:        - name: innodb_use_native_aio          defaultValue: "OFF"          mode: readonly          restart: false          unit: STRING          divisibilityFactor: 0          optional: "[ON|OFF]"        - ...    gms: ...

应用参数模板 (PolarDBXCluster的yaml文件)

# 应用参数模板apiVersion: polardbx.aliyun.com/v1kind: PolarDBXClustermetadata:  name: pxcspec:  ...  ...  # 须要配置的参数模板  parameterTemplate:    name: parameterTemplate

详情能够参考文档：

参数模版使用指南
MySQL 8.0举荐参数模板

容灾部署

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. 三地五核心，如何定义部署
    详情能够参考文档：

集群拓扑规定-容灾部署
配置参数定义
更多更具体的文档，能够参考：PolarDB-X Operator运维指南

08 全面的性能优化和晋升

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

更小的起步规格

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

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

反对在一个2c8g的ECS节点中部署单机版的PolarDB-X，蕴含残缺的GMS/CN/DN/CDC组件，通过quick start的形式，不便大家疾速体验分布式数据库的个性。
反对单节点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万，满足增量提早<1秒，同时对大事务也做了磁盘swap的兼容解决，能够反对20GB的大事务机制，满足绝大部分的业务诉求。将来，PolarDB-X也会反对binlog多流，实现更大千万级别规模的线性扩大。

结尾

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