KlustronDB 系统架构
KlustronDB 系统架构
01 前言
KlustronDB 分布式关系数据库管理系统(RDBMS)，面向 TB 和 PB 级别海量数据存储管理和分析利用，以高吞吐量和低延时的极致性能支撑海量数据高并发读写请求。
应用软件开发者按照使用单节点关系数据库相同的方法使用KlustronDB，完全不需要考虑数据的分区方式等存储细节，快速的开发健壮可靠的，高可用和高可扩展的信息系统。
KlustronDB 集群多组件协作提供健壮的事务 ACID 保障，高效易用的分布式查询处理，高可扩展性，高可用性和透明的分库分表数据处理功能，业务层和终端用户无感知的水平扩展能力。
02 架构介绍
一个 KlustronDB 集群有3类组件构成：若干个计算节点，若干个存储分片(storage shard)，一个元数据集群(metashard)，以及集群管理工具。
KlustronDB 的计算节点(KlustronDB-server) 负责接受应用软件端的连接请求，验证请求合法性后建立连接；以及从已经建立的连接中接受SQL查询请求，执行请求，然后后返回查询结果。
三个或者更多个存储节点组成一个存储分片(storage shard，简称shard)，每个shard 存储着一部分用户表或者表分区，不同shard的数据没有交集；Clustermgr和Metashard管理和服务若干个KlustronDB集群，Metashard存储这些集群的元数据。
KlustronDB集群极简部署
一个KlustronDB集群最少需要多少台服务器 ？ 这是新用户经常提出的问题。在下文介绍各类组件详细功能之前先回答这个问题。KlustronDB 集群的所有节点可以部署在一台或者多台服务器上面，不过为了最基本的高可用保障，推荐至少使用两台服务器， 了解更多集群部署指南。
单服务器部署方式
如果不需要高可用能力，那么最少只需要一台即可，部署方式见下表。为方便说明，服务器标记为A。这样部署的风险是如果这台服务器的磁盘坏了，那么KlustronDB数据库中的全部数据或者最新数据就可能丢失；只要服务器宕机，那么集群立刻停止服务。KlustronDB支持全量备份和实时流式增量备份，因此在启用了备份机制的情况下，可以使用全量备份数据加上实时增量备份数据，把数据库恢复到最新增量备份时间点，这通常是最新的数据更新之前几分钟。
| 组件 | 部署个数 | 部署架构 | 部署说明 |
|---|---|---|---|
| 计算节点 | 1 | 部署一个计算节点 | 部署在服务器A上面 |
| 存储节点 | 1 | 部署单主节点 | 部署在服务器A上面 |
| Storage Shard | 1 | 单主节点, 无备机，无高可用 | |
| MetaShard | 1 | 单主节点, 无备机，无高可用 | 部署在服务器A上面 |
| Cluster_mgr | 1 | 单主节点, 无备机，无高可用 | 部署在服务器A上面 |
| 其他附属组件 | 各1个 | 都部署到服务器A上面 |
两台服务器的部署方式
在支持高可用的情况下，最少需要2台服务器。为方便说明，两台服务器分别标记为A和B，按照下表部署。这种情况下一台服务器宕机，KlustronDB可以在另一台服务器上面继续提供服务。如果shard主节点故障，系统会自动把备机升级为主机继续提供服务，此时DBA应该及时修复旧的服务器并且启动运行以便KlustronDB把它当做备机。如果在新的主节点单独运行期间该节点也发生了故障，那么就没有更多备机可以升级为主节点了，因此集群将停止运行并且无备机运行期间发生的是磁盘故障的话还可能导致全部数据或者最新数据丢失（同上，启用备份机制时可以重建数据库从而仅丢失最新数据）。
| 组件 | 部署个数 | 部署架构 | 部署说明 |
|---|---|---|---|
| 计算节点 | 2 | 每台服务器部署一个计算节点 | 部署在服务器A，B上面 |
| 存储节点 | 2 | 部署1个主节点, 1个备节点 | 主备节点分别部署在服务器A，B上面 |
| Storage Shard | 1 | 1主1备，有高可用 | 主节点故障时KlustronDB自动选出新主节点，但是DBA要即时增加备机节点 |
| MetaShard | 1 | 1主1备，有高可用 | 主备节点分别部署在服务器A，B上面 |
| Cluster_mgr | 1 | 1主1备，有高可用 | 部署在服务器A，B上面 |
| 其他附属组件 | 各1个 | 每个组件部署到 A或者B均可 |
在较大规模的生产系统中，建议使用至少3台服务器或者更多服务器，参考更多部署方式和规格。
2.1 计算节点
KlustronDB 的计算节点(KlustronDB-server) 负责接受应用软件端的连接请求，验证请求合法性后建立连接；以及从已经建立的连接中接受SQL查询请求，执行请求，然后后返回查询结果。用户可以根据工作负载来增减计算节点，每个计算节点彼此平等和独立，没有依赖关系，都可以处理用户连接和读写请求。一个KlustronDB集群可以安装最多1023 个计算节点，应用软件系统可以连接KlustronDB集群的任何一个计算节点来读写数据，执行SQL语句。
连接示例
./psql -h192.168.12.34 -p23456 -Uabc kunlundb
./mysql -h192.168.12.34 -P23457 -uabc -pabc kunlundb
可以连接任何一个计算节点执行DDL语句，然后集群所有其他计算节点也会迅速复制执行此DDL从而可以通过任何一个计算节点来读写一个数据表，或者调用存储过程、函数等。每个计算节点 含有每个数据表以及其他数据库对象（索引、视图、物化视图、序列、存储过程/函数、用户/角色和特权等）的元数据，但是不存储用户数据，因而可以随时按需增减KlustronDB-server节点。用户数据存储在存储 shard 中。
计算节点中的元数据表
下面的语句查询出当前计算节点所在的KlustronDB集群有哪些shard，每个shard有哪些节点，及其详细信息。用户禁止修改任何此类元数据信息，否则系统将无法正常工作。
kunlundb=# select*from pg_shard;
name | id | master_node_id | num_nodes | space_volumn | num_tablets | db_cluster_id | when_created
---------+----+----------------+-----------+--------------+-------------+---------------+-------------------------------
shard_2 | 1 | 2 | 3 | 311296 | 76 | 1 | 2026-02-26 13:02:43.465621+08
shard_1 | 2 | 6 | 3 | 258048 | 63 | 1 | 2026-02-26 13:02:43.465621+08
(2 行记录)
kunlundb=# select*from pg_shard_node;
id | port | shard_id | svr_node_id | ro_weight | ping | latency | user_name | hostaddr | passwd | when_created | extra
----+-------+----------+-------------+-----------+------+---------+-----------+---------------+---------+-------------------------------+-------
2 | 22067 | 1 | 0 | 10 | 0 | 0 | pgx | 192.168.0.136 | *** | 2026-02-26 13:02:43.465621+08 |
5 | 22064 | 2 | 0 | 10 | 0 | 1500519 | pgx | 192.168.0.132 | *** | 2026-02-26 13:02:43.465621+08 |
6 | 22064 | 2 | 0 | 10 | 0 | 0 | pgx | 192.168.0.136 | *** | 2026-02-26 13:02:43.465621+08 |
1 | 22067 | 1 | 0 | 10 | 0 | 1303656 | pgx | 192.168.0.132 | *** | 2026-02-26 13:02:43.465621+08 |
4 | 22064 | 2 | 0 | 10 | 0 | 3 | pgx | 192.168.0.125 | *** | 2026-02-26 13:02:43.465621+08 |
3 | 22067 | 1 | 0 | 10 | 0 | 109135 | pgx | 192.168.0.125 | *** | 2026-02-26 13:02:43.465621+08 |
(6 行记录)
下面的SQL语句查询出当前计算节点以及Metashard集群的全局元数据信息。
kunlundb=# select*from pg_cluster_meta;
comp_node_id | cluster_id | cluster_master_id | ha_mode | cluster_name | comp_node_name | meta_ha_mode
--------------+------------+-------------------+---------+---------------------------+----------------+--------------
1 | 1 | 2 | 2 | cluster_1772081642_000001 | comp1 | 2
(1 行记录)
kunlundb=# select*from pg_cluster_meta_nodes;
server_id | cluster_id | is_master | port | user_name | hostaddr | passwd
-----------+------------+-----------+-------+-----------+---------------+---------
1 | 1 | f | 22061 | pgx | 192.168.0.125 | ***
2 | 1 | t | 22061 | pgx | 192.168.0.132 | ***
3 | 1 | f | 22061 | pgx | 192.168.0.136 | ***
(3 行记录)
计算节点支持 PostgreSQL 连接协议和 MySQL 连接协议接收和验证用户的连接请求，验证通过后，就接收和处理连接上发来的查询并返回结果给客户端。
执行一个 SQL时，计算节点解析该语句，然后对它做分布式查询优化，然后通过与后端存储 shard 做交互来完成分布式查询执行。交互的方法就是根据 SQL 语句的需要和数据表分区在后端 shard 的分布信息，为相关的后端存储 shard 生成 SQL 语句。
计算节点会并发地发送 SQL 语句到存储集群，如果执行的 SQL 语句是 SELECT 或者 INSERT/DELETE/UPDATE...RETURNING 而不是简单的 INSERT/DELETE/UPDATE , 那么计算节点发送语句后还会接收存储集群返回的部分结果并且合并处理所有后端存储 shard 返回的结果，形成最终的查询结果，返回给客户端。
2.2 存储集群(storage shard )
每个存储 shard 存储着一部分用户表或者表分区，每个 shard 的用户数据子集没有交集；一个 shard 的主节点接受来自计算节点的读写请求，执行请求并返回结果给计算节点；启用了备机读功能时，shard 的备节点可以接收和处理来自计算节点的只读请求。
KlustronDB 的存储节点(KlustronDB-storage) 是KlustronDB 研发团队基于 percona-server-8.0 深度优化开发的 MySQL 分支。每个存储 shard 是一个 binlog 复制集群，通过标准的 MySQL row based binlog replication(RBR) 和KlustronDB特有的 Fullsync 强sync机制 来实现金融级数据一致性，确保RPO=0；同时 KlustronDB 自研的高可用机制 Fullsync HA 可以监测每个shard的主节点运行状态并且在发现主节点故障时自动完成主节点选举和主备切换，确保 RTO小于30秒。
一个 shard 的主节点接受来自计算节点的读写请求，执行请求并返回结果给计算节点；启用了备机读功能时，shard 的备节点可以接收和处理来自计算节点的只读请求。
用户可以根据数据量的增加和减少来增加和较少存储 shard，数据会自动均匀分散到所有 shard 上面，实现自动和透明的水平可扩展。
必须使用 KlustronDB-storage 软件组建 KlustronDB 的存储集群和元数据集群，因为 KlustronDB 集群需要的关键功能只存在于 KlustronDB-storage 中，并且它还包含了社区版 MySQL-8.0 XA 事务处理的所有容灾缺陷的修复；最后，KlustronDB-storage 在 分布式事务处理方面比社区版 MySQL 有大幅性能优化。
2.3 元数据集群
元数据集群也是一个由 KlustronDB-storage 实例组成的集群，并且也基于Fullsync 和Fullsync HA技术实现强一致性和高可用。一个元数据集群存储着若干个 KlustronDB 集群的元数据，可以被多个数据库集群共用。元数据集群存储这些KlustronDB集群的拓扑结构、节点连接信息、DDL日志，commit log，和其他集群管理日志。
KlustronDB 用户和DBA 不需要使用或者直接读写元数据集群的任何数据表。特别地，禁止直接修改metashard的任何元数据表的结构或者其数据，否则KlustronDB将无法正常工作 。
2.4 cluster_mgr 集群
KlustronDB 的 cluster_mgr 集群负责维护正确的集群和节点状态，实现集群管理、集群逻辑备份和恢复, 集群物理备份和恢复、水平弹性伸缩等功能。所有这些功能都以API的形式提供给用户，方便用户在脚本或者各种软件中调用。 同时，KlustronDB 自带的 XPanel DBA GUI 工具软件 也是通过调用 cluster_mgr API 来实现其功能。
cluster_mgr 高可用集群基于raft技术实现高可用，确保主节点宕机后，集群备节点可以立刻发现并选举出新的主节点提供集群管理工作。DBA可以管理cluster_mgr集群 ，完成高级cluster_mgr集群管理功能。
一个cluster_mgr 集群绑定一个元数据集群并与之紧密协作，为一个或者多个KlustronDB 集群提供服务。这里绑定的意思是指一个cluster_mgr集群使用一个固定的元数据集群，一个元数据集群只能被同一个cluster_mgr集群使用，二者是一对一的。
2.5 辅助工具
1、XPanel
KlustronDB 提供了 XPanel GUI 工具软件，让 DBA 通过点击鼠标就可以轻松完成所有的数据库运维管理工作。XPanel的用法 简单，以所见即所得的图形用户界面提供操作KlustronDB集群的便捷方式。 XPanel也之一对一 绑定一个metashard，与之协作运行。
2、prometheus 和 Grafana 监控集群节点运行状态
KlustronDB 在 bootstrap 时自动安装 prometheus 和 Grafana 以便 DBA 可以使用 Grafana 监控 KlustronDB 集群各个节点的实时运行状态。
3、ElasticSearch + Kibana 收集和检索集群节点日志
如果用户安装了 ElasticSearch 并且在 bootstrap 时候设置了其访问方式的话，KlustronDB 的相关模块还会自动与 ES 相关模块协作，让 ES 可以收集 KlustronDB 集群所有节点的运行日志，方便用户通过 Kibana 检索和查看这些节点的日志。
4、KlustronDB 具备完备的数据导入导出工具集
这些工具方便用户轻松地用 MySQL 和 PostgreSQL 数据库实例的全量数据备份完成静态数据迁移，或者用其全量数据备份加上流式增量数据更新完成热数据迁移和复制。同时 KlustronDB 可以与常见的第三方数据迁移工具协作，从常见的数据库系统（例如 Oracle，SQL Server，TiDB 等）完成静态全量数据迁移和动态的热数据迁移。