Understanding Galera Cluster: Architecture, Benefits, and Operational Considerations

1. What Is Galera Cluster

Galera Cluster is a MySQL cluster that integrates the Galera plugin, offering a multi‑master, highly redundant, high‑availability solution. The two main implementations are Percona XtraDB Cluster and MariaDB Cluster, both built on Galera’s multi‑master capabilities.

The cluster consists of three equal nodes (see Figure 1). Unlike traditional master‑slave setups, each node can act as a master, providing synchronous data replication without shared storage.

2. Why Use Galera Cluster

Traditional MySQL master‑slave replication cannot guarantee full data consistency and often requires costly workarounds that sacrifice performance. Galera Cluster solves this by eliminating the master‑slave model and delivering true multi‑master consistency.

3. How Galera Solves the Problem

3.1 Galera’s Core Mechanism

Galera wraps the wsrep (Write‑Set Replication) API, exposing status information and callbacks that enable true multi‑master operation, multi‑point writes, and synchronous replication.

Each transaction generates a write‑set that contains the modified rows and the associated binlog. Nodes compare incoming write‑sets with their local apply queue; if no conflict is detected, the transaction is committed. Conflicts cause the offending node to be removed from the cluster.

Key features include:

Multi‑master architecture: all nodes can read and write the latest data at any time.

Synchronous replication: no replication lag; data is not lost if a node fails.

Parallel apply: apply phase can run concurrently for better performance.

Failover: multi‑point writes make failover straightforward.

Hot‑plug: nodes can be added or removed with minimal service interruption.

Automatic node cloning: new nodes automatically pull missing data from online peers.

Application transparency: the cluster behaves like a single MySQL instance to client applications.

3.2 Flow Control

The fc_limit (flow‑control limit) parameter prevents slow nodes from causing unbounded replication lag. When a node’s apply queue exceeds fc_limit, it signals the cluster to throttle writes; when the queue falls below fc_limit × fc_factor, normal flow resumes.

3.3 Common Pitfalls

Operational challenges include:

Write‑set composition: Galera still uses binlog‑based replication; disabling the binlog only hides it internally.

Concurrency control: Galera enforces a global order for commits (parameter repl.commit_order) to keep binlogs identical across nodes.

DDL lock‑up: Large schema changes block the entire cluster because commits are serialized; using online schema‑change tools (e.g., pt‑online‑schema‑change) mitigates this.

“Kill‑the‑blocker” issue: During a DDL‑induced stall, attempts to kill connections may fail, requiring a node restart.

4. Suitable Scenarios

Galera Cluster excels in environments that demand strong data consistency, such as transactional systems, and where multi‑point writes enable seamless maintenance without service disruption. Performance is acceptable for most workloads, though extremely high‑throughput use‑cases may need additional scaling strategies.

5. Conclusion

Overall, Galera Cluster provides a reliable, strongly consistent MySQL solution that eliminates replication lag and simplifies DBA operations, making it a compelling choice for high‑availability database deployments.