I really like how Rolando described the sequence of operations
a replication performs. However, I think it would be more clear
if we add another component - client.
With client the sequence of operations for asynchronous replication
could be the following:
Client sends to the master the SQL query (for example, insert)
using transactions
Master executes the transaction. In case of success the record
is stored on the disk, but the transaction is not committed yet.
Master records the insertion event in the master binary log
If the master could not store it in the binary log, the
transaction rolled back.
Client receives response from the master (success or rollback).
In case of transaction success, the dump thread on the master
reads the event from the binary log and send it to the slave
I/O thread.
Slave I/O thread receives the event and writes it to the end of
the relay log file.
Once the event got into relay log, the slave SQL thread executes
the event to apply the changes to the database on the slave.
In this scenario master does not care about the slave and client
only knows that something is wrong on the slave by manually executing
"SHOW SLAVE STATUS" command.
n case of a semi-synchronous replication the sequence of operations could
be the following:
Client sends to the master the SQL query (for example, insert)
using transactions.
Master executes the transaction. In case of success the record
is stored on the disk, but the transaction is not committed.
Master records the insertion event in the master binary log
If the master could not store it in the binary log, the
transaction rolled back and client receives the response only
in the case of rollback.
Due to the success of the transaction on the master, the dump
thread on the master reads the event from the binary log and
send it to the slave I/O thread.
Slave I/O thread receives the event and writes it to the end of
the relay log file.
Slave Acknowledges Master of the recording the event in the relay
log file.
Master commits the insertion transaction.
Client receives the response from the master (success).
Once the event got into relay log, the slave SQL thread executes
the event. Master and client don't know whether the execution
was successful or not.
The semi-synchronous replication solved one very important case
when slave or network died and master continued to proceed and
when slave recovered it did not know the position to start to
catch up. Now, if the master did not received the slave's
confirmation it does not go ahead until waiting period finishes.
If waiting period is infinite, master binary log position always
will be in sync with the slave relay log position assuming that
all queries on the slave were successful. How realistic this
assumption?
I think it is very realistic. One of the most common case of the
slave query failure is "duplicate record". Where the duplicate record
came to the slave if master did not have it? It came from wrong position
given to the slave to start to replicate. The starting replication
position included the record that was already replicated. In case of
semi-synchronous replication this situation will not happened.
Jacob Nikom
