Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Trivial
-
Resolution: Fixed
-
Affects Version/s: 10.0.8
-
Fix Version/s: 10.0.13
-
Component/s: None
-
Labels:None
Description
MySQL now uses LOST EVENTS incidents when s GRANT/REVOKE statement partially fails:
http://bugs.mysql.com/bug.php?id=68892
http://www.dbasquare.com/2013/04/09/granting-privileges-may-break-replication-in-mysql-5-6-10/
Replication is supposed to abort, and the discrepancy to be treated manually.
This works with 10.0 as a slave, but the error message which 10.0 writes into the error log and shows in SLAVE STATUS upon this incident is corrupted:
Last_Error: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log�y�K Slave SQL: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log<E9>y<CD>K, Internal MariaDB error code: 1590
MySQL writes a clean message:
Last_SQL_Error: TThe incident LOST_EVENTS occured on the master. Message: error writing to the binary log Slave SQL: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log, Error_code: 1590
To reproduce:
# Set up replication MySQL 5.6 => MariaDB 10.0 # Execute on 5.6 master: grant all on db.* to user1, user2; revoke all on db.* from user1, user1; # An error will occur (expected): # ERROR 1141 (42000): There is no such grant defined for user 'user1' on host '%' # On 10.0 slave, wait till replication aborts (expected), see the error message
revision-id: monty@askmonty.org-20140304183748-2wo25348vicg2qgp revno: 4028 branch-nick: 10.0
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-5705 replication testing: 5.6->10.0
-
- Stalled
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I'm running with all defaults on master and slave, which are:
MySQL [test]> select @@version;
+------------------+
| @@version |
+------------------+
| 5.6.19-debug-log |
+------------------+
MySQL [test]> show variables like '%checksum%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| binlog_checksum | CRC32 |
| innodb_checksum_algorithm | innodb |
| innodb_checksums | ON |
| master_verify_checksum | OFF |
| slave_sql_verify_checksum | ON |
+---------------------------+--------+
MariaDB [test]> select @@version;
+---------------------------+
| @@version |
+---------------------------+
| 10.0.12-MariaDB-debug-log |
+---------------------------+
MariaDB [test]> show variables like '%checksum%';
+-------------------------------+--------+
| Variable_name | Value |
+-------------------------------+--------+
| aria_page_checksum | ON |
| binlog_checksum | NONE |
| innodb_checksum_algorithm | innodb |
| innodb_checksums | ON |
| innodb_log_checksum_algorithm | innodb |
| master_verify_checksum | OFF |
| slave_sql_verify_checksum | ON |
+-------------------------------+--------+
This is also reproducible on pure MariaDB, when checksums are enabled on the
master (checksums seem to be enabled by default on the master in MySQL 5.6).
I backported the patch for Bug#59123, and also added a test case.
Looks like this may be this bug: http://bugs.mysql.com/bug.php?id=59123
Elena, did you run with checksums enabled when you reproduced this?