Read the MySQL manual to understand what semi-sync does. It is not synchronous replication. With semi-sync each connection to a master can lose at most one transaction when the master crashes. This reduces but does not eliminate the problem of transaction loss on a master crash. Semi-sync also limits a busy connection so that it cannot commit faster than a slave can receive its transactions.
Additional references for this include:
- notes from the MySQL forge page
- design docs from the Google patch
Posts
Hi
ReplyDeleteThanks for the nice resources about semi-sync.
I have a doubt regarding your claim that "With semi-sync each connection to a master can lose at most one transaction when the master crashes"
MySQL manual says that "a thread that performs a transaction commit on the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has received all events for the transaction, or until a timeout occurs. "
This doesn't seem to support your claim.
Consider an example with a maseter and three slaves (S1,S2,S3)
Now suppose there are three transactions.
After commiting transaction (T1) on master the thread blocks until one of the slave receives the events for T1. Assume slave S1 does this.
Similarly for T2(S2 receives the events for T2) and T3 (S3 receives the events for T3).
Now suppose the master crashes. Each slave can potentially lose more than one transaction (two transactions in our example, S1 loses T2 and T3).
Can you please tell me where I got the concept of semi-sync wrong.
Transactions are serialized in the binlog. For you example assume the order is T1, T2, T3. For a slave to receive T3 it must have received T1 and T2.
ReplyDelete