GoldenDB 装完之后，系统里到底多了什么？
2026-09-18 09:57 圣彼得堡的村长 阅读(26) 评论(0) 收藏 举报GoldenDB 装完之后，系统里到底多了什么？
在历经波折装好三节点集群后，我们开始梳理一下 GoldenDB 集中式部署下的组件分布、端口规划和相关进程，为后续深入研究和运维实战的基础。
顺便提一句，在第 12 步安装组件，初始化数据库时，默认等待 40 次，每次 30 秒，如果由于磁盘性能不够等因素导致超过了 1200 秒，安装主程序就会报错，但是数据库仍可始化成功，可以将时间间隔或者等待次数调大一些，避免主程序报错终止。
vim /ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install/global_args.py
# 安装组件超时时间计算方式为 MAX_INTERVAL_COUNT*SLEEP_TIME
# 默认 1200秒=20min
MAX_INTERVAL_COUNT = 40 # 单位：次数
INTERVAL_TIME = 30 # 单位：秒
1. 集群部署架构与组件分布
| 192.168.182.41（golden1） | 192.168.182.42（golden2） | 192.168.182.43（golden3） |
|---|---|---|
| Insight(8444) | DBProxy(8880) | DBProxy(8880) |
| Manager | 业务租户(mysqld 5501) | GTM(6026) |
| RBD(mysqld 3309) | LOADSERVER(6251) | |
| 系统租户(mysqld 5501) | 业务租户(mysqld 5501) | |
| 业务租户(mysqld 5502) | ||
| Zookeeper(32181) |
组件说明：
- Manager 也就是管理节点，安装的组件有：
MetadataServer(端口 6406)、ProxyManager(6006)、ClusterManager(6016) 以及ommagent代理。 - 总共安装了 5 套 MySQL 数据库：
RDB（单机）：存储整个集群架构的拓扑配置、高可用决策状态以及管理平台的底层配置信息，包括 Insight 管理平台的后台数据，metadataserver，clustermanager，运维管理（OMM）系统的监控配置和阈值等数据；- 系统租户（单机）：存储系统租户的底层运行统计信息、业务租户的热点表读写次数、慢 SQL、QPS 流量统计等信息；
- 业务租户（一主两从）存储用户数据；
- 业务租户配置的是一主两从架构，其中 43 节点为主，其余两个为备。主从库的端口和安装用户并不要求一致，如 43 主库的所属操作系统用户为 zxdb1，端口是 5501, 而 41 上的从库所属用户为 zxdb2，端口是 5502，因为系统租户的数据库先创建，占用了 zxdb1 和 5501。
2. 目录查看
2.1 golden1 节点
golden1 节点主要安装的是 Insight（OMM、RDB、Zookeeper）、Zxmanager 以及一套系统租户库 和 一套业务租户库。
[root@golden1 goldendb]# pwd
/home/goldendb
[root@golden1 goldendb]# ll
总用量 16
drwxr-xr-x. 23 insight golden 4096 9月 17 14:51 insight
drwxr-xr-x 7 zxdb1 golden 91 9月 17 12:56 install_log
drwxr-xr-x 21 root golden 4096 9月 17 12:41 OnekeySwitch
drwxr-x--- 17 zxdb1 golden 4096 9月 17 15:42 zxdb1
drwxr-xr-x 2 zxgdbcheck golden 62 9月 17 12:37 zxgdbcheck
drwxr-x--- 16 zxmanager golden 4096 9月 17 16:52 zxmanager
# zxdb1 为系统主库
[root@golden1 goldendb]# du -sh *
7.5G insight
252K install_log
7.7M OnekeySwitch
21G zxdb1
12K zxgdbcheck
1.3G zxmanager
# 业务数据库
[root@golden1 zxdb2]# pwd
/zxdb2
[root@golden1 zxdb2]# du -sh *
0 backup_root
3.2G bin
4.5M collect
17G data
0 dbagent_tmp
484K etc
1.8M lds_share
492M lib
...
[root@golden1 data]# du -sh redo/*
8.0G redo/ib_logfile0
8.0G redo/ib_logfile1
目前库基本上是空的，但还是占用了 17G 的空间，原因是默认初始化的 两个 redo 日志均为 8G。
2.2 golden2 节点
主要是安装 Insight 客户端、DBProxy 以及一套业务数据库。
[root@golden2 goldendb]# pwd
/home/goldendb
[root@golden2 goldendb]# du -sh *
2.5G insight
80K install_log
1.6G zxdbproxy1
12K zxgdbcheck
# 业务数据库
[root@golden2 zxdb2]# pwd
/zxdb2
[root@golden2 goldendb]# ll /zxdb2/
总用量 36
drwxrwx--- 2 zxdb2 golden 6 9月 17 16:24 backup_root
drwxr-x--- 10 zxdb2 golden 8192 9月 17 16:26 bin
drwxr-xr-x 2 zxdb2 golden 4096 9月 17 16:25 collect
drwxr-xr-x 8 zxdb2 golden 83 9月 17 16:26 data
drwxrwx--- 4 zxdb2 golden 52 9月 17 16:27 dbagent_tmp
drwxr-x--- 3 zxdb2 golden 4096 9月 17 16:30 etc
...
2.3 golden3 节点
主要是安装 Insight 客户端、GTM、LoadServer、DBProxy 以及一套业务数据库。
[root@golden3 goldendb]# pwd
/home/goldendb
[root@golden3 goldendb]# ll
总用量 0
drwxr-xr-x. 10 insight golden 180 9月 17 12:45 insight
drwxr-xr-x 6 zxdb1 golden 60 9月 17 12:56 install_log
drwxr-xr-x 2 zxgdbcheck golden 62 9月 17 12:37 zxgdbcheck
drwxr-x--- 15 zxgtm1 golden 326 9月 17 12:59 zxgtm1
drwxr-x--- 12 zxload1 golden 275 9月 17 13:00 zxload1
[root@golden3 goldendb]# du -sh *
2.5G insight
104K install_log
12K zxgdbcheck
334M zxgtm1
740M zxload1
[root@golden3 goldendb]# cd /zxdb1/
[root@golden3 zxdb1]# ll
总用量 36
drwxrwx--- 2 zxdb1 golden 6 9月 17 16:26 backup_root
drwxr-x--- 10 zxdb1 golden 8192 9月 17 16:27 bin
drwxr-xr-x 2 zxdb1 golden 4096 9月 17 16:27 collect
drwxr-xr-x 8 zxdb1 golden 83 9月 17 16:27 data
drwxrwx--- 4 zxdb1 golden 52 9月 17 16:28 dbagent_tmp
3. 进程查看
3.1 golden1 节点
节点 1 上，安装的用户及相应的进程如下：
insight用户：insight.jarjava 进程（Insight 管理平台主程序） ；ommagent.jarjava 进程（Insight 本地的运维管理代理）；RDB数据库；zookeeper；
zxmanager用户：metadataserver：元数据服务进程，负责存储和分发整个分布式集群的拓扑配置、路由分片规则和 DDL 表结构元数据。proxymanager：Proxy 管理进程，负责监控 Proxy 节点的状态，接收并下发 Proxy 的横向扩容、缩容指令，并负责配置参数的热加载。clustermanager：集群管理进程，负责整个集群主备节点的高可用状态裁决。ommagent.jarJava 进程（Manager 的运维代理），收集 MDS、CM 等组件自身的 CPU、内存和状态指标，并定时将健康心跳上报给 Insight 管理平台。
zxdb1用户：mysqld --defaults-file=/home/goldendb/zxdb1/etc/my.cnf --datadir=/home/goldendb/zxdb1/data/data：mysql数据库；dbagent：负责配合 Proxy 节点处理跨分片的两阶段提交 分布式事务，负责本地分布式锁的管理及协调。loadserver：负责底层数据的快速导入、导出以及分片重组数据块的高速处理。ommagent.jar：运维管理代理：负责将当前 zxdb1 实例的指标上报给 Insight 平台。dbmonidamon dbagent：监控并守护dbagent核心进程；dbmonidamon loadserver：监控并守护loadserver核心进程；dbmonidamon ommagent：监控并守护ommagent核心进程；
3.2 golden2 节点
在节点 2，安装的用户及相应的进程如下：
zxdbproxy1用户：dbproxy进程，负责接收 SQL 请求、解析并分发给存储层。ommagent.jar：运维管理代理进程，负责与 Insight 进行心跳通信，上报当前节点的 CPU、内存及运行状态。dbmonidamon ommagent：ommagent 的守护进程；dbmonidamon dbproxy：Proxy 守护进程；flock ... dbproxy_damon.lock防重启动锁：确保同一台机器上不会同时跑两个 Proxy 的守护脚本；flock ... ommagent_damon.lock防重启动锁：确保同一台机器上不会跑两个运维代理（OMM）的守护脚本。
zxdb2用户：mysqld --defaults-file=/zxdb2/etc/my.cnf --datadir=/zxdb2/data/data：mysql数据库；dbagent数据库代理：负责提供分布式事务支持。ommagent.jar：运维代理实体：与管理平台维持心跳和基础状态上报；flock/dbmonidamon：分别是dbagent、loadserver和ommagent的高可用守护文件锁和脚本。
3.3 golden3 节点
在节点 3，安装的用户及相应的进程如下：
zxdbproxy1用户：dbproxy进程，负责接收 SQL 请求、解析并分发给存储层。ommagent.jar：运维管理代理进程，负责与 Insight 进行心跳通信，上报当前节点的 CPU、内存及运行状态。dbmonidamon ommagent：ommagent 的守护进程；dbmonidamon dbproxy：Proxy 守护进程；flock ... dbproxy_damon.lock防重启动锁：确保同一台机器上不会同时跑两个 Proxy 的守护脚本；flock ... ommagent_damon.lock防重启动锁：确保同一台机器上不会跑两个运维代理（OMM）的守护脚本。
zxdb1用户：mysqld --defaults-file=/zxdb1/etc/my.cnf --datadir=/zxdb1/data/data：mysql数据库；dbagent数据库代理：负责提供分布式事务支持。ommagent.jar：运维代理实体：与管理平台维持心跳和基础状态上报；flock/dbmonidamon：分别是dbagent、loadserver和ommagent的高可用守护文件锁和脚本。
可以看到进程相对来说还是比较多的，而且很多进程是主进程（如 MDS/CM/DBProxy/DB）的辅助运维进程，这些辅助运维进程还配置了守护进程。这些进程之间还涉及到数据同步，比如 MDS 向系统租户写入数据，系统租户还会同步数据到 RDB 中。
控制链：元数据下发（MDS ➔ Proxy/DBAgent ➔ RDB）
指标链：运行期监控流转（Proxy/DB ➔ OmmAgent ➔ MDS ➔ 系统租户 ➔ RDB）
OceanBase 的组件也比较多，例如 OAT、MetaDB、OpenSearch、OCP、OMA、OMS 等，但是通过容器化部署，将复杂的运维生态进行高度的封装。而 GoldenDB 将所有组件解耦打散在操作系统中，但是比较透明和易于掌控。
** 这里是《实战派K8S&DB》，更多干货敬请关注公众号。如果本文对你有所帮助，欢迎点赞、推荐和转发，也欢迎关注后续文章，一起考证、一起学习 GoldenDB 分布式数据库。**
浙公网安备 33010602011771号