Issue with audit_log_filter component on Replica Nodes in 3-Node MySQL InnoDB Cluster (Percona MySQL 8.4.7)

MySQL & MariaDB
,
1

Hi Percona Support Team,

I am testing the audit_log_filter component of Percona MySQL 8.4.7 on a 3-node MySQL InnoDB Cluster (Group Replication) setup and have observed inconsistent behavior between the primary and replica nodes.

Environment

  • Database Version: MySQL CE 8.4.7

  • Topology: 3-node MySQL InnoDB Cluster (Group Replication)

  • Audit Log Filter Component: audit_log_filter component from Percona MySQL 8.4.7

Configuration

The audit filter rule is created and assigned as follows:

 MySQL  localhost:3306 ssl  SQL > SELECT * FROM mysql.audit_log_filter;
+-----------+---------+---------------------------------------------------------------------------------------------------------------------------------+
| filter_id | name    | filter                                                                                                                          |
+-----------+---------+---------------------------------------------------------------------------------------------------------------------------------+
|         1 | log_ddl | {"filter": {"rule": {"log": true, "event_class": "query", "command_class": ["create", "alter", "drop", "truncate", "rename"]}}} |
+-----------+---------+---------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.0005 sec)

  MySQL  localhost:3306 ssl  SQL > SELECT * FROM mysql.audit_log_user;
+----------+----------+------------+
| username | userhost | filtername |
+----------+----------+------------+
| %        | %        | log_ddl    |
+----------+----------+------------+
1 row in set (0.0006 sec)

 MySQL  localhost:3306 ssl  SQL > select audit_log_session_filter_id();
+-------------------------------+
| audit_log_session_filter_id() |
+-------------------------------+
|                             1 |
+-------------------------------+

Observed Behavior

  • On the primary node, DDL operations are correctly captured in the audit log.

  • On the replica nodes, no audit entries are generated even though:

    • The component is installed

    • The filter rules exist

    • The filter is assigned to the user (%)

    • The mysql.audit_log_filter and mysql.audit_log_user tables are replicated.

Additional Observation

When attempting to reload the filters on the replica:

SELECT audit_log_filter_flush();

The following error is returned:

ERROR: Could not reinitialize audit log filters

Expected Behavior

Since the filter metadata tables are replicated across the cluster, the audit plugin on replica nodes should load the filters and log the relevant events locally.

Actual Behavior

Replica nodes do not generate audit logs despite having the filter configuration present.

2

I have filed a new bug report (Jira) on this. However, I am unable to edit the description of this jira so i have posted the details in the comment section.

3

Hi,

The installation script includes INSTALL COMPONENT 'file://component_audit_log_filter'; and this won’t be transferred like any other component installation or config changes either. How did you perform the installation for other nodes?

Also, you mentioned the database version is MySQL CE 8.4.7, which is an enterprise feature in upstream MySQL.

4

Hello Yunus,

For the replica nodes, we temporarily disabled read_only and then executed the component installation manually using:

INSTALL COMPONENT ‘file://component_audit_log_filter’;

After the installation completed, we re-enabled read_only on the replica nodes.

However, we are observing that the issue still occurs specifically on replica servers running the Percona MySQL 8.4.7 distribution. The same behavior is described in the ticket comment we referenced earlier.