活动专区

活动公告

上车！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 集群各组件产生大量日志文件，很多运维人员只知道查 system.log，却不知道不同日志的分工和关键字段含义。本文系统梳理 gcware、gcluster、gnode 三层日志的位置、格式、关键信息，并附常见故障的日志级排查方法。


---

## 一、日志体系总览

GBase 8a 是一个多进程的分布式集群，gcware、gcluster、gnode 三类进程各司其职，各自维护一套独立的日志体系。这种设计的好处是每层日志的职责边界清晰，坏处是排查跨层问题时需要同时打开多个日志文件交叉比对。理解日志分层是高效排障的第一步。

三层日志的分工可以类比为：gcware 是"仲裁法庭"的记录，负责记录哪个节点活着、谁是主副本、集群状态如何变化；gcluster system.log 是"SQL 法庭"的记录，每条 SQL 的执行、报错、慢查询都在这里；gnode 的日志是"仓库工人"的工作记录，数据扫描、内存分配、磁盘写入发生了什么都在这里。

实际排查时，一般从现象出发反向定位：业务反馈查询报错，先看 gcluster system.log 的 ERROR 行；集群监控说节点 CLOSE，先看 gcware.log 的心跳超时；gnode 进程崩溃，先看 gnode 的 error.log 和 system.log 中的 OOM。掌握这条反向定位链路，能把排障时间缩短数倍。

日志文件的默认路径布局如下，实际路径取决于安装时指定的 `installPrefix`：

```
/opt/gbase/
├── gcware/log/
│   ├── gcware.log         ← 仲裁层：节点心跳、Leader 选举、副本状态
│   └── gcware_audit.log   ← gcware 审计
├── gcluster/log/gcluster/
│   ├── system.log     ← 核心：SQL 执行、错误、集群事件
│   ├── slow_query.log ← 慢查询（log_output=FILE 时）
│   ├── error.log      ← 严重错误摘要
│   └── gcrecover.log  ← 副本同步恢复进程日志
└── gnode/log/gbase/
    ├── system.log       ← 数据节点：查询执行、内存、I/O 事件
    ├── error.log        ← gnode 严重错误
    └── gbase_loader.log ← 数据加载专用日志
```

---

## 二、gcware 日志：集群仲裁层的眼睛

gcware 是整个集群的神经中枢，基于 Corosync 实现节点间心跳和状态仲裁。gcware.log 记录的是集群拓扑层面发生的一切事件，与上层的 SQL 执行无关。这个日志最重要的价值在于：当集群出现节点故障、状态变化、主副本切换时，这里是第一手的时间线记录。

gcware 的心跳机制每隔几百毫秒向其他节点发送探活报文。当一个节点连续若干次心跳无响应时，gcware 会按照配置的超时参数将其标记为 DOWN，随后触发主副本的切换流程。整个过程都忠实地记录在 gcware.log 中，包括每次心跳的延迟、超时前的重试次数、最终宣布节点失联的时刻，以及哪个 Segment 的主角色从哪个节点转移到了哪个节点。

gcware 日志的模块标签（尖括号中的缩写）帮助快速识别事件来源：`` 是 Cluster Manager，负责节点存活管理；`` 是副本同步模块，负责数据版本协商和主副本切换；`` 是分布式锁模块，负责防止并发的集群管理操作互相冲突。

```
2024-06-01 02:13:45.123 [INFO ]  node 10.168.10.27 joined the cluster
2024-06-01 02:13:45.456 [INFO ]  cluster state changed to ACTIVE
2024-06-01 03:42:11.789 [WARN ]  node 10.168.10.28 heartbeat timeout, retrying...
2024-06-01 03:42:16.012 [ERROR]  node 10.168.10.28 declared DOWN after 5 retries
2024-06-01 03:42:16.345 [INFO ]  segment 3 primary transferred from node3 to node2
```

从上面这段日志可以清楚地读出：10.168.10.28 在 03:42:11 开始出现心跳超时，经过 5 次重试（约 5 秒后）在 03:42:16 被宣告 DOWN，紧接着 gcware 完成了 Segment 3 的主副本转移。整个自动切换过程不到 10 秒，这也是 GBase 8a 高可用设计的体现——节点故障对上层业务的影响窗口极短。

有两类高危日志特征需要立即响应。第一种是 gcware 启动失败时的端口扫描错误，通常意味着节点间的 UDP 5405 端口被防火墙阻断，导致 Corosync 无法建立通信通道。第二种是仲裁节点数下降到临界值时的降级警告，对于 3 个 gcware 节点的集群，2 个节点存活是临界值，任何一个节点再故障就会导致集群 INACTIVE，此时必须把修复第三个节点作为最高优先级处理。

```bash
# 查找节点故障切换事件
grep -E "DOWN|transferred|primary" /opt/gbase/gcware/log/gcware.log | tail -50

# 查找心跳超时（用于还原故障时间线）
grep "heartbeat timeout" /opt/gbase/gcware/log/gcware.log | tail -20

# 查找集群状态变化（ACTIVE → INACTIVE）
grep "cluster state changed" /opt/gbase/gcware/log/gcware.log
```

---

## 三、gcluster system.log：SQL 执行的完整档案

gcluster 的 system.log 是日常运维中查阅频率最高的日志文件。所有经过 gcluster 的 SQL 请求（包括成功的、失败的、超时的）、所有 DDL 变更、所有连接建立和断开，都会在这里留下记录。

这个日志最有价值的设计是​**线程 ID（TID）**​。每个客户端连接对应一个固定的 TID，该连接存活期间发出的所有操作都会携带同一个 TID 前缀。这意味着当某个业务反馈"刚才有一条查询报错了"，可以用错误发生时刻在日志里找到对应的 TID，然后用这个 TID 过滤出该连接的完整操作序列——它登录时的用户名、发出了哪些 SQL、哪条失败了、失败的错误码是什么——全部一目了然。这个设计极大地降低了线上问题复现的难度。

需要注意的是，gcluster system.log 默认​**只记录慢查询的 SQL 文本**​，普通执行成功的 SQL 只记录一行 `Query OK` 摘要（含执行时间和影响行数），不记录完整 SQL 内容。这是为了避免日志文件过大。如果需要记录所有 SQL，可以将 `log_level` 调为 DEBUG，但代价是日志量暴增，不建议在生产环境长期开启，仅在定向排查特定问题时临时使用。

```
2024-06-01 14:23:05.123456 [INFO ][TID:12345] Connected: user=analyst host=10.168.10.100 db=sales_db
2024-06-01 14:23:05.567890 [INFO ][TID:12345] Query: SELECT dept_id, SUM(amount) FROM orders ...
2024-06-01 14:23:08.123456 [INFO ][TID:12345] Query OK: 34 rows affected, elapsed: 2.556s
2024-06-01 14:30:11.000000 [ERROR][TID:67890] Query Error: [1064] You have an error in your SQL syntax
2024-06-01 14:35:22.000000 [WARN ][TID:11111] Query slow: elapsed=35.12s, rows_examined=300000000
```

慢查询日志行（`Query slow`）含有两个关键信息：`elapsed` 是客户端感受到的总耗时，`rows_examined` 是 gnode 扫描的总行数。如果 elapsed 很长但 rows\_examined 不多，说明瓶颈在 gcluster 的汇总或网络传输；如果 rows\_examined 达到亿级，说明需要检查分区裁剪是否生效、分布键是否导致了数据倾斜。

对于安全审计场景，DDL 操作的追踪尤为重要。`CREATE TABLE`、`DROP TABLE`、`TRUNCATE TABLE` 这类高风险操作都会留下带有 TID（进而可追溯到用户名和来源 IP）的日志记录。定期导出 DDL 操作日志，可以作为安全审计的基础数据。连续出现大量 `Access denied` 记录时，也可能是暴力破解尝试，需要及时关注。

```bash
# 查找所有 ERROR 级别日志
grep "\[ERROR\]" /opt/gbase/gcluster/log/gcluster/system.log | tail -100

# 查找 DDL 操作（CREATE/DROP/ALTER）
grep -iE "(CREATE|DROP|ALTER|TRUNCATE) (TABLE|DATABASE)" \
    /opt/gbase/gcluster/log/gcluster/system.log | tail -50

# 用 TID 追踪某个会话的完整操作历史
grep "\[TID:12345\]" /opt/gbase/gcluster/log/gcluster/system.log

# 查找连接认证失败（可能是暴力破解）
grep "Access denied" /opt/gbase/gcluster/log/gcluster/system.log | tail -20

# 统计过去 1 小时的错误数（用于监控告警）
awk -v ts="$(date -d '1 hour ago' '+%Y-%m-%d %H:%M:%S')" \
    '$0 &gt;= ts &amp;&amp; /ERROR/' \
    /opt/gbase/gcluster/log/gcluster/system.log | wc -l
```

---

## 四、gnode system.log：数据节点的内部状态

如果说 gcluster system.log 是"指挥中心的记录"，那么 gnode 的 system.log 就是"前线工兵的日志"。gcluster 把一个 SQL 拆分成若干 Fragment 后分发给各个 gnode，每个 gnode 的执行过程、内存使用、磁盘 I/O 情况，都记录在各自的 system.log 里。

在多节点集群中，每个 gnode 都有自己独立的 system.log，排查某个节点是否是性能瓶颈时，需要逐一检查各节点的日志。这在实践中稍显繁琐，但也是 Shared-Nothing 架构的特性——每个节点完全自治，日志自然也是分散的。

gnode system.log 中最有价值的信息有三类。第一是​**内存配置验证**​：gnode 每次启动都会把实际加载的内存参数打印出来。配置文件里写的值和实际生效的值有时会有差异（比如配置超过物理内存，gnode 会自动降调），通过检查启动日志可以确认配置是否真正生效，这是很多"改了参数没效果"问题的排查起点。第二是​**Fragment 执行统计**​：通过对比不同节点处理的数据量，可以直接量化数据倾斜程度。第三是​**内存超限和 OOM**​：内存不足时先出现 WARN 后出现 ERROR，配合参数调整可以逐步解决。

```
2024-06-01 14:23:05.200 [INFO ] Express engine started, heap_data=16384M, heap_large=16384M
2024-06-01 14:23:07.300 [INFO ] Fragment exec: sql_id=abc123 seg=4 rows=25000000 elapsed=2.1s
2024-06-01 14:35:00.000 [WARN ] express total heap size exceeds memory limit!
2024-06-01 14:35:00.100 [ERROR] OOM: query aborted, session=67890
2024-06-01 15:00:00.000 [INFO ] Segment 4 sync start from primary node1, version=1000
2024-06-01 15:02:30.000 [INFO ] Segment 4 sync complete, rows=25000000, elapsed=150s
```

```bash
# 查找 OOM 和内存超限事件
grep -iE "(OOM|heap.*exceed|memory limit|out of memory)" \
    /opt/gbase/gnode/log/gbase/system.log | tail -50

# 确认 gnode 启动时的实际内存配置
grep "Express engine started" /opt/gbase/gnode/log/gbase/system.log | tail -5
```

---

## 五、gcrecover.log：副本同步的进度追踪

gcrecover 是在每个 gcluster 节点上运行的后台进程，专门负责主副本之间的数据对齐。当某个 gnode 宕机恢复，或者新节点加入时，gcrecover 会把主副本上"比从副本多"的那部分数据追补过去，直到主从版本一致。

gcrecover.log 的核心价值是追踪​**同步进度**​。日志中的 `lag_rows` 字段表示从副本落后主副本的行数，这个数字应该随时间持续减小。如果 lag\_rows 在较长时间内停止减小甚至增大（说明写入速度快过同步速度），就需要立即介入——可能是目标 gnode 的磁盘 I/O 达到上限，也可能是 gcrecover 进程本身出现了异常。

副本同步异常往往是无声无息的，不会触发显式报错，只会在 `gclusterdb.segment_info` 的 `data_state` 字段中默默标记非零值。养成定期检查 gcrecover.log 的习惯，能在数据不一致发展成大问题之前发现苗头。建议将 gcrecover.log 中的 ERROR 和 FAIL 关键词纳入监控告警体系，做到第一时间感知。

```
2024-06-01 03:42:20.500 [INFO ]  segment 3: target=node2, source=node1, lag_rows=5000000
2024-06-01 03:45:10.000 [INFO ]  segment 3: sync complete, rows=5000000, elapsed=170s
```

```bash
# 查找同步失败事件
grep -E "(FAIL|ERROR|timeout)" /opt/gbase/gcluster/log/gcluster/gcrecover.log | tail -50

# 观察 lag_rows 变化趋势（数字应持续减小）
grep "lag_rows" /opt/gbase/gcluster/log/gcluster/gcrecover.log | tail -20
```

---

## 六、加载日志：gbase\_loader.log

gbase\_loader.log 专门记录每次 gload 或 LOAD DATA 的全过程，是数据加载问题排查的第一入口。这个日志以\*\*任务（task）\*\*为单位组织内容，每个加载任务有唯一的 task\_id，所有相关日志行都携带这个 ID。在高并发加载场景（多个系统同时向不同表加载数据），可以精确地按 task\_id 过滤出某次加载的完整日志，而不会被其他任务干扰。

加载日志还记录了逐阶段的速度数据，对性能优化非常有参考价值。通过对比不同参数配置下的加载速度（`speed` 字段的行/秒），可以量化地评估参数调整效果，而不是凭感觉猜测。每次调整 `gcluster_loader_max_data_processors` 或 `gbase_loader_parallel_degree` 后，对比加载日志中的 speed 变化，能清楚地看到参数调整是否奏效、奏效了多少。

```
2024-06-01 02:00:05 [INFO ] Load task started: task_id=20240601_020005_000001, table=orders
2024-06-01 02:00:05 [INFO ] File: /data/import/orders_2024.csv, size=2.3GB
2024-06-01 02:05:30 [INFO ] Progress: 50000000 rows loaded, speed=166667 rows/s
2024-06-01 02:10:55 [INFO ] Load complete: 100000000 rows, 0 errors, elapsed=10m50s
```

```bash
# 查找加载错误和异常
grep -i "error\|fail\|reject" /opt/gbase/gnode/log/gbase/gbase_loader.log | tail -50

# 汇总最近加载任务的速度表现
grep "Load complete" /opt/gbase/gnode/log/gbase/gbase_loader.log | tail -20
```

---

## 七、日志轮转：防止磁盘被日志写满

GBase 8a 的日志默认不做自动轮转，在高负载的生产环境中，gcluster system.log 每天可以产生数 GB 甚至更多的内容。如果任其增长，最终会把磁盘写满，反过来影响数据库正常运行。磁盘因日志写满导致集群故障，是完全可以通过提前配置 logrotate 来避免的事故，属于"明知道会发生但没做预防"的低级问题。

logrotate 的 `postrotate` 钩子向 gcluster 进程发送 HUP 信号，可以让进程在轮转后重新打开新的日志文件，而不是继续向已被重命名的旧文件写入。日志保留策略需要结合安全审计要求来定——如果所在行业要求日志至少保留 6 个月，`rotate` 参数应设为 180（配合 `daily` 轮转），并确保日志所在磁盘有足够空间。`compress` + `delaycompress` 的组合能在节省磁盘空间的同时，保留最近一天的未压缩日志，便于实时 grep。

```bash
# /etc/logrotate.d/gbase8a
/opt/gbase/gcluster/log/gcluster/*.log
/opt/gbase/gnode/log/gbase/*.log
/opt/gbase/gcware/log/*.log
{
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        kill -HUP $(pgrep -f gcluster) 2&gt;/dev/null || true
    endscript
}
```

```bash
logrotate -d /etc/logrotate.d/gbase8a   # 调试模式，不实际执行
logrotate -f /etc/logrotate.d/gbase8a   # 强制立即执行
```

---

## 八、跨日志联动的排障思路

实际故障排查很少只看一个日志文件就能找到根因，通常需要在三层日志之间反复跳转，用时间戳和 ID 把散落在各处的线索串联起来。

​**集群突然变 INACTIVE**​：先看 gcware.log 确认哪个节点在何时被标记为 DOWN，以及是否有 quorum 不足的警告；然后定位到该节点，查看 gnode 的 system.log 确认节点崩溃的原因（OOM？进程 core dump？磁盘满？）；修复后确认 gcware.log 出现节点重新 joined 的记录，再检查 gcrecover.log 确认副本数据重新对齐完成。

​**SQL 报错信息不详细**​：应用层拿到的错误往往只有一个错误码，缺乏上下文。在 gcluster system.log 中用时间点 + ERROR 关键词找到对应日志行，获取 TID，然后用 TID 提取该会话从建立连接到报错的完整操作序列，可以看到报错发生前执行了哪些 SQL、使用了什么数据库和用户，快速还原现场。

​**副本同步长时间不完成**​：在 gcrecover.log 中观察目标 Segment 的 lag\_rows 变化趋势。如果 lag\_rows 停止变化超过 10 分钟，说明同步已停滞，需要检查目标 gnode 是否有 I/O 异常，或者用 `gcadmin` 确认该节点的状态是否仍然是 OPEN。

---

## 九、日志级别与生产规范

日志级别从低到高依次是 DEBUG、INFO、WARN、ERROR。生产环境标准配置是 INFO——既能记录足够的运行信息，又不会产生过多的文件 I/O。调低到 DEBUG 会记录每个 SQL 的内部执行步骤、每次内存分配的细节，文件增长速度约为 INFO 的 5～10 倍，只应在深度排查特定问题时临时开启，问题定位后立即恢复，并且务必在维护窗口内操作，避免 DEBUG 日志把磁盘写满。

建议为监控系统配置对 ERROR 日志的实时告警：用 `tail -F` 持续追踪 gcluster system.log 中的 ERROR 行，当出现新 ERROR 时通过告警通道通知值班人员。结合慢查询告警（出现 `Query slow` 且 elapsed 超过业务容忍阈值），可以构建一套几乎零成本的基础监控体系，让绝大部分严重问题在用户感知之前被内部发现。

```ini
# gcluster 的 gbase.cnf
log_level = INFO    # 生产环境标准
# log_level = DEBUG  # 排查问题时临时开启，用完立即改回
```



运维管理

GBase 8a 日志体系全解析：日志分类、格式解读与故障排查实战

GBase 8a 日志体系全解析：日志分类、格式解读与故障排查实战

评论

热门帖子