关于mysql:云栖大会开源重磅升级PolarDBX-v22-企业级和国产化适配

9次阅读

共计 15074 个字符，预计需要花费 38 分钟才能阅读完成。

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 分布式数据库在金融、通信、政务等行业的普适性。

目前市场上对于国产服务器的适配有比拟强的需要，常见的需要就是兼容 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

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

从测试后果看：

在强一致性读下，在 OLTP 读场景下流量从主实例切换到只读实例上吞吐的性能衰减 20～30%，然而通过增加只读实例个数，性能能够做到肯定的线性减少；

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

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

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 小时的长事务等。

# 存储过程 demo
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/docum…

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

相比于目前绝大部分的 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 齐全兼容

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

传统的数据库审计，个别采纳网络旁路的形式，通过外置组件集中收集所有网络流量，从中采集到对应的 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

删库跑路事件不常有，但因大意导致的误删数据却不足为奇，比方手误执行了一个谬误的 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 返回的正确值对数据进行了勘误。

分布式数据库中，数据须要依照肯定的策略散布到多个节点中，对数据的可管理性是数据库的一个重要能力维度，在保障数据库线性程度扩大下，基于数据管理来达到业务的诉求。

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

交易和日志类业务，有依照工夫维度的归档属性，冀望数据一级分区依照用户做 hash 散布，二级分区依照 range 做工夫滚动
多租户的业务场景，比方政务零碎的省地市业务，冀望一张表的数据依照 list 做散布，同时指定分区相互隔离，每个分区独自调配一个存储节点
冷热数据拆散的场景，比方近期写入的属于热数据，优先搁置在 SSD 盘的节点中，将历史数据动静调度到 HDD 盘的节点中，历史数据能够做肯定的压缩，从而升高存储老本
PolarDB-X 在 V2.2.0 版本中，进一步加强了分区表的治理能力以及基于 Locality 的调度。

传统的数据分区策略，个别仅在数据表第一次创立时定义了散布规定，预先的分区新增、批改、删除个别不反对数据搬迁。PolarDB- X 在分区表的变更能力上，在满足分布式数据不均衡性上做了更多灵便的变更治理。

比方一张表 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 的数据分区不须要挪动

在 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);

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

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

更多内容能够参考文档：

表级分区变更语法
PolarDB-X 热点优化系列（二）：如何反对淘宝大卖家分区热点

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

1、database 对象，指定 locality 能够限度库下对应的表只散布在 dn=polardbx-dn-0000

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

table 对象，指定 loality 能够将不同的单表散布到不同的 DN 节点中

# 0 号 DN
CREATE TABLE tableA(a int) single locality = 'dn=polardbx-dn-0000';

# 1 号 DN
CREATE TABLE tableB(a int) single locality = 'dn=polardbx-dn-0001';

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: 冷热数据拆散存储

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

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

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

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

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

工具个性：

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

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 工具导入导出数据
如何优化数据导入导出

PolarDB-X Operator 是一个基于 Kubernetes 的 PolarDB-X 集群管控零碎，心愿能在原生 Kubernetes 上提供残缺的生命周期治理能力，满足用户的轻量化部署。

在 PolarDB-X V2.2.0 版本，咱们进一步欠缺了泛滥面向生产运维的企业级性能。

数据库通过备份复原来保障数据安全，用户在运维误操作、或删库跑路等重大故障的状况下，能够采纳备份集复原的形式来疾速复原业务数据，缩小业务损失。

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

数据存储广泛比拟大，传统的单机备份模式受限于单机 IO，备份速度是一个重大挑战。比方一个 100TB 的数据库，传统单机 MySQL 是 300MB/ s 备份速度，差不多须要 100 个小时，须要通过分布式多机备份晋升性能
数据备份的一致性，分布式数据库人造物理多节点散布，基于分布式的一致性快照做备份是根本诉求。传统基于分布式事务的 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/v1
kind: PolarDBXParameterTemplate
metadata:
  name: parameterTemplate
spec:
  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/v1
kind: PolarDBXCluster
metadata:
  name: pxc
spec:
  ...
  ...
  # 须要配置的参数模板
  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 配置，大家能够施展下设想空间：

同城 3 机房下，如何定义部署为 5 正本
两地三核心，如何定义部署，3 正本 or 5 正本
三地五核心，如何定义部署
详情能够参考文档：

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

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 个外围优化：

RPC 协定优化，晋升 CN 和 DN 之间的申请效率。次要在 DN 端实现基于原生 epoll 的网络执行框架，摈弃 MySQL 官网的 x -protocol 网络框架，在 1000+ 的高并发下，新版 RPC 在查问性能晋升 60% 以上
分布式事务 1PC 优化，重点优化单分片读写场景下的事务优化。比方，sysbench、TPC- C 场景里有 90% 的比例都是单分片的读写操作，写入事务能够利用 XA ONE PHASE COMMIT 的 1PC 写入进行分布式事务优化，能够将传统 2PC 的 3 次 RTT，优化为 1 次 RTT。同时，针对简略主键的点查场景，能够利用 HLC 混合逻辑时钟的思路，在单个 DN 节点保护一个本地化工夫戳，查问仅读取一个 DN 分片时能够不被动获取全局工夫戳 TSO，缩小 1 次网络交互
存储引擎 GCN 缓存优化，分布式事务获取 TSO 后会写入存储引擎的 GCN(Global Commit Number)，GCN 的写入和读取是一个高频操作，在新版本中减少 GCN 零碎缓存最近提交 (或拜访) 的 GCN 事务信息，可大大降低通过 UBA 拜访长久化事务信息带来的工夫和空间开销，晋升零碎性能。
初步测试的高并发状况：3 16C64G (CN)、3 16c128g (DN)

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

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 分布式数据库的开源领导者，继续做好开源！

正文完

mysql

发表至： mysql

2022-11-04

0

关于mysql:MySQL的账户设置

关于mysql:面试官说道小伙子耗子尾汁查询SQL的执行流程难道都不知道吗

关于mysql:mysqlsql优化原则

关于mysql:msyql-触发器

关于负载均衡:赋能信息技术应用创新需要怎样的可持续性业务架构

关于mysql:云栖大会开源重磅升级PolarDBX-v22-企业级和国产化适配

架构简介

版本阐明

01 国产 ARM 适配

02 全新读写拆散架构

强统一读写拆散

HTAP 混合负载

03 MySQL 生态兼容性

存储过程

Auto Increment 自增束缚

04 数据库安全

全量 SQL 审计

Flashback Query

05 分布式数据管理

分区表治理

1. hash/key 分区决裂

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

3. 分区迁徙

Locality 调度

冷热数据拆散

06 开源相干配套工具

polardbx-backup

benchmark-boot

batch-tool

导出办法比照

导入办法比照

07 轻量化部署和运维

强统一备份复原

参数模板

容灾部署

08 全面的性能优化和晋升

更小的起步规格

全方位的性能优化

更实时的 CDC 能力

结尾

站内搜索