Galera Cluster

By Pradipti Simkhada
Introduction to Database Clustering
Definition of database clustering
● Database clustering involves using multiple computers to store the same information, ensuring data
redundancy and fault tolerance.
Importance of high availability and scalability
● High availability ensures continuous access to data, minimizing downtime and maintaining business
continuity.
● Scalability enables databases to handle increasing workloads and user demands effectively.
Introduction to Galera Cluster as a database clustering technology
● Galera Cluster is a synchronous multimaster replication plugin for InnoDB, developed by Codership.
● It offers a mastermaster topology where all nodes have equal standing, allowing both read and write
operations.
● Galera utilizes synchronous replication, ensuring immediate data transfer and mutual agreement among all
nodes before committing transactions.
● This technology addresses issues such as write conflicts, replication lag, and data inconsistency, providing
a robust solution for database clustering.

2
Setting up the Galera Cluster
Infrastructure Requirements for Setting Up a Galera Cluster
● Nodes and Virtual Machines
○ Each computer participating in the cluster represents a node.
○ Setting up a Galera Cluster typically involves having multiple nodes, ideally one per computer.
○ Utilizing virtual machines (VMs) for each node offers flexibility and scalability in managing the
cluster.
● Explanation of Nodes and Virtual Machines
○ Nodes are individual servers or instances that collectively form the Galera Cluster.
○ Virtual machines emulate physical computers and allow for the creation of multiple isolated
environments on a single physical server.
○ Each node is hosted on a separate virtual machine, ensuring independent operation and resource
allocation.
● Importance of Linux for Communication Between Nodes
○ Linux operating system is commonly used for hosting Galera Cluster nodes due to its robust
networking capabilities and compatibility with cluster control software.
○ Linuxbased virtual machines facilitate seamless communication between nodes through protocols
like SSH.

3
Components of Galera Cluster
● Database Management System (DBMS):
Galera Cluster relies on a supported DBMS such as MySQL Server, Percona Server for MySQL, or MariaDB
Server. These database servers run on individual nodes within the cluster.
● wsrep API:
The WriteSet Replication (wsrep) API is the interface responsible for integration between the database server
and the replication provider in Galera Cluster. It facilitates the writeset replication functionality.
● Galera Plugin:
The Galera Plugin enables the writeset replication service functionality within the DBMS. It acts as the wsrep
provider, communicating with the wsrep API to replicate transactions (writesets) across the cluster.
● Group Communication Plugins:
Galera Cluster utilizes various group communication systems to facilitate communication and coordination
among cluster nodes. These plugins ensure that all nodes remain synchronized and maintain consensus on the
state of the cluster.

4
Integration with Database Servers and Replication Providers

● Galera Cluster seamlessly integrates with

supported database servers by incorporating
the wsrep API patch into their codebase. This
patch enables the Galera Plugin to
communicate with the wsrep API, facilitating
writeset replication.

● Through the wsrep API, transactions

executed on one node are replicated
synchronously to all other nodes in the
cluster. This integration ensures that all nodes
maintain identical copies of the database,
providing high availability and data
consistency.

5
Write Set Replication Functionality
➢ Writeset replication is the core mechanism used by Galera Cluster to replicate
transactions across the cluster.
➢ When a transaction is committed on one node, all changes made by the transaction and
the primary keys of the changed rows are collected into a writeset.
➢ This writeset is then replicated to all other nodes in the cluster using the group
communication plugins.
➢ Each node receives the writeset and applies the changes locally, ensuring that all nodes
have an identical copy of the database.
➢ The certification based replication process ensures that transactions are replicated in a
globally ordered manner, maintaining data consistency across the cluster.

6
Certification Based Replication

Certification based replication is a method used in Galera Cluster to achieve synchronous replication
with reduced overhead. It relies on group communication and transaction ordering techniques to
ensure global consistency across all nodes in the cluster.

➢ Prerequisites for Certification Based Replication

○ The database must be transactional, capable of rolling back uncommitted changes.
○ Each replication event must change the database atomically.
○ Replicated events must be globally ordered and applied on all instances in the same order
to maintain consistency.

7
Certification Based Replication Process

➢ Optimistic Execution
○ Transactions execute conventionally until the commit point, assuming no conflicts.
○ At the commit command, changes made by the transaction and the primary keys of
modified rows are collected into a writeset.
➢ Certification Test
○ Before actual commit, the writeset undergoes a deterministic certification test on
each node.
○ The certification test checks for conflicts with other transactions based on the global
ordering of transactions.
○ If conflicts are detected, the writeset is dropped, and the transaction is rolled back.

8
Certification Based Replication Process

➢ Transaction Commitment
○ If the certification test succeeds on all nodes, the transaction is committed.
○ The committed transaction and its writeset are applied to all nodes, ensuring global
consistency.
○ Each node reaches the same decision about the transaction's outcome, maintaining
uniformity across the cluster.

9
Failure Handling with Galera Cluster

● Failure in a database cluster can lead to downtime and data inconsistency.

● Failures can occur due to software bugs or hardware problems, necessitating automatic

responses to minimize downtime.

● Automatic and efficient failure handling is crucial for maintaining cluster stability and

ensuring continuous availability of the database services.

● When a node fails, Galera Cluster continues to operate using the remaining nodes,

ensuring uninterrupted service availability.

10
Failure Handling Mechanisms
➢ State Snapshot Transfer (SST)
○ In case of a new node joining or a failed node rejoining the cluster, SST is used to synchronize its state
with the rest of the cluster.
○ SST involves transferring a full snapshot of the database from an existing node (donor) to the
joining/failed node.
○ This ensures that the joining/failed node has an up-to-date copy of the database, allowing it to resume its
role in the cluster.
➢ Incremental State Transfer (IST)
○ IST is a more efficient mechanism used when a node needs to catch up with the cluster after a temporary
disconnect or a shorter downtime.
○ Instead of transferring the entire database snapshot, IST only sends the incremental changes (write sets)
that occurred during the node's downtime.
○ This reduces the time and resources required for synchronization, allowing the node to quickly rejoin the
cluster and resume normal operations.

11
Split Brain Condition
➢ Split brain is a condition in which a database cluster becomes divided into two or more
parts, each willing to accept writes independently.
➢ Data drift can lead to serious problems such as application errors, incorrect query results,
and corrupted data.

12
Split Brain Condition
● By design galera cluster tries to avoid split brain by employing the quorum algorithm

Why odd number of nodes ?

● Consider 2 nodes working in a cluster, one of the node(half) couldn’t process some
transaction
● Galera tries to pick out the primary component by voting
● If even number of nodes, votes from each segment gets equal, so error picking primary
component

13
Methods to prevent Split Brain
➢ Quorum Mechanism:
○ Galera Cluster incorporates a built-in "circuit breaker" mechanism to prevent split brain scenarios.
This mechanism relies on achieving a quorum, ensuring that a majority of nodes are available in
the cluster for normal operation.
○ If a majority (50% + 1) of the nodes are operational, Galera continues to operate normally.
○ If a majority cannot be reached due to node failures or network issues, Galera switches to a "non-
Primary" state, ceasing to serve traffic until the majority is restored.

14
Handling Split Brain Condition
➢ Identifying Master Nodes:
○ In the event of a split brain, it's crucial to identify which nodes continue to serve as master
nodes.
○ These master nodes will dictate the dataset to which data from other nodes will be
merged.
➢ Merging Datasets:
○ Data from the old master node, which is missing on the current master, needs to be
identified.
○ This process involves manual identification of missing data, potentially leveraging
timestamps or binary logs.
○ Once identified, the missing data must be loaded into the new master node.
○ Care must be taken to avoid primary key conflicts during data insertion.
○ Depending on the setup, adjustments to primary key values may be necessary to ensure
smooth data integration.

15