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

Cannot use GTID with a second master in multi-source replication setup

Details

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

    Description

      It's quite possibly another wrong configuration on my side, but I really don't know what I might have done differently here.

      I start 3 servers, all with different server-ids and domain-ids.
      Initially I have replication from server 1 to server 3. It works all right.
      I create another slave connection on server 3, to server 2, and set it to use GTID.
      On the second slave start, it aborts with 'Error: connecting slave requested to start from GTID 1-1-1, which is not in the master's binlog'.
      Surely the second master binlog does not have GTID 1-1-1, since it has domain ID 2. And I mustn't use the same domain ID on different masters in multi-source setup, right?

      Test case:

      --let $rpl_topology= 1->3
      --source include/rpl_init.inc
       
      --connection server_1
      create table t1 (i int);
       
      --connection server_2
      create table t2 (i int);
       
      --connection server_3
       
      set default_master_connection = 'm2';
      eval change master to master_host='127.0.0.1', master_port=$SERVER_MYPORT_2, master_user='root', master_use_gtid=1;
      --source include/start_slave.inc
       
      --connection server_2
      insert into t2 values (1);
      --save_master_pos
       
      --connection server_3
      --sync_with_master 0,'m2'
       
      --source include/rpl_end.inc

      cnf file:

      !include suite/rpl/rpl_1slave_base.cnf
      !include include/default_client.cnf
       
      [mysqld.1]
      log-slave-updates
      gtid-domain-id=1
       
      [mysqld.2]
      log-slave-updates
      gtid-domain-id=2
       
      [mysqld.3]
      log-slave-updates
      gtid-domain-id=3
       
      [ENV]
      SERVER_MYPORT_3=                @mysqld.3.port
      SERVER_MYSOCK_3=                @mysqld.3.socket

      All slaves status:

      *************************** 1. row ***************************
                    Connection_name: 
                    Slave_SQL_State: Slave has read all relay log; waiting for the slave I/O thread to update it
                     Slave_IO_State: Waiting for master to send event
                        Master_Host: 127.0.0.1
                        Master_User: root
                        Master_Port: 16000
                      Connect_Retry: 1
                    Master_Log_File: master-bin.000001
                Read_Master_Log_Pos: 440
                     Relay_Log_File: mysqld-relay-bin.000002
                      Relay_Log_Pos: 728
              Relay_Master_Log_File: master-bin.000001
                   Slave_IO_Running: Yes
                  Slave_SQL_Running: Yes
                    Replicate_Do_DB: 
                Replicate_Ignore_DB: 
                 Replicate_Do_Table: 
             Replicate_Ignore_Table: 
            Replicate_Wild_Do_Table: 
        Replicate_Wild_Ignore_Table: 
                         Last_Errno: 0
                         Last_Error: 
                       Skip_Counter: 0
                Exec_Master_Log_Pos: 440
                    Relay_Log_Space: 1026
                    Until_Condition: None
                     Until_Log_File: 
                      Until_Log_Pos: 0
                 Master_SSL_Allowed: No
                 Master_SSL_CA_File: 
                 Master_SSL_CA_Path: 
                    Master_SSL_Cert: 
                  Master_SSL_Cipher: 
                     Master_SSL_Key: 
              Seconds_Behind_Master: 0
      Master_SSL_Verify_Server_Cert: No
                      Last_IO_Errno: 0
                      Last_IO_Error: 
                     Last_SQL_Errno: 0
                     Last_SQL_Error: 
        Replicate_Ignore_Server_Ids: 
                   Master_Server_Id: 1
                         Using_Gtid: 0
               Retried_transactions: 0
                 Max_relay_log_size: 1073741824
               Executed_log_entries: 9
          Slave_received_heartbeats: 0
             Slave_heartbeat_period: 60.000
                           Gtid_Pos: 1-1-1
      *************************** 2. row ***************************
                    Connection_name: m2
                    Slave_SQL_State: Slave has read all relay log; waiting for the slave I/O thread to update it
                     Slave_IO_State: 
                        Master_Host: 127.0.0.1
                        Master_User: root
                        Master_Port: 16001
                      Connect_Retry: 60
                    Master_Log_File: 
                Read_Master_Log_Pos: 0
                     Relay_Log_File: mysqld-relay-bin-m2.000001
                      Relay_Log_Pos: 4
              Relay_Master_Log_File: 
                   Slave_IO_Running: No
                  Slave_SQL_Running: Yes
                    Replicate_Do_DB: 
                Replicate_Ignore_DB: 
                 Replicate_Do_Table: 
             Replicate_Ignore_Table: 
            Replicate_Wild_Do_Table: 
        Replicate_Wild_Ignore_Table: 
                         Last_Errno: 0
                         Last_Error: 
                       Skip_Counter: 0
                Exec_Master_Log_Pos: 0
                    Relay_Log_Space: 248
                    Until_Condition: None
                     Until_Log_File: 
                      Until_Log_Pos: 0
                 Master_SSL_Allowed: No
                 Master_SSL_CA_File: 
                 Master_SSL_CA_Path: 
                    Master_SSL_Cert: 
                  Master_SSL_Cipher: 
                     Master_SSL_Key: 
              Seconds_Behind_Master: NULL
      Master_SSL_Verify_Server_Cert: No
                      Last_IO_Errno: 1236
                      Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Error: connecting slave requested to start from GTID 1-1-1, which is not in the master's binlog'
                     Last_SQL_Errno: 0
                     Last_SQL_Error: 
        Replicate_Ignore_Server_Ids: 
                   Master_Server_Id: 2
                         Using_Gtid: 1
               Retried_transactions: 0
                 Max_relay_log_size: 1073741824
               Executed_log_entries: 1
          Slave_received_heartbeats: 0
             Slave_heartbeat_period: 60.000
                           Gtid_Pos: 1-1-1
      2 rows in set (0.01 sec)

      bzr version-info

      revision-id: knielsen@knielsen-hq.org-20130503092729-gedp152b19k5wdnj
      revno: 3626
      branch-nick: 10.0-base

      Attachments

        Issue Links

          Activity

            Still fails with the new implementation (10.0-base 3635), both with master_use_gtid=current_pos and master_use_gtid=slave_pos

            elenst Elena Stepanova added a comment - Still fails with the new implementation (10.0-base 3635), both with master_use_gtid=current_pos and master_use_gtid=slave_pos

            This one seems to be pretty serious (unless I am doing something wrong here), because it affects not only explicit multi-source setups, i.e. several masters running at once, but also hidden ones.
            Lets say you have a master M which collects some kind of information. Master doesn't really care about previously collected data, it just writes it.
            And you have a slave S that you use for backup/archiving purposes.
            At some point, you want to replace master with a brand new one, NM, and to switch slave to replicate from it.
            Currently, the only non-hackish solution that I see (with GTID) is to replicate everything from S to NM, and only then to start writing to NM. But it seems a big waste, since you don't need all this gigantic archive on the master.
            Instead, a reasonable approach would be to provide NM with a new domain ID, and start replicating from it as if it's a totally independent stream – why not, if you only insert anyway. But it will be just like the multi-source scenario described above, and it doesn't work..

            elenst Elena Stepanova added a comment - This one seems to be pretty serious (unless I am doing something wrong here), because it affects not only explicit multi-source setups, i.e. several masters running at once, but also hidden ones. Lets say you have a master M which collects some kind of information. Master doesn't really care about previously collected data, it just writes it. And you have a slave S that you use for backup/archiving purposes. At some point, you want to replace master with a brand new one, NM, and to switch slave to replicate from it. Currently, the only non-hackish solution that I see (with GTID) is to replicate everything from S to NM, and only then to start writing to NM. But it seems a big waste, since you don't need all this gigantic archive on the master. Instead, a reasonable approach would be to provide NM with a new domain ID, and start replicating from it as if it's a totally independent stream – why not, if you only insert anyway. But it will be just like the multi-source scenario described above, and it doesn't work..

            I put in code deliberately to cause this error, but as the test case
            shows this was pretty stupid.

            Fixed and pushed to 10.0-base.

            knielsen Kristian Nielsen added a comment - I put in code deliberately to cause this error, but as the test case shows this was pretty stupid. Fixed and pushed to 10.0-base.

            People

              knielsen Kristian Nielsen
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.