[MDEV-4485] Cannot use GTID with a second master in multi-source replication setup Created: 2013-05-05  Updated: 2013-08-16  Resolved: 2013-05-29

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.2
Fix Version/s: 10.0.3

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Kristian Nielsen
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-26 Global transaction ID Closed

 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



 Comments   
Comment by Elena Stepanova [ 2013-05-27 ]

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

Comment by Elena Stepanova [ 2013-05-29 ]

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..

Comment by Kristian Nielsen [ 2013-05-29 ]

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.

Generated at Thu Feb 08 06:56:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.