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