Root Cause Analysis of MySQL Replication Error 1590 Caused by INCIDENT_EVENT During Partial Permission Changes

1 Fault Description

DMP received an alert: the slave SQL thread stopped. MySQL version 5.7.32. Running show slave status \G on the replica returned Last_Errno: 1590 and the error message "REVOKE/GRANT failed while granting/revoking privileges in databases".

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
               ...
               Last_Errno: 1590
               Last_Error: The incident LOST_EVENTS occured on the master. Message: REVOKE/GRANT failed while granting/revoking privileges in databases.
               ...

The replica error log shows:

[ERROR] Slave SQL for channel '': The incident LOST_EVENTS occured on the master. Message: REVOKE/GRANT failed while granting/revoking privileges in databases. Error_code: 1590
[ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000003' position 12531.

The corresponding binlog entry is:

# Incident: LOST_EVENTS
RELOAD DATABASE; # Shall generate syntax error

The master error log also contains the same REVOKE/GRANT failure.

2 Fault Analysis

The error indicates that during a permission‑change operation the master wrote an INCIDENT_EVENT to the binlog; the replica aborts when it encounters this event.

When does a GRANT/CREATE USER cause an INCIDENT_EVENT? When the operation processes only part of the request and fails on the remaining part.

MySQL 5.7 Issue

Using GRANT to create a user and grant privileges can fail partially. Example:

mysql> grant select,insert,file on test.* to test@'%' identified by 'Q1w2e3E$';
ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES

mysql> select user,host from mysql.user where user='test';
+------+------+
| user | host |
+------+------+
| test | %    |
+------+------+
1 row in set (0.00 sec)

Even though the FILE privilege is invalid for a database, the user is created and the valid privileges are applied, causing the master to emit an INCIDENT_EVENT .

GRANT to Two Users Simultaneously

When a single GRANT statement targets two users, one existing and one non‑existent, the statement succeeds for the existing user and fails for the missing one, again generating an INCIDENT_EVENT :

mysql> create user test@'10.186.63.5' identified by '123';
Query OK, 0 rows affected (0.00 sec)

mysql> grant all on test.* to test@'10.186.63.5', test@'10.186.63.29';
ERROR 1133 (42000): Can't find any matching row in the user table

Both cases do not match the customer's exact statements, which failed due to password‑policy violations.

Password‑Validation Plugin Interaction

When the validate_password plugin is enabled (policy MEDIUM, length 8, etc.), creating multiple users in a single CREATE USER statement can cause one user to be created while the other fails, even though both should fail according to the policy. Example:

mysql> create user test@'%' , app@'%' identified by 'Root@123';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

mysql> select user,host from mysql.user;
+-----------+------+
| user      | host |
+-----------+------+
| app       | %    |
| universe_op| %   |
| ...
+-----------+------+

Here app@'%' was created successfully while test@'%' failed.

Subsequent GRANT statements that reference the non‑existent user cause partial execution and trigger the INCIDENT_EVENT , leading to the replication error observed.

3 Summary

Partial permission changes that encounter errors cause the master to write an INCIDENT_EVENT to the binlog, which aborts the replica SQL thread.

With the password‑validation plugin enabled, a single CREATE USER that creates multiple accounts may succeed for one account and fail for another, producing the same issue.

4 Recommendations

When the password‑validation plugin is active, create users one at a time to avoid partial success.

Grant privileges individually per user to prevent partial GRANT failures that generate INCIDENT_EVENT .

Reference

[1] 云树 DMP: https://www.actionsky.com/cloudTreeDMP