Percona audit_log_filter component does not work on the slave server 8.4

MySQL & MariaDB Percona Server for MySQL 8.0
1

I’m testing the new percona audit_log_filter component and found a strange behavior when using it on the replica server.
The component is installed, filter rules exist, and the user is added.
On the master, I can see the query log, but on the replica, the log is empty.
I can’t figure out if this is normal audit_log_filter behavior, if I’m making a mistake somewhere, or if I should file a bug report.

Here’s what I did:

  • Installed 8.4.5-5 Percona Server (GPL), Release 5, Revision 3d3abca6 on both master and slave. Host OS is AlmaLinux release 8.10 (Cerulean Leopard).
  • Installed the plugin on both master and replica using:
    mysql < /usr/share/mysql/audit_log_filter_linux_install.sql
  • Configured replication and set the replica server to read-only mode.
  • Set up the filter on the master:
    SELECT audit_log_filter_set_filter(
'log_dml_ddl',
'{
 "filter": {
   "class": [
     {
       "name": "query",
       "event": {
         "name": ["start"]
       }
     },
     {
       "name": "connection",
       "event": {
         "name": ["connect", "disconnect"]
       }
     }
   ]
 }
}');
  • Added myself as a user:
    SELECT audit_log_filter_set_user('dba@%','log_dml_ddl');

Checked the configuration on both master and replica:

  SELECT audit_log_filter_set_user('dba@%','log_dml_ddl');

Checked that the filter is enabled on both master and replica:

select @@audit_log_filter.disable;
+----------------------------+
| @@audit_log_filter.disable |
+----------------------------+
|                          0 |
+----------------------------+
1 row in set (0.08 sec)

Then, I ran this on the master:

select audit_log_session_filter_id();
+-------------------------------+
| audit_log_session_filter_id() |
+-------------------------------+
|                             1 |
+-------------------------------+
1 row in set (0.09 sec)

This shows that the filter with filter_id=1 is active for my user.

On the replica, the same query returns:

select audit_log_session_filter_id();
+-------------------------------+
| audit_log_session_filter_id() |
+-------------------------------+
|                             0 |
+-------------------------------+
1 row in set (0.09 sec)

This indicates that no filters are active for my user on the replica.

The only way to make audit_log_filter work on the replica is:

  • Disable read-only mode: SET GLOBAL read_only=OFF;
  • Reload the filter:SELECT audit_log_filter_flush();
  • Enable read-only mode again:SET GLOBAL read_only=ON;

When the replica is in read-only mode, adding a filter or user leads to this error:

SELECT audit_log_filter_set_user('dba@%','log_dml_ddl');
+-------------------------------------------------------+
| audit_log_filter_set_user('dba@%','log_dml_ddl')      |
+-------------------------------------------------------+
| ERROR: Failed to check filtering rule name existence  |
+-------------------------------------------------------+
1 row in set (0.09 sec)

Attempting to reload the component shows another error:

SELECT audit_log_filter_flush();
+-------------------------------------------------+
| audit_log_filter_flush()                        |
+-------------------------------------------------+
| ERROR: Could not reinitialize audit log filters |
+-------------------------------------------------+
1 row in set (0.09 sec)
2

Hello @Mastervi,

Firstly, the term ‘slave’ is no longer used. You may have noticed in MySQL 8.4 that all references to ‘slave’ have been removed, and replaced with ‘replica’. Secondly, to answer your post question, I believe what you are experiencing on the replica is correct behavior. The audit plugin audits user-level actions within the database. The replication threads (SQL, and IO) are not user-level threads.

3

Hello @matthewb
I wasn’t talking about replication threads. I’m connecting to the master via the MySQL client from the console, running: select 'master2';
And I can see this query in the log:

# tail -f audit_filter.log  
</AUDIT_RECORD>
<AUDIT_RECORD>
<NAME>Query Start</NAME>
<RECORD_ID>2_2025-08-22T10:33:15</RECORD_ID>
<TIMESTAMP>2025-08-22T10:33:15</TIMESTAMP>
<STATUS>0</STATUS>
<CONNECTION_ID>15196</CONNECTION_ID>
<COMMAND_CLASS>select</COMMAND_CLASS>
<SQLTEXT>select 'master2'</SQLTEXT>
</AUDIT_RECORD>

When I connect to the replica via the MySQL client from the console and run: select 'replica2';
the log on replica remains empty.

cat audit_filter.log
<?xml version="1.0" encoding="utf-8"?>
<AUDIT>
<AUDIT_RECORD>
<NAME>Audit</NAME>
<RECORD_ID>0_2025-08-22T12:14:07</RECORD_ID>
<TIMESTAMP>2025-08-22T12:14:07</TIMESTAMP>
<COMMAND_CLASS>Audit</COMMAND_CLASS>
<SERVER_ID>2</SERVER_ID>
</AUDIT_RECORD>