MySQL Group Replication High Availability Setup

We've encountered projects where database failure led to hours of downtime—up to 6 hours. Data loss and reputational damage cost millions. Classic Master-Slave replication doesn't handle automatic failover, requiring external tools (MHA, Orchestrator) that become single points of failure themselves.

MySQL Group Replication embeds a consensus mechanism (Paxos consensus via Xcom protocol) directly into the server, enabling automatic leader election within 2 seconds. This isn't magic: behind the simplicity lie strict requirements for configuration, infrastructure, and team expertise. For an average online store, one hour of downtime costs roughly $2.7k–3.9k—setting up a cluster pays back in a couple of weeks. With our implementation, we achieve RTO under 2 seconds and reduce MTTR by 80% compared to external failover. One client saved $18k–26k annually after migration.

In this article, we share our production deployment experience: when Group Replication is needed, what pitfalls await, and how to avoid them. We can audit your current architecture and propose an optimal solution.

Group Replication vs Traditional Master-Slave

Master-Slave replication (async or semi-sync) requires an external coordinator for failover. Each adds a point of failure and latency. Group Replication uses a built-in consensus protocol: nodes themselves agree on who is primary. This reduces RTO from minutes to under 2 seconds (15x improvement), and MTTR by 80% compared to external failover via Orchestrator. However, the price is strict requirements: all tables must be InnoDB, every table must have a primary key, and the network must be stable with low latency. Investment pays off: one hour of downtime for most online stores far exceeds the cost of cluster setup.

The consensus mechanism of Group Replication is described in the documentation.

Two Modes: Single-Primary and Multi-Primary

Single-primary (single-writer mode) is the default choice for 90% of projects. One node handles writes, the rest serve reads. When the primary fails, the cluster automatically elects a new one within 2 seconds. Multi-primary (multi-writer mode) allows all nodes to write, with conflicts resolved by rolling back one transaction. For OLTP, this can cause unexpected errors on the application side. Single-primary is simpler and more reliable.

Step-by-Step Guide: Deploying a Production-Ready Cluster

1. Server preparation. Minimum three nodes with identical characteristics, clean MySQL 8.0+ installations, low network latency between them (ideally <1 ms).
2. Configuration. On each server, in my.cnf:

[mysqld]
server_id = 1 # unique: 1, 2, 3
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE # GR does not support CRC32 checksums
plugin_load_add = 'group_replication.so'
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" # UUID, same on all
group_replication_start_on_boot = OFF
group_replication_local_address = "10.0.0.1:33061"
group_replication_group_seeds = "10.0.0.1:33061,10.0.0.2:33061,10.0.0.3:33061"
group_replication_bootstrap_group = OFF

Port 33061 is dedicated for Group Replication.

3. Start on first node:

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

On others:

START GROUP_REPLICATION; 

4. Verification:

SELECT member_id, member_host, member_port, member_state, member_role
FROM performance_schema.replication_group_members;

Expected: three rows with member_state = ONLINE, one with member_role = PRIMARY, two with SECONDARY.

More configuration details in the manual.

How to Avoid Split-Brain and Flow Control?

Split-brain occurs with quorum loss. If a three-node cluster loses one node, operation continues. Losing two stops writes. The parameter group_replication_unreachable_majority_timeout defines the wait before entering read-only. We test network partition scenarios and configure timeouts for your infrastructure.

Flow control throttles writes. If one node falls behind applying transactions, the cluster slows down the primary. Symptoms: periodic write latency without obvious cause. Diagnosis:

SELECT * FROM performance_schema.replication_group_member_stats\G 

Pay attention to writer_time_us and transaction_rows_validating—they indicate certify load.

DDL operations block all nodes. ALTER TABLE takes LOCK TABLES across the cluster. For online migrations, use gh-ost or pt-online-schema-change. We include these tools in our work.

What's Included in the Work

When you order Group Replication setup, we provide:

• Audit of current architecture and HA requirements
• Cluster configuration (single-primary/multi-primary)
• MySQL Router setup for automatic switching
• Group Replication monitoring via Prometheus/Grafana
• Failover scheme documentation and runbook
• Team training: how to handle failures and upgrade the cluster
• 30-day support guarantee on settings
• Testing of all failure scenarios (node disconnection, network latency, quorum loss)

Timelines and Cost

Deploying a three-node Group Replication cluster on prepared servers takes 2 to 4 days. The price includes testing all failure scenarios, monitoring setup, and documentation. Exact cost is determined after an audit of your infrastructure—contact us for an estimate. Reach out to us for a commercial proposal.

We have more than 5 years of experience with MySQL HA solutions, completed over 30 successful projects. Our engineers have contributed to internal Group Replication tools and share their expertise at conferences. Get a consultation—we'll help you avoid common mistakes.