ITPub博客

一文读懂 GoldenDB 的分片与分区1. 分库分表 VS 分布式数据库    谈到分布式数据库，最核心的诉求是将数据分散存储于多个数据库实例中，这也是传统 Mycat 等中间件的核心能力。然而，GoldenDB 与 Mycat 有着本质区别：GoldenDB 并非简单地将分片路由逻辑叠加在 MySQL 之上，而是将计算层（CN）与存储层（DN）进行了深度融合。概念Mycat 传统中间

GoldenDB 快速安装分布式集群  之前的文章里介绍了通过配置 install_senior.ini 文件来标准安装 GoldenDB 集中式集群，前提是需要我们了解 GoldenDB 的集群架构以及参数意义，这对初学者来说不太友好。好在官方提供了三种安装模式，这次我们介绍一下通过配置 install_fast.ini 文件，快速安装分布式集群。快速安装: 单机房(install_fast.i

TDSQL for MySQL 集群部署及初始化（详细版） 1. 安装组件1.1 控制与管控层chitu（赤兔管理平台）：全生命周期运营管理控制台，提供实例创建、扩容、销毁及高可用运维的 Web 界面。OSS（Operation Support System）：运营支撑系统后台，作为 Web 服务的核心后端，接收并分发来自 chitu 的请求，调度各底层模块。Scheduler（任务调度

GoldenDB 启停命令  前面提到过，GoldenDB 在部署时会为每个组件创建一个操作系统用户，组件的相关操作，需要切换到相应的用户下执行。组件用户名规则ManagerzxmanagerGTMzxgtm1、zxgtm2 ...CNzxdbproxy1、zxdbproxy2 ...DNzxdb1、zxdb2 ...LoadServerzxload1、zxload2 ...InsightServ

GoldenDB 装完之后，系统里到底多了什么？在历经波折装好三节点集群后，我们开始梳理一下 GoldenDB 集中式部署下的组件分布、端口规划和相关进程，为后续深入研究和运维实战的基础。顺便提一句，在第 12 步安装组件，初始化数据库时，默认等待 40 次，每次 30 秒，如果由于磁盘性能不够等因素导致超过了 1200 秒，安装主程序就会报错，但是数据库仍可始化成功，可以将时间间隔或者等待次数调

GoldenDB 安装配置文件详细解析本篇文章介绍一下 GoldenDB 的安装参数，之前陆续介绍过 OceanBase、TiDB 和 GaussDB 的安装，并没有详细解释参数文件，是因为 OceanBase 和  TiDB  分别通过 OBD 和 Tiup 安装时，只需要配置 集群拓扑的 YAML 文件即可，相应的 GaussDB 通过 Python 在 脚本安装配置也不太

GoldenDB 整体架构解析1. 整体架构GoldenDB 是一款由中兴通讯自主研发的金融级分布式关系型数据库，整体采用分层架构，由管理节点、计算节点、数据节点以及 全局事务节点组成。在此基础上，系统配备了统一的运维管理平台（Insight / OMM），实现集群监控、诊断分析与自动化运维能力。当然，外围生态工具同样丰富，包括导入导出组件（LoadServer）、数据迁移平台（SLOTH）以及备

GoldenDB Insight及三节点集群部署  前面我们陆续介绍了 OceanBase、GaussDB 和 TiDB 分布式数据库，其中，OceanBase 和 TiDB 同属“从 KV 生长出来的 NewSQL”路线：底层采用 LSM-Tree 存储引擎，数据分片在进程内部进行细粒度切分—— Oceanbase 以日志流管理多个 Tablet，TiDB 则以 Region 为单位，通过 Mu

GaussDB 高可用流复制核心参数和视图  昨天系统介绍了一下 GaussDB 的系统表和视图，由于 DCF 集群环境铲掉装成了流复制环境，因此，本篇文章介绍一下流复制常用的核心参数与监控视图。说明：本文所述基于标准流复制环境（非 DCF 模式）。关于 DCF 模式的概念解析及复制状态查询，请参见《GaussDB 高可用演进：从流复制到 DCF 分布式共识》1. 流复制参数1.1 主库侧wal_

GaussDB 高可用演进：从流复制到 DCF 分布式共识  在上一篇中，我们介绍了基于 PostgreSQL + Patroni + etcd的高可用部署方式，其特点包括：Patroni 负责 PostgreSQL 实例的生命周期管理（启动、停止、角色切换、故障转移等）；ETCD 作为外部分布式一致性存储，承担 Leader 选举 与 集群元数据 的职责；集群依赖 ETCD 的 Raft 协议*

GaussDB 集群参数管理(GUC)1. 参数分类与设置级别  GaussDB 的物理参数均保存在 gaussdb.conf 和 pg_hba.conf 配置文件中。根据内核控制范围，参数分为以下六种级别：参数类型作用域与控制级别标准修改方式生效时机INTERNAL静态固定参数，建库时确定。无法修改，仅供 SHOW 查看。固定POSTMASTER服务端核心参数（如内存、连接数）。gs_guc s

GaussDB 系统表与系统视图详解（内网运维版）1. 系统表视图分类pg_ ：继承自开源内核的系统表和视图，存储最基础的数据库元数据（如对象 OID、表结构、依赖关系等）。gs_ ：GaussDB 特有的系统表或视图，多用于扩展的内核特性与高级安全审计。pgxc_ ：分布式集群 场景下的专属前缀，用于维护多节点拓扑、分布式分布键、数据分片（Slice）等集群级元数据。pgxc_node：查看集群

从原生 PG 到 Vastbase、GaussDB：聊透“Patroni + ETCD”高可用架构演进与实战  昨天我们介绍了 PostgreSQL 的一主两从搭建过程，并详细说明了 synchronous_standby_names 参数在 ANY、FIRST等不同配置下的同步差异，尽管可以保障数据冗余，但无法提供高可用自动切换能力。因此，本期我们将手把手搭建 PG + Patroni + ET

PostgreSQL 一主两从搭建及同步模式深度详解  本打算介绍一下 GaussDB 集中式集群的同步机制，但考虑到其底层本质上仍基于 PostgreSQL 流复制，因此先“回归本源”， 介绍 PostgreSQL 一主两从集群的搭建过程，并详细解析 synchronous_standby_names 参数配置为 ANY、FIRST 和 * 场景下复制模式的差异，为后面介绍 GaussDB 复制

GaussDB 系列文章（一）：集中式数据库集群纯命令部署   今天我们继续扒国产分布式数据库，前面陆续介绍了 OceanBase 和 TiDB 的安装，今天我们将目光转向 GaussDB，一个既让人感觉“熟悉”却又带有几分“神秘色彩”的国产数据库标杆。   与 OceanBase、TDSQL 以及 GoldenDB 类似，GaussDB 并非单一的数据库引擎，而是一套完整的数据库解决方案，同时支

OceanBase 主备租户1. 租户级主备库  在 OceanBase 数据库的容灾体系中，物理备库扮演着“准实时热备份”的关键角色。可以在当主库不可用时接管服务，最大限度降低服务停机时间，减少可能带来的数据损失。1.1 架构演进V4.1.0 版本开始，物理备库的产品形态从集群级变更为租户级：V 4.1.0 之前：主备库形态为集群级，粒度较粗。V 4.1.0 及以后：产品形态重构为租户级。主/备

OceanBase 物理备份恢复为什么 OceanBase 提供了多副本同步机制，还需要进行备份？一是如果用户执行了误操作，这一破坏性指令会以合法的事务日志形式迅速同步并应用到所有副本中。此时唯有依赖备份（或回收站/闪回）才能还原数据。二是如果发生超越容容灾等级的极端灾难，导致多数派故障，此时也需要借助备份恢复解决。多副本和备份恢复的关注点：多副本（实时强一致性）：关注的是当前时刻数据的可用性与实

《OBCP 实验考试经验总结贴》  最近抽空考了一把 OBCP 实验，由于前期没重视，总体感受不是很顺利，但刚刚发成绩单，已经通过了。除了没重视外，客观因素也有一些：首先是开考后  OCP 页面半天打不开，OAT 页面里显示 OpenSearch、MetaDB 和 OCP 全部是红色异常状况，但是我在后台看 docker 和 进程都在运行，排查了十多分钟，正当我准备要卸载重装时，OCP

OceanBase 局部索引和全局索引1. 局部索引1.1 核心概念在 OceanBase 数据库中，局部索引（Local Index） 是默认且最常用的索引类型。它的核心特征是索引的分区规则与主表完全保持一致。局部索引必须和主表保持相同的分区关系，索引的每个分区与主表对应分区绑定。也就是：主表某个分区的数据，对应的局部索引数据也在相应的索引分区中。对普通局部索引而言，索引列不要求包含主表分区键。

如何在内网配置 TiDB 数据库 Agent昨天的文章已经实现了通过 FastAPI + OpenAI + pyTiDB 的方式搭建 Agent 智能体，也在文章结尾演示了在聊天框中操作数据库。但是因为此种方式要手写一个 FastAPI http 接口，加上 Centos 7.9 的系统，GCC 和 Python 版本都较低，操作相对复杂。因此，这次我们使用 RockyLinux 的系统，再配置一