数据库审计日志的管理向来是个麻烦事。写得太频繁怕影响性能，集中存储又担心查询不便。GBase 8a在这件事上做了个务实的取舍——用两张表、一个定时任务，把"本地快速写入"和"全局统一查询"串了起来。
这套设计的核心是两兄弟：audit_log和audit_log_express。前者是前线哨所，每个节点各自一份，新日志先到这儿落脚；后者是中央仓库，把分散在各节点的记录汇总成一张集群级大表。一个跑在后台的import_audit_log事件，每天把前者的增量数据搬运到后者，顺便按31天的周期自动清理过期记录。
这个搬运工是系统自动配置的。集群安装或升级时，audit_log_express表和import_audit_log事件就一起创建好了，不需要DBA手动搭流水线。每天一次的调度频率是个平衡选择——既不会让本地日志积压太多，也不会给集群带来持续的I/O压力。
多虚拟集群（Multi-VC）环境要留个心眼。import_audit_log事件必须绑定到正确的VC才能工作，否则该VC的审计数据就是孤岛状态。部署后第一件事：用SHOW VCS拿到VC ID，然后在gbase库执行UPDATE gbase.event SET vc_id = 'vc00001' WHERE name = 'import_audit_log'。这步很容易漏，漏了就是审计盲区。
日常操作建议也很清晰。查历史审计优先走audit_log_express，这是完整的集群视图，不用跨节点折腾。本地audit_log想清理的话，用TRUNCATE SELF audit_log即可，只清本节点、不影响全局数据。多VC场景下，定期核对事件的vc_id绑定状态是个好习惯。
整个流程没用什么复杂技术，就是"本地写、定时搬、集中查、自动删"四步。对于需要合规审计又不想太重运维负担的场景，这种轻量 pipeline 够用了。
热门跟贴