MySQL High Availability Framework Explained – Part II

MySQL High Availability Framework Explained – Part II

  • January 21, 2019
Table of Contents

MySQL High Availability Framework Explained – Part II

InPart I, we introduced a High Availability (HA) framework forMySQL hostingand discussed various components and their functionality. Now in Part II, we will discuss the details of MySQL semisynchronous replication and the related configuration settings that help us ensure redundancy and consistency of the data in our HA setup. Make sure to check back in for Part III where we will review various failure scenarios that could arise and the way the framework responds and recovers from these conditions.

What isMySQL Semisynchronous Replication? Simply put, in aMySQL semisynchronous replicationconfiguration, the master commits transactions to the storage engine only after receiving acknowledgement from at least one of the slaves. The slaves would provide acknowledgement only after the events are received and copied to the relay logs and also flushed to the disk.

This guarantees that for all transactions committed and returned to the client, the data exists on at least 2 nodes. The term ‘semi’ in semisynchronous (replication) is due to the fact that the master commits the transactions once the events are received and flushed to relay log, but not necessarily committed to the data files on the slave. This is in contrast to fully synchronous replication, where the transaction would have been committed on both the slave and the master before the session returns to the client.

Source: highscalability.com

Share :
comments powered by Disqus

Related Posts

Kubernetes Federation Evolution

Kubernetes Federation Evolution

Deploying applications to a kubernetes cluster is well defined and can in some cases be as simple as kubectl create -f app.yaml. The user’s story to deploy apps across multiple clusters has not been that simple. How should an app workload be distributed?

Read More