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

out-of-order error with --gtid-ignore-duplicates and row-based replication

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.20
    • Fix Version/s: 10.0.21, 10.1.6
    • Component/s: Replication
    • Labels:
    • Environment:
      CentOS 7.1.1503 64bit

      Description

      I'm trying to set up multiple masters with multi-source replication slaves but i'm getting the following error even with gtid-ignore-duplicates ON:
      "An attempt was made to binlog GTID (...) which would create an out-of-order sequence number with existing GTID (...), and gtid strict mode is enabled."

      If I do just a single insert/update query, it seems to work just fine. Under any sort of load (even mysqlslap) replication stops for one of the slave connections on my slave with the error above. Here's my setup:

      A and B are masters. C is the slave.
      A is gtid domain ID 1, server ID 1.
      B is gtid domain ID 2, server ID 2.
      C doesn't have gtid domain ID configured (therefore it's the default of 0), server ID 3.

      Replication is currently as follows (all are using master_use_gtid=current_pos)
      A --> C
      B --> C
      A --> B
      The goal, once it's working, is to also have B --> A.

      The MariaDB-server package is installed from the repo:

      # MariaDB 10.0 CentOS repository list
      # http://mariadb.org/mariadb/repositories/
      [mariadb]
      name = MariaDB
      baseurl = http://yum.mariadb.org/10.0/centos7-amd64
      gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
      gpgcheck=1

      Server A config:

      [mariadb-10.0]
      innodb-strict-mode=1
      log-error=wopr-errorlog
      relay-log=wopr-relaylog
      log-basename=wopr
      server-id=1
      report-host=mn1-dbtest1
      gtid-domain-id=1
      auto_increment_increment=2
      auto_increment_offset=1
      log-bin=wopr-binlog
      log-bin-index=wopr-binlog-index
      binlog-format=ROW
      log-slave-updates=1
      slave-exec-mode=IDEMPOTENT
      gtid-ignore-duplicates=1
      gtid-strict-mode=1

      Server B config:

      [mariadb-10.0]
      innodb-strict-mode=1
      log-error=wopr-errorlog
      relay-log=wopr-relaylog
      log-basename=wopr
      server-id=2
      report-host=mn1-dbtest2
      gtid-domain-id=2
      auto_increment_increment=2
      auto_increment_offset=2
      log-bin=wopr-binlog
      log-bin-index=wopr-binlog-index
      binlog-format=ROW
      log-slave-updates=1
      slave-exec-mode=IDEMPOTENT
      gtid-ignore-duplicates=1
      gtid-strict-mode=1

      Server C config:

      [mariadb-10.0]
      innodb-strict-mode=1
      log-error=wopr-errorlog
      relay-log=wopr-relaylog
      log-basename=wopr
      server-id=3
      report-host=mn1-dbtest3
      log-bin=wopr-binlog
      log-bin-index=wopr-binlog-index
      binlog-format=ROW
      log-slave-updates=1
      slave-exec-mode=IDEMPOTENT
      gtid-ignore-duplicates=1
      gtid-strict-mode=1
      read-only=1


      Steps to reproduce:
      Set up the three servers with the configs above. Set up the slave replication from B to A, from C to A, and from C to B using master_use_gtid=current_pos for all of them.

      Do a single insert/update/create and it'll work just fine. No error.
      Now on server A do:
      mysqlslap -u root -p --auto-generate-sql

      Now Server C's slave connection to Server B will stop (Slave_SQL_Running is No) with the following error (the GTID position isn't the same every time)
      "Last_SQL_Error: An attempt was made to binlog GTID 1-1-6 which would create an out-of-order sequence number with existing GTID 1-1-6, and gtid strict mode is enabled."

      Server C's gtid_slave_pos is, however, 1-1-111 since the transactions worked through the replication with server A. If I simply do a

      {reset master;}

      on server C and then

      {start slave 'serverB';}

      then the error goes away. Doing the mysqlslap again will cause the error again as well.

      I spoke to knielsen in the #maria IRC chat about this last week and he seemed to be puzzled by the issue as well.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              knielsen Kristian Nielsen
              Reporter:
              mneth1 Matt Neth
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: