数据库教程FGMT84：国产数据库-GoldenDB数据库工程师培训（中兴GoldenDB金融级/运营商级分布式数据库）
数据库教程FGMT84：国产数据库-GoldenDB数据库工程师培训（中兴GoldenDB金融级/运营商级分布式数据库）
## 前言与本套风哥教程内容大纲
风哥教程本文是本套风哥教程的技术主体，面向主机工程师、数据库工程师、数据库DBA与IT运维人员，目标是让读者在一台 8 核 CPU、64GB 内存的实验规格上，完整走通中兴 GoldenDB 金融级/运营商级分布式数据库的原理认知、集群规划、安装配置、启停管理、连接使用与日常运维全流程。本套风哥教程不做产品宣传，所有结论以可复现的配置项、命令与现象为准，涉及的软件安装包请读者自行从官方渠道获取，生产与测试环境需求请联系 GoldenDB 官方厂家。
风哥教程本文的内容组织遵循”先懂原理、再动手、最后会运维”的顺序，大纲如下：第一部分为 GoldenDB 基础知识与体系架构，包括产品定位、核心特性、应用场景、整体架构与关键组件；第二部分为 GoldenDB 集群部署模式与应用场景，说明集中式与分布式、单机房与多机房的选型边界；第三部分为 GoldenDB 集群部署规划与环境要求，给出 8C64G 规格下的节点、端口、资源与操作系统基线规划；第四部分为 GoldenDB 数据库集群安装配置实战，逐段解析 install_senior.ini 并执行一键安装；第五部分为 GoldenDB 数据库集群启动与停止，覆盖状态检查、启停顺序与主备切换；第六部分为 GoldenDB 数据库连接登录与业务使用，完成建库、建分片表、写入、查询与执行计划验证；第七部分为 GoldenDB 数据库集群日常管理维护指南，覆盖扩容分片、备份恢复、读写分离、监控巡检与故障处置。
—
## 第一部分 GoldenDB 数据库基础知识与体系架构（理论）
### 1.1 GoldenDB 产品定位
GoldenDB 是中兴通讯股份有限公司研发、由其控股子公司金篆信科有限责任公司管理的金融级、运营商级国产分布式数据库。金篆信科成立于 2021 年 11 月，总部位于北京，注册资本超过 6.2 亿元，研发人员超过 600 人。GoldenDB 历经二十余年技术积累，拥有专利超过 800 项，内核自主掌控，于 2024 年 9 月成为首批通过国家安全可靠测评的分布式数据库之一。从技术血统上看，GoldenDB 的数据节点（DN）基于 MySQL 内核演进，上层叠加分布式计算、全局事务与集群管理能力，因此它对 MySQL 生态的 SQL 语法、客户端协议、运维习惯有很高的兼容性，这也是 DBA 迁移学习成本较低的根本原因。
风哥提醒读者注意一个容易混淆的概念：GoldenDB 不是”把 MySQL 简单堆在一起”。它在 MySQL 之上增加了无状态计算层、全局事务协调层与统一管理层，把单机 MySQL 的本地事务扩展为跨分片的分布式事务，把单实例的高可用扩展为分片组级别的强同步高可用。理解这一点，是看懂后续所有配置项的前提。
### 1.2 GoldenDB 核心特性
本套风哥教程将官方特性归纳为技术视角下的十二项，逐项说明其工程含义。
第一，分布式事务强一致性。跨分片事务由全局事务管理器（GTM）分配全局唯一事务标识与时间戳，计算节点（CN）协调各数据节点（DN）完成两阶段提交，保证一笔转账类事务要么全部成功、要么全部回滚，RPO 趋近于 0，这是金融核心系统的底线要求。
第二，灵活的数据切片技术。支持 Range、Has-h、List 三种水平分片规则，支持复制表（DUPLICATE），支持分片之上再做本地分区（PARTITION BY），也支持多级分片，DBA 可以按业务访问模式把热点数据打散到不同分片组。
第三，高 SQL 语法兼容性。DN 沿用 MySQL 语法与协议，应用侧使用标准 MySQL JDBC/ODBC 驱动即可接入，绝大多数单表 SQL 无需改造；只有跨分片 JOIN、分布式事务、分片键更新等场景需要按规则设计。
第四，高可用性。每个分片组由一主多备组成，备机以强同步方式复制主库日志，主库故障时在分片组内部自动选举切换，切换过程对应用透明；GTM、管理节点同样以集群或主备方式部署，整体架构无单点故障。
第五，可扩展性。分片可以在线新增，新增分片后通过数据重分布把存量数据迁移到新分片，扩容过程不中断业务，理论上支持水平无限扩展。
第六，高性能与混合负载能力。计算层无状态，可横向扩展承接连接；数据层按分片并行执行；同时支持交易型计算节点与分析型计算节点分离的 HTAP 形态，OLTP 交易与 OLAP 分析互不抢占。
第七，读写分离。分片组内的备机可以承接只读请求，CN 根据事务类型与读负载把读请求路由到主或备，提升整体吞吐。
第八，数据备份恢复。支持基于 MySQL 生态的逻辑备份与物理备份，配合 LoadServer（LDS）完成数据装载与迁移，支持按时间点恢复。
第九，多租户部署能力。一套物理集群可以划分出 sys_cluster 系统租户与多个业务租户（cluster_1、cluster_2……），各租户的元数据、分片、GTM 绑定相互隔离，便于在同一套资源上承载多个业务库。
第十，云化支持能力。资源以 cgroup 做 CPU/内存隔离，支持物理机、虚拟机、容器混合载体部署，可作为数据库云服务标准化交付。
第十一，图形化运维。通过 Insight（前端展示）+ OMM（后端管理）Web 界面完成拓扑查看、启停、主备切换、分片扩容、监控告警，降低命令行操作风险。
第十二，自主、安全、可控。内核自主研发，全栈适配国产芯片与操作系统，满足信创环境要求。
> 风哥 itpux-com
### 1.3 GoldenDB 应用场景
从技术落地角度，GoldenDB 主要服务三类场景。其一是核心交易系统下移，即把传统大型机/小型机上的银行账务、支付、计费核心库迁移到分布式数据库，要求强一致、高可用、高并发；其二是构建数据库云服务平台，在统一集群上为多个业务部门提供隔离的租户库；其三是提升交易系统的快速决策能力，通过 HTAP 把实时分析与交易放在同一底座，避免再建一套数仓。
风哥教程本文的实验环境对应最小化的分布式单机房部署，读者掌握这套最小形态后，再向同城双机房、异地灾备扩展只是配置项的增加，原理不变。
### 1.4 GoldenDB 体系架构
GoldenDB 整体由计算节点、数据节点、全局事务管理器、管理节点四种核心模块组成，外围包含数据迁移装载模块 LoadServer、运维监控模块 Insight/OMM 以及管理协调用的 ZooKeeper。风哥把每个模块的职责、内存视角与端口归纳如下。
**计算节点（CN，即安装配置中的 DBPROXY）**：无状态组件，不存储业务数据。它接收应用发来的 MySQL 协议请求，完成 SQL 解析、查询优化、分片路由计算，把一条 SQL 拆成发往各 DN 的子 SQL，再把各 DN 返回的结果集合并、聚合、排序后返回给应用。CN 可以部署多个，应用通过负载均衡或连接列表访问任一 CN。
**数据节点（DN，配置段 [CLUSTER] 中的 DB）**：真正存储数据的 MySQL 内核实例。一个分片组（DBGroup）由一个 Master 和若干 Standby（以及可选的 Logger 日志节点）组成，组内强同步复制。分片组是高可用与故障切换的最小单元，数据按分片键分布在不同分片组上。
**全局事务管理器（GTM）**：维护全局事务的全生命周期，提供全局事务的申请、释放、查询，分配全局事务号与一致性时间戳，采用集群方式部署，主备强同步。没有 GTM，跨分片的两阶段提交就无法保证全局一致。
**管理节点（Manager，含 MDS/PM/CM）**：保存全局元数据、集群拓扑、系统配置与控制策略，负责组件注册、状态协调与调度。DG理节点模式下 Metadataserver、ProxyManager、ClusterManager、LoadServer 装在同一台机器；ZK 模式下多管理节点基于 ZooKeeper 选主防脑裂。
**Insight/OMM**：Insight 是 Web 前端展示，OMM 是后端管理服务，RDB 是 Insight 自身使用的后台 MySQL 库（默认端口 3309）。运维人员通过 Insight 页面查看拓扑、组件状态、监控指标并执行管理操作。
**LoadServer（LDS）**：数据装载与迁移组件，用于把外部存量数据批量导入新分片，或在扩容时配合数据重分布。
**ZooKeeper**：在 ZK 管理模式下为管理节点选主、为元数据一致性提供协调，属于典型 CP 系统。
逻辑层级从上到下为：应用 → CN（计算层）→ 分片组 DBGroup → 响应组 Team → 物理 DN 实例。这里要重点理解 **Team（响应组）** 的概念：Team 是机房级故障域的最小评估单元，同一个机房内的副本划为同一 Team。集群判断同步成功时不只是数收到几个 ACK，而是要求每个关键 Team 都达到响应阈值，从而避免单机房断网时本机房节点凑够多数派盲目提交造成脑裂。系统据此设置高水位（HW）与低水位（LW）：有效 Team 数 ≥ HW 时全速强同步运行；介于 LW 与 HW 之间时业务继续但触发降级告警；低于 LW 时对应分片或 GTM 自动切只读，拒绝写入。
### 1.5 分布式事务与分片的工程理论
跨分片事务的难点在于：一条 `UPDATE account SET bal=bal-100 WHERE id=1` 命中分片 A，另一条 `UPDATE account SET bal=bal+100 WHERE id=2` 命中分片 B，两个 DN 各自的本地事务无法互相感知成败。GTM 为这笔全局事务分配唯一标识，CN 先向各 DN 发送 Prepare，全部就绪后由 GTM 协调 Commit，任一 DN 失败则全局 Rollback。这就是两阶段提交，代价是多一次网络往返，因此事务内尽量只访问同一分片键的数据（单分片事务走本地事务路径，性能最好）。
分片规则方面，Range 分片按分片键值区间落组，适合时间序列、自增 ID；Has-h 分片按哈希取模打散，适合均衡负载；List 分片按枚举值落组，适合按地域、机构划分；DUPLICATE 复制表把全量数据复制到指定的每个分片组，适合字典表、维表，读可并行但写需同步复制所有副本。分片键的选择是设计核心：高基数、查询必带、避免更新、尽量让关联数据同组。
### 1.6 GoldenDB 集群部署模式与应用场景
安装包提供三种安装模式：快速安装 install_fast.ini（单机房，由安装程序自动规划组件与拓扑，适合学习与小规模验证）；自定义安装 install_advance.ini（单机房，人工规划）；标准安装 install_senior.ini（多机房，人工规划本机房/同城/异地 AZ，适合生产）。本套风哥教程以标准安装配置文件 install_senior.ini 为主线讲解，因为看懂它就能反推快速安装自动生成的结果。
部署形态分集中式与分布式：集中式（group_mode=1）只有一个分片组，本质是一主多备的 MySQL 高可用，不水平扩展；分布式（group_mode=0）有多个分片组，数据水平切分，是 GoldenDB 的主体形态。生产再按机房划分为单机房、同城双活、异地灾备，对应配置文件里的 local_room、city_room1/2、remote_room1/2。
> 风哥教程 113257174
### 1.7 集群部署规划与环境要求（8C64G 规格）
本套风哥教程实验采用两台物理/虚拟服务器，均为 8 核 CPU、64GB 内存，主机名 fgedu-net-cn1、fgedu-net-cn2，操作系统以 RHEL/CentOS 兼容发行版为例，规划如下：
| 节点 | IP | 承担组件 |
| — | — | — |
| fgedu-net-cn1 | 192.168.10.11 | DG理节点 Manager、Insight/OMM、RDB、GTM 主、CN(dbproxy1)、分片 g1 主、g2 备 |
| fgedu-net-cn2 | 192.168.10.12 | GTM 备、CN(dbproxy2)、分片 g1 备、g2 主、LoadServer |
资源按 8C64G 用 cgroup 隔离：管理节点 4C16G、CN 4C16G、DN 4C24G、GTM 2C8G、Insight 4C16G、RDB 2C8G、LDS 2C8G。默认安装路径统一为 /fgedudb（凡旧资料中的 /u01 一律替换为 /fgedudb）。业务数据库名、实例名、用户名统一为 fgedudb、fgedudb、fgedu，应用访问密码示例为 Fgedu@2026。关键监听端口：CN 业务端口 8880/8881，RDB 3309、RDB 管理端口 65100，OMM 6471，Insight HTTPS 8444，ZK 客户端 32181、心跳 2888、选举 3888。
操作系统基线要求：配置静态 IP 与主机名互信、关闭防火墙与 NetworkManager、关闭 SELinux、设置 Asia/s-hanghai 时区、禁用透明大页与 NUMA（Intel 环境）、放大文件句柄与进程数限制、安装 python2 及 PyMySQL/kazoo 依赖、使用产品包自带的 mysql 客户端与 JDK。这些基线是安装脚本能否一次通过的前提。
—
## 第二部分 GoldenDB 数据库集群安装配置实战
### 2.1 操作系统基础环境准备（两台节点分别执行）
第一步，配置主机名并重启生效：
“`bas-h
# fgedu-net-cn1 上执行
hostnamectl set-hostname fgedu-net-cn1
# fgedu-net-cn2 上执行
hostnamectl set-hostname fgedu-net-cn2
“`
第二步，在两台机器的 /etc/hosts 中写入互解析：
“`bas-h
cat >> /etc/hosts <<‘EOF’
192.168.10.11 fgedu-net-cn1
192.168.10.12 fgedu-net-cn2
EOF
“`
第三步，关闭并禁用防火墙与 NetworkManager：
“`bas-h
systemctl stop NetworkManager firewalld.service
systemctl disable NetworkManager firewalld.service
“`
第四步，关闭 SELinux：
“`bas-h
sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/’ /etc/selinux/config
setenforce 0
“`
第五步，设置时区并校对时间：
“`bas-h
timedatectl set-timezone Asia/s-hanghai
date
“`
第六步，禁用透明大页与 NUMA（Intel 平台建议关闭 NUMA；Hygon/AMD/ARM 平台建议保留 NUMA）：
“`bas-h
sed -i ‘s/GRUB_CMDLINE_LINUX=”/GRUB_CMDLINE_LINUX=”transparent_hugepage=never numa=off /g’ /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
“`
重启后验证：
“`bas-h
cat /sys/kernel/mm/transparent_hugepage/enabled
dmesg | grep -i numa
“`
第七步，修改文件句柄与进程数限制：
“`bas-h
cat >> /etc/security/limits.conf <<‘EOF’
* soft nofile 655350
* hard nofile 655350
* soft stack unlimited
* hard stack unlimited
* soft nproc 655360
* hard nproc 655360
* soft core unlimited
* hard core unlimited
EOF
“`
第八步，安装系统依赖与 python2：
“`bas-h
yum install -y python2 python2-devel numactl perl-Time-HiRes \
bind-chroot java-1.8.0-openjdk gcc unixODBC bind-libs tar expect \
python-devel python-setuptools python-pip
“`
> 风哥数据库教程 itpux-com
### 2.2 上传安装包与依赖准备
把 GoldenDB 全量安装包上传到 fgedu-net-cn1 的 /root 目录并解压到 /fgedudb 同级目录，解压后目录名形如 ZXCLOUD-GoldenDB-ALL-RHVx.x.xx：
“`bas-h
mkdir -p /fgedudb
cd /root
unzip ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12.zip -d /fgedudb/
ls /fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install/
“`
安装脚本依赖 PyMySQL 与 kazoo，在 fgedu-net-cn1 的 install 目录分别安装：
“`bas-h
cd /fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install
tar -zxvf ./prepare_env/PyMySQL-master.tar.gz
cd PyMySQL-master && python setup.py install && cd ..
tar -zxvf ./prepare_env/kazoo-2.6.1.tar.gz
cd kazoo-2.6.1 && python setup.py install && cd ..
“`
### 2.3 配置 install_senior.ini（八段参数，8C64G 规格）
风哥强调，install_senior.ini 是标准安装的核心，分 [GENERAL]、[NODES]、[MANAGER_SINGLE]、[GTM]、[DBPROXY]、[CLUSTER]、[LOADSERVER]、[INSIGHT] 八段。下面给出按本套风哥教程环境改写后的完整文件，并逐段说明。
“`ini
[GENERAL]
# 安装所用高权用户
root_user=root
root_pwvalue=Fgedu@2026
# 操作系统组件用户前缀与公共组
user_prefix=zx
user_group_name=goldendb
gdb_normal_user_pwd=Fgedu@2026
# 安装路径：所有组件 bin/data/log 均在此目录下
install_path=/fgedudb
# 0=DG理节点，2=ZK 管理节点
install_type=0
# 0=完整安装（Manager/GTM/LDS/DB/Proxy 并组建集群）
install_tenancy=0
# 0=物理机/虚拟机，1=管理节点物理、其余容器，2=管理节点容器
install_carrier=0
# 安装脚本是否直接修改系统内核参数
system_parameter=1
# OMM 后端地址与监听端口（填 Insight 所在节点）
omm_domain_name=192.168.10.11
omm_listen_port=6471
# RDB（Insight 后台库）端口与管理端口
rdb_port=3309
rdb_admin_port=65100
# RDB 各类内部用户密码
rdb_super_pwvalue=Fgedu@2026
rdb_repl_pwvalue=Fgedu@2026
rdb_normal_pwvalue=Fgedu@2026
rdb_root_pwvalue=Fgedu@2026
# 使用产品包自带 mysql 客户端与 JDK
mysql_client_switch=1
jdk_switch=1
[REMOTEENV]
DBPROXY|ip_local_reserved_ports=8880-10000
[NODES]
# Region|AZ-城市|IP列表|AZ优先级
local_room=Region1|AZ1-Chengdu|192.168.10.11,192.168.10.12|1
city_room1=
city_room2=
remote_room1=
remote_room2=
[MANAGER_SINGLE]
# DG理节点只允许一个 IP，填本机房节点
local_room_ip=192.168.10.11
city_room1_ip=
remote_room1_ip=
manager_install_path=/fgedudb
manager_apply_user_pwvalue=Fgedu@2026
manager_apply_user_uid=1332
# 8C64G 规格：管理节点上限 4C16G，0C0G 表示不限制
manager_cgroup_limit=4C16G
[GTM]
gtm_install_path=/fgedudb
gtm_apply_user_pwvalue=Fgedu@2026
# GTM 一主一备，M=Master，S=Standby
sys_gtmg1_team1=192.168.10.11,M;192.168.10.12,S
sys_gtm_template=
increment_persistence=3
is_master_count=1
response_num=1
hw=1
lw=1
auto_switch_between_different_room=0
# 8C64G：GTM 上限 2C8G
gtm_cgroup_limit=2C8G
[DBPROXY]
# 两台节点各装一个 CN，重复 IP 代表同机多实例
ip=192.168.10.11,192.168.10.12
dbproxy_install_path=/fgedudb
dbproxy_apply_user_pwvalue=Fgedu@2026
dbproxy_pwvalue=Fgedu@2026
[CLUSTER]
db_install_path=/fgedudb
db_apply_user_pwvalue=Fgedu@2026
default_pwvalue=Fgedu@2026
dbagent_pwvalue=Fgedu@2026
mds2proxy_pwvalue=Fgedu@2026
super_maint_pwvalue=Fgedu@2026
gdbquery2db_pwvalue=Fgedu@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
sys_cluster_g1_team1=192.168.10.11,M;192.168.10.12,S
sys_cluster_conn1=192.168.10.11_dbproxy1:8880
# ===== cluster_1 业务租户（库名 fgedudb）=====
c1_character_set_server=utf8mb4
c1_binlog_compress_flag=0
c1_binlog_compress_mode=zstd
c1_binlog_compress_level=1
# 0=多分片分布式，1=单分片集中式
c1_group_mode=0
# 分片组 g1：主在 cn1，备在 cn2
c1_g1_team1=192.168.10.11,M;192.168.10.12,S
# 分片组 g2：主在 cn2，备在 cn1（跨节点分布，避免单点）
c1_g2_team1=192.168.10.12,M;192.168.10.11,S
# 业务租户绑定的 CN 与端口
c1_conn1=192.168.10.11_dbproxy1:8880
c1_conn2=192.168.10.12_dbproxy1:8881
# 业务租户绑定 GTM 集群
c1_gtmg1_team1=192.168.10.11,M;192.168.10.12,S
# 8C64G：CN 上限 4C16G，DN 上限 4C24G
c1_cn_cgroup_limit=4C16G
c1_dn_cgroup_limit=4C24G
c1_template=
[LOADSERVER]
ip=192.168.10.12
lds_install_path=/fgedudb
loadserver_apply_user_pwvalue=Fgedu@2026
lds_template=
lds_cgroup_limit=2C8G
[INSIGHT]
zk_server_ip=192.168.10.11
zk_server_port=32181
zk_heartbeat_port=2888
zk_elect_port=3888
install_zk=1
https_server_port=8444
live_reload_port=35729
https_port=8024
socketPort=8028
insight_install_path=/fgedudb
insight_user=insight
insight_apply_user_pwvalue=Fgedu@2026
insight_apply_user_uid=1334
insight_cgroup_limit=4C16G
“`
逐段要点：[GENERAL] 决定安装路径、模式与各类内部密码，install_path=/fgedudb 是后续所有组件的根；[NODES] 用 Region|AZ-城市|IP|优先级 描述机房拓扑，本实验只有单机房 local_room；[MANAGER_SINGLE] 在 install_type=0 时生效，只允许一个管理 IP；[GTM] 的 sys_gtmg1_team1 用 M/S 标注主备，hw/lw 是高低水位；[DBPROXY] 的 ip 列表中重复地址代表同机多实例；[CLUSTER] 是核心，sys_cluster 放元数据，c1 是业务租户，c1_group_mode=0 表示分布式多分片，c1_g1_team1、c1_g2_team1 定义两个分片组的主备归属；[LOADSERVER] 负责装载；[INSIGHT] 定义 Web 监控与内嵌 ZK 端口。
### 2.4 清理残留环境（重装前必做）
若机器上有失败的旧安装，先强杀组件进程、删除组件用户与目录：
“`bas-h
pkill -9 -u insight 2>/dev/null
pkill -9 -u zxgtm1 2>/dev/null
pkill -9 -u zxgtm2 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 zxdbproxy2 2>/dev/null
pkill -9 -u zxmanager 2>/dev/null
pkill -9 -u zxload1 2>/dev/null
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 goldendb 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches
rm -rf /fgedudb/*
“`
### 2.5 执行一键安装
进入 install 目录执行 setup.s-h，传入安装包与配置文件：
“`bas-h
cd /fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install
s-h setup.s-h -a “” \
“/fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12.zip” \
“/fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install/config/install_senior.ini”
“`
安装过程共约 16 步：环境检查、远程免密、创建用户、部署各组件、初始化数据库、组建集群、启动非管理节点、安装后环境检查。若磁盘较慢导致初始化等待超时，可调大 global_args.py 中的等待次数与间隔：
“`bas-h
vi /fgedudb/ZXCLOUD-GoldenDB-ALL-RHV6.1.03.12/oneKeyInstallUpdate/install/global_args.py
MAX_INTERVAL_COUNT = 60
INTERVAL_TIME = 60
“`
安装成功的标志是日志末尾出现 16/16 步”安装结果:成功”，并输出校验表 omm function / component status / component links / proxy function / rdb data / rdb master slave 全部 success，Final Result 为 PASS。
### 2.6 安装结果验证
先看进程，在两台节点分别确认 CN、DN、GTM 进程存在：
“`bas-h
ps -ef | grep -E “zxdbproxy|zxdb[0-9]|zxgtm|zxmanager|insight” | grep -v grep
“`
再看监听端口，fgedu-net-cn1 应能看到 8880、3309、65100、6471、8444、32181：
“`bas-h
ss -lntp | grep -E “8880|8881|3309|65100|6471|8444|32181”
“`
访问 Insight Web 界面：浏览器打开 [https://192.168.10.11:8444](https://192.168.10.11:8444)，默认账号 admin，密码 Insight@2020。登录后在拓扑视图应看到：管理节点 1 个、GTM 一主一备、CN 两个、分片组 g1/g2 各一主一备、RDB 正常。命令行也可用 ommtool 检查后端状态：
“`bas-h
/fgedudb/zxmanager/bin/ommtool -status
“`
输出 `ommtool -status is OK` 即表示管理后端正常。
> 网上搜索风哥教程可以学习全套数据库教程
—
## 第三部分 GoldenDB 数据库集群启动与停止
### 3.1 启停总原则
GoldenDB 由 OMM 统一纳管，生产环境优先通过 Insight/OMM 图形界面执行集群、分片组、节点的启动与停止，避免命令行误操作。命令行层面只做状态核查与应急处置。启动顺序为：管理节点 → GTM → CN → DN（分片组）；停止顺序相反：DN → CN → GTM → 管理节点。先停数据层、先起管理层，是为了让组件注册与元数据先就绪。
### 3.2 状态检查命令
查看管理后端与组件注册状态：
“`bas-h
/fgedudb/zxmanager/bin/ommtool -status
“`
查看各节点进程与存活：
“`bas-h
# fgedu-net-cn1
ps -ef | grep -E “zxdbproxy1|zxdb1|zxdb2|zxgtm1|zxmanager|insight” | grep -v grep
# fgedu-net-cn2
ps -ef | grep -E “zxdbproxy1|zxdb1|zxdb2|zxgtm1” | grep -v grep
“`
查看 CN 端口连通性：
“`bas-h
mysql -h 192.168.10.11 -P 8880 -u fgedu -p’Fgedu@2026′ -e “SELECT 1;”
“`
查看 DN 主备角色与复制状态，登录分片组主库执行：
“`bas-h
mysql -h 192.168.10.11 -P 3306 -u root -p’Fgedu@2026′ -e “s-hOW REPLICA STATUS\G”
“`
### 3.3 通过 Insight 执行启停与主备切换
在 Insight 拓扑视图中选中集群或分片组，右键菜单提供启动集群、停止集群、主备切换、节点下线/上线。执行主备切换时，系统先确认备机已追上日志、Team 达到响应阈值，再把新主提升并更新路由，期间业务连接会有短暂重连，应在低峰执行。
应急场景下如需命令行停止某组件，先确认其在拓扑中已被 OMM 标记下线，再 kill 对应用户进程；严禁直接 kill 正在提供服务的主库进程而不做切换，否则会触发强制选主与告警。
### 3.4 常见启停故障排查
若 Insight 页面组件显示红色，按四层定位：先看进程是否存活（ps），再看端口是否监听（ss），再看日志目录 /fgedudb/zxdbproxy1/log、/fgedudb/zxdb1/log、/fgedudb/zxgtm1/log 下的 error 日志，最后看网络与防火墙。管理节点起不来先查 RDB（3309）与 OMM（6471）；GTM 起不来先查主备间 2888/3888 心跳选举端口连通；CN 连不上先查 8880 端口与 dbagent 连通。
—
## 第四部分 GoldenDB 数据库连接登录与业务使用
### 4.1 使用自带 mysql 客户端连接 CN
应用与 DBA 都通过 CN 的 MySQL 协议端口接入，不直连 DN。fgedu-net-cn1 上使用产品包自带客户端连接业务租户：
“`bas-h
/fgedudb/zxdbproxy1/bin/mysql -h 192.168.10.11 -P 8880 \
-u fgedu -p’Fgedu@2026′ fgedudb
“`
登录后提示符进入 fgedudb 库。先查看当前连接信息与分片拓扑：
“`sql
SELECT VERSION();
s-hOW DATABASES;
“`
### 4.2 创建业务库与账号（系统租户侧）
S首接入先在管理侧确认业务库 fgedudb 已创建，并授予 fgedu 用户权限：
“`sql
CREATE DATABASE IF NOT EXISTS fgedudb DEFAULT CHARACTER SET utf8mb4;
CREATE USER IF NOT EXISTS ‘fgedu’@’%’ IDENTIFIED BY ‘Fgedu@2026’;
GRANT ALL PRIVILEGES ON fgedudb.* TO ‘fgedu’@’%’;
FLUs-h PRIVILEGES;
“`
### 4.3 创建分片表、复制表与分区组合表
本套风哥教程以订单表为例，演示三种表形态。第一种：Has-h 分片表，按 order_id 水平打散到 g1、g2 两个分片组，分片键必须包含在主键中：
“`sql
CREATE TABLE tb_orders_has-h (
order_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
region_code VARCHAR(10) NOT NULL,
amount DECIMAL(10,2) DEFAULT NULL,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (order_id, user_id)
)
DISTRIBUTED BY HAs-h(order_id) (g1, g2);
“`
第二种：Range 分片表，按创建月份 ym 区间落组：
“`sql
CREATE TABLE tb_orders_range (
order_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
ym INT NOT NULL,
amount DECIMAL(10,2) DEFAULT NULL,
PRIMARY KEY (order_id, ym)
)
DISTRIBUTED BY RANGE(ym) (
g1 VALUES LESS THAN (202607),
g2 VALUES LESS THAN MAXVALUE
);
“`
第三种：分片叠加本地分区的组合表，先 Has-h 分片，组内再按 ym 做 Range 本地分区：
“`sql
CREATE TABLE tb_orders_has-h_par_range (
order_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
region_code VARCHAR(10) NOT NULL,
amount DECIMAL(10,2) DEFAULT NULL,
create_time DATETIME NOT NULL,
ym INT NOT NULL,
PRIMARY KEY (order_id, ym)
)
PARTITION BY RANGE (ym) (
PARTITION p202609 VALUES LESS THAN (202610),
PARTITION p202610 VALUES LESS THAN (202611),
PARTITION p202611 VALUES LESS THAN (202612),
PARTITION p202612 VALUES LESS THAN (202701),
PARTITION pmax VALUES LESS THAN MAXVALUE
)
DISTRIBUTED BY HAs-h (order_id) (g1, g2);
“`
第四种：复制表（字典表），数据全量复制到指定分片组，适合小维表：
“`sql
CREATE TABLE dim_region (
region_code VARCHAR(10) NOT NULL,
region_name VARCHAR(50) NOT NULL,
PRIMARY KEY (region_code)
)
DISTRIBUTED BY DUPLICATE(g1, g2);
“`
注意：建表时若不写 DISTRIBUTED BY 且集群存在多个分片组，表会默认建成 DUPLICATE 复制表，数据复制到所有组；想明确只放一个组，要写 DISTRIBUTED BY DUPLICATE(g1)。
### 4.4 写入、提交与分片定位验证
写入测试数据：
“`sql
INSERT INTO tb_orders_has-h(order_id,user_id,region_code,amount,create_time)
VALUES (1001,2001,’CD’,88.50,NOW()),
(1002,2002,’BJ’,120.00,NOW()),
(1003,2003,’s-h’,56.80,NOW());
COMMIT;
INSERT INTO dim_region VALUES
(‘CD’,’成都’),(‘BJ’,’北京’),(‘s-h’,’上海’);
COMMIT;
“`
用 storagedb 语法直接查看某分片组上的数据，验证分片落点：
“`sql
SELECT COUNT(*) FROM tb_orders_has-h storagedb g1;
SELECT COUNT(*) FROM tb_orders_has-h storagedb g2;
SELECT COUNT(*) FROM dim_region storagedb g1;
SELECT COUNT(*) FROM dim_region storagedb g2;
“`
分片表在 g1、g2 上各存一部分，复制表在两个组上都有完整副本。执行计划验证路由是否命中分片键：
“`sql
EXPLAIN SELECT * FROM tb_orders_has-h WHERE order_id = 1001\G
“`
执行计划中 KEY 字段显示 Cluster1,g1 或 g2，表示只下发到对应分片组，避免全组扫描；若不带分片键，CN 会向所有分片组并行下发再合并，这就是分片键必须出现在高频查询 WHERE 条件中的原因。
### 4.5 分布式事务演示
跨分片转账用一条事务完成，GTM 保证两阶段提交：
“`sql
BEGIN;
UPDATE tb_orders_has-h SET amount = amount – 10.00 WHERE order_id = 1001;
UPDATE tb_orders_has-h SET amount = amount + 10.00 WHERE order_id = 1002;
COMMIT;
“`
若第二条语句报错，执行 ROLLBACK，分片 1 的扣款一并回滚，不会出现单边扣钱。收集统计信息供优化器使用：
“`sql
ANALYZE TABLE tb_orders_has-h;
“`
> 风哥 itpux-com
—
## 第五部分 GoldenDB 数据库集群日常管理维护指南
### 5.1 在线新增分片（扩容）
业务增长导致单分片数据量过大时，通过 Insight 拓扑视图选择”新增分片”，输入分片 ID（如 g3）、数据节点数（每节点 1 个 MySQL 实例）、响应数 response_num=1（该 Team 有 1 个备机 ACK 即允许提交）。新增分片部署完成后，对需要迁移的表触发数据重分布，把热点数据按分片键重新均衡到 g3。命令行侧确认新分片进程与端口：
“`bas-h
ps -ef | grep zxdb3 | grep -v grep
ss -lntp | grep 3306
“`
### 5.2 备份与恢复
DN 是 MySQL 内核，逻辑备份可用自带 mysqldump 按分片导出，物理备份可用 XtraBackup 对每个分片组主库备份。先在 CN 侧导出 fgedudb 库结构与数据：
“`bas-h
/fgedudb/zxdbproxy1/bin/mysqldump -h 192.168.10.11 -P 8880 \
-u fgedu -p’Fgedu@2026′ –databases fgedudb \
–single-transaction –routines –triggers \
> /fgedudb/backup/fgedudb_$(date +%Y%m%d).sql
“`
> 上51CTO搜索风哥可以学习全套数据库教程
恢复时先确保目标集群拓扑正常，再通过 CN 导入：
“`bas-h
/fgedudb/zxdbproxy1/bin/mysql -h 192.168.10.11 -P 8880 \
-u fgedu -p’Fgedu@2026′ < /fgedudb/backup/fgedudb_20261110.sql
“`
生产环境的物理备份、定时备份策略与时间点恢复在 Insight 的备份管理页面统一配置，备份文件落地到独立备份目录，禁止与数据盘同盘。
### 5.3 读写分离配置
在 Insight 分片组属性中开启读写分离，设置备机可读比例。CN 会把只读 SELECT 路由到 Standby，写与强制读主（/*+MASTER*/ 提示或事务内读）仍走主库。验证：
“`sql
SELECT /*+ MASTER */ @@hostname;
SELECT @@hostname;
“`
前者固定回主库，后者可能被路由到备机。读写分离要注意复制延迟带来的”刚写后读不到”问题，对一致性敏感的交易语句走主库。
### 5.4 日常巡检清单
每日巡检按以下命令与页面指标执行：
“`bas-h
# 1. 管理后端状态
/fgedudb/zxmanager/bin/ommtool -status
# 2. 各节点进程存活
ps -ef | grep -E “zxdbproxy|zxdb[0-9]|zxgtm|zxmanager|insight” | grep -v grep | wc -l
# 3. 端口监听
ss -lntp | grep -E “8880|8881|3309|65100|8444”
# 4. 磁盘与日志增长
df -h /fgedudb
du -s-h /fgedudb/zxdb1/log /fgedudb/zxdb2/log
# 5. DN 复制延迟（登录主库）
mysql -h 192.168.10.11 -P 3306 -u root -p’Fgedu@2026′ \
-e “s-hOW REPLICA STATUS\G” | grep -E “Seconds_Behind|Replica_IO|Replica_SQL”
# 6. 慢查询与连接数
mysql -h 192.168.10.11 -P 8880 -u fgedu -p’Fgedu@2026′ \
-e “s-hOW STATUS LIKE ‘Threads_connected’; s-hOW STATUS LIKE ‘Slow_queries’;”
“`
Insight 页面同步查看：分片组主备角色是否正常、GTM 主备、告警是否有堆积、CPU/内存 cgroup 是否触顶、binlog 磁盘水位。
### 5.5 常见故障处置
第一，分片组主库宕机：OMM 检测到主无响应，在达到 Team 响应阈值后自动把备提升为主，Insight 上观察角色翻转，事后检查原主重启并追平日志后作为备机重新加入。第二，单节点断网：若只剩一个有效 Team 且低于低水位 LW，分片自动切只读，恢复网络后自动解除只读；不要在脑裂风险下手动写主。第三，CN 故障：CN 无状态，应用切换到另一 CN 即可，不影响数据。第四，GTM 主故障：备 GTM 自动接管全局事务号分配，短暂事务排队后恢复。第五，磁盘满：先清理过期 binlog 与慢日志，再评估扩容，禁止直接删数据文件。
> 风哥教程 113257174
### 5.6 参数与资源调优（8C64G 基线）
在 8C64G 规格下，DN 的 innodb_buffer_pool_size 建议给到分片组物理内存的 50%~60%（约 12~16G），CN 主要消耗在连接与结果合并，关注 Threads_connected 上限；cgroup 上限已在 install_senior.ini 通过 c1_dn_cgroup_limit=4C24G、c1_cn_cgroup_limit=4C16G 约束，避免单组件打满整机。调参通过 Insight 参数管理页面下发，修改后按组件重启或动态生效，变更前先备份参数基线。
—
## 风哥针对本文总结
风哥针对本文总结：本套风哥教程从产品定位讲起，拆解了 GoldenDB 计算层 CN、数据层 DN、全局事务 GTM、管理节点 Manager 与 Insight/OMM/LDS 的职责，讲清了分片规则、两阶段提交、Team 高低水位与脑裂防护的原理；实战部分按 8C64G 规格，在 fgedu-net-cn1、fgedu-net-cn2 两台节点上完成了操作系统基线、install_senior.ini 八段配置、一键安装、启停管理、连接建库、分片表写入验证、扩容、备份恢复、读写分离与日常巡检的完整闭环。
> 风哥数据库教程 itpux-com
读者落地时要抓住三条主线：一是分片键决定性能上限，所有高频查询尽量带分片键；二是 Team 与高低水位决定可用性边界，不要为追求可用性而突破强同步约束；三是生产操作优先走 Insight/OMM 图形界面，命令行只用于核查与应急。GoldenDB 的工程价值在于把 MySQL 的成熟生态与分布式强一致结合，掌握本套风哥教程的最小两节点形态后，向多分片、同城双机房、异地灾备扩展只需在规划层增加 AZ 与 Team，命令与原理保持不变。
—
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
