Code & Light
数据库 · · Code & Light

openGauss 5.x 管理实战：安装部署、用户权限、数据库与表管理、远程访问及故障排查

一篇面向日常 DBA 与后端开发的 openGauss 5.x 运维手册，涵盖单机与主备部署、启停、账号权限、数据库兼容模式、DDL、远程接入、CPU/内存/锁/连接数诊断。

openGauss 与 PostgreSQL 在 SQL 语法和部分工具上较为接近，但 openGauss 5.x 并不等于 PostgreSQL 5，也不能直接套用 PostgreSQL 的全部运维命令。尤其是 OM 部署方式、主备管理、兼容模式、线程视图和权限模型。

本文以 openGauss 5.0.x 企业版 / OM 管理的普通单机或主备部署 为主，兼顾使用 gs_ctl 的独立实例。5.0.1、5.0.3 等补丁版以及极简版、容器版、CM/DCF 部署方式可能存在细节差异。请先使用实际安装包中的帮助命令与官方对应版本文档核对。

执行前必读

  • 示例服务器、IP、数据库、用户和路径仅用于演示，不要直接复制到生产环境。
  • 所有 SQL 假设使用有相应授权的账号操作；维护命令通常使用 Linux 系统账号 omm。
  • DROP、TRUNCATE、RESTART、终止会话、修改主备关系可能影响业务，务必先备份、确认维护窗口。
  • 不建议将数据库 5432 等端口直接暴露到公网。远程接入应优先内网/VPN、最小 IP 白名单、强密码和 TLS。

1. 环境准备与安装

1.1 先辨认版本、安装形态和端口

查看程序版本、集群管理工具、主机名与数据目录：

su - omm
gaussdb --version
gsql --version
hostname
command -v gs_om
command -v gs_ctl
echo "$GAUSSHOME"
echo "$GAUSSLOG"
echo "$PGDATA"

如果已经运行，连接管理库：

# -p 必须改为实际监听端口；以下以 15400 为例
gsql -d postgres -p 15400 -U omm
SELECT version();
SHOW port;
SHOW data_directory;
SHOW config_file;
SHOW hba_file;

端口没有统一固定值。官方安装示例使用过 15400，其他部署可能是 5432、8000 或自定义端口，不能想当然。

1.2 安装前检查

优先选择与 openGauss 5.x 安装包架构、操作系统及依赖相匹配的 Linux 发行版。示例检查：

cat /etc/os-release
uname -m
hostname -f
getent hosts "$(hostname)"
free -h
df -h
ulimit -n
timedatectl

多节点还应确认：

  • 每台机器的主机名、业务网卡 IP、节点间互访及 SSH 配置正确。
  • 所有节点时间同步，防火墙只放行必要的业务、复制和管理端口。
  • 安装用户、安装目录、数据目录的归属与权限一致。
  • 安装包与系统架构匹配，操作系统版本属于对应发行包的支持范围。
  • 磁盘空间充足，数据、WAL、日志与备份预留增长空间。

1.3 单机：企业版 OM 安装

OM 安装的核心是 XML 描述拓扑 → root 预安装 → omm 正式安装。官方 openGauss 5.0 文档提供单节点 XML 模板；其典型结构如下（按实际主机修改）：

<?xml version="1.0" encoding="UTF-8"?>
<ROOT>
  <CLUSTER>
    <PARAM name="clusterName" value="og_single" />
    <PARAM name="nodeNames" value="db01" />
    <PARAM name="gaussdbAppPath" value="/opt/opengauss/app" />
    <PARAM name="gaussdbLogPath" value="/opt/opengauss/log" />
    <PARAM name="tmpMppdbPath" value="/opt/opengauss/tmp" />
    <PARAM name="gaussdbToolPath" value="/opt/opengauss/om" />
    <PARAM name="corePath" value="/opt/opengauss/core" />
    <PARAM name="backIp1s" value="192.168.10.11" />
  </CLUSTER>
  <DEVICELIST>
    <DEVICE sn="db01">
      <PARAM name="name" value="db01" />
      <PARAM name="azName" value="AZ1" />
      <PARAM name="azPriority" value="1" />
      <PARAM name="backIp1" value="192.168.10.11" />
      <PARAM name="sshIp1" value="192.168.10.11" />
      <PARAM name="dataNum" value="1" />
      <PARAM name="dataPortBase" value="15400" />
      <PARAM name="dataNode1" value="/opt/opengauss/data/dn" />
      <PARAM name="dataNode1_syncNum" value="0" />
    </DEVICE>
  </DEVICELIST>
</ROOT>

安装包解压到规划目录后，使用其提供的脚本；脚本所在目录依压缩包布局确定：

# root 执行，脚本路径以实际解压结果为准
./gs_preinstall -U omm -G dbgrp -X /opt/software/cluster_config.xml

# 预安装成功后改用安装用户 omm
su - omm
gs_install -X /opt/software/cluster_config.xml

# 验证
gs_om -t status --detail
gsql -d postgres -p 15400 -U omm

预安装可能涉及创建/配置操作系统用户及系统参数，请严格按照目标服务器对应的 5.x 官方安装说明实施。正式安装通常会提示设置数据库初始口令；不要在脚本里写入明文生产密码。

官方文档：openGauss 5.0 XML 模板 · gs_install

1.4 单机：仅有 gs_ctl 的独立实例

如果没有安装 OM，而是已经使用 gs_initdb 初始化了独立数据目录，可由 omm 直接管理：

su - omm
gs_ctl -D /opt/opengauss/data/dn status
gs_ctl -D /opt/opengauss/data/dn start
gs_ctl -D /opt/opengauss/data/dn stop -m fast
gs_ctl -D /opt/opengauss/data/dn restart -m fast
gs_ctl -D /opt/opengauss/data/dn reload

二选一管理：对已经使用 OM 管理的实例，正常启停应优先用 gs_om，避免一边用 gs_ctl 启停、一边让管理工具误判状态。容器部署则优先遵循容器编排的生命周期控制。

1.5 集群：一主一备的安装与检查

openGauss 常见集群形态是一主一备或一主多备，而不是把多个实例当成可以各自写入的独立数据库。数据变更一般写入主节点，备节点负责复制/故障接管，是否允许只读访问由部署与配置决定。

以一主一备为例，需要两台服务器：

主机私有地址角色示例业务端口
db01192.168.10.11Primary15400
db02192.168.10.12Standby按 XML 规划

与单节点 XML 相比，关键变化：

  1. CLUSTER 的 nodeNames 包含两台主机，backIp1s 包含两个 IP。
  2. DEVICELIST 内分别配置 db01、db02 的 DEVICE 信息。
  3. 主节点的 dataNode1 项需要写入备节点的主机名与数据目录映射；不是简单复制单机 XML 后修改主机数量。
  4. 设置复制端口、复制模式及同步备数量时需要按可用性和写入一致性要求规划。
  5. 两台机器的安装包、SSH 互信和用户环境需要准备完毕。

官方一主一备结构的关键字段示意（不是完整安装 XML）：

<PARAM name="nodeNames" value="db01,db02" />
<PARAM name="backIp1s" value="192.168.10.11,192.168.10.12" />
<!-- db01 的 DEVICE 下 -->
<PARAM name="dataNode1"
       value="/opt/opengauss/data/dn,db02,/opt/opengauss/data/dn" />
<!-- db02 也必须有自己的 DEVICE 节点和网络参数 -->

务必从官方 一主一备完整 XML 示例 获取模板，再做环境替换。不要把双节点直接等同于自动故障转移：没有配置 CM/DCF 等管理能力时，主节点故障不代表业务入口能够自动、无感切换。

# root：准备所有节点的预安装环境
./gs_preinstall -U omm -G dbgrp -X /opt/software/cluster_config.xml

# omm：根据多节点 XML 安装
su - omm
gs_install -X /opt/software/cluster_config.xml

# 查看实际主备角色及状态
gs_om -t status --detail

检查主备时特别关注：

  • cluster_state 是否正常。
  • Primary、Standby 角色是否符合预期。
  • 实例状态和复制状态是否正常、有无明显延迟。
  • 连接业务的读写入口是否指向当前 Primary。

2. 启动、停止、重启与状态查询

2.1 OM 单机和集群

以下命令使用操作系统账号 omm，在具备 OM 环境的主机执行：

su - omm

# 查看整体和实例状态
gs_om -t status
gs_om -t status --detail

# 启动
gs_om -t start

# 停止：会中断业务连接
gs_om -t stop

# 重启
gs_om -t restart

# 如遇到启动超时，可在诊断后适当放宽超时
gs_om -t start --time-out=600

使用 gs_om -t restart 是 OM 集群级重启，不等于滚动、无损重启；不能假设有备机就不会断开连接。集群生产环境重启前必须明确复制状态、业务入口和可用性方案。

官方：openGauss 5.0 gs_om 说明

2.2 单节点启停（OM 管理）

# 仅对指定主机上的实例操作，主机名应与 XML 匹配
gs_om -t status -h db01
gs_om -t stop -h db02
gs_om -t start -h db02

不要在未确认主备角色、仲裁与复制同步状态时停止 Primary。某些版本与 CM 拓扑下，指定 -D 等参数可能只操作数据库进程、不管理 CM 相关进程。

2.3 确认服务恢复

gs_om -t status --detail
ss -lntp | grep 15400
SELECT current_database(), current_user, now();
SELECT 1;

如果无法启动，先查 gs_om 输出及 GAUSSLOG 下的数据库和 OM 日志，再检查数据目录权限、端口占用、磁盘空间和操作系统资源；不要反复强制 kill 主进程。

3. 用户管理：查看、新增、修改、重置、删除

3.1 列出用户及登录属性

-- gsql 元命令，快速列出角色
\du

-- 用户信息（不查询密码哈希）
SELECT usename, usesysid, usecreatedb, usesuper
FROM pg_user
ORDER BY usename;

-- 角色属性
SELECT rolname, rolcanlogin, rolcreatedb, rolcreaterole, rolsuper
FROM pg_roles
ORDER BY rolname;

角色/用户在实例级管理，但数据库和 Schema 的访问权限是另一个层面。普通业务账号应避免 SYSADMIN、CREATEDB、CREATEROLE 等高权限。

3.2 创建普通登录用户

-- 使用足够复杂的临时密码；这里只是结构示例
CREATE USER app_user WITH LOGIN PASSWORD 'ChangeMe_2026@Strong';

-- 若确实需要建库权限，可以在创建时指定
CREATE USER db_creator WITH CREATEDB PASSWORD 'ChangeMe_2026@Strong2';

-- 检查用户
SELECT rolname, rolcanlogin, rolcreatedb
FROM pg_roles
WHERE rolname IN ('app_user', 'db_creator');

生产环境应通过交互式工具、安全密钥管理或受控脚本传递密码；命令行、SQL 历史文件、应用日志都可能泄露明文口令。openGauss 默认有密码复杂度策略。

3.3 修改用户、密码和账号状态

-- 管理员重置密码，是否需要旧口令取决于操作者身份和权限策略
ALTER USER app_user PASSWORD 'ReplaceWith_NewStrong2026@';

-- 用户自行修改可采用需要旧口令的形式
ALTER USER app_user IDENTIFIED BY 'NewStrong2026@' REPLACE 'OldStrong2026@';

-- 禁止 / 恢复登录
ALTER USER app_user ACCOUNT LOCK;
ALTER USER app_user ACCOUNT UNLOCK;

-- 修改登录资格
ALTER USER app_user NOLOGIN;
ALTER USER app_user LOGIN;

-- 撤回创建数据库资格
ALTER USER db_creator NOCREATEDB;

修改口令后，还要同步调整应用连接池、任务调度及密钥管理器中的配置，避免应用持续重试错误密码导致账号锁定。

3.4 删除用户

-- 先检查其拥有的对象和授权依赖，不要立即 CASCADE
DROP USER app_user;

如果报对象依赖或权限依赖，先评估应当转移哪些数据库、Schema、表的所有权，以及需要撤回哪些授权；必要时在对象所属的每一个数据库分别处理。不要为了省事直接使用 DROP USER … CASCADE，它可能影响业务对象。

4. 权限管理：查看、授予、撤销、创建时赋权

openGauss 的访问控制至少涉及三层：

层级常见权限用途
数据库CONNECT、CREATE、TEMPORARY连接数据库、在允许的位置建对象等
SchemaUSAGE、CREATE访问命名空间、在其中创建对象
表SELECT、INSERT、UPDATE、DELETE、TRUNCATE 等数据读写及表操作

只给 CONNECT 并不等于可以 SELECT 表。只给 SELECT 而无 Schema USAGE，也可能无法通过名称访问表。

4.1 查询数据库与 Schema 权限

-- 在 postgres 或目标数据库执行
\l
\dn+

-- 数据库原始 ACL：空值不等于“任何用户都有权限”
SELECT datname, datacl
FROM pg_database
WHERE datname = 'appdb';

-- 对某个账号判断有效权限（含角色继承等）
SELECT
    has_database_privilege('app_user', 'appdb', 'CONNECT') AS can_connect,
    has_database_privilege('app_user', 'appdb', 'CREATE') AS can_create;

-- 切换到 appdb 再检查 Schema 权限
SELECT
    has_schema_privilege('app_user', 'app', 'USAGE') AS can_use,
    has_schema_privilege('app_user', 'app', 'CREATE') AS can_create;

4.2 查询表权限和角色继承

\dp app.*

SELECT
    has_table_privilege('app_user', 'app.orders', 'SELECT') AS can_select,
    has_table_privilege('app_user', 'app.orders', 'INSERT') AS can_insert,
    has_table_privilege('app_user', 'app.orders', 'UPDATE') AS can_update,
    has_table_privilege('app_user', 'app.orders', 'DELETE') AS can_delete;

-- 查询用户所属角色（角色授权）
SELECT member.rolname AS member_name, parent.rolname AS granted_role
FROM pg_auth_members m
JOIN pg_roles parent ON parent.oid = m.roleid
JOIN pg_roles member ON member.oid = m.member
WHERE member.rolname = 'app_user';

4.3 创建用户时就配置权限：推荐角色化授权

创建用户时能声明 CREATEDB 等系统属性，但数据库、Schema、表级授权需要额外执行 GRANT。推荐先创建角色，再把角色授给业务账号：

-- 在具备权限的账号下执行
CREATE ROLE app_readonly;
CREATE USER report_user WITH LOGIN PASSWORD 'ChangeMe_2026@Report';
GRANT app_readonly TO report_user;

-- 在目标数据库已经存在之后执行
GRANT CONNECT ON DATABASE appdb TO app_readonly;

-- 连接 appdb，再执行以下语句
CREATE SCHEMA app;  -- 已存在时不重复创建
GRANT USAGE ON SCHEMA app TO app_readonly;

-- 为当前已存在的表授予只读权限
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_readonly;

注意：CREATE SCHEMA app 只应执行一次，已有 Schema 则省略。角色应由管理员创建，创建表及默认权限的角色与实际部署方式有关。

4.4 为读写用户赋权

CREATE ROLE app_readwrite;
GRANT app_readwrite TO app_user;

GRANT CONNECT ON DATABASE appdb TO app_readwrite;

-- 以下在 appdb 内执行
GRANT USAGE ON SCHEMA app TO app_readwrite;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA app TO app_readwrite;

-- 如果应用要自己在此 Schema 建表，才额外授予：
GRANT CREATE ON SCHEMA app TO app_readwrite;

TRUNCATE、ALTER、DROP 等属于高风险操作，不建议直接授予普通业务账号。序列等对象可能需要独立授权，应根据表主键生成方式检查实际依赖。

4.5 新表自动授权：解决“旧表能查、新表无权限”

-- 在 appdb 中由实际创建表的角色（例如 app_owner）执行
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
GRANT SELECT ON TABLES TO app_readonly;

ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLES TO app_readwrite;

默认权限只影响以后由指定角色创建的对象，不会补齐已有表的权限；对现有表仍需使用 GRANT ON ALL TABLES。不同建表账号有各自的默认权限配置，不能只配一次就假设全库所有账号创建的新表都继承授权。

官方：ALTER DEFAULT PRIVILEGES

4.6 回收权限

-- 回收某表的写入权限
REVOKE INSERT, UPDATE, DELETE
ON TABLE app.orders FROM app_readwrite;

-- 回收 Schema 创建权限
REVOKE CREATE ON SCHEMA app FROM app_readwrite;

-- 回收数据库连接权限
REVOKE CONNECT ON DATABASE appdb FROM app_readonly;

-- 回收角色成员资格
REVOKE app_readonly FROM report_user;

-- 回收未来新表的默认授权（由适当角色在 appdb 内执行）
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
REVOKE SELECT ON TABLES FROM app_readonly;

回收单项 GRANT 后仍可能通过其他角色、PUBLIC、对象所有权或其他授权路径取得权限；请用 has_*_privilege 重新验证实际有效权限，而不是只看一条 REVOKE 的执行结果。

5. 数据库管理：查看、创建、修改、删除与兼容模式

5.1 查看数据库列表、大小与兼容模式

\l

SELECT
    datname,
    pg_get_userbyid(datdba) AS owner_name,
    pg_encoding_to_char(encoding) AS encoding,
    datcompatibility,
    datconnlimit,
    datallowconn
FROM pg_database
ORDER BY datname;

-- 当前连接的数据库大小
SELECT pg_size_pretty(pg_database_size(current_database()));

关键字段是 pg_database.datcompatibility，不要误写成 datcompatible。连接到目标库后还可执行：

SHOW sql_compatibility;

5.2 创建数据库并指定兼容模式

-- Oracle 风格兼容
CREATE DATABASE appdb WITH DBCOMPATIBILITY = 'A';

-- MySQL 风格兼容（需要按实际应用需求选择）
CREATE DATABASE mysql_style_db WITH DBCOMPATIBILITY = 'B';

-- PostgreSQL 风格兼容
CREATE DATABASE pg_style_db WITH DBCOMPATIBILITY = 'PG';

-- 指定所有者（必须先存在该账号）
CREATE DATABASE owned_db WITH OWNER = app_user DBCOMPATIBILITY = 'PG';

openGauss 5.x 的主要兼容模式：

模式语法/行为侧重
AOracle
BMySQL
CTeradata
PGPostgreSQL

兼容不代表 100% 实现另一种数据库的所有功能。模式会影响 SQL 行为，例如空字符串语义，应在建库之前确定。数据库兼容模式是创建数据库时确定的属性，不能依靠 ALTER DATABASE 直接切换；要转换模式通常需要新建目标库并开展结构和数据迁移。

官方：5.0 SQL 兼容性参数

5.3 修改数据库属性

-- 不能连接到正在重命名的数据库自身
ALTER DATABASE appdb RENAME TO appdb_v2;

-- 修改所有者
ALTER DATABASE appdb_v2 OWNER TO app_user;

-- 允许的最大连接数（示例）
ALTER DATABASE appdb_v2 CONNECTION LIMIT 100;

-- 某数据库登录后的默认配置
ALTER DATABASE appdb_v2 SET search_path TO app, public;

-- 恢复该配置
ALTER DATABASE appdb_v2 RESET search_path;

其中数据库改名、所有者变更需要满足相应权限及连接条件。ALTER DATABASE 不等于允许直接修改兼容模式或字符编码。

5.4 删除数据库

-- 必须先切换到其他数据库，确保业务已停用目标库
\c postgres

-- 先查是否有连接
SELECT datname, count(*)
FROM pg_stat_activity
WHERE datname = 'appdb_v2'
GROUP BY datname;

-- 备份和业务确认之后才执行
DROP DATABASE appdb_v2;

DROP DATABASE 会删除数据库及其对象，且有活动连接时通常无法执行；不要以终止所有连接作为默认处理方式。

6. 表管理：查看、新建、修改、删除、清空

6.1 查表、字段、约束与大小

\c appdb

-- gsql 元命令
\dt
\dt app.*
\d app.orders
\d+ app.orders

-- 标准 SQL 查看某 Schema 的表
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_schema = 'app'
  AND table_type = 'BASE TABLE'
ORDER BY table_name;

-- 字段
SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'app' AND table_name = 'orders'
ORDER BY ordinal_position;

-- 表大小（以实际数据库支持情况为准）
SELECT pg_size_pretty(pg_total_relation_size('app.orders'));

6.2 创建 Schema 和表

CREATE SCHEMA app;

CREATE TABLE app.orders (
    id BIGINT PRIMARY KEY,
    order_no VARCHAR(64) NOT NULL UNIQUE,
    amount NUMERIC(18, 2) NOT NULL,
    status VARCHAR(20) DEFAULT 'NEW',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_orders_created_at
ON app.orders(created_at);

如果 Schema 已经存在，省略 CREATE SCHEMA。真实业务场景应进一步设计主键生成机制、字段约束、索引、分区及空间使用情况。

6.3 修改表结构

-- 新增字段
ALTER TABLE app.orders ADD COLUMN remark VARCHAR(255);

-- 修改字段类型前应检查现有数据是否可转换
ALTER TABLE app.orders ALTER COLUMN remark TYPE VARCHAR(500);

-- 修改字段默认值
ALTER TABLE app.orders ALTER COLUMN status SET DEFAULT 'PENDING';

-- 字段重命名
ALTER TABLE app.orders RENAME COLUMN remark TO note;

-- 表重命名
ALTER TABLE app.orders RENAME TO order_records;

-- 删除字段（会造成不可逆的数据丢失）
ALTER TABLE app.order_records DROP COLUMN note;

生产库的 DDL 可能等待锁、造成阻塞或触发表重写。对大表修改类型前应评估执行计划、停机窗口及回退方案，不要默认是在线无锁操作。

6.4 清空表：DELETE 与 TRUNCATE 的区别

-- 有条件删除数据，可在提交前核对影响范围
BEGIN;
DELETE FROM app.order_records WHERE status = 'CANCELLED';
-- 检查业务影响后 COMMIT，或使用 ROLLBACK
ROLLBACK;

-- 清空全部数据（仅在确认后执行）
TRUNCATE TABLE app.order_records;
操作范围典型特点
DELETE … WHERE按条件逐行删除，适合精确清理
DELETE（无 WHERE）全表逐行删除，可能产生大量日志
TRUNCATE全表快速清空，可能取得更强的表锁

TRUNCATE 不是“随便执行的快速 DELETE”：涉及外键、触发器、事务和锁时应先核对目标 5.x 版本的实际行为与业务约束。不要将“可以回滚”当成替代备份的理由。

6.5 删除表

DROP TABLE app.order_records;

生产环境建议先确认依赖、备份和保留策略；不要未经审核就使用 CASCADE。删除表通常同时删除其数据、索引、约束及相关对象定义。

7. 配置远程访问

远程访问至少要通过 四关：服务监听地址、数据库认证规则、防火墙网络、用户权限。仅放开防火墙是不够的。

以下示例允许 192.168.10.50 这台应用服务器连接数据库服务器 192.168.10.11:15400。

7.1 查看监听与认证文件位置

SHOW listen_addresses;
SHOW port;
SHOW hba_file;
SHOW config_file;
su - omm
ss -lntp | grep 15400

7.2 配置监听地址

OM 部署优先使用 gs_guc 管理参数：

# 根据实际集群和版本检查命令帮助
gs_guc check -I all -c "listen_addresses"

# 举例：只监听本机和业务内网 IP
gs_guc set -I all -c "listen_addresses='localhost,192.168.10.11'"

# 配置生效通常需重启实例/集群；生产环境先规划维护窗口
gs_om -t restart

如果是单独用 gs_ctl 管理的实例，可在 postgresql.conf 中设置监听地址，再使用 gs_ctl restart；不要同时使用两套工具修改不同的数据目录。集群中 -I all 的范围与具体拓扑相关，先确认每个节点是否都存在配置的 IP；不应把主节点 IP 照搬到备节点监听配置。

7.3 配置 pg_hba.conf 的最小白名单

使用 gs_guc 给指定应用用户和数据库添加认证规则：

# 仅允许指定来源 IP、数据库和账号
gs_guc reload -N all -I all \
  -h "host appdb app_user 192.168.10.50/32 sha256"

或者找到目标实例的 pg_hba.conf，在恰当位置配置同等规则后重载。规则按匹配顺序检查，切勿依赖一条追加在宽松规则之后的白名单达到封锁效果。

避免如下危险配置：

  • 所有来源 0.0.0.0/0 直接暴露公网；
  • 使用 trust 让未知客户端免密码登录；
  • 使用业务最高权限账号连接应用；
  • 把生产密码写入仓库。

如需加密传输，结合客户端驱动支持情况配置数据库服务器证书与 TLS/SSL 连接参数。

官方：远程连接配置（5.1 文档作为操作参考，请核对 5.0 当前安装包语法）。

7.4 网络及连接排查

# 数据库服务器：确认本机监听
ss -lntp | grep 15400

# 应用服务器：确认路由与端口可达
nc -vz 192.168.10.11 15400

# 应用服务器：用指定数据库用户发起连接，按提示输入口令
gsql -h 192.168.10.11 -p 15400 -d appdb -U app_user -W

如果 telnet/nc 不通，先查安全组、防火墙、监听与网路；如果 TCP 已通但认证失败，查 pg_hba、用户名、口令、CONNECT 权限以及实际源 IP（NAT/代理环境下源地址可能变化）。

8. 故障排查：CPU、内存、锁、死锁、连接数

建议先定位问题范围，再动参数或杀会话。 常用顺序：操作系统资源 → 实例/节点状态 → 活跃 SQL/等待事件 → 执行计划和索引 → 必要时限流或处理异常连接。

8.1 CPU 飙高

先确认究竟是不是数据库占用了 CPU：

top
ps -eo pid,ppid,%cpu,%mem,etime,args --sort=-%cpu | head -25
pidstat -u 1 5
vmstat 1 5

再检查数据库会话：

SELECT pid, usename, datname, state,
       query_start, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start;

对定位出的具体 SQL先用 EXPLAIN 查看执行计划：

EXPLAIN SELECT * FROM app.orders WHERE order_no = 'A001';

检查是否缺少索引、扫描行数过大、统计信息过旧、排序或 Hash 操作开销过大、并发请求骤增。不要直接对生产写入 SQL 执行 EXPLAIN ANALYZE：该命令会真正执行语句。

8.2 内存持续上涨或 OOM

free -h
vmstat 1 5
cat /proc/meminfo | head -20
dmesg -T | grep -i -E 'oom|out of memory' | tail -20
ps -eo pid,rss,vsz,%mem,args --sort=-rss | head -20
SHOW shared_buffers;
SHOW work_mem;
SHOW max_connections;
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

排查方向：

  1. 实际数据库进程和系统内存使用是否匹配，是否还有其他服务抢占内存。
  2. 并发查询数量、排序/哈希内存、连接数是否同时升高。
  3. 是否出现大量空闲事务、大 SQL、中间结果或临时文件。
  4. Linux 是否发生 OOM Killer、交换分区抖动。
  5. 参数调整需要评估机器总内存与实际并发，不要机械地把 work_mem 设置得非常大。

8.3 锁等待与死锁

锁等待不等于死锁。 锁等待是一个会话正在等另一会话释放资源；死锁是多个会话形成循环依赖。死锁通常会由数据库检测并终止其中一个事务，但具体取决于版本、锁类型和检测参数。

-- 查看等待中的活动会话
SELECT pid, usename, datname, state, waiting,
       query_start, query
FROM pg_stat_activity
WHERE waiting = true;

-- 查看当前锁
SELECT * FROM pg_locks WHERE NOT granted;

-- openGauss 特有的等待状态视图
SELECT * FROM pg_thread_wait_status
WHERE wait_status = 'acquire lock';

处理步骤：

  1. 确定阻塞持续时间，关联应用请求与 SQL。
  2. 检查 idle in transaction 连接：是否忘记 COMMIT/ROLLBACK。
  3. 对照数据库日志识别 deadlock detected 等错误、事务顺序和涉及的表。
  4. 让应用尽快结束异常事务；优化事务时长并统一多表更新顺序。
  5. 如确需人为干预，先确认会话所有者和影响范围。
-- 根据实际查询出的 PID 填值；此处使用变量式占位说明
-- SELECT pg_cancel_backend(<确认后的PID>);
-- SELECT pg_terminate_backend(<确认后的PID>);

在 openGauss 中，pg_stat_activity.pid 可能是线程标识，不要直接等同于 Linux 上可以 kill -9 的传统进程 PID。优先使用数据库提供的取消/终止接口，而不是操作系统强制杀进程。

官方：锁与日常巡检 · 会话信号接口

8.4 连接数过多 / too many connections

SHOW max_connections;

-- 当前连接总数
SELECT count(*) AS total FROM pg_stat_activity;

-- 按数据库、账号、状态分析
SELECT datname, usename, state, count(*) AS connections
FROM pg_stat_activity
GROUP BY datname, usename, state
ORDER BY connections DESC;

-- 找长期不释放的事务
SELECT pid, usename, datname, state,
       xact_start, now() - xact_start AS xact_age,
       query
FROM pg_stat_activity
WHERE state LIKE 'idle in transaction%'
ORDER BY xact_start;

通常应先检查：

  • HikariCP 等应用连接池的 maximumPoolSize、minimumIdle、连接超时和泄漏检测。
  • 是否多个应用实例或批任务同时连接，导致连接池总和超过数据库容量。
  • 代码是否忘记关闭连接，是否存在长事务和慢 SQL。
  • 数据库 max_connections 与机器内存是否匹配。

必要时限制某个账号或数据库：

ALTER USER app_user CONNECTION LIMIT 30;
ALTER DATABASE appdb CONNECTION LIMIT 100;

限制新连接不等于立即回收现有连接。提升 max_connections 也不是无成本的解决方案，会增加内存与调度开销。

8.5 磁盘、日志、复制状态排查

df -h
df -i
du -sh /opt/opengauss/data/dn
gs_om -t status --detail

# 具体日志目录以 GAUSSLOG 和实例配置为准
echo "$GAUSSLOG"
SHOW logging_collector;
SHOW log_directory;
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
WHERE datallowconn
ORDER BY pg_database_size(datname) DESC;

检查磁盘异常时不要只关注数据文件，还要关注 WAL、归档、临时文件、系统日志及备份目录。绝对不要手工删除数据目录内的 WAL 或数据库内部文件来“腾空间”。主备异常应先检查集群拓扑、网络、复制状态和数据库日志，再决定是否重建备机。

9. 值得收藏的日常巡检清单

检查事项最快入口重点
实例健康gs_om -t status —detailNormal、主备角色
版本/配置SELECT version(); / SHOW版本、端口、路径
用户\du / pg_roles高权限账号、过期账号
有效权限has_*_privilege实际可读写能力
数据库模式pg_database.datcompatibilityA / B / C / PG
表与索引\dt / \d+表结构、索引及大小
活跃 SQLpg_stat_activity时长、状态、等待
锁pg_locks / pg_thread_wait_status阻塞、长事务
内存free -h / OOM 日志峰值、连接并发
连接max_connections / pg_stat_activity连接池总量
磁盘df -h / df -i数据、日志、WAL
远程连接listen_addresses / pg_hba.confIP 白名单、TLS

10. 总结：生产环境推荐实践

  • 安装：选择与 openGauss 5.x、OS、CPU 架构匹配的发行包；OM 部署使用 XML + gs_preinstall + gs_install。
  • 启停：OM 实例优先 gs_om；独立实例才用 gs_ctl。集群重启不等于零停机。
  • 用户：应用账号独立，禁止滥用 SYSADMIN；口令在密钥系统中管理。
  • 权限：数据库 CONNECT + Schema USAGE/CREATE + 表级 GRANT 分开控制；角色化授权并配置未来新表默认权限。
  • 数据库：创建前决定 DBCOMPATIBILITY；现有库不能靠简单 ALTER 切换模式。
  • 数据表：大表 DDL、TRUNCATE、DROP 先评估影响和回滚；上线前备份。
  • 网络：监听、pg_hba、网络白名单、TLS 四层一起核对，数据库端口不直接暴露公网。
  • 排障：OS 指标与 SQL 会话结合分析，定位根因后再调参，慎用强制终止。

官方参考文档

  1. openGauss 5.0 安装 XML 与主备配置模板
  2. openGauss 5.0 gs_install
  3. openGauss 5.0 gs_om
  4. openGauss 5.0 gs_ctl
  5. openGauss 5.0 用户管理
  6. openGauss 5.0 兼容性参数
  7. openGauss 官方文档首页

本文是基于官方 5.x 文档整理的运维参考与操作示例，不是在特定生产集群中逐条执行得到的验收报告。执行可能影响数据或服务的命令前，请在与你环境一致的测试库验证。