GoldenDB 安装配置文件详细解析

本篇文章介绍一下 GoldenDB 的安装参数，之前陆续介绍过 OceanBase、 TiDB 和 GaussDB 的安装，并没有详细解释参数文件，是因为 OceanBase 和   TiDB  分别通过 OBD 和 Tiup 安装时，只需要配置 集群拓扑的 YAML 文件即可，相应的 GaussDB 通过 Python 在 脚本安装配置也不太复杂，先确定部署节点，再确定集群架构（集中式/分布式），最后修改 IP、路径和用户密码即可一键安装。

相对来说， GoldenDB 的安装配置文件 install_senior.ini 配置相对会复杂一些，因此，我们专门用一篇文章来解读一下。下面开始解析一下 GoldenDB 的安装文件里的参数。

1.   install_senior.ini 文件解析

安装配置文件 install_senior.ini 内容主要分为： GENERAL、 NODES、 MANAGER、 GTM、 DBProxy、 Cluster 、 LoadServer 和 Insight  八大部分。

1.1 GENERAL 参数

通用部分参数，指定了如安装用户名前缀、安装路径、部署模式等。

[GENERAL]
# 安装所使用的用户，root 用户或者具备 sudo 权限的用户
root_user=root
# 安装所使用的用户密码, 如需手动交互输入请置空
root_pwvalue=******
# 操作系统上 GTM, Proxy, DB, LOADSERVER 等用户名的前缀信息
user_prefix=zx
# 公共的用户组名
user_group_name=goldendb
# gdbcheck 用户的密码，安装检查会创建 check 用户
gdb_normal_user_pwd=******
# 安装路径，所有的组件（bin，data，log）都会装在此目录下面
install_path=/home/goldendb
# 安装模式，只能填0 或者 2
#  0代表单个管理节点，需要配置[Nodes]，[Manager-Single]，[GTM]，[DBPROXY]，[CLUSTER]，[LOADSERVER];
#  2代表ZK,         需要配置[Nodes]，[Manager-ZK]，    [GTM]，[DBPROXY]，[CLUSTER]，[LOADSERVER];
install_type=0
# 安装租户形态
# 0 代表正常安装，包括管理节点，GTM节点，LDS节点，DB，Proxy，并组建集群
# 1 代表是只安装管理节点和GTM节点，LDS节点(不安装db和proxy、不组建集群)
# 2 代表只安装管理节点(不安装db和proxy、lds、gtm, 不组建集群)
install_tenancy=0
# 安装载体，
# 0代表GDB全部使用物理机，虚拟机安装
# 1代表管理节点--物理机，虚拟机，非管理节点--容器
# 2代表管理节点--容器
install_carrier=0
# 直接修改系统内核参数，#系统级参数脚本：产品包/oneKeyInstallUpdate/install/prepare_env/checkkernel.sh
system_parameter=1
# OMM Server 机器地址，Insight 是前端展示，OMM 是后端管理，填入 Insight 的安装地址即可
omm_domain_name=10.0.0.10
# listen port for ommagent.
omm_listen_port=6471
# rdb port，默认是3309，RDB 是 Insight 后台数据库
rdb_port=3309
# rdb admin port，默认是65100，MySQL8.0.14 之后提供了一个管理端口
rdb_admin_port=65100
# rdb super 超级用户密码
rdb_super_pwvalue=******
# rdb repl 复制用户密码
rdb_repl_pwvalue=******
# rdb normal 普通用户密码
rdb_normal_pwvalue=******
# rdb root 用户密码
rdb_root_pwvalue=******
# 1：表示无论现在有什么客户端，都使用产品包自带的mysql客户端替换
mysql_client_switch=1
# 1：表示无论操作系统什么版本的 jdk1.8.0 ，都使用产品包自带的jdk替换
jdk_switch=1

1.2 NODES 参数

指定所有安装涉及到的服务器。

# 所有服务器
[NODES]
# 配置项的名称格式如下，不允许修改：
#     local_room表示本区域AZ，city_room1表示同区域AZ1，city_room2表示同区域AZ2，remote_room1表示异区域AZ1，remote_room2表示异区域AZ2
#     配置值的格式如下
#     Region|AZ-所在物理城市|服务器ip列表|AZ优先级 （所在物理城市一定要填实际的地级市名称）如: local_room=Region|AZ1-南京|10.0.0.10,10.0.0.11-12,10.0.0.18|1
local_room=Region1|AZ1-南京|10.0.0.10,10.0.0.11-12,10.0.0.18|1
city_room1=Region1|AZ2-南京|10.0.0.13,10.0.0.14|2
city_room2=Region1|AZ3-南京|10.0.0.13,10.0.0.14|3
remote_room1=Region2|AZ4-北京|10.0.0.15,10.0.0.16|4
remote_room2=

这里比较好理解：

• local\_room 可以理解为 主数据中心；
• city\ room 1 和 city\room 2 可以理解为同城灾备中心，但是 city\_room 1 优先级更高；
• remote\_room 1 可以理解异地灾备中心。

1.3 MANAGER 参数

前面设置 install\_type=0 时，此配置生效，即 单个管理节点安装，包括 Metadataserver、 ProxyManager、 ClusterManager 和 LoadServer 都会安装在此节点上。

[MANAGER_SINGLE]
# 从[Nodes]配置段中选取，用于配置 本地，同城，异地
# 本地，只允许一个IP
# 同城、异地如果没有，可以保留为空值，如果有值，也是只允许一个IP
# IP可支持配置ipv4或ipv6
local_room_ip=10.0.0.10
city_room1_ip=
remote_room1_ip=
# 管理节点安装路径, 如不配置则使用[GENERAL]段中的install_path
manager_install_path=/home/goldendb
# manager节点应用用户密码
manager_apply_user_pwvalue=******
# manager节点应用用户uid，install_carrier=2时生效
manager_apply_user_uid=1332
# cgroup资源限制，配置格式为_C_G（_处填写数字）不配置则留空，会不做资源限制即（会自动设置为0C0G)
manager_cgroup_limit=0C0G

前面设置 install\_type=2 时，此配置生效，即多个节点都会安装 Metadataserver、 ProxyManager、 ClusterManager 和 LoadServer 。

[MANAGER_ZK]
# 配置管理节点ip，配置项的名称为ip，不允许修改。
# 配置值的格式如下：
#    ip1,ip2,...
#    说明：从[Nodes]配置段中选取，英文逗号分隔,ip可支持配置ipv4或ipv6
#    连续ip只支持ipv4格式，ipv6必须填完整ip,用英文逗号分隔
#    ipv6示例：local_room_ip=FE80::5200:FF:FE01:0,FE80::5200:FF:FE01:2,FE80::5200:FF:FE01:3
# 连续ip使用-连接，起始IP-同网段截止IP中最后一段:例如10.0.0.11-20，代表10.0.0.11到10.0.0.20内所有连续ip
local_room_ip=10.0.0.10,10.0.0.11
city_room1_ip=
city_room2_ip=
remote_room1_ip=
remote_room2_ip=
# 管理节点安装路径, 如不配置则使用[GENERAL]段中的install_path
manager_install_path=/home/goldendb
# manager节点应用用户pw
manager_apply_user_pwvalue=******
# manager节点应用用户uid，install_carrier=2时生效
manager_apply_user_uid=1332
# cgroup资源限制，配置格式为_C_G（_处填写数字）不配置则留空，会不做资源限制即（会自动设置为0C0G)
manager_cgroup_limit=0C0G

1.4 GTM 参数

指定 GTM 安装的相关参数。

# GTM组件
[GTM]
# GTM 的安装路径
gtm_install_path=/home/goldendb
# GTM 机器上操作系统用户 zxgtmN 的密码
gtm_apply_user_pwvalue=******
# gtm资源限制，0C0G代表不限制
gtm_cgroup_limit=0C0G
# 第一个 GTM 组
sys_gtmg1_team1=10.0.0.10,M;10.0.0.11,S
# 第二个 GTM 组
sys_gtmg1_team2=10.0.0.10,S;10.0.0.11,S
# GTM 的底层配置文件基线。留空代表使用产品包中默认的 gtm.json 模板进行标准化安装。
sys_gtm_template=

参数说明：

• sys_gtmg1_team1 代表默认的 GTM 集群，group 编号 1，team 编号 1， 一个 GTM 集群暂时只支持一个 GTM 组，为什么是 group，因为 GTM 生产中部署肯定要配置高可用。
• team （可用区）是集群进行 数据强同步校验、高低水位判定以及机房级容灾的 最小评估单元。在实际生产部署中，运维人员通常将 同一个机房内的副本节点划分为同一个 Team。
• 本地机房（A） 里的主备节点 \\rightarrow Team 1
• 同城机房（B） 里的备节点 \\rightarrow Team 2
• 异地机房（C） 里的灾备节点 \\rightarrow Team 3

\\text{集群（Cluster）} \\longrightarrow \\text{分片组（DBGroup）} \\longrightarrow \\text{响应组（Team）} \\longrightarrow \\text{物理节点（DB / GTM）}   为什么需要 team ？如果只按“收到了多少个单个节点的 ACK”来判断同步成功，无法保障 机房级别的物理隔离与跨数据中心一致性。 假设有一个 5 节点的集群，部署在两个机房：机房 A 有 3 个节点，机房 B 有 2 个节点。

• 如果只看“收到 3 个 ACK 就代表成功”，那么当机房 A 的网络发生抖动，或者机房 A 与机房 B 之间的跨光纤专线整体中断时：
• 机房 A 的 3 个节点可以自娱自乐地凑够 3 个 ACK，继续对外提供写服务。
• 但此时机房 B 实际上已经与 A 隔离。如果客户端在机房 B 也能访问，就会产生严重的 脑裂。
• 按 Team 约束：共识机制不能只看“总数”，而必须要求 每个关键 Team 内部都必须达成局部一致，或者多数派必须跨越物理机房边界，从而避免单一机房网络故障时盲目提交。

DBGroup 的同步状态，不以节点数量为判定依据，而是以 Team 为最小可用单元：每个 Team 至少存在一个同步节点，所有 Team 同时满足条件，DBGroup 才视为同步成功，这其实是 分组多数派（AZ-Quorum）的思想。

• 高水位：正常情况下，强一致性同步需要写入的 目标 Team 数量。
• 低水位：当有灾备机房断电或部分 Team 的机器挂掉时，集群降级运行允许的 最小活动 Team 数量。只要当前存活的 Team 数量不低于低水位，GTM 就能继续提供全局时间戳，数据库就不会脑裂或停摆。
• 配置建议：
• 当本地同城有 3 个及以上 team 时（高水位为 3，低水位为 2）；
• 当本地同城 2 个 team 时（高水位为 2，低水位为 1）；
• 当本地同城 1 个 team 时（高水位为 1，低水位为 1）。

Team 与 DN/GTM 实例、高低水位线 的串联工作逻辑：

在每一个 Team 内部，并不要求所有节点全部存活，而是通过参数约束局部响应：

• Team 内响应阈值：要求 Team 内必须有指定数量的备机（DB 实例或 GTM 实例）成功返回 ACK。
• 有效 Team（Valid Team）：只有当某个 Team 内的响应节点数达到了配置的阈值，该 Team 才会被系统判定为一个“健康的有效 Team”。如果该机房整体断网或瘫痪，其对应的 Team 就会变成“失效 Team”。

系统将所有“健康有效 Team 的数量”与用户配置的高水位线（HW） 和低水位线（LW）进行实时比对，从而决定整个 DBGroup 或 GTM Group 的运行状态：

• 高于或等于高水位线（Count ≥ HW）
• 状态：所有关键机房 Team 协同正常（如本地 + 同城 Team 同时达标）。
• 表现：业务全速运行，严格保障金融级强一致性（RPO=0），事务提交需要跨 Team 的强同步确认。
• 介于高低水位之间（LW ≤ Count  ≤ HW）
• 状态：部分机房/Team 发生故障或网络抖动（例如异地备机房失联，仅剩本地 Team 支撑）。
• 表现：业务继续正常运行，但系统会触发告警，在可用性（A）和一致性（C）之间做出妥协，优先保障业务不中断。
• 低于低水位线（Count ≤ LW ）
• 状态：有效 Team 数量严重不足（甚至有效 Team 个数小于 1）。
• 表现：系统判定当前处于极高风险状态（存在双写或脑裂隐患）， 对应的分片或 GTM 会自动切为“只读”状态，拒绝一切写请求。

1.5 DBProxy 参数

在 GoldenDB 中， DBProxy 就是 CN（计算节点）。它不存储业务数据，主要负责接收应用端的 SQL 请求、进行分布式解析、分发给底层数据节点（DN）并合并结果。

[DBPROXY]
# 安装节点，写重复代表
ip=10.0.0.11,10.0.0.12,10.0.0.11,10.0.0.12
# DBPROXY节点安装路径,
dbproxy_install_path=/home/goldendb
# dbproxy节点操作系统用户 zxdbproxyN 的密码
dbproxy_apply_user_pwvalue=******
# 数据库内部组件连接密码
dbproxy_pwvalue=******

参数说明：

• IP 里面出现 2 个重复的地址，说明每个节点安装 2 个 Proxy，所属用户分别是 zxdbproxy1, zxdbproxy2；

1.6 CLUSTER 参数

[CLUSTER] 配置是 GoldenDB 分布式数据库中最核心的部分，这里定义了 sys_cluster  系统租户 和 cluster_1 业务租户。 sys_cluster 主要存放在分布式集群运行过程中所需的 全局元数据、集群拓扑、系统配置与控制策略信息。业务租户则存放用户数据。

[CLUSTER]
# DB节点安装路径, 如不配置则使用[GENERAL]段中的install_path
db_install_path=/home/goldendb
# db节点操作系统用户密码
db_apply_user_pwvalue=******
# db root用户
default_pwvalue=******
# dbagent访问db pw
dbagent_pwvalue=******
# MDS访问DB
mds2proxy_pwvalue=******
super_maint_pwvalue=******
# AWR运维只读pw
gdbquery2db_pwvalue=******
# 字符集
sys_cluster_character_set_server=utf8mb4
sys_cluster_binlog_compress_flag=0
sys_cluster_binlog_compress_mode=zstd
sys_cluster_binlog_compress_level=1
sys_cluster_g1_team1=10.0.0.11,M;10.0.0.12,S
sys_cluster_g1_team2=10.0.0.13,S;10.0.0.14,S
sys_cluster_g1_team3=10.0.0.15,L;10.0.0.16,S
sys_cluster_conn1=10.0.0.11_dbproxy1,10.0.0.12_dbproxy1:8880
sys_cluster_dn_cgroup_limit=4C8G
sys_cluster_cn_cgroup_limit=4C8G
# cluster_1
# 主流字符集
c1_character_set_server=utf8mb4
# 关闭 Binlog 压缩
c1_binlog_compress_flag=0
c1_binlog_compress_mode=zstd
c1_binlog_compress_level=1
c1_dn_cgroup_limit=0C0G
c1_cn_cgroup_limit=0C0G
# 租户的分片模式。0 代表分布式分片模式，1 则代表集中式主备模式
c1_group_mode=0
c1_g1_team1=10.0.0.11,M;10.0.0.12,S
c1_g1_team2=10.0.0.13,S;10.0.0.14,S
c1_g1_team3=10.0.0.15,L;10.0.0.16,S
c1_g2_team1=10.0.0.15,M;10.0.0.16,S
c1_conn1=10.0.0.11_dbproxy2,10.0.0.12_dbproxy2:8880
# 该业务租户指定的 GTM 集群 节点
c1_gtmg1_team1=10.0.0.15,M;10.0.0.16,S

参数说明：

• sys_cluster_g1_team1 = 10.0.0.11,M;10.0.0.12,S，11 为 Master，12 为 Standby；
• sys_cluster_g1_team2=10.0.0.13,S;10.0.0.14,S ：在同城灾备中心的 .13 和 .14 两台机器上部署两个 Standby；
• sys_cluster_g1_team3=10.0.0.15,L;10.0.0.16,S ：15 担任 L（Logger，日志节点）， 日志节点不回放数据，只参与 Paxos 协议的投票和日志强一致性确认。总体来说 系统租户配置的是 1 主 4 备 1 日志 的架构，没有进行分片。

再看看业务租户 c 1:

• c1_g1_team1=10.0.0.11,M;10.0.0.12,S：同系统租户；
• c1_g1_team2=10.0.0.13,S;10.0.0.14,S：同系统租户；
• c1_g1_team3=10.0.0.15,L;10.0.0.16,S：同系统租户；
• c1_g2_team1=10.0.0.15,M;10.0.0.16,S ： g2 代表 业务集群的第二个数据分片（Shard 2）。分片 1 的主节点在 11（主中心），分片 2 的主节点在 15（另一个区域）。

最后看看 DBPROXY：

• sys_cluster_conn1=10.0.0.11_dbproxy1,10.0.0.12_dbproxy1:8880 和 c1_conn1=10.0.0.11_dbproxy2,10.0.0.12_dbproxy2:8880，两个租户的 Proxy 节点相同，因此每个节点回安装 2 个 Proxy。

1.7 LoadServer 参数

指定 LoadServer 的相关参数。

[LOADSERVER]
# 安装节点
ip=10.0.0.11,10.0.0.12
# LOADSERVER节点安装路径 
lds_install_path=/home/goldendb
# loadserver节点操作系统用户密码
loadserver_apply_user_pwvalue=******
# lds基线文件dn.json，如果不填写，则使用默认值安装
lds_template=

1.8 Insight 参数

为了实现 OMM & Insight 的金融级高可用和防止集群脑裂，可以选择安装 ZooKeeper 集群， Zookeeper 在昨天的文章中介绍过了，满足 CAP 理论中的典型 CP 系统。

[INSIGHT]
zk_server_ip=10.0.0.1,10.0.0.2,10.0.0.3
# zookeeper客户端连接端口
zk_server_port=32181
# 心跳端口
zk_heartbeat_port=2888
# 选举端口
zk_elect_port=3888
# 是否安装zk，1代表全新安装或者制作zk大数据组件镜像，2代表使用已有的组件（仅修改配置），3代表制作需要zk的管理节点镜像（不实际安装，仅入库）
install_zk=1
# https访问insight界面的端口
https_server_port=8444
# insight的热部署LiveReload服务监听端口
live_reload_port=35729
# https访问Agent采集端服务端口，建议使用
https_port=8024
# 主机代理与omm的socket通信建链端口
socketPort=8028
# INSIGHT安装路径, 如不配置则使用[GENERAL]段中的install_path
insight_install_path=/home/goldendb
# insight应用用户名, 置空则使用[GENERAL]段中的user_prefix + insight
insight_user=insight
# insight应用用户pw
insight_apply_user_pwvalue=******
# insight应用用户uid， install_carrier=2时生效
insight_apply_user_uid=1334
# cgroup资源限制，配置格式为_C_G（_处填写数字）不配置则留空，会不做资源限制即（会自动设置为0C0G，最小为2C6G
# insight内存限制小于11G时，is进程内存对应调小，并关闭大部分采集指标（可从页面手动开启，但需注意资源影响）
insight_cgroup_limit=0C0G

以上就是安装 GoldenDB 时，需要配置的参数文件，看着比较复杂，但只要在部署前完成 集群规划、Team 故障域划分及组件节点布局，整体配置逻辑便会十分清晰。

2. 安装过程

2.1 设计部署角色

公众号里 GoldenDB 系列的第一篇文章，由于编辑器原因参数文件没有换行，不能直接使用。加上部署的集群中第一个节点部署的组件太多，因此，重新设计成如下，再进行部署。

2.2 配置 install\_senior.ini 文件

[GENERAL]
# 安装机器登录用户
root_user=root
# root 用户密码
root_pwvalue=12341234
# 用户前缀
user_prefix=zx
# goldendb用户组名
user_group_name=golden
user_group_id=600
gdb_normal_user_pwd=Gdcp@2026
# 安装路径
install_path=/home/goldendb
license_dat_path=
# 0代表单个管理节点，2 代表ZK
install_type=0
install_tenancy=0
install_carrier=0
system_parameter=1
omm_domain_name=192.168.182.41
omm_listen_port=6471
rdb_port=3309
rdb_admin_port=65100
rdb_super_pwvalue=Gdcp@2026#
rdb_repl_pwvalue=Gdcp@2026#
rdb_normal_pwvalue=Gdcp@2026#
rdb_root_pwvalue=Gdcp@2026#
mysql_client_switch=1
jdk_switch=1
# 环境初始化
[REMOTEENV]
DBPROXY|ip_local_reserved_ports=8880-10000
# 所有服务器
[NODES]
local_room=Region|AZ1-上海嘉定|192.168.182.41,192.168.182.42,192.168.182.43|1
city_room1=
city_room2=
remote_room1=
remote_room2=
# 单个管理节点安装, 管理节点所有组件都安装在 golden1 上
[MANAGER_SINGLE]
local_room_ip=192.168.182.41
city_room1_ip=
remote_room1_ip=
manager_install_path=/home/goldendb
manager_apply_user_pwvalue=Gdcp@2026#
manager_apply_user_uid=1332
# GTM组件
[GTM]
gtm_install_path=/home/goldendb
gtm_apply_user_pwvalue=Gdcp@2026#
#由于资源限制，GTM 只配置一个节点
sys_gtmg1_team1=192.168.182.43,M
sys_gtm_template=
increment_persistence=1
is_master_count=1
response_num=1
hw=1
lw=1
auto_switch_between_different_room=0
[DBPROXY]
#配置两个 Proxy，分别给系统租户和业务租户使用
ip=192.168.182.42,192.168.182.43
dbproxy_install_path=/home/goldendb
dbproxy_apply_user_pwvalue=Gdcp@2026#
dbproxy_pwvalue=Gdcp@2026#
# 集群信息
[CLUSTER]
# DB节点安装路径
db_install_path=/home/goldendb
# 各组件访问及内部管理密码
db_apply_user_pwvalue=Gdcp@2026#
default_pwvalue=Gdcp@2026#
dbagent_pwvalue=Gdcp@2026#
mds2proxy_pwvalue=Gdcp@2026#
super_maint_pwvalue=Gdcp@2026#
gdbquery2db_pwvalue=Gdcp@2026#
# ==================== SYS_CLUSTER (系统租户)  ==================
sys_cluster_character_set_server=utf8mb4
sys_cluster_binlog_compress_flag=0
sys_cluster_binlog_compress_mode=zstd
sys_cluster_binlog_compress_level=1
# 系统租户绑定的 GTM 节点
sys_cluster_g1_team1=192.168.182.41,M
# 系统租户绑定 42 的 Proxy
sys_cluster_conn1=192.168.182.42_dbproxy1:8880
# ==================== CLUSTER_1 (业务租户) ====================
c1_character_set_server=utf8mb4
c1_binlog_compress_flag=0
c1_binlog_compress_mode=zstd
c1_binlog_compress_level=1
# 1 代表单分片模式，0 代表多分片模式
c1_group_mode=1
c1_g1_team1=192.168.182.43,M;192.168.182.42,S;192.168.182.41,S
# 业务租户绑定的 43 Proxy
c1_conn1=192.168.182.43_dbproxy1:8881
# 业务租户为集中式，绑定 GTM 会报错
# c1_gtmg1_team1=192.168.182.43,M
c1_template=
# ==================== 其他大数据与周边组件 ====================
[LOADSERVER]
# 资源受限，选择只安装一个
ip=192.168.182.43
lds_install_path=/home/goldendb
loadserver_apply_user_pwvalue=Gdcp@2026#
lds_template=
# insight安装配置
[INSIGHT]
# zk安装服务器列表
zk_server_ip=192.168.182.41
# zookeeper客户端连接端口
zk_server_port=32181
# 心跳端口
zk_heartbeat_port=2888
# 选举端口
zk_elect_port=3888
# 1 代表全新安装 ZK 监控集群，不过是单节点的
install_zk=1
https_server_port=8444
live_reload_port=35729
https_port=8024
socketPort=8028
# INSIGHT安装路径
insight_install_path=/home/goldendb
# insight应用用户名
insight_user=insight
insight_apply_user_pwvalue=Gdcp@2026#
# insight应用用户uid
insight_apply_user_uid=1334
insight_cgroup_limit=2C6G

2.3 铲掉残留环境

# 1. 强行终止所有 goldendb 的进程
pkill -9 -u insight 2>/dev/null; 
pkill -9 -u zxgtm1 2>/dev/null; 
pkill -9 -u zxdb1 2>/dev/null; 
pkill -9 -u zxdb2 2>/dev/null; 
pkill -9 -u zxdbproxy1 2>/dev/null; 
pkill -9 -u zxmanager 2>/dev/null; 
pkill -9 -u zxgdbcheck 2>/dev/null; 
pkill -9 -u zxload1 2>/dev/null; 
ps -ef|grep -i insight|grep -v grep|awk '{print $2}'|xargs sudo kill -9
 # 2. 删除所有用户和用户组
for u in $(cat /etc/passwd | awk -F: '{print $1}' | grep -E "insight|zxgtm|zxdb|zxdbproxy|zxmanager|zxgdbcheck|zxload"); 
do userdel -r "$u" 2>/dev/null; done; 
groupdel golden 2>/dev/null; 
# 3. 清理缓存
echo 3 > /proc/sys/vm/drop_caches
# 4. 验证以上用户和用户组是否删除
cat /etc/passwd | grep -E "insight|zxgtm|zxdb|zxdbproxy|zxmanager|zxgdbcheck|zxload" && cat /etc/group | grep golden
# 5. 删除磁盘上的数据文件
rm -rf /home/goldendb

2.4 执行安装

cd /home/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install
sh setup.sh -a "" "/home/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12.zip"

细节就不一一展示了，第一篇文章中有详解。可将参数文件复制，直接替换 IP，便可一键安装成功。下一期，我们探索一下   GoldenDB 的进程架构、监听端口及核心目录布局。

*  这里是《实战派 K 8 S&DB》，更多干货敬请关注公众号。如果本文对你有所帮助，欢迎点赞、推荐和转发，也欢迎关注后续文章，一起考证、一起学习 GoldenDB 分布式数据库。*