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 'email@example.com: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 'firstname.lastname@example.org: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 :: 18.104.22.168 CHANGE MASTER TO Syntax.