When it comes to choosing your MySQL replication setup you have the choice between Asynchronous replication or Semi-Synchronous replication. At the time of writing, there is no fully-synchronous solution for MySQL replications.
The way these two differ is interesting and would be very useful when you are choosing your architecture.
In MySQL Manual for semi-synchronous replication it is said very well :
- With asynchronous replication, the master writes events to its binary log and slaves request them when they are ready. There is no guarantee that any event will ever reach any slave.
- With fully synchronous replication, when a master commits a transaction, all slaves also will have committed the transaction before the master returns to the session that performed the transaction. The drawback of this is that there might be a lot of delays to complete a transaction.
- Semisynchronous replication falls between asynchronous and fully synchronous replication. The master waits after commit only until at least one slave has received and logged the events. It does not wait for all slaves to acknowledge receipt, and it requires an only receipt, not that the events have been fully executed and committed on the slave side.
There are two types of replication methods in VM Replication
- Synchronous Replication
- Asynchronous Replication
- Semisynchronous replication
Synchronous Replication
Synchronous Replication is a process of copying source virtual machine’s data to the target over the network in an up to date manner. In Synchronous replication process, it’s writing the data in both source and target machine at the same time and making sure that there is no difference between the source and target. Comparatively the synchronous replication is more expensive than the asynchronous replication as it needs a high-speed network to transfer the data without latency.
Let us see an example of how data are synchronized between the Source and Target in Synchronous replication method
1→ Source storage gets a data write request from its host
2→ Source storage writes the data to its storage array and immediately sends the data to the Target storage.
3→ Target storage writes the data to its storage array and sends an acknowledgment to the source storage.
4→ Then the Source storage sends the acknowledgment to the Source host that the write request completed.
For synchronous replication, the order of events will be as follows:
- Site A host sends a write transaction to Site A storage array.
- Site A storage array commits the transaction to cache and immediately sends the update to the Site B storage array.
- Site B storage array sends an acknowledgment to the Site A storage array.
- Site A storage array sends an acknowledgment to the host.
With synchronous replication, both arrays process the transaction before an acknowledgment is sent to the host, meaning the arrays will always be synchronized.
Asynchronous Replication
Asynchronous replication is a process of transferring the virtual machines data in a regular time interval unlike of maintaining both the source and target exactly the same. In asynchronous replication, the source VM’s data will be copied to its replica VM in a specified time interval and not in an up to date manner. There will be some difference between the source and target in terms of its data until the configured time for replication occurs. This replication method does not need a high-speed network since its having enough time to transfer data which reduces the cost.
Let us see an example of how data are synchronized between the Source and Target in Asynchronous replication method
1→ Source storage gets a data write request from its host
2→ Source storage writes the data to its storage array and sends the acknowledgment to its host.
3→ Then the Source storage sends the update to the Target storage at the specified time.
4→ Target storage writes the data to its storage array and sends the acknowledgment to the source storage.
For asynchronous replication the order of events will be as follows:
- Site A host sends a write transaction to Site A storage array.
- Site A storage array commits the transaction to cache and sends an acknowledgment to the host.
- Site A storage array sends the update to the Site B storage array following a time delay.
- Site B storage array sends an acknowledgment to the Site A storage array.
With asynchronous replication, the secondary storage array will almost always be a few transactions behind the primary array. It should be noted that as the distance between the primary and secondary data centers increases, the acknowledgment delay caused by synchronous replication can make it inappropriate for some applications.
Semi-Synchronous Replication
Semi-Synchronous Replication comes to the rescue if you really need this type of guarantee, but it comes at a cost. You enable it on the master, then on the slave and restart the slave. Whenever the master commits a transaction, it will block until one of two things happen. It must either get an acknowledgment from at least one slave that the transaction has been applied downstream or it must reach the timeout threshold.
This type of arrangement may sound fine in theory as such blocking would often be less than a second. However, in the microscopic world of high speed, high transaction, high traffic websites, this may be an eternity and one which can slow the database down substantially. So test first before assuming it’s a solution that will help you.
So as you can see the ideal situation in terms of data consistency and no data-loss would be the fully-synchronous solution. Which on the other hand may result in a lot of delay in the performance of the system and will make the responses slower, as you are dealing with (at least) two nested levels of transactions. (Although fully-synchronous is not available)
On an Asynchronous solution, Master writes the events in the binary log and it may happen that no Slave would pick it up after Master has crashed or any other reason.
Semi-Synchronous seems to be a good and practical solution for many cases where High Availability and No Data-loss is important, but you should consider that semi-synchronous “does not provide strong guarantees against data loss“. [article]
You may ask why? It is as simple as this, imagine Master has sent out the event and one slave has received it, then Master will commit. But on the other hand, the slave could have possibly crashed or timed-out or an error happens. In this way, you have received the commit on the client, while in reality data has not been committed on the Slave. [article]
Just wanted to point out the differences and ask you to be careful when you are choosing you solution for replication. Semi-Synchronous Does NOT guarantee no data-loss.
MySQL DataBase Administration 