MySQL Master / Slave replication is amazingly easy to set up. But what if you do everything by the book, log into the slave, and issue the climactic SLAVE START;
command, followed by SHOW SLAVE STATUSG
, and see this error?
Last_IO_Errno: 1045 Last_IO_Error: error connecting to master 'slave_user@master.domain.int:3306' - retry-time: 60 retries: 86400
and your log file shows:
110201 22:53:26 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='master.domain.int', master_port='3306', master_log_file='', master_log_pos='4'. New state master_host='10.0.0.10', master_port='3306', master_log_file='mysql-bin.000001', master_log_pos='106'. 110201 22:53:26 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000001' at position 106, relay log '/mnt/mysql/logs/relay-bin.000001' position: 4 110201 22:53:26 [ERROR] Slave I/O: error connecting to master 'slave-user@10.0.0.10:3306' - retry-time: 60 retries: 86400, Error_code: 1045
The master isn’t rejecting your password, and there isn’t useful feedback indicating why the slave cannot connect. Note the error code 1045, which indicates a credentials problem. Double-check the length of your password; MySQL has a MASTER_PASSWORD maximum length limit of 32 characters. Shorten that puppy up and have another try. From the command line, you can issue a command such as mysql --user=slave-user --host=master -p
to verify that your credentials are valid. However, be aware that you can connect this way with a password that is too long and that will not work for replication.
And as John_A points out in the comments: “turns out you cannot use a pound sign ‘#’ when your password is in my.cnf either. A work around is to copy the password into your master.info file.”
Also, double-check that neither firewalls nor SELinux are blocking the connection; you can telnet master 3306
to verify that MySQL is listening and accepting connections on that port.
More MySQL variable restrictions at: MySQL :: MySQL 5.1 Reference Manual :: 12.5.2.1 CHANGE MASTER TO Syntax.