How Audit Logs Flow from audit_log to audit_log_express in GBase 8a

GBase 8a's audit architecture relies on two key system tables: audit_log and audit_log_express. They form a "local source → centralized archive" relationship. A built‑in scheduled job automatically aggregates audit records from every node into a single cluster‑wide view, enabling both global querying and automatic data aging.

The Two Tables at a Glance

audit_log is where raw logs first land, one copy per node. audit_log_express is the consolidated warehouse for all those records.

Feature	gbase.audit_log	gclusterdb.audit_log_express
Storage	Local to each node; records only that node's events	Centralized, randomly distributed across data nodes
Content	GCluster nodes: full original SQL. GNode nodes: dispatched sub‑task fragments	Aggregated logs from all nodes, with complete context
Retention	No automatic cleanup; manual TRUNCATE required	Auto‑aged: keeps only the last 31 days by default
Primary use	Node‑level audit queries and HA data source	Cluster‑wide auditing, long‑term archival, compliance

How Data Flows Between Them

The entire flow is driven by a system‑created event called import_audit_log.

1. Automatic setup: During cluster installation or upgrade, the system creates the audit_log_express table and the import_audit_log event.
2. Daily schedule: The event runs once per day, exporting new records from gbase.audit_log on all nodes and merging them into audit_log_express.
3. Built‑in aging: audit_log_express has a lifecycle policy that automatically deletes records older than 31 days.

Multi‑VC Configuration

In a multi‑Virtual Cluster environment, you must manually bind the import_audit_log event to the correct VC. Without this step, the VC's audit logs won't be collected.

-- Find the VC ID
SHOW VCS;

-- Update the event's VC (run in the gbase database)
UPDATE gbase.event SET vc_id = 'vc00001' WHERE name = 'import_audit_log';

Operational Best Practices

• Query audit_log_express for daily audits — it's the complete, query‑friendly view without touching production nodes.
• Use TRUNCATE SELF audit_log to safely clear local logs.
• In multi‑VC setups, always verify the vc_id of import_audit_log right after deployment.

This design gives your gbase database a lightweight yet powerful audit pipeline: write locally, query globally, and age automatically. It's a solid foundation for compliance and operational visibility in any GBASE environment.