GoldenDB 集群架构、组件说明、运维操作的详细入门指南。

GoldenDB 分布式数据库 新手入门手册（详细版）

——架构图解 · 组件详解 · 工作流程 · 运维实战

版本：V6.1.03.07 适用对象：初级运维工程师 / DBA 编制日期：2026年6月

1. 目 录

第一章 GoldenDB 是什么

第二章 整体架构总览（含架构图）

第三章 核心组件详解（含模块关系图）

第四章 SQL 请求处理流程（含流程图）

第五章 逻辑集群与分片原理（含分片图）

第六章 GTM 全局事务管理器（含高可用图）

第七章 DBProxy（CN）代理节点

第八章 数据节点（DN）

第九章 RDB 管理数据库

第十章 Insight 监控平台

第十一章 dbtool 运维工具详解

第十二章 备份与恢复（含流程图）

第十三章 故障检测与自动切换（含流程图）

第十四章 日常运维操作手册

第十五章 常见问题与排查

附录 A 端口速查表

附录 B 目录结构速查表

2. 第一章 GoldenDB 是什么

2.1 1.1 产品简介

GoldenDB 是中兴通讯（ZTE）自主研发的金融级分布式关系型数据库产品。它采用 shared-nothing 架构，将数据水平拆分到多个数据节点上，同时通过全局事务管理器（GTM）保证分布式事务的一致性。GoldenDB 旨在替代传统单机数据库，提供高可用、高性能、可水平扩展的数据库服务。

2.2 1.2 核心特性

• 分布式架构：数据自动分片，支持在线扩容，单集群可管理数十PB数据。

• 全局一致性：基于 GTM 实现分布式事务的全局一致性读写，支持 ACID 事务语义。

• 高可用：每个数据节点组（Group）支持一主多备，故障自动切换，RTO<30秒。

• MySQL 兼容：对外提供 MySQL 协议接口，应用可直接使用 MySQL 客户端和驱动连接。

• 运维友好：提供 dbtool 命令行工具和 Insight 监控平台，支持在线备份恢复、滚动升级。

2.3 1.3 版本信息

本手册基于 GoldenDB V6.1.03.07 版本编写。该版本属于 V6.1 系列的稳定发布版，已在多个金融、电信客户环境中部署运行。

3. 第二章 整体架构总览

3.1 2.1 架构全景图

GoldenDB 的整体架构分为四层：接入层、事务管理层、数据存储层和运维管理层。下图展示了完整的架构拓扑，包括所有组件的物理部署位置和通信关系：

3.2 2.2 四层架构说明

接入层（DBProxy / CN）：接收客户端的 SQL 请求，进行路由、负载均衡和安全控制。客户端通过 MySQL 协议连接到 DBProxy，就像连接普通 MySQL 一样。DBProxy 根据 SQL 类型（读/写）和分片规则，将请求转发到对应的 DN 节点。

事务管理层（GTM）：全局事务管理器，为分布式事务提供全局唯一的时间戳和 GTID（全局事务标识符）。GTM 本身也是高可用部署，一主一备，故障时自动切换。

数据存储层（DN）：数据节点，实际存储数据的地方。每个 DN 本质上是一个 MySQL 实例。多个 DN 按 Group（组）组织，每个 Group 内有一主多备，支持自动故障切换。

运维管理层：包括 MDS（元数据服务）、CM（集群管理器）、PM（代理管理器）、RDB（管理数据库）和 Insight（监控平台）。这些组件共同负责集群的配置管理、状态监控、故障检测和自动恢复。

3.3 2.3 逻辑分层关系表

3.4 2.4 物理部署拓扑

在典型三节点部署中，GoldenDB 集群运行在三台服务器上：

关键原则：组件采用交叉部署策略，同一类组件的不同副本分布在不同物理节点上，确保任意单节点故障不会导致服务中断。

4. 第三章 核心组件详解

4.1 3.1 组件关系与通信图

下图展示了 GoldenDB 各核心组件之间的通信关系和数据流向：

4.2 3.2 MDS（MetaDataServer）元数据服务

MDS 是 GoldenDB 的"大脑"，运行在 6408 端口，负责管理整个集群的元数据信息：

集群拓扑结构（哪些 DN、哪些 Group、哪些 Cluster）

GTM 信息（哪些 GTM 实例、谁是主、谁是备）

用户账号信息（全局统一的账号管理）

分片规则（数据如何拆分到不同 DN）

DDL 锁管理（分布式 DDL 操作的全局协调）

GTM GTID 的加载和同步

4.3 3.3 CM（ClusterManager）集群管理器

CM 运行在 6016 端口，负责集群的高可用管理：

监控 DN 节点健康状态，发现故障后自动发起主备切换

管理集群的备份恢复策略

处理跨机房/跨城市的容灾切换

管理集群的 license 和配置热加载

执行一致性检查（consience check）

4.4 3.4 PM（ProxyManager）代理管理器

PM 负责管理所有 DBProxy（CN）节点的生命周期：

从 MDS 同步最新的元数据到各 DBProxy

管理 DBProxy 的启停、故障恢复

监控 DBProxy 与后端 DN 的连接状态

处理 DBProxy 的配置更新和热加载

4.5 3.5 Insight 监控平台

Insight 运行在 8021/8028 端口，是 GoldenDB 的监控和告警平台：

采集所有组件的运行指标（CPU、内存、连接数、QPS等）

将监控数据写入 RDB 的 goldendb_insight 数据库

提供 Web 管理界面，支持告警配置和历史查询

5. 第四章 SQL 请求处理流程

5.1 4.1 完整处理流程图

当客户端发起一条 SQL 请求时，GoldenDB 内部的完整处理流程如下：

5.2 4.2 读请求流程

1. 客户端通过 MySQL 协议连接到 DBProxy（CN）

2. DBProxy 解析 SQL，识别为读操作（SELECT）

3. 根据分片规则确定目标 Group

4. 路由到该 Group 的备节点（读写分离，降低主节点压力）

5. DN 执行查询，返回结果

6. DBProxy 将结果返回客户端

5.3 4.3 写请求流程

1. 客户端通过 MySQL 协议连接到 DBProxy（CN）

2. DBProxy 解析 SQL，识别为写操作（INSERT/UPDATE/DELETE）

3. 向 GTM 申请全局事务 ID（GTID）

4. 路由到目标 Group 的主节点执行写操作

5. 如果涉及多个 Group，执行两阶段提交（2PC）

6. 事务持久化，结果返回客户端

6. 第五章 逻辑集群与分片原理

6.1 5.1 数据分片原理图

GoldenDB 使用分片（Sharding）技术将数据水平拆分到不同的 Group 中：

6.2 5.2 什么是逻辑集群（Cluster）

GoldenDB 中的"逻辑集群"是指一组逻辑上相关的数据节点组（Group）的集合。每个逻辑集群对应一个独立的业务数据库，拥有自己的分片规则和数据分布。不同逻辑集群之间的数据完全隔离，互不影响。

6.3 5.3 当前环境的逻辑集群

6.4 5.4 什么是分组（Group）

每个逻辑集群内部，数据节点按 Group（分组）组织。每个 Group 由一主多备组成，负责存储该集群的一部分数据（一个或多个分片）。

例如，mount2（Cluster 3）有 3 个 Group，每个 Group 有 2 个 DN 节点： • Group 1：DN10（从）+ DN11（主） • Group 2：DN12（主）+ DN13（从） • Group 3：DN14（主）+ DN15（从）

7. 第六章 GTM 全局事务管理器

7.1 6.1 GTM 的作用

在分布式数据库中，一个事务可能涉及多个 DN 节点的数据修改。为了保证这些操作的全局一致性，GoldenDB 引入了 GTM 组件。

分配全局唯一的事务 ID（GTID），确保事务的全局有序性

维护全局快照信息，支持全局一致性读（Consistent Read）

协调跨 DN 的分布式事务的提交和回滚

记录和管理集群的全局 GTID 进度

7.2 6.2 GTM 高可用切换流程

GTM 本身也是高可用部署，采用一主一备模式。下图展示了 GTM 故障切换的完整流程：

7.3 6.3 当前环境的 GTM 部署

7.4 6.4 查看 GTM 状态

# 使用 dbtool 查看 GTM 详细信息
cd /data/zxmanager && export HOME=/data/zxmanager
./bin/dbtool -mds -showgtminfos

输出中 masterFlag=1 表示主 GTM，masterFlag=0 表示备 GTM。status=2 表示正常运行。

8. 第七章 DBProxy（CN）代理节点

8.1 7.1 DBProxy 的角色

DBProxy（也称为 CN，Compute Node）是 GoldenDB 的接入层组件。它对外提供标准的 MySQL 协议接口，应用使用普通的 MySQL 客户端即可连接。

8.2 7.2 核心功能

• SQL 解析与路由：解析客户端 SQL，根据分片规则确定目标 DN 节点

• 分布式事务协调：对于涉及多个 DN 的事务，协调各节点的提交顺序

• 连接池管理：维护与后端 DN 的长连接，避免每次请求都新建连接

• 负载均衡：在同 Group 的多个 DN（主备）之间分发读请求

• 读写分离：自动将读请求路由到备节点，写请求路由到主节点

8.3 7.3 当前环境的 DBProxy 部署

8.4 7.4 连接 DBProxy

# 连接到 prod 集群的 DBProxy
mysql -h10.7.16.65 -P8880 -u<用户名> -p<密码>

# 连接到 mount2 集群的 DBProxy
mysql -h10.7.16.65 -P8881 -u<用户名> -p<密码>

9. 第八章 数据节点（DN）

9.1 8.1 DN 的本质

DN（Data Node）是 GoldenDB 中实际存储数据的节点。每个 DN 本质上是一个 MySQL 实例，负责存储一部分数据并执行本地事务。多个 DN 按 Group 组织，每个 Group 内的 DN 通过 MySQL 主从复制实现数据同步。

9.2 8.2 DN 端口说明

数据端口（如 5501-5506）：对外提供 MySQL 协议连接，用于数据读写

Agent 端口（如 5018、6151-6155）：用于 CM/PM 与 DN 之间的管理通信

9.3 8.3 DN 直连方式

有时候需要直连 DN 进行诊断（跳过 DBProxy）：

# 直连某个 DN（使用数据端口）
mysql -h10.7.16.66 -P5504 -usuper -pP@ssw0rd_123

# 注意：直连 DN 只能看到该节点存储的分片数据，
# 无法执行跨分片查询。

10. 第九章 RDB 管理数据库

10.1 9.1 RDB 概述

RDB（Registry Database）是 GoldenDB 的管理数据库，运行在 3309 端口。它存储了整个集群的管理数据，包括拓扑信息、监控数据、告警记录等。

10.2 9.2 关键数据库

• mds：存储集群元数据：cluster_info、device_info、proxy_info、gtm_info 等

• goldendb_insight：存储监控数据：gtm_gtidinfo、alarm_list 等

• goldendb_omm：存储运维数据：备份恢复记录等

• cm：存储 CM 状态数据

10.3 9.3 连接 RDB

# RDB 运行在 3309 端口
mysql -h10.7.16.65 -P3309 -usuper -pP@ssw0rd_123

# 查看所有集群
SELECT * FROM mds.cluster_info;

# 查看所有数据节点
SELECT * FROM mds.device_info;

# 查看 GTM 信息
SELECT * FROM mds.gtm_info;

11. 第十章 Insight 监控平台

Insight 是 GoldenDB 内置的监控和告警平台，端口 8021/8028。它会定期采集所有组件的运行指标，并将数据存储到 RDB 的 goldendb_insight 数据库中。

11.1 10.1 常用监控指标

• GTM 监控：gtm_gtidinfo（GTID进度）、gtm_connection（连接数）

• DN 监控：dn_connection（连接数）、dn_slow_query（慢查询）

• DBProxy 监控：cn_connection（连接数）、cn_sql_count（SQL计数）

• 告警信息：alarm_list（告警列表）、alarm_history（历史告警）

12. 第十一章 dbtool 运维工具详解

12.1 11.1 dbtool 概述

dbtool 是 GoldenDB 自带的命令行运维工具，功能非常强大。它可以与各组件（CM、MDS、PM、GTM 等）通信，执行各种运维操作。

12.2 11.2 运行环境要求

⚠️ 重要：运行 dbtool 时必须设置 HOME 环境变量为组件安装目录，否则会报 "process inactive" 错误。

# 正确的运行方式
cd /data/zxmanager
export HOME=/data/zxmanager
./bin/dbtool -cm -state

# 错误的运行方式（会报 process inactive）
cd /tmp
dbtool -cm -state  # ❌ 报错！

这是因为 dbtool 需要通过 HOME 目录下的 socket 文件与本地组件进程通信。如果 HOME 不正确，dbtool 找不到通信 socket，就会认为组件未运行。

12.3 11.3 常用 CM 命令

• 查看 CM 状态：dbtool -cm -state

• 查询集群信息：dbtool -cm -query-cluster <ID>

• 主备切换：dbtool -cm -switch -clusterID=<ID> -groupID=<ID> -dbID=<ID>

• 备份（全量）：dbtool -cm -backup -strategy=master -clusterid=<ID> -groupid=<ID> -type=full

• 恢复：dbtool -cm -restore -clusterid=<ID> -type=group -nodeid=<ID>

• 一致性检查：dbtool -cm -check-consience -clusterID=<ID> -groupID=<ID>

• 热加载配置：dbtool -cm -load-config

• 热加载 License：dbtool -cm -load-license

12.4 11.4 常用 MDS 命令

• 查看 MDS 关键信息：dbtool -mds -showmore

• 查看 GTM 信息：dbtool -mds -showgtminfos

• 查看当前会话：dbtool -mds -showsessionsinuse

• 获取最大 GTID：dbtool -mds -getmaxgtid

• 设置主 GTM：dbtool -mds -setmastergtm <gtm_id>

• 查看 DDL 锁：dbtool -mds -print-ddl-lock

13. 第十二章 备份与恢复

13.1 12.1 备份恢复流程图

下图展示了 GoldenDB 备份和恢复的完整流程：

13.2 12.2 备份策略

• master 策略：从主节点备份，适合日常全量备份

• slave 策略：从备节点备份，避免影响主节点性能

• room 策略：按机房备份，适合跨机房容灾

• node 策略：按节点备份，适合特定节点的数据保护

13.3 12.3 备份示例

# 全量备份 mount2 集群的所有 Group
dbtool -cm -backup -strategy=master -clusterid=3 -groupid=0 -type=full

# 增量备份 prod 集群的 Group 1
dbtool -cm -backup -strategy=slave -clusterid=4 -groupid=1 -type=inrc

⚠️ 恢复前必须确认备份文件路径和时间点。恢复操作会覆盖目标节点数据，请谨慎操作！

14. 第十三章 故障检测与自动切换

14.1 13.1 故障切换流程图

当 DN 主节点故障时，GoldenDB 的自动故障检测和切换流程如下：

14.2 13.2 手动切换操作

如果需要手动干预，可以使用以下命令：

# 手动切换指定 Group 的主节点
cd /data/zxmanager && export HOME=/data/zxmanager
./bin/dbtool -cm -switch -clusterID=3 -groupID=1 -dbID=11

# 强制切换（跳过一致性检查，有数据丢失风险）
./bin/dbtool -cm -switch -force -clusterID=3 -groupID=1 -dbID=11

⚠️ 警告：强制切换（-force）可能导致数据不一致，仅在紧急情况下使用。正常情况下应等待 CM 自动切换。

15. 第十四章 日常运维操作手册

15.1 14.1 每日巡检流程

Step 1 - 检查 CM 状态：ssh 到 64 号机执行 dbtool -cm -state，确认 CM 处于 active 模式

Step 2 - 检查 MDS 状态：执行 dbtool -mds -showmore，查看集群拓扑是否完整

Step 3 - 检查 GTM 主备：执行 dbtool -mds -showgtminfos，确认 GTM 主备状态正常

Step 4 - 检查 DN 连接：通过 RDB 查询 goldendb_insight 中的连接监控数据

Step 5 - 检查 DBProxy：执行 dbtool -pm -showmore，确认所有 CN 状态正常

Step 6 - 查看告警：查询 RDB 中 goldendb_insight.alarm_list，处理未关闭的告警

15.2 14.2 动态配置热加载

# 热加载 CM 配置
dbtool -cm -load-config

# 热加载 MDS 配置
dbtool -mds -load-config

# 热加载 License
dbtool -cm -load-license

16. 第十五章 常见问题与排查

16.1 15.1 dbtool 报 "process inactive"

原因：HOME 环境变量未正确设置。解决：cd /data/zxmanager && export HOME=/data/zxmanager

16.2 15.2 RDB 连接被拒绝

排查：检查端口 3309、用户名密码（super/P@ssw0rd_123）、IP 白名单

16.3 15.3 DBProxy 状态异常（status=-1）

排查：检查进程存活 → dbtool -pm -recover-proxy <proxyid> → 查日志

16.4 15.4 GTM 主备不一致

已知行为。master_flag 字段反映配置信息，实际主备查 gdb_stat_gtm_gtidinfo 表。

17. 附录 A 端口速查表

18. 附录 B 目录结构速查表