why issue 'reset master' when resyncing a mysql slave

Question

Ive recently needed to perform some DB resync's and have a question regarding (what appears to be) the common practice of issuing a 'RESET MASTER' before dumping the DB on the master.

Just about all of the documentation i have found surrounding this process has a 'RESET MASTER' prior to dumping the databases from the master.

example: https://stackoverflow.com/a/3229580/1570785

In a production environment, however, this seems to be counter-productive mainly because the the 'RESET MASTER' command will clear the existing binary logs. So if something goes wrong with your master while replication is broken, you end up with an inconsistent/corrupt master and an out of sync slave.

Given that this process needs to be performed in the first place (ie something has gone wrong with mysql replication), it seems unwise to be wiping out binlogs (that could be used to recover from a COMPLETE disaster) just because the slave needs to be resynced.

What i am really asking: what am i missing - is there valid reason to perform a 'RESET MASTER' before taking a dump from the master?

Answer 1

This is not necessary. If you use mysqldump to create dump, add this options: --single-transaction - to not lock innodb tables and create consistent snapshot. --master-data - to add master's binary log position, that slave should start replicating from.