活动专区

活动公告

上车！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 常用函数、表达式



&gt; 集群在生产环境中出现故障时，最稀缺的资源是时间。本文按故障类型分类整理了 GBase 8a 最常见的十类故障场景，每个场景给出完整的"报错现象 → 快速定位 → 根因分析 → 恢复操作"链路，可以在故障发生时直接按图索骥，减少排查时间，缩短业务中断窗口。

---

## 一、使用本手册的前提

在处理任何故障之前，先确认以下几个基础信息，这些信息会决定后续的处理路径：

```bash
# 1. 集群整体状态
gcadmin

# 2. 各节点存活状态和副本分布
gcadmin showdistribution node

# 3. 最近 100 行 gcluster 日志（定位时间点）
tail -100 $GCLUSTER_BASE/log/gcluster/system.log

# 4. gcware 仲裁层状态
tail -50 $GCWARE_BASE/log/gcware.log
```

快速扫描这四个输出，通常就能把故障范围缩小到"哪个层（gcware / gcluster / gnode）出了什么大类的问题"，然后再进入对应的场景处理流程。

---

## 二、故障场景一：集群状态 INACTIVE，业务完全无法访问

### 现象

所有客户端连接报错，gccli 无法连接，`gcadmin` 显示 `CLUSTER STATE: INACTIVE`。

### 快速定位

```bash
# 检查 gcware 的仲裁状态
grep "cluster state\|quorum\|DOWN" $GCWARE_BASE/log/gcware.log | tail -20
```

INACTIVE 的唯一原因是 gcware 判定存活节点数不足多数派（低于 N/2+1）。通常有两种情况：超过半数的 gcware 节点宕机，或者网络分区导致 gcware 节点之间无法通信。

### 恢复操作

**情况一：gcware 节点宕机**

```bash
# 在宕机节点上重启 gcware（root 或 gbase 用户）
gcware_services all start

# 观察 gcware 日志，确认节点重新加入集群
tail -f $GCWARE_BASE/log/gcware.log
# 期望看到：node X.X.X.X joined the cluster
# 然后：cluster state changed to ACTIVE
```

**情况二：网络分区（所有 gcware 进程都在运行但互相无法通信）**

```bash
# 检查 UDP 5405 端口是否通
# 在任意 gcware 节点上测试到其他节点的连通性
nc -u -z 10.168.10.27 5405 &amp;&amp; echo "通" || echo "不通"

# 临时关闭防火墙验证
systemctl stop firewalld

# 如防火墙是根因，放行端口后重启 gcware
firewall-cmd --permanent --add-port=5405/udp
firewall-cmd --reload
gcware_services all restart
```

集群恢复 ACTIVE 后，通过 `gcadmin showdistribution node` 确认所有副本状态恢复正常，然后开放业务访问。

---

## 三、故障场景二：单个 gnode 状态 CLOSE，该节点数据无法访问

### 现象

`gcadmin` 显示某个 gnode 状态为 `CLOSE`，访问包含该节点数据的查询报错，而不涉及该节点的查询仍然正常。

### 快速定位

```bash
# 查看该 gnode 的日志，找到 CLOSE 发生的原因
tail -200 $GNODE_BASE/log/gbase/system.log | grep -iE "ERROR|WARN|OOM|heap"

# 确认 gnode 进程是否还在运行
ps -ef | grep gbase | grep -v grep
```

gnode 变为 CLOSE 最常见的三种根因：内存超限触发 OOM；磁盘空间耗尽（gnode 无法写数据文件）；gnode 进程意外崩溃（可检查 core dump 文件是否生成）。

### 恢复操作

**根因是 OOM（日志中有 `heap size exceeds` 或 `OOM`）**

修改该节点的内存配置后重启：

```bash
# 检查当前内存配置（是否与实际物理内存不匹配）
grep "gbase_memory_pct_target\|gbase_heap" $GNODE_BASE/config/gbase.cnf

# 调整为合理值（以 64GB 物理内存为例）
vim $GNODE_BASE/config/gbase.cnf
# 确认：gbase_memory_pct_target = 0.75
# 确认：gbase_heap_data = 16384M
# 确认：gbase_heap_large = 16384M

# 重启该 gnode
gcluster_services gbase restart

# 等待该节点重新 OPEN
gcadmin  # 观察状态变化
```

**根因是磁盘满（日志中有 `No space left on device`）**

```bash
# 检查磁盘使用率
df -h $GNODE_BASE

# 清理可能占用大量空间的内容
# 1. 清理旧的日志文件
find $GNODE_BASE/log -name "*.log.*" -mtime +7 -delete

# 2. 如有大量 core dump 文件
find /tmp -name "core.*" -delete
find $GNODE_BASE -name "core.*" -delete

# 3. 如果是数据本身太多，考虑归档历史分区
# 磁盘释放后再重启 gnode
gcluster_services gbase restart
```

gnode 重启并变为 OPEN 后，gcrecover 会自动开始副本数据同步。通过以下 SQL 监控同步进度：

```sql
SELECT segment_id, node_name, data_state
FROM gclusterdb.segment_info
WHERE data_state != 0
ORDER BY segment_id;
```

等 `data_state` 全部变为 0，代表该节点的数据已与主副本完全同步，恢复完成。

---

## 四、故障场景三：SQL 执行卡住，长时间无响应

### 现象

某条业务 SQL 提交后一直没有响应，客户端等待超过正常预期时间数倍，但没有报错。gcluster 侧能看到该查询处于执行中状态。

### 快速定位

```sql
-- 查看当前所有活跃查询，找到卡住的那条
SELECT id, user, time, state, LEFT(info, 200) AS sql_snippet
FROM information_schema.processlist
WHERE command = 'Query'
ORDER BY time DESC;

-- 查看各节点对该查询的执行进度（通过 dql_statistic）
SELECT node_name, exec_time, rows_processed
FROM gclusterdb.dql_statistic
ORDER BY start_time DESC
LIMIT 10;
```

查看 `state` 字段是关键：`Sending data`（正在执行，只是慢）、`Waiting for table lock`（等待锁）、`Copying to tmp table`（中间结果太大，溢出到磁盘）。

### 恢复操作

**如果是正常慢查询（Sending data）**

判断是否可以继续等待，还是需要终止：

```sql
-- 确认该 SQL 是否有优化空间（执行 EXPLAIN 分析）
EXPLAIN &lt;卡住的 SQL&gt;;
-- 如果发现是全表扫描或笛卡尔积，立即终止
KILL QUERY ;
```

**如果是锁等待（Waiting for table lock）**

找到持有锁的查询并终止：

```sql
-- 查找持有锁的连接
SHOW OPEN TABLES WHERE In_use &gt; 0;

-- 查看 processlist 中持有锁的查询
SELECT id, user, time, state, info
FROM information_schema.processlist
WHERE state LIKE '%lock%'
ORDER BY time DESC;

-- 终止持有锁的旧查询
KILL &lt;持有锁的 id&gt;;
```

---

## 五、故障场景四：数据加载任务失败（status: FAILED）

### 现象

gload 或 LOAD DATA 执行后返回错误，或者 `gclusterdb.load_task` 中显示 `status = FAILED`。

### 快速定位

```sql
-- 查看失败任务的错误信息
SELECT task_id, table_name, status, error_msg, start_time, end_time
FROM gclusterdb.load_task
WHERE status = 'FAILED'
ORDER BY start_time DESC
LIMIT 10;

-- 查看错误行的具体内容
SELECT error_row_no, error_msg, SUBSTR(raw_data, 1, 200) AS raw_line
FROM gclusterdb.load_error_log
WHERE task_id = 'TARGET_TASK_ID'
LIMIT 20;
```

加载失败的最常见根因按频率排列：数据文件与表结构列数不匹配（字段分隔符配置错误或文件格式变化）；字段值超出列宽（源数据有脏数据）；字符集不匹配导致解析失败；目标分区不存在（数据的日期没有对应分区，落入 pmax 后因某种原因失败）。

### 恢复操作

**根因是文件格式问题**

```bash
# 检查数据文件的实际格式
head -3 /data/import/problem_file.csv | cat -A   # 显示不可见字符
file -i /data/import/problem_file.csv              # 检查字符集

# 确认分隔符
head -1 /data/import/problem_file.csv | awk -F',' '{print NF}' # 实际列数
```

对照 gload 配置文件检查 `fields terminated by` 是否与实际文件一致，修正后重新执行加载。

**根因是超出列宽的脏数据**

先定位问题行，在 ETL 上游处理脏数据后重新导出，或者在加载前用 `errors = N` 参数允许跳过部分错误行：

```ini
# load.cfg
errors = 1000   # 允许最多 1000 个错误行，不因少量脏数据中断整个加载
```

---

## 六、故障场景五：副本同步卡住，data\_state 长时间不为 0

### 现象

监控发现 `gclusterdb.segment_info` 中某些 Segment 的 `data_state != 0` 超过 30 分钟仍未恢复。

### 快速定位

```bash
# 查看 gcrecover 进程的同步进度日志
grep "segment\|lag_rows\|ERROR" $GCLUSTER_BASE/log/gcluster/gcrecover.log | tail -50
```

副本同步卡住通常有两种情况：目标 gnode 的磁盘 I/O 达到上限（新数据写入速度 &gt; 同步速度，`lag_rows` 不减反增）；gcrecover 进程遇到了无法处理的异常，同步线程已经停止（`lag_rows` 长时间没有变化）。

### 恢复操作

**情况一：磁盘 I/O 瓶颈（lag\_rows 缓慢减小但不停止）**

暂时降低同时进行的同步并发数，让磁盘 I/O 有更多余量：

```sql
-- 降低并发同步任务数（默认为 1，如果已调高则降回来）
SET gcluster_rebalancing_concurrent_count = 1;
```

同时检查目标 gnode 是否有其他 I/O 密集型操作（正在进行的查询或加载）正在竞争磁盘，暂停这些操作让同步优先完成。

**情况二：同步线程停止（lag\_rows 完全不变）**

```bash
# 重启 gcrecover 进程（在 gcluster 主节点执行）
gcluster_services gcrecover restart

# 等待片刻后观察同步是否重新开始
grep "Recover Thread started" $GCLUSTER_BASE/log/gcluster/gcrecover.log | tail -5
```

---

## 七、故障场景六：gcluster 无法启动，集群不可用

### 现象

gcluster 进程启动失败，`gcluster_services all start` 执行后进程不在，日志中有启动错误。

### 快速定位

```bash
# 查看 gcluster 启动日志（通常在进程目录的 startup.log 或 system.log 开头）
head -100 $GCLUSTER_BASE/log/gcluster/system.log

# 或者直接前台启动看报错
$GCLUSTER_BASE/server/bin/mysqld --defaults-file=$GCLUSTER_BASE/config/gbase.cnf &amp;
tail -f $GCLUSTER_BASE/log/gcluster/system.log
```

gcluster 启动失败的常见根因：配置文件语法错误（修改了 gbase.cnf 但写错了参数名或值）；端口已被占用（5258 端口被其他进程占用）；数据目录权限问题（gbase 用户对数据目录没有写权限）；上次异常关闭留下了 pid 文件或锁文件。

### 恢复操作

**根因是端口占用**

```bash
# 检查 5258 端口是否被占用
netstat -tulnp | grep 5258
lsof -i :5258

# 如果是上次未清理的残留进程
kill -9 &lt;残留进程PID&gt;

# 清理 pid 文件
rm -f $GCLUSTER_BASE/data/*.pid

# 重新启动
gcluster_services all start
```

**根因是配置文件错误**

```bash
# 使用参数检查命令验证配置文件语法
$GCLUSTER_BASE/server/bin/mysqld \
    --defaults-file=$GCLUSTER_BASE/config/gbase.cnf \
    --validate-config 2&gt;&amp;1 | head -20

# 对照错误信息修正配置文件后重新启动
```

---

## 八、故障场景七：查询结果与预期不符（数据异常）

### 现象

报表数字突然变化、某天的数据量异常偏少或偏多、聚合结果与上游源系统对不上。

### 快速定位

这类问题不是集群故障，而是数据质量问题，需要从数据层面定位：

```sql
-- 1. 检查最近几天的每日数据量趋势（是否某天突然异常）
SELECT order_date, COUNT(*) AS daily_rows, SUM(amount) AS daily_amount
FROM orders
WHERE order_date &gt;= CURDATE() - INTERVAL 7 DAY
GROUP BY order_date
ORDER BY order_date;

-- 2. 检查是否有重复数据（最常见的数量偏多根因）
SELECT order_date,
       COUNT(*) AS total_rows,
       COUNT(DISTINCT order_id) AS unique_orders,
       COUNT(*) - COUNT(DISTINCT order_id) AS duplicate_rows
FROM orders
WHERE order_date &gt;= CURDATE() - INTERVAL 3 DAY
GROUP BY order_date;

-- 3. 检查当天的加载任务是否全部成功
SELECT task_id, table_name, status, loaded_rows, error_rows, start_time, end_time
FROM gclusterdb.load_task
WHERE DATE(start_time) = CURDATE() - INTERVAL 1 DAY
ORDER BY start_time;
```

根据以上检查的结果，按不同根因走对应的处理流程：重复数据走去重修复（参考第 28 篇数据质量文章）；加载任务失败走故障场景五的流程处理；统计信息过期导致查询结果异常（极少见但可能）走 ANALYZE TABLE 更新统计信息。

---

## 九、故障场景八：连接数耗尽，新连接被拒绝

### 现象

应用报 `Too many connections` 错误，但部分已有连接仍然正常。gccli 尝试连接也失败。

### 快速定位

```sql
-- 用已有的连接（或通过 DBA 专用账号）查看连接分布
SELECT user, COUNT(*) AS conn_count
FROM information_schema.processlist
GROUP BY user
ORDER BY conn_count DESC;

-- 查看长时间空闲的连接（占用连接资源但没有实际工作）
SELECT id, user, host, time, command
FROM information_schema.processlist
WHERE command = 'Sleep' AND time &gt; 300
ORDER BY time DESC;
```

### 恢复操作

**紧急处理：清理长时间空闲的连接**

```sql
-- 生成 KILL 语句后执行（谨慎：会断开对应的客户端连接）
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.processlist
WHERE command = 'Sleep' AND time &gt; 600;

-- 确认后执行（可以一次性执行多个 KILL）
KILL 12345;
KILL 12346;
```

**根本解决：增大连接数上限或调整连接池配置**

临时增大 max\_connections（不需要重启，立即生效）：

```sql
SET GLOBAL max_connections = 1000;
```

同时联系应用方检查连接池配置是否合理（是否开启了 `testWhileIdle`、`poolRecycle` 等保活和回收机制，防止空闲连接长期占用）。长期解决方案是在 gbase.cnf 中调整 `max_connections` 并给每个账号设置 `MAX_USER_CONNECTIONS` 上限。

---

## 十、集群巡检与预防性维护

故障后的被动处理不如主动预防。以下是一套建议的日常巡检项目，能在大多数问题演变成重大故障之前发现苗头：

```sql
-- 每日必查：节点状态和副本同步（任何异常立即告警）
SELECT node_name, gnode_status, data_state
FROM gclusterdb.node_info
WHERE gnode_status != 'OPEN' OR data_state != 0;

-- 每日必查：前一天是否有加载任务失败
SELECT table_name, COUNT(*) AS failed_tasks, SUM(error_rows) AS total_errors
FROM gclusterdb.load_task
WHERE status = 'FAILED' AND DATE(start_time) = CURDATE() - INTERVAL 1 DAY
GROUP BY table_name;

-- 每周必查：各节点数据量均衡性（偏差超 30% 需关注）
SELECT node_name,
       ROUND(SUM(data_size)/1073741824, 2) AS data_gb,
       ROUND((SUM(data_size) - AVG(SUM(data_size)) OVER()) /
             AVG(SUM(data_size)) OVER() * 100, 1) AS deviation_pct
FROM gclusterdb.segment_info
GROUP BY node_name
ORDER BY data_gb DESC;

-- 每周必查：pmax 分区数据量（应该接近 0）
SELECT table_name, table_rows, ROUND(data_length/1073741824, 3) AS pmax_gb
FROM information_schema.partitions
WHERE partition_name = 'pmax' AND table_rows &gt; 100000
ORDER BY table_rows DESC;
```

把以上巡检 SQL 整合到每日/每周的自动化脚本中，结合第 18 篇中介绍的告警推送机制，构建一套轻量但有效的预防性监控体系，是降低集群故障频率和缩短平均修复时间（MTTR）最有性价比的投入。



GBase 8a 集群故障处理手册：从报错到恢复的完整操作指南

评论

热门帖子