磐维数据库（PanWeiDB）日常运维命令总结

一、日常运维命令

1. 环境准备（黑屏操作前置）

磐维运维大量操作依赖命令行环境变量加载，执行任何工具前先加载环境：

bash 复制代码

source /home/Ruby/.bashrc
if [ -f /home/Ruby/gauss_env_file ]; then source /home/Ruby/gauss_env_file; fi

提示：官方也提供白屏化运维页面，可直接下发常用 SQL 语句或命令，减少黑屏化操作。

2. 集群 / 实例状态查看

命令	用途	版本
`cm_ctl query -Cvidp -z ALL`	查看集群所有节点/实例状态（分布式常用）	分布式
`gs_om -t status --detail`	输出各节点角色、状态详情，应急排查第一步	两版通用
`gs_om -t query`	CM 组件不可用时降级查询 DN 集群状态	两版通用
`ha_ctl monitor all -l http://<ip>:2379 -H`	连接 etcd 查看 CN/DN/GTM 服务状态与 HA 组主备角色	分布式
`gs_ctl query -D /database/panweidb/data`	查询单实例状态及 `receiver_flush_location` 等 LSN 位置	两版通用

相关配置确认命令：

bash 复制代码

# 查看同步备节点名称
cat /database/panweidb/data/postgresql.conf | grep synchronous_standby_names

3. 启停管理

命令	用途
`cm_ctl start` / `cm_ctl stop`	启动/停止数据库实例服务、AZ 所有实例、单主机所有实例或单个实例进程
`cm_ctl start -n <节点名>`	启动指定节点（如重建后拉起 CM）
`gs_ctl start -D <数据目录>`	启动单个实例服务
`gs_ctl stop -D <数据目录>`	停止单个实例服务
`gs_ctl restart -D <数据目录>`	重启单个实例服务
`gs_om -t start` / `gs_om -t stop`	集群级启停
`ha_ctl stop -n <节点名> <coordinator	datanode>`

注意：集中式单节点不支持主备间操作。gs_om 正常运行依赖有效的许可证（lic）导入，缺失会直接报错。

4. 参数管理（gs_guc）

bash 复制代码

# 批量设置所有节点参数
gs_guc set -Z <role> -N all -I all -c "param=value"

# 查看参数当前值
gs_guc check -N all -I all -c 'param_name'

# 在线生效（无需重启时）
gs_guc reload -N all -I all -c 'param_name=value'

-Z：角色（coordinator / datanode / gtm），分布式按角色下发；
-N -I：节点范围；
部分参数需重启数据库或重新打开会话才生效；部分参数不能写入配置文件，会自动还原。

常用检查示例：

bash 复制代码

# 确认节点是否被置为只读
gs_guc check -N all -I all -c 'default_transaction_read_only'
# 恢复读写
gs_guc reload -N all -I all -c 'default_transaction_read_only=off'

5. 节点重建与主备切换

bash 复制代码

# 备节点异常（如 Standby Need repair）时全量重建
# 1) 先关闭该节点的 CM
# 2) 执行重建
gs_ctl build -D /database/panweidb/data
# 3) 确认状态为 normal
gs_ctl query -D /database/panweidb/data
# 4) 启动该节点 CM
cm_ctl start -n <节点名>
# 5) 整体确认
gs_om -t status --detail

多数节点故障手动升主流程（应急）：

bash 复制代码

# 优先尝试拉起原主
gs_ctl start -D /data -M primary
# 若失败：注释 crontab 中 om_monitor 定时任务，kill 掉 CM 相关进程
# （om_monitor / cm_agent / cm_server）
# 比较各备节点 LSN，选 LSN 靠后者升主
gs_ctl failover

6. 会话 / 锁 / 内存 / 日志巡检

会话与锁（基于系统视图）：

pg_stat_activity：实时查看活动会话、锁等待状态、事务与查询执行情况；
pg_locks + pg_stat_activity 关联：定位持有锁与等待锁的会话、被阻塞等待秒数；
gs_asp：按 sample_time、block_sessionid 分组统计阻塞会话数，逐层追溯阻塞链（HAVING count(*) > 5 过滤高频 blocker）。

内存检查视图：

gs_total_memory_detail：dynamic_used_memory 接近 max_dynamic_memory 表示动态内存可能不足；dynamic_peak_memory 超过 max_dynamic_memory 说明曾发生 OOM；
关键参数：max_process_memory（单进程最大可用内存）、shared_buffers（共享缓存大小）。

检查点 / WAL 位置：

bash 复制代码

pg_controldata -D /database/panweidb/data
# 查看 last checkpoint 点与 redo location 点，判断是否落后于主机日志位置

兼容模式查看（知识库示例）：

sql 复制代码

SELECT datname, datcompatibility FROM pg_database WHERE datname='目标库名';

7. 表空间与日志管理

表空间：可通过 CREATE TABLESPACE / DROP TABLESPACE 控制磁盘布局与分布；删除前表空间内不能有任何对象，否则报错；仅所有者或具备 DROP 权限的用户可删除；
告警日志：由平台定期清理，清理任务异常会触发 ALM-5012601 告警日志清理异常。

二、备份恢复命令

磐维提供物理备份 与逻辑备份两条路线，均支持通过管理平台统一调度。

1. 物理备份（推荐，高性能）

底层执行程序为核心系统备份工具（由管理平台调用），支持全量和增量物理备份。

gs_probackup 常用命令：

bash 复制代码

# 初始化备份目录（首次）
gs_probackup init -B /backup/probackup

# 全量备份（增加 -t 延长超时，防止大负载下 checkpoint 超时）
gs_probackup backup -B /backup/probackup --instance <实例名> -b FULL -t 600

# 增量备份
gs_probackup backup -B /backup/probackup --instance <实例名> -b INCR

# 查看备份集状态（排查备份失败第一步）
gs_probackup show -B /backup/probackup

# 恢复（先 restore 全量，再应用归档日志前滚）
gs_probackup restore -B /backup/probackup --instance <实例名> -i <备份ID>

备份参数参考（日志示例）： 版本 2.4.2、模式 FULL、WAL 模式 STREAM、无压缩。

关键注意事项：

超时控制 ：备份启动需先做一次全量 checkpoint，rwtimeout 默认 120 秒，业务流量大 / 磁盘慢时易超时断开，务必用 -t <秒数>（如 -t 600）延长；
后台执行：未后台运行的备份命令会受终端超时影响而断开，建议改为后台运行；
归档检查 ：全量备份失败常见于归档未开启、归档路径错误、目录无权限、wal_sender_timeout 不当等，需逐项排查；
校验和 ：启用数据块校验和后，备份读取到损坏页会报 page verification failed, calculated checksum X but expected Y，需通过文件路径中的 OID 与 relfilenode 定位具体表修复；
恢复性能：备份文件放在 NFS 网络存储会显著拖慢恢复（受带宽、延迟及 I/O 竞争影响），建议复制到本地高性能存储再恢复。

2. 逻辑备份 / 恢复（gs_dump / gs_restore / gs_dumpall / gs_loader / gsql）

bash 复制代码

# 备份指定表（文本格式）
gs_dump -p 15400 -U panwei postgres -t test_addback_time -F p -f test_addback_time.sql

# 备份整个数据库
gs_dump -p 15400 -U panwei postgres -F p -f postgres.sql

# 按 Schema 备份（可连续使用多个 -n）
gs_dump -p 15400 -U panwei my_database -n schema1 -n schema2 -F p -f schema.sql

# 导出所有数据库
gs_dumpall -p 15400 -U panwei -f all.sql

# 使用 gs_restore 导入 gs_dump 导出的文件
gs_restore -p 15400 -U panwei -d targetdb dumpfile

# 使用 gsql 执行脚本恢复
gsql -p 15400 -U panwei postgres -f test_addback_time.sql
# 恢复到新库
gsql -p 15400 -U panwei testdb -f postgres.sql

# gs_loader 批量导入数据
gs_loader -p 15400 -U panwei control_file.ctl

注意：gs_dump 导出 Schema 时若依赖其他未导出的 Schema，导入会报缺少依赖对象，恢复前需先创建好被依赖对象。备份建议以初始用户或具备 sysadmin 权限的用户执行。

3. 基于时间点恢复（PITR）

原理：利用全量物理备份 + 连续归档日志构建恢复链，先 restore 全量备份，再基于归档日志做 recovery 重做，通过指定停止时间点还原到任意时刻；
操作方式：通过管理平台发起恢复，可选择恢复到不同备份时间点（全量 / 增量 / 指定时间点）；
恢复校验关键字段 ：Data（恢复的全量数据大小）、WAL（应用的归档日志大小）、Time（恢复耗时）、LSN 范围（确认数据恢复位置）。例如某次全量恢复：Data 629GB、WAL 1632MB、耗时 41 分 35 秒。

4. 备份恢复验证流程（标准做法）

全量恢复验证：

创建 testdb 库和 txn_proc_result 表，插入数据并记录数据量与时间点；
通过管理平台执行全量备份；
删除 testdb 库；
通过管理平台发起恢复；
校验库、表及数据量与备份时一致。

增量恢复验证：

第一次备份后记录数据量与时间；
插入新数据并记录时间；
执行第二次增量备份；
恢复时指定第一次或第二次备份时间点；
通过 SELECT count(*), now() 验证数据量与该时间点记录一致。

三、两版本差异速查

能力	集中式	分布式
集群状态	`gs_om -t status --detail`	`cm_ctl query -Cvidp -z ALL`、`ha_ctl monitor all -l http://ip:2379 -H`
节点管理	单节点，不支持主备间操作	`ha_ctl stop/monitor` 管理 coordinator/datanode
参数下发	`gs_guc set/check/reload`	`gs_guc set -Z <role> -N all -I all -c` 按角色下发
物理备份	gs_probackup / 平台工具	gs_probackup / 平台工具（支持增量 + 指定时间点）