三台机器装完 GoldenDB，登录上去第一反应往往是懵的：用户一堆、进程一堆、端口一堆，目录还散在 /home/goldendb 和根目录 / 下。这篇就把集中式部署后的家底摊开——谁部署在哪台机器、每个进程干什么、空间被什么吃掉，顺便说几个装机时容易踩的坑。
先记住一个坑：初始化超时不是数据库失败
第 12 步部署组件、初始化数据库时，安装程序默认等 40 次，每次间隔 30 秒。超时时间算法很简单：MAX_INTERVAL_COUNT 乘以 INTERVAL_TIME，默认 40×30=1200 秒，也就是 20 分钟。
磁盘性能不够的机器，这一步很容易超过 1200 秒。结果是安装主程序报错，但数据库其实已经初始化成功了。遇到这种情况不用重装，把等待次数或间隔调大即可。
配置文件在这里：
参数含义：
MAX_INTERVAL_COUNT = 40 # 单位：次数
INTERVAL_TIME = 30 # 单位：秒
判定标准很直接：只要报错后数据库能正常连上、组件进程都在，就说明只是安装脚本等超时了，不是初始化失败。
三节点到底各自扛了什么
机器规划先摆出来：
192.168.182.41（golden1）
192.168.182.42（golden2）
192.168.182.43（golden3）
组件落位大致是这样：
Insight(8444) 在 41
DBProxy(8880) 在 42 和 43
Manager 在 41
GTM(6026) 在 43
RDB(myd 3309) 在 41
LOADSERVER(6251) 在 43
Zookeeper(32181) 在 41
租户分布上，41 上有场景租户（myd 5501）和体系租户（myd 5501），42 上是场景租户（myd 5501），43 上是场景租户（myd 5502）。
Manager 节点上跑着什么
Manager 就是管控机器，部署在 41 上，包含四个东西：Metadata Server（端口 6406）、Proxy Manager（6006）、Cluster Manager（6016），以及 ommagent 代理。
整个集群一共部署了 5 套 MySQL 数据库，用途各不相同：
RDB 是单机，存整个集群的拓扑配置、高可用决策状态、管控底层配置，还包括 Insight 管理平台的后台数据、metadataserver、clustermanager、OMM 运维体系的监控配置和阈值。
体系租户也是单机，存系统租户的运行统计信息、场景租户的热点表读写次数、慢 SQL、QPS 吞吐统计。
场景租户是一主两从，存用户数据。业务租户配置的就是一主两从架构，43 机器为主，其余两个为备。
这里有个细节：主从库的端口和部署用户并不要求一致。43 主库所属运维体系用户是 zxdb1，端口 5501；41 上的从库所属用户是 zxdb2，端口 5502。原因是系统租户的数据库先创建，后面的实例跟着自己的节奏走。
目录里藏着多少空间
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
…
重点来了，data 目录下：
[root@golden1 data]# du -sh redo/*
8.0G redo/ib_logfile0
8.0G redo/ib_logfile1
库本身是空的，却占了 17G，原因就是默认初始化了两个 8G 的 redo 日志文件。这是 InnoDB 的默认行为，不是异常。
golden2
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
…
golden3
golden3 主导部署 Insight 客户端、GTM、Load Server、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
进程才是真正的主角
golden1 上的用户与进程
insight 用户下：
insight.jar 是 Java 进程，Insight 管控平台主程序。
ommagent.jar 也是 Java 进程，Insight 本地的运维管控代理。
此外还有 RDB 数据库和 zookeeper。
zxmanager 用户下：
metadataserver 是元数据支撑进程，负责存储和分发整个分布式集群的拓扑配置、路由分片规则和 DDL 表结构元数据。
proxymanager 是 Proxy 管控进程，负责监控 Proxy 机器状态，接收并下发 Proxy 的横向扩容、缩容指令。
clustermanager 是集群管控进程，负责整个集群主备机器的高可用状态裁决。
ommagent.jar 是 Manager 的运维代理，收集 MDS、CM 等组件自身的 CPU、内存和状态指标，定时把健康心跳上报给 Insight 管控平台。
zxdb1 用户下：
myd –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 核心进程。
golden2 上的用户与进程
zxdbproxy1 用户下：
dbproxy 进程负责接收 SQL 请求、解析并分发给存储层。
ommagent.jar 是运维管控代理进程，负责与 Insight 做心跳通信，上报当前机器的 CPU、内存及运行状态。
dbmonidamon ommagent 是 ommagent 的守护进程。
dbmonidamon dbproxy 是 Proxy 守护进程。
flock … dbproxy_damon.lock 是防重启动锁，保证同一台机器上不会同时跑两个 Proxy 守护脚本。
flock … ommagent_damon.lock 是防重启动锁，保证同一台机器上不会跑两个运维代理（OMM）守护脚本。
zxdb2 用户下：
myd –defaults-file=/zxdb2/etc/my.cnf –datadir=/zxdb2/data/data，MySQL 数据库进程。
dbagent 数据库代理，负责分布式事务处理。
ommagent.jar 是运维代理实体，与管控平台保持心跳和状态上报。
flock 和 dbmonidamon 分别是 dbagent、loadserver 和 ommagent 的高可用守护文件锁和脚本。
golden3 上的用户与进程
zxdbproxy1 用户下：
dbproxy 进程负责接收 SQL 请求、解析并分发给存储层。
ommagent.jar 是运维管控代理进程，负责与 Insight 做心跳通信，上报当前机器的 CPU、内存及运行状态。
dbmonidamon ommagent 是 ommagent 的守护进程。
dbmonidamon dbproxy 是 Proxy 守护进程。
flock … dbproxy_damon.lock 是防重启动锁，保证同一台机器上不会同时跑两个 Proxy 守护脚本。
flock … ommagent_damon.lock 是防重启动锁，保证同一台机器上不会跑两个运维代理（OMM）守护脚本。
zxdb1 用户下：
myd –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 → Omm Agent → MDS → 体系租户 → RDB）。
和 OceanBase 的部署思路差异
OceanBase 那边有 OAT、MetaDB、OpenSearch、OCP、OMA、OMS 等组件，走的是镜像化部署，组件数量也不少。
GoldenDB 的思路是把所有组件解耦打散在运维体系中，相对更透明、更容易掌控。代价就是进程和目录看起来更散，需要自己把关系理清楚。
几个实操判断
第一，初始化超时先别急着重装，确认数据库能连、进程在，就只是脚本等待时间不够。
第二，看到 data 目录 17G 别慌，空库加两个 8G redo 是默认行为，属于预期内。
第三，主从库端口和用户不一致是允许的，别拿这个当故障排查。
第四，flock 锁文件是防重复启动的，看到它们说明守护机制在工作，不是残留垃圾。
第五，进程多不代表乱，按控制链和度量链两条线去理解，MDS 是核心分发点，Omm Agent 是统一上报口。
