[MDEV-5799] Error messages written upon LOST EVENTS incident are corrupted Created: 2014-03-05  Updated: 2019-11-13  Resolved: 2014-06-25

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.8
Fix Version/s: 10.0.13

Type: Bug Priority: Trivial
Reporter: Elena Stepanova Assignee: Kristian Nielsen
Resolution: Fixed Votes: 0
Labels: replication-incident-event

Issue Links:
Relates
relates to MDEV-5705 replication testing: 5.6->10.0 Stalled

 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



 Comments   
Comment by Kristian Nielsen [ 2014-06-25 ]

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?

Comment by Elena Stepanova [ 2014-06-25 ]

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     |
 
+-------------------------------+--------+

Comment by Kristian Nielsen [ 2014-06-25 ]

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.

Generated at Thu Feb 08 07:07:08 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.