GBase 8a 集群巡检需分步核验：先测试客户端与 JDBC 能否正常连接 CN 节点，再验证增删建表等写入操作，排查只读或集群不可用报错；核对 CN、DN 节点数量与在线状态，同时检查各节点磁盘、内存资源负载。注意网络通不代表集群服务正常，多 CN 环境需逐台检测，区分集群只读的不同成因，并使用低权限账号执行巡检。整体遵循先查集群状态、连通性与读写能力，再深入专项问题的思路，做好巡检记录便于运维复盘。

日常巡检 GBase 8a，首先确认 gccli、JDBC 可正常登录 CN，测试写入语句是否触发只读、集群不可用类错误；其次核对节点数量与在线状态，检查硬件资源是否临近上限。

开展 GBase 8a 集群健康检查，依次完成连接登录、读写功能、节点状态、系统资源四大项检测。

活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

GBase 8a 上线后，DBA 的日常工作不只是「慢 SQL 调优」，还包括 **节点是否齐、服务是否可写、磁盘与进程是否健康**。很多故障在业务报障前，其实能在巡检里看到苗头：某个 DataNode 状态异常、集群处于 readonly、或 coordinator 列表与预期不符。命令行工具 **gcadmin**（名称与参数以现场版本文档为准）是集群侧最常用的入口之一，适合写成脚本做日检、周检。

本文整理一套 **由浅入深** 的巡检顺序，并说明每项异常时该往哪继续查，便于在 8a 环境直接落地。

## 一、巡检目标：先回答四个「能不能」

每次巡检建议先记录时间、集群名、版本，然后快速回答：

1. **能不能连上**：gccli / 应用 JDBC 是否正常登录 CN？
2. **能不能写**：`INSERT`/`CREATE` 是否报 cluster readonly 或 not available？
3. **节点齐不齐**：DN/CN 数量是否与部署规划一致、有无 offline？
4. **资源够不够**：各节点磁盘、内存是否逼近阈值？

下面命令在 **集群管理节点或安装了 gcadmin 的主机** 上执行（权限以现场为准）。

## 二、集群状态：gcadmin 第一眼

常见第一步是查看集群整体状态（子命令以文档为准）：

```bash
gcadmin
# 或
gcadmin showcluster
```

阅读输出时建议对照表：

| 关注点 | 正常大致形态 | 异常时动作 |
|--------|----------------|------------|
| Cluster state | ACTIVE / NORMAL | readonly → 查 ZK、长事务、维护窗口 |
| Coordinator | 列表数量与规划一致 | 少节点 → 查进程与日志 |
| Data node | 全部 online | 单节点 offline → 查该 DN 主机与磁盘 |
| Version | 各节点一致 | 不一致 → 禁止继续扩容，先对齐版本 |

若 `showcluster` 显示某 DN **offline**，在改 SQL 之前应先恢复节点或做副本切换；否则后续 EXPLAIN 再漂亮也会拖尾或报错。

## 三、节点与进程：从列表到主机

在确认 gcadmin 有异常节点后，到对应主机检查（路径以安装为准）：

```bash
# 进程是否在（示例）
ps -ef | grep gbased
ps -ef | grep gcluster

# 磁盘
df -h
```

典型分支：

- **进程不在、磁盘满** → 先清日志/临时目录（勿删数据目录），再按手册拉起 DN。
- **进程在但 gcadmin 仍 offline** → 看该节点 `gcluster`/`gbased` 日志中的注册、心跳、端口错误。
- **仅网络闪断** → 恢复后观察是否自动同步；长时间 offline 需核对副本与数据一致性（参见集群恢复类文档）。

CN 异常时，业务侧多为 **连接失败或间歇超时**；此时 `SHOW PROCESSLIST` 可能都进不去，要以 gcadmin + CN 日志为主。

## 四、gccli 侧快速写读探针

gcadmin 正常后，用 **gccli** 在 CN 上做最小探针，确认 SQL 层可用：

```sql
SELECT 1;

-- 若有权限，查看当前库
SELECT DATABASE();

SHOW PROCESSLIST;
```

写探针（在测试库或专用 schema，避免污染生产）：

```sql
-- 示例：在允许的环境插入一行后回滚
START TRANSACTION;
INSERT INTO t_health_probe(id, probe_time) VALUES (1, NOW());
ROLLBACK;
```

若 `SELECT 1` 成功但 `INSERT` 报 cluster 不可用，问题在 **集群写状态或元数据**，而不是单条 SQL 计划。

## 五、与 MPP 性能巡检的衔接

健康巡检通过后，再抽样 **性能向** 检查（可与慢 SQL 文配合）：

```sql
EXPLAIN
SELECT COUNT(*) FROM large_fact WHERE dt = CURRENT_DATE - 1;
```

关注是否出现 **全分片扫 + 无分区裁剪**。日检不必每条 SQL 都 EXPLAIN，选 1～2 条核心业务模板即可。

同时看 **连接数**（会话治理文）：`Sleep` 占比过高说明连接池配置需治理，与「节点 offline」是不同条线。

## 六、建议的日检 / 周检清单（可脚本化）

```text
[日检]
  gcadmin showcluster → 记录 state、offline 节点数
  各 DN df -h → 数据盘、tmp 盘 &lt;85%
  gccli SELECT 1 + 可选写探针
  应用侧错误日志有无 mass connection / readonly

[周检]
  对比节点版本、补丁是否一致
  抽查 2 条核心 SQL 的 EXPLAIN（Motion、裁剪）
  统计信息：大表上次 ANALYZE 时间
  备份/归档任务是否成功（若有）
```

将输出重定向到文件，便于与次日对比——**磁盘缓慢增长**比突然打满更容易提前处理。

## 七、常见误报与避坑

1. **只 ping 通不代表集群健康**：TCP 通但 gcluster 未注册，gcadmin 仍会 offline。
2. **不要仅凭单 CN 判断全局**：多 CN 时应对照列表逐台探针，或确认 LB 背后 CN 都正常。
3. **维护窗口忘记改回 writable**：gcadmin 显示 readonly 时先查变更单，再查 ZK/锁。
4. **巡检账号权限过大**：探针用专用只读/可回滚账号，避免误操作生产表。

## 小结

GBase 8a 集群健康巡检的核心，是用 **gcadmin 看拓扑与状态**，再到异常节点查 **进程、磁盘、日志**，最后用 **gccli 探针** 验证读写。把「能不能写、节点齐不齐」先搞清楚，再进入慢 SQL、落盘、连接治理等专题，排障路径会更稳。建议将每次巡检的 `showcluster` 摘要与 offline 事件记入运维台账，积累成自己的 8a 集群基线。



GBase 8a 集群健康巡检：gcadmin 与日常可执行的检查项

评论

热门帖子