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

Galera: with binlog-checksum=1 any ALTER TABLE statement results in Error_code: 1064 and not replicated on other nodes

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.5.28a-galera
    • 5.5.29-galera
    • None
    • Cent OS 5.x Ubuntu 12.04

    Description

      We have a setup of 3 servers in a galera cluster: db01, db02, db03.

      If we run an ALTER TABLE statement on one of the nodes then the other two nodes get an error in the log and the statement is not replicated. For example, the following queries run on db01:

      ALTER TABLE `test` ADD INDEX `started_time` (`started_time`);
      ALTER TABLE `test2` ADD COLUMN `ip` varchar(39) DEFAULT NULL;

      Resulted in the following errors on db02 (db03 errors look the same):

      130227 7:30:09 [ERROR] Slave SQL: Error 'You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1' on query. Default database: 'test'. Query: 'ALTER TABLE `test` ADD INDEX `started_time` (`started_time`)', Error_code: 1064
      130227 7:30:09 [Warning] WSREP: RBR event 1 Query apply warning: 1, 9952638
      130227 7:30:09 [Warning] WSREP: Ignoring error for TO isolated action: source: 6885794c-7ea3-11e2-0800-7f8704162adb version: 2 local: 0 state: APPLYING flags: 65 conn_id: 2863428 trx_id: -1 seqnos (l: 60187, g: 9952638, s: 9952637, d: 9952637, ts: 1361950209418672000)
      130227 7:36:10 [ERROR] Slave SQL: Error 'You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 2' on query. Default database: 'test'. Query: 'ALTER TABLE `test2` ADD COLUMN `ip` varchar(39) DEFAULT NULL', Error_code: 1064
      130227 7:36:10 [Warning] WSREP: RBR event 1 Query apply warning: 1, 9955444
      130227 7:36:10 [Warning] WSREP: Ignoring error for TO isolated action: source: 6885794c-7ea3-11e2-0800-7f8704162adb version: 2 local: 0 state: APPLYING flags: 65 conn_id: 2862856 trx_id: -1 seqnos (l: 63003, g: 9955444, s: 9955443, d: 9955443, ts: 1361950570003527000)

      No errors have been produced on the db01.

      I've submitted my.cnf for another bug (https://mariadb.atlassian.net/browse/MDEV-4136), the only change is the following addition:

      wsrep_log_conflicts=1

      Aleksey

      Attachments

        Activity

          seppo Seppo Jaakola added a comment -

          A temporary fix has been pushed, which sends a format description event before query event, the FD carries current binlog checksum setting. This fix enables checksums only for DDL statements, and binlog_checksum option should still not be used.

          seppo Seppo Jaakola added a comment - A temporary fix has been pushed, which sends a format description event before query event, the FD carries current binlog checksum setting. This fix enables checksums only for DDL statements, and binlog_checksum option should still not be used.
          seppo Seppo Jaakola added a comment - Fix pushed in: http://bazaar.launchpad.net/~maria-captains/maria/maria-5.5-galera/revision/3389

          I disagree that checksums for binlog should not be used. In a mixed setup with Galera cluster streaming data with normal replication (e.g. for delayed replication) these checksums in binlog are useful.

          aleksey.sanin Aleksey Sanin (Inactive) added a comment - I disagree that checksums for binlog should not be used. In a mixed setup with Galera cluster streaming data with normal replication (e.g. for delayed replication) these checksums in binlog are useful.
          seppo Seppo Jaakola added a comment -

          Aleksey, that's a valid use case, indeed. And binlog checksumming should not hurt with Galera replication in general. It is just that this issue was acknowledged so close to the release deadline, that there was no time for a proper fix with full binlog checksum support. The plan is to continue with this development for future releases.

          seppo Seppo Jaakola added a comment - Aleksey, that's a valid use case, indeed. And binlog checksumming should not hurt with Galera replication in general. It is just that this issue was acknowledged so close to the release deadline, that there was no time for a proper fix with full binlog checksum support. The plan is to continue with this development for future releases.

          Hi Seppo. Thanks for your reply. It is perfectly fine to have temporarily hack for the release I was just concerned that the issue was marked as "fixed" in the same time so it was not clear if there are plans to implement the "right" fix.

          aleksey.sanin Aleksey Sanin (Inactive) added a comment - Hi Seppo. Thanks for your reply. It is perfectly fine to have temporarily hack for the release I was just concerned that the issue was marked as "fixed" in the same time so it was not clear if there are plans to implement the "right" fix.

          People

            seppo Seppo Jaakola
            aleksey.sanin Aleksey Sanin (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.