Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.
For a variety of reasons, MySQL replication is not very resilient to crashes, power outages, and corruption caused by disk, memory, or network errors. You’ll almost certainly have to restart replication at some point due to one of these problems.
Most of the problems you’ll have with replication after an unexpected shutdown stem from one of the servers not flushing something to disk. Here are the issues you might encounter in the event of an unexpected shutdown:
If the master isn’t configured with sync_binlog, it might not have flushed
its last several binary log events to disk before crashing. The
replication I/O thread may, therefore, have been in the middle of
reading from an event that never made it to disk. When the master
restarts, the replica will reconnect and try to read that event
again, but the master will respond by telling it that there’s no
such binlog offset. The binlog dump process is typically almost
instantaneous, so this is not uncommon.