I'm pretty sure the answer is "yes", but I'd like to be certain.
I have an environment with one MySQL master and several replication slaves. I want to add a new slave.
Last night I took one of the slaves out of the rotation, stopped replication on it, and ran mysqldump --dump-slave --include-master-host-port -u username -p databasename > slavedump.sql. This dumped the contents of the database databasename (it's the only one that's being replicated) and included the CHANGE MASTER TO statement with the slave's current binary logfile name and position.
I then re-enabled that slave and put it back into production. Then I imported the dump on the new slave and went to bed as it was late and was taking a while.
The import was successful, and I pointed the new slave at the master and started the slave. Everything worked fine and as far as I can tell, it started downloading the necessary binary logs in order to catch up. However, the output of SHOW SLAVE STATUS very quickly showed that Master_Log_File and Read_Master_Log_Pos are up-to-date with the live log, yet Seconds_Behind_Master is rather large (and dropping, but very slowly, and sometimes increasing).
I'm chalking this up to the following:
- The slave was able to download the binary logs rather quickly
- The slave is currently processing the historical binary logs from overnight, and also downloading the new ones as they're published
- The slave is just barely able to process the logs faster than they're coming in, so it's taking a while to catch up
- Given enough time, the slave will catch up and then be fine to put into production
So, my question is, are these assumptions correct? Obviously when the new slave began replicating, its binary log filename was not identical to the filename of the binary log file to which the master is currently writing. MySQL should be able to handle this and download the logs in the proper order, right?