架构简介
PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由5个核心组件组成。
PolarDB-X 架构
- 计算节点（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)
列存节点负责提供列式存储数据，基于行列混存 + 分布式计算节点构建HTAP架构，预计在今年底或者明年初会正式开源
开源地址：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面向数据库生产环境的易用性和安全性，比如：提供数据快速导入、性能测试验证、生产部署建议等。
01 内核的稳定性和高性能
PolarDB-X 2.2.1版本，重点面向生产级的部署要求，优化数据库实例的稳定性和性能、以及提供面向生产部署的相关最佳实践。
1.最低部署规格 (建议>=2c8g)
GMS 和 DN 2.5 倍资源说明：GMS 和 DN 是基于多数派 Paxos 协议构建的高可靠存储服务，因此一个 GMS（DN）会包括三个角色的节点：Leader，Follower，Logger。 Leader 与 Follower 资源要求相同，保证高可用切换后的服务质量，而 Logger 节点，只存储日志，不回放日志，固定为2核4GB的资源规格，即可满足常见百万级TPS的需求。因此一个 GMS（DN）需要 2.5 倍的资源，其中 2 是 Leader 和 Follower的资源，0.5 是 Logger的资源。
可以参考文档：PolarDB-X 服务器推荐配置
2.在线/离线安装部署
PolarDB-X 2.2.1在面向很多线下用户POC测试，受限于现场网络条件，需要提供离线部署安装的能力，比如：从3台裸机开始，从0到1安装PolarDB-X。PolarDB-X提供了一键下载离线安装包的能力，
可参考文档：PolarDB-X 软件包下载
# 下载 x86_64 架构的 PXD 离线安装包
pxd download -env pxd -arch amd64 -repo "registry:5000" -dest ~/ -i images.list
# 下载 x86_64 架构的 PXD 离线安装包
pxd download -env pxd -arch amd64 -repo "registry:5000" -dest ~/ -i images.list
# 下载 ARM64 架构的 PXD 离线安装包
pxd download -env pxd -arch arm64 -repo "registry:5000" -dest ~/ -i images.list
# 下载 x86_64 架构的 K8s 离线安装包
pxd download -env k8s -arch amd64 -repo "registry:5000" -dest ~/ -i images.list
# 下载 ARM64 架构的 K8s 离线安装包
pxd download -env k8s -arch arm64 -repo "registry:5000" -dest ~/ -i images.list同时，结合生产部署稳定性的要求，提供一份系统与环境配置，包含系统OS参数、磁盘配置等，可参考文档：PolarDB-X 系统与环境配置
3.性能全面提升
PolarDB-X 2.2.1在公有云上选择了标准ECS进行了性能测试和摸底，相比于2.2.0版本结合多方面的优化，有了明显的性能提升。
测试资源：
sysbench测试：
TPC-C测试：
可参考性能白皮书：
4.分布式1024节点
PolarDB-X 分布式数据库中最重要的特性就是线性扩展，目前市面上也有众多分布式数据库号称超大规模的线性扩展，但理论和实践还是需要相结合，通过面向用户可验证的方式，来体验下PolarDB-X在分布式1024节点下的稳定性。
PolarDB-X提供了基于k8s生态构建的 polardbx-operator 组件，基于k8s的分布式容器技术可以快速构建PolarDB-X 1024节点，考虑用户的体验成本，采用了虚拟化的压缩部署方式，选择在24台ECS主机上完成分布式1024超大规格节点的部署，并通过近百万级别TPS的稳定性验证。
PolarDB-X 1024节点主机资源
说明：
- PolarDB-X采用存储计算分离的架构，CN和DN是可以独立部署，实验设计部署1024个DN节点，比如公有云PolarDB-X单个DN节点可支持3TB，那超大规模节点下可支持 1024 * 3TB = 3PB
- DN节点选择了最小的1C8GB (1024节点下也需要8TB的内存)，通过k8s的多租户cgroup技术，采用24台高配ECS进行部署，单个ECS平均需要承载40+的PolarDB-X CN/DN节点。
- 本实验所需要的测试资源的成本，24台ECS按量付费 288元/小时，测试时间1天左右，预计花费7000元。
参考文档：分布式1024节点！1天玩转PolarDB-X超大规模集群
02 分布式CDC架构升级
Binlog是MySQL记录变更数据的二进制日志，它可以看做是一个消息队列，队列中按顺序保存了MySQL中详细的增量变更信息，通过消费队列中的变更条目，下游系统或工具实现了与MySQL的实时数据同步，此机制也称为CDC（Change Data Capture，增量数据捕捉）
PolarDB-X是兼容MySQL生态的分布式数据库。通过实例内PolarDB-X的CDC组件，能够提供与MySQL binlog格式兼容的变更日志，并且对外隐藏了实例扩缩容、分布式事务、全局索引等分布式特性，让您获得与单机MySQL数据库一致的使用体验。
PolarDB-X 2.2.1版本后，提供了两种形态的binlog日志消费订阅能力，且两种形态可同时共存。
- 单流形态：即单流binlog日志（也称为Global binlog），将所有DN的binlog归并到同一个全局队列，提供了保证事务完整性和有序性的日志流，可以提供更高强度的数据一致性保证。例如在转账场景下，基于Global binlog接入PolarDB-X的下游MySQL，可以在任何时刻查询到一致的余额。
- 多流形态：即多流binlog日志（也称为Binlog-X），并不是将所有DN的binlog归并到一个全局队列，而是将数据进行Hash打散并分发到不同的日志流，在一定程度上牺牲了事务的完整性，但大大提升了扩展性，可以解决大规模集群下单流binlog存在的单点瓶颈问题。
CDC 单流形态：
PolarDB-X CDC单流形态
CDC 多流形态：
PolarDB-X CDC多流形态
多流binlog提供了3种形式的数据拆分级别，在开通多流服务时可进行设定，满足不同场景下的使用需求。
库级别按照数据库的名字计算Hash值并进行分发，即对应同一个库的binlog数据，会始终按序路由给同一个binlog数据流，适用于单个PolarDB-X实例上数据库比较多的场景，如果事务不涉及跨库操作，该策略下不仅可以具备多流能力，还可以保证事务的完整性。
表级别按照数据表的名字计算Hash值并进行分发，即对应同一张表的binlog数据，会始终按序路由给同一个binlog数据流，适用于表的数量较多且希望针对单张表的操作（如DML、DDL等）在binlog日志流中保持有序的场景。
记录级别按照数据行的主键计算Hash值并进行分发，即对应同一数据行的binlog数据，会始终按序路由给同一个binlog数据流，适用于希望将数据充分打散且不要求日志数据按库或按表保持有序的场景，该策略要求数据表必须含有主键，无主键表的数据会被直接丢弃。
使用例子：
# 查看binlog多流stream列表
SHOW BINARY STREAMS;
返回例子：
+--------+-----------------+-------------------------------+----------+
| GROUP | STREAM | FILE | POSITION |
+--------+-----------------+-------------------------------+----------+
| group1 | group1_stream_0 | group1_stream_0#binlog.000001 | 3625148 |
| group1 | group1_stream_1 | group1_stream_1#binlog.000001 | 3625148 |
| group1 | group1_stream_2 | group1_stream_2#binlog.000001 | 3625148 |
| group1 | group1_stream_3 | group1_stream_3#binlog.000001 | 3625148 |
+--------+-----------------+-------------------------------+----------+MySQL相关指令体验：
#不加WITH子句，可查看单流服务的global binlog文件列表。
# 添加WITH子句，可查看多流服务的某个流下面的binlog文件列表。参数stream_name表示某个流的名称
SHOW MASTER STATUS [WITH stream_name]
SHOW BINLOG EVENTS [WITH stream_name]
SHOW BINARY LOGS [WITH stream_name];
## 单流返回的例子
+---------------+-----------+
| LOG_NAME | FILE_SIZE |
+---------------+-----------+
| binlog.000001 | 4 |
+---------------+-----------+
## 多流返回的例子
+-------------------------------+-----------+
| LOG_NAME | FILE_SIZE |
+-------------------------------+-----------+
| group1_stream_0#binlog.000001 | 3626808 |
+-------------------------------+-----------+PolarDB-X CDC引入多流形态，可以在满足binlog兼容性的同时，结合业务场景提升分布式增量日志变更的吞吐量。同时CDC多流形态，为了更好的兼容现有binlog开源生态，联合alibaba canal提供了多流兼容消费的能力，参考PR：add support for polardbx multi binlog streams #4660
canal使用例子：
# canal一键拉起PolarDB-X的多流binlog
sh run.sh -e canal.auto.scan=false
-e canal.instance.master.address=pxc-xxxx.polarx.xxxx.rds.aliyuncs.com:3306
-e canal.instance.dbUsername=tpcc
-e canal.instance.dbPassword=xxxx
-e canal.instance.connectionCharset=UTF-8
-e canal.instance.tsdb.enable=true
-e canal.instance.gtidon=false
-e canal.instance.multi.stream.on=false
-e canal.destinations.expr=group1_stream_{0-7}参考文档：
- CDC单流性能解读，Sysbench 30w QPS / TPC-C 100w tpmC下，增量数据延迟时间 < 1秒
- CDC高可用架构解读，可以在各种故障形态下，满足RTO在20~45秒内
- CDC多流形态，以及 如何创建CDC节点
03 基于时间点的恢复(point-in-time recovery, PITR)
PolarDB-X 2.2.0的版本中，我们正式提供了静态的全量备份集恢复能力，通过 PolarDB-X Buckup工具 (基于XtraBuckup改造而来) ，我们基于DN的物理备份的方式，结合分布式并行提升备份吞吐量，备份速度可达到GB/s，同时提供了分布式下的一致备份集。
在阿里云数据库服务用户过程中，经常会遇到用户误删数据后期望通过备份恢复的方式找回数据，对于基于时间点的恢复有比较强的诉求。因此，PolarDB-X 2.2.1开源版本中，我们提供了日志增量备份 + 基于时间点的恢复的完整能力，满足用户数据库安全性的需求。
大致的工作原理：
PolarDB-X 指定时间点恢复的工作原理图
说明：
全量备份集，指定调度规则进行定期全量备份，参考文档：PolarDB-X 备份调度
0 2 * * 1,4 周一和周四的2点发起备份- 增量日志备份，准实时备份增量的日志数据，备份的实时性决定了数据可恢复的最近时间点，参考文档：PolarDB-X 增量日志备份。
- 发起指定时间点恢复(PITR)，找到恢复时间点最近的一个全量备份集，再从增量备份中找到全量备份集时间点和恢复时间点之间的增量日志，执行一个全量+增量的物理恢复，参考文档：PolarDB-X 指定时间点恢复
使用的例子：
apiVersion: polardbx.aliyun.com/v1
kind: PolarDBXCluster
metadata:
name: polardb-x-clone # 恢复出的集群名字
spec:
topology: # 集群规格
nodes:
cn:
template:
image: polardbx/polardbx-sql:latest
dn:
template:
image: polardbx/polardbx-engine:latest
restore: # 指定集群的创建方式是恢复
from:
clusterName: polardb-x # 源PolarDB-X 集群名称
time: "2023-03-24T11:11:11Z" # 恢复的时间点04 MySQL一键导入PolarDB-X
开源MySQL的主备复制协议，主要支持增量日志的同步和消费，在MySQL 8.0开始在内核中新增了Clone Plugin，全量通过物理文件拷贝，结合增量日志的同步和消费提供了clone实例的效果。
PolarDB-X作为分布式数据库，在物理数据分布和文件格式上和开源MySQL略有差异，为了方便用户体验类似MySQL 8.0的Clone Plugin的效果，PolarDB-X 2.2.1提供了类似Clone Plugin的一键导入能力，通过一条DDL指令，可以对存量MySQL进行表结构迁移、存量数据的全量迁移，最后保持一个持续的增量数据同步
工作原理：
PolarDB-X 一键导入工作原理
使用例子：
// 配置MySQL与PolarDB-X的复制关系
CHANGE MASTER TO
MASTER_HOST='10.0.0.1',
MASTER_USER='root',
MASTER_PASSWORD='xxxxxx',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql_bin.000001',
MASTER_LOG_POS='58050130',
SOURCE_HOST_TYPE=mysql,
Mode='IMAGE'; // 指定mode为image镜像复制模式
// 设置需要同步的库表，不配置就是默认整个实例
CHANGE REPLICATION FILTER REPLICATE_DO_DB=(tpcc);
// 开启任务
START SLAVE;
// 查看任务
SHOW SLAVE STATUS \G整个操作体验，最大化的兼容了MySQL DBA的运维体验，基于常见的主备复制管理方式可以很方便的实现单机MySQL到PolarDB-X分布式的一键迁移，如果考虑数据割接后的回滚链路，可以反向配置PolarDB-X到MySQL的主备复制链路。
参考文档：PolarDB-X 一键导入
更详细的ChangeLog
PolarDB-X 各组件的开源地址，欢迎访问github
结尾
PolarDB-X 是由阿里自主研发的原生MySQL分布式数据库，坚持以全内核开源的方式，保持开源的持续迭代。本次发布V2.2.1的升级版本，重点加强了生产级关键能力，全面提升PolarDB-X面向数据库生产环境的易用性和安全性。期望PolarDB-X未来能作为国内原生MySQL分布式数据库的开源领导者，持续做好开源！
本文为阿里云原创内容，未经允许不得转载。