数据库教程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 兼容发行版为例，规划如下：

资源按 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 操作系统基础环境准备（两台节点分别执行）

第一步，配置主机名并重启生效：