GBase 8a 运维实战：数据加载监控、审计日志与内存参数调优

一、数据加载监控

1.1 GBase 8a 的加载方式

GBase 8a 支持两种主要加载方式：

1.2 查看加载任务进度

加载任务启动后，可通过系统表实时监控进度：

-- 查看当前正在执行的加载任务
SELECT
    task_id,
    table_name,
    status,
    start_time,
    loaded_rows,
    error_rows,
    TIMESTAMPDIFF(SECOND, start_time, NOW()) AS elapsed_sec
FROM gclusterdb.load_task
WHERE status IN ('RUNNING', 'PENDING')
ORDER BY start_time DESC;

若要查看历史任务（包括已完成的）：

-- 查看最近 50 条加载历史
SELECT
    task_id,
    table_name,
    status,
    start_time,
    end_time,
    loaded_rows,
    error_rows,
    TIMESTAMPDIFF(SECOND, start_time, end_time) AS duration_sec
FROM gclusterdb.load_task
ORDER BY start_time DESC
LIMIT 50;

1.3 获取最近一次加载的 task_id

在 LOAD DATA / gload 完成后，通过以下方式获取本次任务 ID，便于核查错误数据：

-- 加载完成后立即执行
SELECT @@gbase_loader_last_task_id;

然后用 task_id 查错误明细：

SELECT *
FROM gclusterdb.load_error_log
WHERE task_id = '上面查出的task_id'
LIMIT 100;

1.4 加载错误数据收集

默认情况下，加载失败的行会被静默跳过。生产环境建议开启错误收集：

# gcluster 的 gbase.cnf 中配置
gbase_loader_logs_collect = ON

开启后，加载时遇到类型不匹配、字段超长等错误的行，会完整记录到 gclusterdb.load_error_log，方便事后排查。

1.5 加载性能相关参数

二、审计日志配置与分析

2.1 开启审计日志

GBase 8a 的审计日志通过以下参数控制，需在 gcluster 和 gnode 的配置文件中同时配置：

# gbase.cnf（gcluster 和 gnode 均需配置）
audit_log          = ON          # 开启审计
log_output         = FILE        # 输出到文件（也可设为 TABLE）
long_query_time    = 5           # 慢查询阈值（秒），超过该值才记录

如果 log_output = TABLE，审计记录写入 gclusterdb.slow_log 表，可以直接 SQL 查询，但高并发下写表的 I/O 开销较大，生产环境通常用 FILE。

2.2 输出到表时的查询方法

-- 查看最近的慢查询记录（log_output = TABLE 时有效）
SELECT
    start_time,
    user_host,
    query_time,
    lock_time,
    rows_sent,
    rows_examined,
    db,
    SUBSTR(sql_text, 1, 200) AS sql_snippet
FROM gclusterdb.slow_log
ORDER BY start_time DESC
LIMIT 50;

-- 找出平均耗时最长的 SQL 模式（去掉字面量后分组）
SELECT
    SUBSTR(sql_text, 1, 100) AS sql_pattern,
    COUNT(*)                  AS exec_count,
    AVG(query_time)           AS avg_time,
    MAX(query_time)           AS max_time,
    SUM(rows_examined)        AS total_rows_scanned
FROM gclusterdb.slow_log
WHERE start_time >= DATE_SUB(NOW(), INTERVAL 1 DAY)
GROUP BY sql_pattern
ORDER BY avg_time DESC
LIMIT 20;

2.3 节点级 SQL 执行时间监控

对于多节点的 MPP 集群，单条 SQL 在各节点的执行时间可能差异很大（数据倾斜的典型表现）。通过以下参数可以按 SQL 记录每个节点的耗时：

# gcluster 的 gbase.cnf
gcluster_dql_statistic_threshold = 3000   # 单位毫秒，超过 3 秒的 SQL 才记录

-- 查看各节点耗时分布（找出倾斜的节点）
SELECT
    sql_id,
    node_name,
    exec_time,
    rows_processed
FROM gclusterdb.dql_statistic
WHERE exec_time > 3000
ORDER BY sql_id, exec_time DESC;

如果某个节点的 exec_time 远高于其他节点，说明该节点处理的数据量偏多，大概率是数据倾斜或该节点硬件异常。

三、内存参数调优

GBase 8a 的 gnode 进程内存由多个参数共同控制，配置不合理会导致查询 OOM 报错或内存利用率低下。

3.1 内存参数层次

系统物理内存
  └─ gnode 可用内存（gbase_memory_pct_target 控制比例）
       ├─ 堆内存（gbase_heap_data + gbase_heap_large）
       │    ├─ Hash Group By 缓冲区（gbase_buffer_hgrby）
       │    ├─ 分布式 Group By 缓冲区（gbase_buffer_distgrby）
       │    ├─ Hash Join 缓冲区（gbase_buffer_hj）
       │    ├─ Sort 缓冲区（gbase_buffer_sort）
       │    └─ 结果集缓冲区（gbase_buffer_result）
       └─ 其他（元数据、连接等）

3.2 关键参数说明

3.3 内存配置示例（64GB 物理内存节点）

# gnode 的 gbase.cnf
gbase_memory_pct_target     = 75      # gnode 使用 48GB

# 堆内存
gbase_heap_data             = 16384   # 16GB，普通操作
gbase_heap_large            = 16384   # 16GB，大操作

# 操作级缓冲区（单位 MB）
gbase_buffer_hj             = 2048    # Hash Join
gbase_buffer_hgrby          = 1024    # Hash Group By
gbase_buffer_distgrby       = 1024    # Distribute Group By
gbase_buffer_sort           = 1024    # Sort
gbase_buffer_rowset         = 256     # 行集缓冲
gbase_buffer_result         = 512     # 结果集
gbase_buffer_insert         = 256     # 批量插入

3.4 监控内存实际使用

开启内存统计参数后，可以查看每个会话的内存消耗：

# gbase.cnf（gcluster + gnode）
_gbase_session_memory_stat = 1

-- 查看当前各会话的内存消耗（MB）
SELECT
    session_id,
    user,
    db,
    ROUND(memory_used / 1024 / 1024, 2) AS memory_mb,
    state,
    SUBSTR(info, 1, 100) AS sql_snippet
FROM gclusterdb.session_memory_stat
ORDER BY memory_used DESC
LIMIT 20;

3.5 内存压力下的热数据淘汰

当内存缓存中堆积了大量已完成查询的热数据，可能影响新查询的内存分配。以下参数加速热数据淘汰：

# gnode 的 gbase.cnf
_gbase_cache_drop_hot_data        = 1       # 开启主动淘汰
_gbase_cache_drop_unlock_cell_count = 1000  # 每次淘汰的 cell 数
_gbase_cache_drop_delay_time      = 100     # 淘汰间隔（毫秒）

四、连接与超时参数速查

运维中经常遇到连接超时或 SQL 卡死的问题，以下是常用超时参数汇总：

# gcluster 的 gbase.cnf

# 客户端连接超时（TCP 握手）
connect_timeout                    = 10       # 秒

# SQL 执行超时（从客户端收到 SQL 到 gcluster 返回结果）
gcluster_connect_net_read_timeout  = 3600     # 秒，读超时
gcluster_connect_net_write_timeout = 3600     # 秒，写超时

# 服务端向客户端发送数据的超时
gcluster_send_client_date_timeout  = 600      # 秒

# 节点间内部连接超时
gcluster_async_connect_timeout     = 5000     # 毫秒
gcluster_reconn_times              = 3        # 重连次数

# 并发锁等待超时
gcluster_lock_timeout              = 30       # 秒

# 空闲会话超时
Wait_timeout                       = 3600     # 秒，空闲超过此值自动断连

对于 JDBC 客户端，还需要在 JDBC URL 中配置：

jdbc:gbase://host:5258/dbname?connectTimeout=10000&socketTimeout=3600000

五、日常运维检查清单

以下是建议的每日/每周检查项：

每日检查

-- 1. 各节点存活状态
SELECT node_name, status, last_heartbeat_time
FROM gclusterdb.node_info
ORDER BY node_name;

-- 2. 昨日加载失败率
SELECT
    table_name,
    COUNT(*) AS total_tasks,
    SUM(CASE WHEN status = 'FAILED' THEN 1 ELSE 0 END) AS failed_tasks,
    SUM(error_rows) AS total_error_rows
FROM gclusterdb.load_task
WHERE DATE(start_time) = CURDATE() - INTERVAL 1 DAY
GROUP BY table_name
HAVING failed_tasks > 0 OR total_error_rows > 0;

-- 3. 当前活跃的长事务
SELECT * FROM information_schema.processlist
WHERE time > 300
ORDER BY time DESC;

每周检查

-- 4. 各节点数据量是否均衡
SELECT
    node_name,
    ROUND(SUM(data_size) / 1024 / 1024 / 1024, 2) AS data_gb
FROM gclusterdb.segment_info
GROUP BY node_name
ORDER BY data_gb DESC;

-- 5. 本周 TOP10 慢查询
SELECT
    SUBSTR(sql_text, 1, 150) AS sql,
    COUNT(*) AS cnt,
    ROUND(AVG(query_time), 2) AS avg_sec,
    MAX(query_time) AS max_sec
FROM gclusterdb.slow_log
WHERE start_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY sql
ORDER BY avg_sec DESC
LIMIT 10;

总结

GBase 8a 的系统表信息非常丰富，养成定期检查 gclusterdb 下各系统表的习惯，能在问题出现前提前发现隐患。