Description:
We encountered an issue where existing users on one replica suddenly lost several privileges and default roles, even though the corresponding user accounts still exist.
This occurred without any intentional privilege modifications in our environment.
Environment:
Master: MySQL 8.0.40 (AWS RDS)
Replicas: MySQL 8.0.35 (EC2)
Multi-source replication setup (two replication sources)
One source uses:
replicate-ignore-table=<list_of_tables>
Some tables on replica are created using the BLACKHOLE engine
slave_skip_errors = ALL is enabled due to application requirements
Issue Details:
On 19th around 08:00 AM, several users on a specific replica lost privileges, including:
database-level privileges
table-level privileges
role inheritance information
default role mappings
These correspond to missing or modified rows in:
mysql.db
mysql.tables_priv
mysql.role_edges
mysql.default_roles
The user accounts themselves remained present in mysql.user.
Other replicas with similar replication configuration did not show this issue.
Recent Activity Prior to the Issue:
New roles were created on the master the previous night.
On the affected replica, the same roles were manually created early morning (~06:45 AM) because they were not present automatically.
The privilege loss began roughly at 08:00 AM.
Suspected Area:
Privilege-related statements such as:
CREATE ROLE
GRANT
SET DEFAULT ROLE
ALTER USER
do not carry a database context in the binlog.
When replication filtering rules such as:
replicate-ignore-table
replicate-wild-ignore-table
are used, these global-privilege events may be unexpectedly skipped, partially applied, or mis-evaluated by the filter rules because the events have:
db = ''
table = ''
Additionally, version differences (8.0.40 master → 8.0.35 replica) may impact privilege replication behavior.
What We Request MySQL Support to Confirm / Investigate:
Whether privilege-related DDL (GRANT, CREATE ROLE, SET DEFAULT ROLE, ALTER USER) can be unintentionally skipped when replicate-* filters are present, because they lack a specific database context.
Whether MySQL version mismatch between master and replica can lead to partial updates or loss of privilege metadata.
Whether MySQL has known bugs where privilege metadata (mysql.* tables) becomes inconsistent across replicas without producing explicit replication errors.
Why only one replica experienced privilege loss, despite identical configuration across replicas.
Impact:
Production users began receiving permission-denied errors because underlying privilege metadata disappeared.
Privileges had to be recreated manually to restore normal functionality
How to repeat:
We are unable to reproduce the same.
© 2025, Oracle Corporation and/or its affiliates