I was surprised to find on a customer MySQL server this new syntax for Master_host in SHOW SLAVE STATUS.
mysql> SHOW SLAVE STATUSG *************************** 1. row *************************** Slave_IO_State: Connecting to master Master_Host: testdb1.xxx.com or 10.XXX.XX.XXX Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: db1-354215-bin-log.000005 Read_Master_Log_Pos: 1624 Relay_Log_File: db2-354214-relay-log.000001
Is this a fancy new Percona Server feature? No. It’s operator error.
We read a little further to find.
mysql> SHOW SLAVE STATUSG ... Slave_IO_Running: Connecting ... Last_IO_Errno: 2005 Last_IO_Error: error connecting to master 'repl@ testdb1.xxx.com or 10.XXX.XX.XXX' - retry-time: 60 retries: 86400
How can this be created.
Using MySQL MHA, you get the following message in the output of commands to manage replication.
... Thu Jan 3 17:06:40 2013 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='testdb1.xxx.com or 10.XXX.XX.XXX', MASTER_PORT=3306, MASTER_LOG_FILE='db1-354215-bin-log.000005', MASTER_LOG_POS=1624, MASTER_USER='repl', MASTER_PASSWORD='xxx'; ...
Needless to say, this syntax was taken literately, and MySQL did not complain.
I would suggest here that while MySQL does not do any validation on the value of the MASTER_HOST value in the CHANGE MASTER TO command to ensure it is resolvable it should at least do some validation to ensure the value is either a DNS entry or an IPV4,IPV6 value, that is space ‘ ‘, is not a valid character in these situations.
sbester says
There is a feature request:
http://bugs.mysql.com/bug.php?id=33144
(CHANGE MASTER does not validate host names within MASTER_HOST variable)
ronald says
Thanks Shane, you crossed that off my todo list