You nearly got it all correct.
On 7/26/2012 1:21 PM, Rick James wrote:
> My understanding is...
> * There is a "permanent" connection (TCP/IP socket) between the Master and each
> Slave. This is opened by the Slave when the slave starts (or restarts or recovers from a
> network glitch).
> * Master writes to binlog _and_ to that connection whenever there is a 'write'
> operation. (I do not know whether the binlog is written/flushed before or after or
> simultaneous with writing to the Slave(s).)
The slave is sent a signal that more data is available. The slave then
requests that data from the master's binary log at the 'next' position
it expects it to be. If there are additional events beyond that, it
retrieves those in sequence after it writes the current statement into
the relay logs.
> * If the connection is interrupted, the Slave will reconnect and ask the Master for
> "old" info. This comes from the binlog. Otherwise, the Master's binlog file is not part
> of the flow of data from Master to Slave.
Once the slave can reconnect, it asks for the 'next' statement in
sequence (based on the end of the last statement it has received). Any
statements beyond that already in the binary logs retrieved in sequence.
If there is no 'next' statement, it waits for a signal that more data is
If the binary log was shortened (which can occasionally happen during an
InnoDB recovery processing) the slave throws an error and waits for the
DBA to fix things.
The removal of statements and the conditions necessary to remove some
events from the end of the binary log is discussed here:
> * Semi-sync (5.5) adds some chatter from Slave to Master so that the Master can wait
> for at least one Slave to have written to its relay log.
> * Percona Cluster, Galera, etc., add more complexity to the replication traffic.
MySQL Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN