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

"Error 'Table 't1' already exists' on query" with slave_ddl_exec_mode=IDEMPOTENT


    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.12
    • Fix Version/s: 10.0.13
    • Component/s: None
    • Labels:



      I set up a simple replication topology with 3 hosts, all running MariaDB 10.0.12.

      node1 <--> node2
        \         /
         \       /
          \     /

      node1 and node2 are in active master-master with each other.

      node3 is set up in one-way multi-source from node1 and node2.

      Replication is set up using old-style binlog positions (GTIDs are not used for replication).

      I execute a CREATE TABLE statement on node1, which is replicated to node2 as expected and logged to its binary log due to log-slave-updates.

      node3 receives this CREATE TABLE event from both streams. node3 is running with gtid_ignore_duplicates=OFF, so it tries executing the CREATE TABLE event both times. I expect this.

      However, I am surprised to see this:

                     Last_SQL_Error: Error 'Table 't1' already exists' on query. Default database: 'test'. Query: 'create table t1 (id int unsigned not null auto_increment primary key, server_id int) comment='created on node1''

      If I do START ALL SLAVES on node3, the CREATE TABLE statement executes without any errors. I then see two copies of this event in the node3's binary log (node3 has log-slave-updates enabled).

      Apparently, if I execute subsequent CREATE TABLE statements on node1 or node2, they are executed twice on the slaves without any intervention.

      So, it seems that the first CREATE TABLE fails but subsequent create tables execute using slave_ddl_exec_mode=IDEMPOTENT behavior?




            • Assignee:
              monty Michael Widenius
              kolbe Kolbe Kegel (Inactive)
            • Votes:
              1 Vote for this issue
              6 Start watching this issue


              • Created: