Which MySQL high availability model fits your team
If MySQL must survive a server failure without waiting for an operator, the MySQL Shell docs recommend InnoDB Cluster wherever possible. The two conditions that point toward InnoDB ReplicaSet are better write performance and deployment over unstable, slow or wide area networks. Start from those two conditions: if your primary site has reliable, low-latency links between nodes and write throughput is not the constraint, the default recommendation applies. If you expect the network between nodes to be unreliable or geographically stretched, or your write workload measurably suffers under group replication, InnoDB ReplicaSet deserves a serious look, provided your team accepts manual failover.
Be clear about what each model asks of your operations team. InnoDB Cluster is built from at least three MySQL server instances running Group Replication, with MySQL Router sending clients to the new primary after an automatic promotion. InnoDB ReplicaSet runs asynchronous GTID-based replication, and its failover must be triggered manually through AdminAPI before writes resume. Transactions incomplete at an unexpected halt can be lost, and promoting a secondary during a network partition can cause split-brain inconsistencies. Confirm with your own network team how often partitions occur between your nodes, and write down who is authorized to run the failover and how quickly they can be reached at night.
Treat this as a decision that is hard to reverse. Once applications, connection strings, backup jobs and monitoring depend on one topology, moving between the two means re-provisioning instances, validating data and retesting failover, all while production traffic continues. Before committing, run a failover test in a non-production copy of your environment, measure the write latency your application actually sees, and ask your implementation partner to document the runbook for each model. Use the MySQL Shell 8.4 InnoDB ReplicaSet documentation to check the failure cases your runbook must cover.
InnoDB Cluster and InnoDB ReplicaSet side by side
This table compares the two MySQL high availability topologies on replication basis, failover, minimum instances, data loss, split-brain risk, multi-primary support, WAN fit and routing. Read each row as the MySQL Shell 8.4 documentation states it, then check the notes against your own network, failover runbook and write volume before you choose.
| Aspect | InnoDB Cluster | InnoDB ReplicaSet |
|---|---|---|
| Replication basis | Group Replication, built into the MySQL server | Asynchronous GTID-based replication from one primary to secondaries |
| Failover mode | Automatic promotion of a secondary with built-in failover | Manual failover triggered through AdminAPI before writes can resume |
| Minimum instances | At least three MySQL server instances | A single primary with one or more secondaries, and the docs say it generally does not provide high availability on its own |
| Data loss on unexpected halt | Group Replication is designed for automatic failover; confirm the durability settings and recovery behavior your environment requires | Transactions incomplete at an unexpected halt can be lost |
| Split-brain risk during network partition | Group Replication manages membership; confirm quorum behavior with your network team and test partition scenarios | Promoting a secondary during a network partition can cause split-brain inconsistencies |
| Multi-primary support | Single-primary mode by default; advanced users can configure multiple primaries | Not supported; no multi-primary mode |
| WAN and unstable network fit | Recommended where possible; confirm latency and quorum tolerance for your links before deployment | Cited by the docs as the better choice for better write performance and deployment over unstable, slow or wide area networks |
| Client routing through MySQL Router | Router configures itself from the cluster and routes clients to the new primary after automatic promotion | Routing after a manual failover depends on your procedure; confirm how Router or your clients follow the new primary |
How the parts fit in each topology
Both topologies sit on the same MySQL Community Server instances, but they differ in who detects a failed primary and who moves writes to a new one. The cards below cover the components that carry that difference, from Group Replication and the AdminAPI to the manual failover step in ReplicaSet and the router that sends client traffic to the right node.
Group Replication with built-in failover
Group Replication is the engine behind InnoDB Cluster. The member instances agree on each transaction through a group protocol, and when the primary becomes unavailable, a secondary is promoted automatically without an operator stepping in. This is the component that gives InnoDB Cluster its automatic failover, so if your recovery plan depends on writes resuming without a person at the console, this is the topology that matches it. Confirm the failover behavior, quorum requirements and recovery steps against the MySQL Shell documentation and test them in your own environment before you rely on them.
AdminAPI builds the cluster
MySQL Shell's AdminAPI creates and manages the topology. InnoDB Cluster is configured through AdminAPI from at least three MySQL server instances, so the minimum footprint is set before any data arrives. The same API is used for day-two work such as adding members and checking status. Plan for the three-instance minimum in your capacity model, and ask your team which operators will run AdminAPI commands during an incident.
Asynchronous GTID-based replication
ReplicaSet uses asynchronous replication keyed on GTIDs. One primary accepts writes and secondaries apply its transactions after they commit, so the primary does not wait for the secondaries to confirm. That keeps write latency low and makes the topology easier to run across slow or wide area links, but it also means a transaction acknowledged by the primary can be missing from a secondary if the primary halts unexpectedly. Ask how your application handles a lost-transaction window before you choose this option.
Manual failover in ReplicaSet
Promotion in ReplicaSet is an operator action through AdminAPI. Writes stay down until someone triggers the failover, so the recovery time depends on how quickly your on-call team detects the outage and runs the command. Promoting a secondary during a network partition can produce split-brain inconsistencies, which makes the decision to fail over a judgment call rather than a routine step. Document who may authorize the promotion, how they confirm the old primary is isolated, and how you will reconcile data afterward.
MySQL Router directs client traffic
MySQL Router sends each connection to the current primary. In InnoDB Cluster, Router configures itself from the cluster metadata and routes clients to the new primary when a secondary is automatically promoted, so applications do not need their own failover logic. Your application still needs to handle dropped connections and retry safely during a switch. Confirm how your connectors and connection pools behave with Router before you finalize the design, and note that the same routing question has to be answered separately for a ReplicaSet deployment.
Single-primary default with optional multi-primary
InnoDB Cluster runs single-primary by default. Advanced users can configure multiple primaries, but InnoDB ReplicaSet has no multi-primary mode at all, so the write topology is a separate decision you make inside InnoDB Cluster. Multi-primary changes conflict handling and application expectations, so it should be a deliberate choice backed by testing, not a default. Ask your architects which write pattern your workload needs and whether multi-primary is in scope for your rollout.
What data loss and split-brain risk look like in practice
An InnoDB ReplicaSet can lose transactions that were not yet complete when the primary halts unexpectedly. The ReplicaSet runs asynchronous GTID-based replication, so a primary can acknowledge a write before any secondary has received it. If the primary fails at that moment, the write may exist only on the old primary. The MySQL Shell 8.4 InnoDB ReplicaSet documentation states that transactions incomplete at an unexpected halt can be lost, and that failover must be triggered manually through AdminAPI before writes resume. The practical question for your team is how much data loss your business can accept, and whether your recovery runbook names the person who decides to promote a secondary and accepts that risk. Confirm the exact replication settings and recovery steps against the current MySQL 8.4 documentation for your version before you rely on them.
Split-brain is the second risk. If the network partitions and a secondary is promoted while the original primary is still reachable by some clients, two servers can accept writes that the other does not see. The MySQL Shell documentation for InnoDB ReplicaSet warns that promoting a secondary during a network partition can cause split-brain inconsistencies. Reconciling those divergent writes is manual work, and it lands on the team that owns the data. InnoDB Cluster reduces this exposure because Group Replication handles automatic failover inside the cluster, but the documentation does not promise that split-brain cannot occur under every network condition, so your own partition tests still matter.
Before trusting either model, test the failure paths in your environment, not only the happy path. Halt the primary under a realistic write load, then measure how many committed and uncommitted transactions survive on the new primary. Partition the network between nodes, and check which side accepts writes. Then review how your application behaves: whether connections are retried, whether transactions are idempotent, and how long a client waits before it reports an error. For InnoDB Cluster, verify that MySQL Router sends traffic to the new primary during the test. Record the results and the time to recover. Those results, not vendor descriptions, should decide which model your data can tolerate.
Choosing by network and workload
When all instances sit in one data center or on a stable, low-latency LAN, the MySQL Shell docs recommend InnoDB Cluster wherever possible. Group Replication runs with built-in failover, and MySQL Router sends clients to the new primary when a secondary is automatically promoted, so no operator has to step in during an outage. The network is rarely the limiting factor here, so the main questions shift to how many instances you can afford to run and how the cluster fits your maintenance windows.
- Minimum instances: InnoDB Cluster is configured from at least three MySQL server instances, so confirm you can place three nodes on separate hosts or failure domains.
- Automatic failover: Promotion happens without a manual AdminAPI step, which matters if your on-call model cannot respond quickly at night.
- Router placement: Ask the application team whether MySQL Router runs beside each application or on shared hosts, since that decides how clients discover the new primary.
- Failure domains: Confirm with the infrastructure team that the three instances do not share one hypervisor, storage array or power feed.
- Operations skill: Check that your team can run Group Replication recovery and rejoin steps.
Before committing, confirm the node count, the failure domains and the router layout with the network and application teams.
When members span a wide area network or links are slow or unstable, the MySQL Shell docs name deployment over unstable, slow or wide area networks as a main reason to choose InnoDB ReplicaSet. ReplicaSet uses asynchronous GTID-based replication, so the primary does not wait on remote members to commit. The cost is that failover is manual through AdminAPI, and a network partition that leads to promoting a secondary can cause split-brain inconsistencies, so the decision depends on how you handle partitions.
- Manual failover: Writes stay unavailable until an operator triggers failover through AdminAPI, so define who makes that call and how fast they can reach it.
- Data loss window: Transactions incomplete at an unexpected halt can be lost, so agree on acceptable loss with the application owners before go-live.
- Partition handling: Ask the network team how often partitions occur between sites and how they are detected, since promoting during a partition is the main split-brain risk.
- Fencing: Confirm with the platform team how the old primary is kept from accepting writes after a promotion.
- Latency budget: Measure the round-trip time between sites with the network team before assuming Group Replication is unusable.
Before choosing ReplicaSet, confirm link quality, partition frequency and the acceptable loss window with both the network and application teams.
When write latency is the main concern, the MySQL Shell docs give better write performance as the main reason to use InnoDB ReplicaSet. InnoDB Cluster must coordinate each write through Group Replication before it commits across members, which adds work on every transaction. InnoDB Cluster runs in single-primary mode by default, and multi-primary mode is available to advanced users, while ReplicaSet does not support multi-primary at all. Choosing ReplicaSet for write speed trades away automatic failover, so the question is whether your write latency target justifies manual recovery.
- Write path cost: Ask the database team to benchmark commit latency on both models using your own transaction mix, since general figures will not match your workload.
- Primary mode: Confirm whether the application needs multi-primary writes, because InnoDB Cluster supports it only as an advanced option and ReplicaSet does not support it.
- Transaction size: Check with application owners whether large batch writes or many small commits dominate, since that changes the coordination overhead.
- Recovery plan: Document who runs manual failover for a write-heavy service and how long the business can accept writes stopping.
- Replica reads: Ask whether read traffic should go to secondaries, which also affects how MySQL Router is configured.
Before deciding, run a commit-latency test on representative transactions with the database and application teams and compare the result with your recovery targets.
Upgrades, backups, monitoring and skills for each model
This table compares the day-two work each model adds, from upgrades and backups to monitoring and team skills. Read it as a checklist of questions to put to your DBA team and to confirm against the MySQL Shell documentation for your exact version. The main takeaway is that InnoDB Cluster shifts effort toward Group Replication health and Router configuration, while InnoDB ReplicaSet keeps failover effort in a runbook your team must execute and rehearse.
| Area | InnoDB Cluster | InnoDB ReplicaSet |
|---|---|---|
| Failover handling | Automatic promotion of a secondary by Group Replication, with MySQL Router routing clients to the new primary | Operator triggers failover manually through AdminAPI before writes resume, so the runbook and on-call response carry the outage time |
| Monitoring focus | Group membership, primary election state and member health reported by the cluster, plus Router connection status | Replication lag and GTID position across secondaries, plus a check that the team knows which node is authoritative after a halt |
| Upgrades | Rolling upgrade of group members under AdminAPI guidance; confirm the sequence for your version in the MySQL Shell docs | Upgrade each instance and manage the topology by hand; confirm the procedure and rollback steps for your version in the MySQL Shell docs |
| Backups | Backups are taken from a member you choose; MySQL Enterprise Backup for hot backups is an Enterprise feature, so Community users need another backup method | Same backup choice applies; Enterprise Backup is available only with MySQL Enterprise Edition, so confirm the Community tooling and restore test for your version |
| MySQL Shell and Router skills | Team must operate AdminAPI, Router bootstrap and cluster state commands, and understand group membership | Team must operate AdminAPI for topology changes and failover, with strong replication troubleshooting skills |
| Recovery drills | Test member loss and rejoin on a staging cluster; confirm expected behavior in the MySQL Shell docs | Rehearse manual promotion, replica rebuild and split-brain checks at least as often as the failover runbook changes |
How MySQL Router changes what applications connect to
With InnoDB Cluster, MySQL Router configures itself from the cluster metadata and routes client connections to whichever instance is the primary, so an application that connects to the router does not need to know which server holds the primary role. When a secondary is automatically promoted after a failure, the router sends new connections to the new primary. The practical decision is architectural: point your application connection strings at the router host and port, not at a fixed database address. Confirm with your application owners that every service, batch job and reporting tool uses the router endpoint, because any component still hard-coded to the original primary will keep failing after a promotion.
With InnoDB ReplicaSet, the MySQL Shell docs describe failover as a manual step triggered through AdminAPI before writes can resume, so the routing picture is different and the docs do not present router-driven automatic promotion as part of that topology. Do not assume that a router in front of a ReplicaSet will redirect writes on its own. Confirm with the vendor documentation and with a test in your own environment exactly how your chosen routing layer behaves during a manual promotion, including which connections are dropped, how long writes are blocked and whether applications retry safely.
Add the router to your test plan before go-live. Run a planned primary switchover and an unplanned instance stop while a representative application load is running, then record how each client reconnects, how many transactions fail or need retry, and whether any application caches a direct server address. Include split-brain and partition scenarios in the same exercise, since routing cannot prevent two instances from accepting writes. Ask your DBA and application teams to sign off on the results, and keep the test output with your change records.
Questions teams ask before building MySQL high availability
What drives the cost and effort of each MySQL high availability model?
Both models run on MySQL Community Server, which is GPL-licensed and freely downloadable, so the cost sits in servers, storage, network and the people who build and operate the cluster. InnoDB Cluster needs at least three MySQL server instances, so it carries the most infrastructure and the most configuration to maintain. InnoDB ReplicaSet can run with fewer instances, but automatic failover is not part of it, so the team must build and rehearse the manual promotion process itself. Expect one-time costs for design, build and testing, and recurring costs for patching, backups, monitoring and on-call coverage. Ask any quote to split labor by these items and to state whether it covers failover drills, runbooks and handover. Oracle Enterprise subscription fees are separate and need a quote from Oracle.
How long does it take to build MySQL high availability?
No supplied figure sets a duration, so treat any number you hear as a claim to verify. The timeline depends on how many instances must be provisioned, whether the nodes sit in one site or across a wide area network, how many environments need the same topology, how backup and restore are proven, and how many failover tests the team wants before go-live. InnoDB Cluster adds work for the three-instance group, MySQL Router configuration and application connection handling. InnoDB ReplicaSet adds work for runbooks covering manual promotion and the decision criteria for triggering it. DeployOpen plans most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. Request a timeline tied to your topology and test plan.
What MySQL and network skills does the team need?
The team needs working knowledge of three areas. First, MySQL administration: instance configuration, GTID-based replication and the AdminAPI in MySQL Shell, which both topologies use to create and manage clusters. Second, network behavior: InnoDB Cluster depends on a stable group of members, and InnoDB ReplicaSet can suffer split-brain inconsistencies if a secondary is promoted during a network partition, so the team must understand latency, packet loss and partition scenarios between nodes. Third, application integration: clients must reach the current primary through MySQL Router or a similar path and handle reconnects during a failover. Check these skills against your own staff before choosing a model, and confirm which of them your existing monitoring and DBA practice already covers.
Can a team run MySQL high availability without outside help?
A team with the skills described above can run either model in house, and the MySQL Shell documentation recommends InnoDB Cluster wherever possible. The harder question is operational coverage. Confirm who performs a manual InnoDB ReplicaSet promotion at night, who decides when to promote, who tests restores on a schedule and who documents each change. If those answers are unclear, an outside team can help with planning, implementation, hardening, backup design, documentation and ongoing support. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Ongoing support, upgrades and continuous testing are available as retainers, and most engagements are fixed-scope.
What changes between MySQL Community and Enterprise for these models?
Both high availability models are available in MySQL Community Edition. Community includes InnoDB Cluster, Group Replication with automated failover, MySQL Router, MySQL Shell and replication, so the topology choice does not require a paid edition. MySQL Enterprise Edition adds Enterprise Backup for hot backups, Thread Pool, external authentication modules, Transparent Data Encryption, Enterprise Encryption, Enterprise Firewall, Enterprise Audit and 24x7 Oracle support. Those additions change backup, security, audit and support arrangements rather than the failover mechanics. Check whether your compliance requirements call for encryption at rest or audit features that Community does not provide, and whether your backup approach meets your recovery targets. Oracle sets Enterprise pricing, so request a quote from Oracle.
How should a team choose between the LTS and Innovation tracks?
MySQL LTS releases are supported under the Oracle Lifetime Support Policy with 5 years of premier support and 3 years of extended support. Innovation releases are supported only until the next Innovation release, so they require a steady upgrade cadence. Features can only be added or removed in the first release of an LTS series, and later LTS point releases carry only necessary fixes, which suits clusters that must stay stable. The MySQL Community Server download page currently lists 26.7.0 (Innovation), 9.7.2 LTS, 8.4.11 LTS and 8.0.46. For a production cluster, most teams start with an LTS series and confirm the exact support dates for their chosen release in the MySQL release documentation or with Oracle before committing.
Does InnoDB ReplicaSet fit a deployment across a wide area network?
The MySQL Shell documentation gives better write performance and deployment over unstable, slow or wide area networks as the main reasons to choose InnoDB ReplicaSet, so wide area networks are where it can make sense. The trade-off is operational. Failover is manual and must be triggered through AdminAPI before writes resume, transactions incomplete at an unexpected halt can be lost, and promoting a secondary during a network partition can cause split-brain inconsistencies. A wide area design therefore needs a documented promotion decision, a tested procedure for isolating the old primary and a recovery plan for lost transactions. Measure the latency and loss between your sites in your own environment, then compare the result against the InnoDB Cluster requirements before deciding.
Steps to decide before you build
This sequence turns the choice between InnoDB Cluster and InnoDB ReplicaSet into a decision backed by your own network measurements, write profile, recovery targets and failover test results, so the topology you build matches what your service can tolerate.
Measure latency and stability between sites
Network engineers measure round-trip time, jitter and packet loss between every site that will hold a MySQL instance, over at least one representative business cycle. Group Replication needs stable, low-latency links to certify transactions quickly, and the MySQL Shell docs name unstable, slow or wide area networks as the main reason to consider InnoDB ReplicaSet instead. The step is done when the team has a written table of measured values per site pair and a clear answer on whether the links are stable enough for synchronous quorum.
Confirm the write profile
The application or database owner documents the write rate, transaction size, peak periods and any write-heavy batch jobs. The MySQL Shell docs cite better write performance as a reason to choose InnoDB ReplicaSet, so this profile tells you whether Group Replication's certification overhead is acceptable. Ask your DBA to benchmark a representative workload on a test cluster. The step is done when the team can state the expected peak write load and the latency budget the service can absorb.
Set the failover requirement from recovery targets
Service owners and the risk or continuity lead decide whether the service must fail over without a human in the loop. InnoDB ReplicaSet requires a manual AdminAPI failover before writes resume, and transactions incomplete at an unexpected halt can be lost, so a service with tight recovery expectations usually points to InnoDB Cluster. Record the recovery time and data loss tolerance the business has approved in writing. The step is done when each database has a documented answer on automatic versus manual failover and the owner has signed it off.
Plan instance count and router placement
The platform team maps the topology: InnoDB Cluster needs at least three MySQL server instances running Group Replication, placed so that a single site or rack failure leaves a quorum. Decide where MySQL Router runs, whether on each application host or on a shared tier, and confirm that clients reach the new primary after promotion. Ask your infrastructure team to confirm the number of hosts, failure domains and the network paths between them. The step is done when a diagram shows instance placement, failure domains and router locations, and each host has a named owner.
Test failover and partition behavior
The database and security engineers run a non-production exercise that stops the primary, isolates a site with a network partition and restores service, then record what the application sees. For InnoDB ReplicaSet, the test should confirm the manual failover runbook and check for split-brain inconsistencies after a partition. For InnoDB Cluster, it should confirm automatic promotion, router redirection and recovery of the rejoining member. Keep the results with the runbook. The step is done when every failure scenario has a recorded result, a named owner for each gap, and a go or no-go decision signed by the service owner.
How DeployOpen scopes, builds and supports MySQL high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside the client's own infrastructure, including MySQL high availability. We start by agreeing which topology fits the write profile, network and recovery expectations, then build and hand over that design in writing.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
- The written scope states the chosen topology, InnoDB Cluster or InnoDB ReplicaSet, and the reasons behind it.
- We confirm the node count, network links, write volume and failover expectations before any quote follows.
How we build
- We deploy the MySQL instances and MySQL Router inside your cloud accounts, data centers or air-gapped networks.
- We configure cluster or replication settings through MySQL Shell AdminAPI and test each failover path on the agreed topology.
- We document split-brain and data loss exposure, including how failover is triggered and how transactions are recovered.
How we hand over
- Handover includes runbooks for failover, rejoining instances, backup restore and routine upgrades on your schedule.
- Your team receives the configuration, test results and documented decisions behind the topology choice.
- We prepare the controls and evidence your compliance assessors may ask for, though auditors and certification bodies issue any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainer scope can cover MySQL release-track upgrades, with the support windows you confirm with Oracle.
- Periodic failover testing can be added to the retainer so the chosen topology is exercised against current configurations.
