审计日志audit_log和audit_log_express这两个系统表的关系是什么？数据是如何从前者流转到后者的？

audit_log 和 audit_log_express 是 GBase 8a 审计日志高可用架构中的两个核心系统表，它们之间是“源表”与“集中化归档表”的关系。数据通过一个自动化的定时任务事件，从分布在各节点的 audit_log 流转到中心的 audit_log_express。

一、两个系统表的核心关系与区别

| 特性 | gbase.audit_log | gclusterdb.audit_log_express |
| :--- | :--- | :--- | :--- |
| 所属数据库 | gbase 系统库

| gclusterdb 系统库
| 存储引擎 | GsSYS引擎（系统表引擎）

| EXPRESS引擎随机分布表
| 存储位置 | 每个节点（GCluster和GNode）本地都有一份，只记录本节点相关的审计日志

| 集中存储，通过EXPRESS引擎随机分布在整个集群的数据节点上，可看到所有节点上发生的日志
| 记录内容 | • GCluster节点：记录完整的原始SQL语句。
• GNode节点：记录经分发后的子任务SQL片段。

| 所有节点审计日志的汇总，包含完整的上下文信息。 |
| 数据保留 | 本地存储，无自动老化机制，需手动清理（TRUNCATE SELF audit_log）。

| 自动老化，默认仅保存31天内的数据，超过31天的记录自动删除。 |
| 主要用途 | 节点级本地审计查询和审计日志高可用数据源。

| 集群级全局审计查询、长期归档和合规性检查。 |

1. “审计日志 audit_log 每个节点上都有，但协调节点上的 audit_log 记录了完整的原始SQL语句，而数据节点上的 audit_log 记录了经分发后的子任务SQL片段。”

    

2. “gclusterdb下的audit_log_express可看到所有节点上发生的日志。”

    

3. “audit_log_express 仅保存31天内的数据，自动删除31天以前记录的内容。”

    

二、数据从 audit_log 流转到 audit_log_express 的机制

数据流转的核心是一个由系统自动创建并调度的定时任务事件 import_audit_log。

流转流程详解

具体步骤：

1. 事件创建：在集群安装或升级时，系统会自动在 gclusterdb 库下创建 EXPRESS 引擎表 audit_log_express，并自动创建一个定时导出事件 import_audit_log。

    

2. 事件调度：该事件被配置为每天自动执行一次（类似 cron 任务），其任务逻辑是：将 gbase 库中的 audit_log 表内容，导出到 gclusterdb 库中的 audit_log_express 表中。

    

3. 数据同步：事件执行时，会收集所有节点上 gbase.audit_log 表中的新日志记录，汇总后插入到中心的 audit_log_express 表中。

    

4. 自动老化：audit_log_express 表具有内置的数据生命周期管理功能，仅保留31天内的数据，更早的数据会被自动清理。

    

“集群安装或升级时自动在gclusterdb库下创建EXPRESS引擎随机分布表audit_log_express，并自动创建定时导出事件import_audit_log，将gbase库中的audit_log表内容定时导出到gclusterdb库中的audit_log_express表中。”

三、关键配置与注意事项（尤其对于多VC环境）

在多虚拟集群（VC） 版本中，必须进行手动配置，否则审计日志高可用功能不会生效。

配置步骤：

1. 查看VC ID：

    

   SHOW VCS;

   记下目标VC的 vc_id（如 vc00001）。

    

2. 更新事件所属VC：import_audit_log 事件默认可能属于根VC或其他VC，需要将其更新到正确的VC ID。

    

   USE gbase;
   UPDATE event SET vc_id = 'vc00001' WHERE name = 'import_audit_log';

3. 验证：更新后，确保事件在正确的VC下运行，才能正确收集该VC内所有节点的审计日志。

“在多VC版本下，审计日志高可用需手动update gbase.event系统表中import_audit_log event的vc id字段，审计日志高可用才会起效。”

四、总结与运维建议

• 关系本质：audit_log 是原始数据源，audit_log_express 是集中化、可老化的归档副本。两者共同构成了审计日志的高可用和生命周期管理体系。
• 运维重点：
  1. 日常查询应使用 gclusterdb.audit_log_express，因为它数据全、查询方便且不影响生产表。

  2. 清理日志时，如需清空 gbase.audit_log，必须使用 TRUNCATE SELF audit_log 语句。

      

  3. 在多VC环境部署后，务必检查并配置 import_audit_log 事件的 vc_id。

      

  4. 保留周期可根据合规要求调整（需通过修改事件逻辑或表管理策略实现，文档中31天为默认值）。

通过这种设计，GBase 8a 既满足了审计日志的实时记录需求，又通过自动化的汇总和老化机制，解决了日志分散存储、查询不便和存储空间无限增长的问题，实现了审计日志的有效管理。