Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-5799

Error messages written upon LOST EVENTS incident are corrupted

Details

    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

      Attachments

        Issue Links

          Activity

            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?

            knielsen Kristian Nielsen added a comment - 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?

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

            elenst Elena Stepanova added a comment - 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.

            knielsen Kristian Nielsen added a comment - 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.

            People

              knielsen Kristian Nielsen
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.