Details
-
Type:
Bug
-
Status: In Review
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 10.0, 5.5
-
Fix Version/s: 10.0
-
Component/s: Prepared Statements, Replication
-
Labels:
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'.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.
Kristian Nielsen,
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.
support issue