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

A group of events under single GTID can be partially skipped

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • 10.0.8
    • None

    Description

      If several statements are written into the binlog under a single GTID, in some circumstances this group can be executed only partially. After slave restart the rest of the group is skipped, so the slave ends up with inconsistent data.

      Here is the output of the test case:

      [slave]
      include/stop_slave.inc
      change master to master_use_gtid=current_pos;
      include/start_slave.inc
      show variables like 'gtid%';
      Variable_name	Value
      gtid_binlog_pos	
      gtid_current_pos	
      gtid_domain_id	0
      gtid_seq_no	0
      gtid_slave_pos	
      gtid_strict_mode	OFF
       
      [master]
      set binlog_format = row;
      # 
      # We create a table on master so that it's written into binlog as two events under one GTID...
      # 
      create table t1 as select 1 as a;
      show variables like 'gtid%';
      Variable_name	Value
      gtid_binlog_pos	0-1-1
      gtid_current_pos	0-1-1
      gtid_domain_id	0
      gtid_seq_no	0
      gtid_slave_pos	
      gtid_strict_mode	OFF
       
      [slave]
      #
      # ... replication is supposed to abort with ER_BINLOG_ROW_INJECTION_AND_STMT_MODE, and it does...
      #
      include/wait_for_slave_sql_error.inc [errno=1666]
      include/stop_slave.inc
      # 
      # ... but GTID has already advanced ...
      # 
      show variables like 'gtid%';
      Variable_name	Value
      gtid_binlog_pos	0-1-1
      gtid_current_pos	0-1-1
      gtid_domain_id	0
      gtid_seq_no	0
      gtid_slave_pos	0-1-1
      gtid_strict_mode	OFF
      # 
      # ... so when we restart the slave, it goes straight away to the next GTID...
      # 
      include/start_slave.inc
       
      [master]
      set binlog_format = statement;
      insert into t1 values (2);
      select * from t1;
      a
      1
      2
       
      [slave]
      # 
      # ... and with some luck, replication continues, thus data discrepancy is created:
      # 
      select * from t1;
      a
      2

      Test case:

      --source include/have_innodb.inc
      --source include/have_binlog_format_statement.inc
       
      --let $rpl_topology=1->2
      --source include/rpl_init.inc
       
      --echo 
      --echo [slave]
      --connection server_2
      --source include/stop_slave.inc
      change master to master_use_gtid=current_pos;
      --source include/start_slave.inc
      show variables like 'gtid%';
       
      --echo 
      --echo [master]
      --connection server_1
      set binlog_format = row;
      --echo # 
      --echo # We create a table on master so that it's written into binlog as two events under one GTID...
      --echo # 
      create table t1 as select 1 as a;
      show variables like 'gtid%';
      --save_master_pos
       
      --echo 
      --echo [slave]
      --connection server_2
      --echo #
      --echo # ... replication is supposed to abort with ER_BINLOG_ROW_INJECTION_AND_STMT_MODE, and it does...
      --echo #
      --let $slave_sql_errno = 1666
      --source include/wait_for_slave_sql_error.inc
      --source include/stop_slave.inc
       
      --echo # 
      --echo # ... but GTID has already advanced ...
      --echo # 
      show variables like 'gtid%';
       
      --echo # 
      --echo # ... so when we restart the slave, it goes straight away to the next GTID...
      --echo # 
      --source include/start_slave.inc
      --sync_with_master
       
      --echo 
      --echo [master]
      --connection server_1
      set binlog_format = statement;
      insert into t1 values (2);
      select * from t1;
      --save_master_pos
       
      --echo 
      --echo [slave]
      --connection server_2
      --sync_with_master
      --echo # 
      --echo # ... and with some luck, replication continues, thus data discrepancy is created:
      --echo # 
      select * from t1;
       
      --connection server_1
      --source include/rpl_end.inc

      cnf file:

      !include suite/rpl/rpl_1slave_base.cnf
      !include include/default_client.cnf
       
      [mysqld.1]
      log-slave-updates
       
      [mysqld.2]
      log-slave-updates

      bzr version-info

      revision-id: sanja@montyprogram.com-20130820135351-6wjeq3u31waunp7c
      revno: 3680
      branch-nick: 10.0-base

      Attachments

        Issue Links

          Activity

            People

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