[MDEV-7640] CHANGE MASTER TO doesn't work with prepared statements Created: 2015-02-26  Updated: 2015-10-12  Resolved: 2015-10-12

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements, Replication
Affects Version/s: 5.5, 10.0
Fix Version/s: 5.5.47, 10.0.22

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Nirbhay Choubey (Inactive)
Resolution: Fixed Votes: 2
Labels: verified


 Description   

CHANGE MASTER TO doesn't actually change the master when using prepared statements. This is problematic for users who use orchestration frameworks that rely on prepared statements.

As an example, we can first set up a master:

MariaDB [(none)]> CHANGE MASTER TO master_host='orig_master', master_user='repl', master_password='password', master_log_file='localhost-bin.000002', master_log_pos=330;
Query OK, 0 rows affected (0.05 sec)
 
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: orig_master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: localhost-bin.000002
          Read_Master_Log_Pos: 330
               Relay_Log_File: localhost-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: localhost-bin.000002
             Slave_IO_Running: No
            Slave_SQL_Running: No
              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: 330
              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: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Then let's try to change it via a prepared statement:

MariaDB [(none)]> SET @s := "CHANGE MASTER TO master_host='new_master', master_user='repl', master_password='password', master_log_file='localhost-bin.000002', master_log_pos=330";
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [(none)]> PREPARE st FROM @s;
Query OK, 0 rows affected (0.00 sec)
Statement prepared
 
MariaDB [(none)]> EXECUTE st;
Query OK, 0 rows affected (0.04 sec)
 
MariaDB [(none)]> DEALLOCATE PREPARE st;
Query OK, 0 rows affected (0.00 sec)

We don't get any errors, so it sounds like things are OK, but the master hasn't actually been changed:

MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: orig_master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: localhost-bin.000002
          Read_Master_Log_Pos: 330
               Relay_Log_File: localhost-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: localhost-bin.000002
             Slave_IO_Running: No
            Slave_SQL_Running: No
              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: 330
              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: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

The wrong change goes into the error log as well:

150226  9:21:48 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='orig_master', master_port='3306', master_log_file='localhost-bin.000002', master_log_pos='330'. New state master_host='orig_master', master_port='3306', master_log_file='localhost-bin.000002', master_log_pos='330'.



 Comments   
Comment by Elena Stepanova [ 2015-02-26 ]

support issue

Comment by Elena Stepanova [ 2015-02-27 ]

Works okay on MariaDB 5.3 and on MySQL 5.5-5.7; but I couldn't find when it started happening in MariaDB 5.5 – the first release 5.5.20 already has this problem.

knielsen,
assigned to you for starters; if it's not a replication issue, please feel free to reassign to whoever it belongs, or back to me.

Comment by Nirbhay Choubey (Inactive) [ 2015-09-17 ]

http://lists.askmonty.org/pipermail/commits/2015-September/008408.html

Comment by Oleksandr Byelkin [ 2015-10-11 ]

OK to push with the comment redone.

Comment by Nirbhay Choubey (Inactive) [ 2015-10-12 ]

https://github.com/MariaDB/server/commit/151f967380c44d46a6d9a5fda1d19985ebf0e22c

Generated at Thu Feb 08 07:21:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.