High availability, Group Replication and upgrades
Choose a topology that matches your real recovery target, run a quorum-based cluster, and upgrade a live deployment without turning a version bump into an outage.
Choosing a topology
| Topology | Behaviour | Trade-off |
|---|---|---|
| Async replica | The primary never waits for a replica | A failover can lose the last committed transactions |
| Semi-synchronous | The primary waits for one replica to acknowledge | One network round trip; the loss window is bounded |
| Group Replication | Majority-based, automatic membership | Needs three members and a low-latency network |
| InnoDB Cluster | Group Replication plus MySQL Router and the AdminAPI | The supported production packaging |
| Multi-primary | Every member accepts writes | Conflict detection; a losing commit is rolled back |
[mysqld]
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE
plugin_load_add = group_replication.so
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_start_on_boot = OFF
group_replication_local_address = "10.0.0.11:33061"
group_replication_group_seeds = "10.0.0.11:33061,10.0.0.12:33061,10.0.0.13:33061"
group_replication_single_primary_mode = ONThe honest first question is how much data you can lose and how long you can be down. A pair of async replicas with a documented manual failover is a legitimate answer when minutes are acceptable; the failure mode to avoid is believing you have automatic failover when you do not.
Running the cluster
-- bootstrap exactly one member
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;
-- then join the others
START GROUP_REPLICATION;
SELECT member_host, member_state, member_role
FROM performance_schema.replication_group_members;
SELECT * FROM performance_schema.replication_group_member_stats;- The primary is elected by the group. Never promote a member by hand; the group will reject the attempt or ignore it.
- Quorum is a strict majority. Three members survive one failure; two do not survive one, because a single member is not a majority of two.
- Applications connect to MySQL Router, which learns the current primary and routes writes and reads to the right member.
- Flow control throttles a fast member so a slow one can keep up. A lagging member shows up as reduced write throughput long before it shows up as an error.
- In multi-primary mode two members can accept conflicting writes. The second commit fails certification and the application must retry it.
💡
High availability is a property of the whole system, not of the database alone. A cluster behind a single load balancer, on a single application node, backing up to a single target, is not highly available — the single point of failure has simply moved.
Backups and version upgrades
- Read the release notes and confirm what the target version removes, for example the deprecated replication terminology in 8.4.
- Back up and restore-test before touching a server, so a failed upgrade is not also a data-loss event.
- Check the instance with the upgrade checker and
mysqlcheck --check-upgradewhile the old version is still running. - Upgrade a replica first, then fail over deliberately so the upgraded member becomes primary, and only then upgrade the rest.
- Rehearse the rollback. Downgrades are supported only within narrow limits, so treat an upgrade as effectively one-way.
// MySQL Shell AdminAPI
dba.checkInstanceConfiguration("[email protected]:3306")
dba.configureInstance("[email protected]:3306")
var cluster = dba.getCluster();
cluster.status();
cluster.rescan();Keep the binary log retention long enough to cover an upgrade window. If you have to rebuild a member from a backup taken before the upgrade, that member needs to be able to catch up from the log rather than from a fresh dump.
FAQ
Group Replication, or a pair of replicas?
If the requirement is seconds of downtime and zero lost transactions, you need a quorum-based topology. Async replicas with a documented manual failover are simpler and honest when a few minutes of recovery is acceptable — the failure mode to avoid is believing you have automatic failover.
How do connections survive a failover?
They do not, unless the client stack reconnects. Route through MySQL Router or a topology-aware proxy, set a short connect timeout, and make the application retry idempotent work instead of surfacing a transient failover as a user-visible error.
Related
Replication, backup and operational pitfalls Next steps: managed MySQL, Aurora and cloud operations
Last refreshed 2026-09-18.