MySQL Group Replication High Availability Architecture

This article explores the underlying architecture of MySQL Group Replication (MGR), a native high-availability solution designed for MySQL databases. It examines how MGR utilizes a shared-nothing, replicated state machine model, relies on the Paxos consensus protocol for message ordering, performs optimistic conflict detection through transaction certification, and manages dynamic cluster membership to guarantee fault tolerance and data consistency.

Replicated State Machine Model

MySQL Group Replication is built on a replicated state machine architecture. In this model, every database server (node) in the replication group represents an independent state machine. Each node contains a complete copy of the database and executes the same sequence of transactions in the same order.

To maintain identical state across all nodes, the system processes transactions through a database state machine replication flow: 1. Local Execution: A client issues a transaction to a local node. The node executes the transaction locally up to the commit phase, generating a “write set” containing the identifiers of the modified rows and their primary keys. 2. Global Ordering: Before committing, the local node broadcasts the write set and transaction metadata to the group. 3. Certification: All nodes receive the transaction in the exact same sequence and run a deterministic conflict detection algorithm. 4. Apply/Rollback: If the transaction passes certification, all nodes commit it. If it fails, the transaction is rolled back on the originating node and discarded by the others.

Group Communication System (GCS) and Paxos Consensus

The foundation of MGR’s consistency is the Group Communication System (GCS) protocol, which is implemented via an engineered Paxos consensus algorithm (XCom). The GCS provides two critical guarantees: * Total Order: All messages (transactions) are delivered to all group members in the exact same sequence. * Safe Delivery: A message is only delivered to the database engine once a majority of group members (a quorum) have acknowledged receiving it.

This consensus-based communication ensures that network partitions do not lead to data divergence. If a network split occurs, only the partition containing a majority of the original nodes (e.g., 3 out of 5) can continue to accept writes, while the minority partition automatically transitions to a read-only or blocked state.

Transaction Certification and Conflict Resolution

Because MySQL Group Replication allows transactions to execute optimistically before global agreement is reached, conflicts can arise when concurrent transactions on different nodes attempt to modify the same data. MGR resolves this through a distributed certification process.

Every node maintains a certification index containing the transaction identifiers and write-set signatures of recently committed transactions. When a transaction’s write set is delivered via Paxos: 1. The certification engine compares the transaction’s read-set version (the database state when the transaction started) with the version of the data currently committed in the certification index. 2. If the data has been modified by a concurrent transaction that committed first, a conflict is detected. 3. The transaction that arrived first via Paxos order is certified and committed, while the conflicting concurrent transaction is rejected and rolled back.

This deterministic certification occurs independently on every node. Because all nodes process the same transactions in the same order, they all reach the exact same certification decision without requiring additional network round trips.

Group Membership and Failure Detection

MGR features a built-in group membership service that dynamically tracks the status of all active servers in the cluster.

• Failure Detector: Nodes exchange periodic heartbeat messages. If a node fails to send heartbeats within a configured timeout, the group suspects a failure.
• Reconfiguration: Upon detecting a node failure, or when a new node joins, the remaining nodes initiate a membership reconfiguration (a “view change”). This view change must be agreed upon by a Paxos consensus majority.
• Distributed Recovery: When a new or recovering node joins the group, it automatically selects an existing member as a donor. It then uses combination of asynchronous binary log transfers and state snapshots to catch up to the current group state before transitioning to an active, serving status.

Architectural Deployment Modes

MySQL Group Replication operates in one of two structural configurations:

Single-Primary Mode

In this configuration, only one designated node (the primary) is allowed to accept write transactions. The remaining nodes (secondaries) are automatically set to read-only mode. If the primary node fails, the group membership service automatically detects the loss and elects a new primary from the surviving secondaries based on predefined criteria, such as node UUID or MySQL version eligibility.

Multi-Primary Mode

In this configuration, all nodes in the replication group can simultaneously accept read and write transactions. This mode relies heavily on the certification process to detect and rollback concurrent write conflicts. While multi-primary mode increases write path redundancy, it requires careful schema design, such as mandatory primary keys and proper constraint handling, to minimize transaction rollbacks.