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: http://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?