Is MySQL Router a single point of failure?

Yes if it is centralised, and Oracle's own community manager says so. Co-locate the Router on the application tier, or build proper redundancy for the proxy layer with health checking that fails over as fast as the database does. This is the part we handle rather than leave to you.

MySQL high availability, designed and proven before it goes live

We design, build and rescue production MySQL InnoDB Clusters across Group Replication, MySQL Router, ProxySQL, ClusterSet DR and Kubernetes. Delivered by DBAs who run these clusters daily and test failover before you depend on it.

Talk to a MySQL HA engineer →

REVIEWED ON Clutch

4.9 · Verified reviews

Quorum Active

Primary

db-node-01

:6446 · R/W

PAXOS Sync

Replica

db-node-02

:6447 · R/O

Replica

db-node-03

:6447 · R/O

0s Lag Failover Armed Router HA

24×7Incident cover

<15 minIncident response

10+Years of operations

6000+Servers managed

Certified ISO 27001 AWS Advanced Tier Partner ISO 9001 PCI DSS · Attestation of Compliance Certified MySQL DBAs

Brands that trust Mydbops

Start with the decision

Is InnoDB Cluster the right choice, or is something else?

Most teams arrive here having already been told InnoDB Cluster is the answer. Sometimes it is. Often the honest recommendation is a managed service, an InnoDB ReplicaSet, or a proxy layer in front of what you already run. We would rather tell you that in week one than build you a cluster you did not need. Here is the comparison we would walk you through, with the vendors' own published numbers.

Option	Failover, as published by the vendor	What you give up	When we recommend it
MySQL InnoDB ClusterGroup Replication, single or multi-primary	Automatic, driven by group consensus. Real-world target depends on topology and workload, which is why we measure yours rather than quote a number (see failover targets below).	You operate it. Quorum, member recovery, version upgrades and the proxy layer are yours.	You need architectural control, portability across clouds or on-premises, and automatic failover: and you have or will have the operational cover.
Amazon Aurora MySQL	“Failover typically completes within 30 seconds.” RDS Proxy “reduces failover times by up to 66%.”	AWS only. Storage engine is Aurora's, not InnoDB. Less granular control over replication behaviour.	You are all-in on AWS, want the operational burden gone, and can accept the pricing model at your I/O profile.
Amazon RDS MySQLMulti-AZ DB instance	“Failover times are typically 60 to 120 seconds. However, large transactions or a lengthy recovery process can increase failover time.”	The standby is not readable. No read scaling. The slowest failover of the options here.	Rarely, once you know the number. Many teams are on this topology and believe they have fast failover.
Amazon RDS MySQLMulti-AZ DB cluster	“Failover times are typically under 35 seconds.”	AWS only, three instances, region-bound.	You want managed MySQL with readable standbys and 2 to 4 times faster failover than the Multi-AZ instance on today.
Google Cloud SQL for MySQL	SLA: Enterprise Plus with HA at 99.99% or better; Enterprise with HA at 99.95% or better. Shared-core and single-zone carry no SLA.	GCP only. Less control over Group Replication internals.	You are on GCP and want the SLA rather than the architecture.
Galera / Percona XtraDB Cluster	Synchronous certification-based replication, virtually synchronous commit.	Write-set certification changes application behaviour. Galera's most tightly integrated home is MariaDB.	You need true multi-primary writes and your workload tolerates certification conflicts.
InnoDB ReplicaSet	Manual failover, asynchronous replication, managed through the same MySQL Shell AdminAPI.	No automatic failover.	Your network between nodes is not stable enough for group consensus, or you want AdminAPI tooling without the consistency constraints.

Placed directly beneath the table

One thing worth knowing before you decide. Oracle's own managed MySQL service, HeatWave, builds its high availability option from three MySQL instances and, in Oracle's words, “high availability uses MySQL Group Replication to replicate data from the primary instance to the secondary instances.”

So the question is rarely InnoDB Cluster or something better. It is usually: who operates Group Replication for you, on whose infrastructure, and at what price. That is a genuine decision with real trade-offs, and it is the first thing we work through with you.

Reference architectures

The topologies we design, to scale

Three patterns we build most often. Each is drawn to the real ports, roles and failure boundaries: not a marketing illustration.

Figure 1 Single-primary InnoDB Cluster with MySQL Router co-located on the application tier. Router splits read/write on 6446 and read-only on 6447 across one primary and two secondary Group Replication members.

Figure 2 InnoDB ClusterSet for cross-region disaster recovery. You will find articles saying you cannot replicate from one InnoDB Cluster to another. That was true before ClusterSet, and it is the single most common piece of out-of-date advice we correct. ClusterSet does exactly this - and the trade-off is honest: the link between regions is asynchronous, so your recovery point objective across it is not zero, and promoting the replica cluster is a decision a person makes, not something the cluster does for you.

Figure 3 MySQL Router compared with ProxySQL as the routing layer for an InnoDB Cluster. Which one is right is a workload decision - and in section 7 we explain how we make the proxy layer itself highly available, whichever you choose.

What we build, and what you receive

Every engagement ends with artefacts you own and can act on without us

Five capabilities, from architecture through Kubernetes. Each one has a named deliverable you keep.

Architecture & topology design

Workload profiling, consistency-level selection (group_replication_consistency), single-primary against multi-primary, node count against your failure-tolerance target, network latency validation between members, and a version floor.

You receive

A topology decision document naming the chosen mode, the consistency setting and the reason for each - plus a diagram matched to your environment.

Build & cutover

Provisioning through MySQL Shell AdminAPI, Group Replication configuration persisted to disk, GTID and UUID hygiene, MySQL Router bootstrap, and cutover with live replication so the old primary stays available until you switch.

You receive

Idempotent build scripts, a cutover runbook with a rollback step, and the recorded results of a failover test performed before you take traffic.

Routing layer

MySQL Router or ProxySQL selected on the evidence rather than by default, read-write splitting, routing strategy, connection behaviour under member loss, and high availability for the proxy tier itself.

You receive

Proxy configuration under version control, plus a documented answer to “what happens to in-flight connections when the primary changes”.

Disaster recovery with ClusterSet

Cross-region replica cluster, replication lag monitoring on the async link, controlled switchover and emergency failover procedures, and a stated recovery point objective you have actually measured.

You receive

A DR runbook with the switchover and emergency-failover commands, and a tested restore - not an assumed one.

Kubernetes

Operator-based lifecycle management, storage class and volume behaviour under node loss (a common cause of members dropping out of sync), pod disruption budgets, and backup integration.

You receive

Helm values or manifests, and the operator upgrade path documented for your MySQL version.

Not sure which of these you need?

That is what the assessment is for. We start read-only, tell you which capabilities your environment actually calls for, and where the honest answer is “you do not need a cluster”, we say so.

Next step

Talk through your topology →

What we commit to

What failover actually looks like, and what we commit to

Anyone can publish a failover number. The number that matters is the one measured on your cluster, with your transaction sizes, at your network latency. Here is how we set the target, and what we will and will not promise.

Question a buyer asks	The answer we publish
How many nodes do we need?	Group Replication tolerates `f` failures with `n = 2f + 1` members. Three members tolerate one failure. Five tolerate two. A two-member group tolerates none, which surprises people more often than it should. This is Oracle's published fault-tolerance formula, not our rule of thumb.
How many data centres or zones?	Members must be close enough for consensus to be healthy. We validate round-trip latency between candidate locations before committing to a layout, because a cluster that forms cleanly in a lab and then flaps in production is almost always a latency problem.
What failover time should we expect?	We set the target during the assessment and then prove it with a failover test before you take production traffic. For reference, the managed alternatives publish: Aurora “typically within 30 seconds”; RDS Multi-AZ DB cluster “typically under 35 seconds”; RDS Multi-AZ DB instance “typically 60 to 120 seconds”.
What is our recovery point objective?	Within a single cluster, Group Replication commits by consensus, so a clean automatic failover does not lose committed transactions. Across a ClusterSet link the replication is asynchronous, so the recovery point objective is not zero, and we will tell you what it measures at on your workload rather than rounding it down.
Who answers when it breaks?	Under-15-minute incident response, 24/7, with a named escalation path and a war-room path for severity-one events.

We do not publish a single headline RTO figure, on purpose. An unmeasured number is the fastest way to lose a technical evaluation and the fastest way to create a contractual problem. The commitment above is deliberately strong without one: we set the target on your cluster, prove it with a test, and put it in writing once it is real.

Already running a cluster

Already have a cluster, and it does not behave?

Most of the InnoDB Clusters we work on already exist. They were built once, they worked, and then something changed. If any of this sounds familiar, it is fixable and we have done it before.

🛑

Every node shows OFFLINE and nothing is serving

Usually Group Replication settings that were never persisted to disk, GTID divergence, or duplicate server UUIDs after a rebuild. Recoverable, in a specific order, without a restore from backup in most cases.

⚠️

“Cluster is NOT tolerant to any failures”

Members have dropped out and nobody noticed, so you have been running without redundancy. Often triggered by storage flipping read-only under a node, not by MySQL at all.

⚡

Split-brain, or a partition that lost quorum

This one needs a person, and it needs the right person. Forcing quorum on the wrong side of a partition is how a bad afternoon becomes a data-loss incident.

🔄

Failover happens, but the application does not recover

Almost always the routing layer rather than the cluster. Connections that never retry, a Router metadata cache that has not refreshed, or a proxy that is itself the single point of failure.

🔌

Intermittent connection errors, nothing wrong server-side

“I don't see anything at MySQL server level or any instance nor cluster problem” is a sentence we hear a lot. The evidence is in the Router layer, and you have to know where to look.

⬆️

An upgrade broke it

Or you are on a version you cannot safely upgrade from. We map the supported path and rehearse it before touching the running cluster.

We start with a read-only assessment. You get the diagnosis and the fix plan whether or not you go on to have us do the work. Not a free audit - a scoped assessment.

Get my cluster assessed →

0dropped transactions 6.56 TBrestored from a corrupted InnoDB engine 1200×load reduction neutralising runaway recovery Ecosmob Technologies · catastrophic engine corruption, recovered during odd hours

The routing layer

MySQL Router or ProxySQL, and how we make the proxy layer itself highly available

You will find strong opinions on this, including from Percona, whose engineers have written that MySQL Router “is still far, far away from being competitive with ProxySQL.” We do not think that settles it, and we deploy both. What decides it is your workload.

Native · metadata-aware

We deploy MySQL Router when

you want the fewest moving parts

You want the native, metadata-aware option with the fewest moving parts

Your routing needs are read-write splitting rather than query rewriting

You can put Router on the application servers, which is where it belongs

Query-aware · layer 7

We deploy ProxySQL when

you need query-level control

You need query-level rules, connection multiplexing against a large client fleet

You need query rewriting or mirroring

You want a proxy tier with its own clustering

And in either case we solve the part most people skip

As Oracle's own MySQL community manager puts it, if you centralise the Router then “yes in that specific case, the router is a spof,” and “you will have to take care by yourself of the router's HA.” That is true, and it is ours to handle: co-location on the application tier, or a properly redundant proxy layer with health checking that fails over as fast as the database does. A cluster with automatic failover behind a proxy with none is not a highly available system.

How the engagement runs

Five steps, each with an owner and an exit condition

Handover is the default and the retainer is the option. We would rather answer the question nobody in the competitive set answers: can we take this over ourselves?: than sell you a permanent dependency.

1

Read-only

Assessment

Read-only review of the current topology, workload profile, network latency between candidate nodes, version and upgrade path, and the routing layer. Ends when you have a written diagnosis and a recommended topology: including the case for not building a cluster if that is the honest answer.

2

Your sign-off

Design

Node count against your failure-tolerance target, single-primary or multi-primary, consistency level, proxy selection, DR shape. Ends when the topology decision document is signed off by your team, not ours.

3

Tested

Build

Provisioning, Group Replication configuration persisted correctly, Router or ProxySQL bootstrap, monitoring and alerting wired before cutover rather than after. Ends when a failover test has been run and the result recorded.

4

Live cutover

Cutover

Live replication from the existing source so the old primary stays available until you switch. Ends when traffic is served by the cluster and the rollback step has been left in place, not removed.

5

Your choice

Handover, or ongoing cover

Runbooks, build scripts and the DR procedure handed over so your team can operate it. Or we keep the pager, with under-15-minute incident response, 24/7. Ends when you can answer “what do we do when the primary fails” without calling us: whether or not you still can.

Proof

Support that shows up in the metrics

Published Mydbops engagements on MySQL high availability: failover, recovery and the proxy layer, not borrowed proof from another database.

Fintech · MySQL RDS · Scalability & performance

Near-zero downtime with automatic failover and optimised routing

3×

Faster query execution

60%

CPU on the primary, after read offloading

80%

Less manual intervention at failover

A high-availability and performance rebuild on MySQL RDS: automatic failover, read traffic offloaded through an optimised routing layer, and manual work at failover cut sharply.

Read full case study →

MySQL RDS · Route53 + Multi-AZ · HA

Availability held through failover testing on Route53 and Multi-AZ

100%

Availability maintained during failover testing

3×

Faster query execution

90%

Table size reduced through archival

The failover-tested phrasing is the point: availability was maintained even while failover was being exercised, with CPU driven from above 60% to below 20% after traffic distribution.

Read full case study →

InnoDB engine recovery · Incident

Millions in revenue safeguarded after a catastrophic InnoDB engine corruption

0

Dropped transactions

6.56 TB

Restored from corruption

1200×

Load reduction on recovery

Zero billing duplicates or data loss on the final merge. The only InnoDB-engine incident record in the portfolio, and it belongs beside the rescue work above.

“When we faced a MySQL corruption issue, Mydbops team responded promptly and demonstrated exceptional commitment by working during odd hours. The database was fully recovered which was very critical for our customer's operations.”Ashish Pandya · Associate Manager, Service DevOps · Ecosmob Technologies

Read full case study →

Razorpay · Zero-downtime migration

A secure data layer with zero downtime and room to grow

0

Downtime during migration

10×

Scalability headroom

Full

Migration to an encrypted environment

Zero-downtime migration with proxy routing, ten times the scalability headroom, and a move to a fully encrypted environment.

Read full case study →

Mydbops has been instrumental in enhancing the stability and disaster recovery of our critical services, supporting over 100,000 customers across Spain and Europe. They've ensured smooth 24/7 operations despite massive transaction volumes and high concurrency.

Teresa Product Owner of Hosting and Email, CDMON

Mydbops team did a very detailed and thorough analysis of all MySQL DB clusters and came up with phased recommendations. Impressed by documentation they did for the whole process and seamless execution without any production impact.

Shital Mehta Chief Architect, Ola

A delivery cadence we can rely on: monthly optimisation reports, query tuning, and automated backups: consistent operational discipline rather than one-off fixes.

Henry Suryawirawan VP of Engineering, Flip

Mydbops really helped us scale 20X times in very short span. They are really good at Database Optimization, Security and Maintenance. Above all, their attitude towards owning up client’s problems and treating them like theirs is absolutely mind blowing. Highly recommended.

Abhishek Ravi CIO, Dream11

The work behind this page

We have been writing about InnoDB Cluster in public for years

In more detail than a service page has room for. If you want to see how we think before you talk to us, start here.

Build & cutover

Running InnoDB Cluster in production, or about to? We design, build and rescue these clusters for a living, and we test the failover before you depend on it. Talk to a MySQL HA engineer →

Questions we get asked

InnoDB Cluster consulting, answered

MySQL InnoDB Cluster is Oracle's high availability solution for MySQL, built on Group Replication with MySQL Router as the routing layer, managed through the MySQL Shell AdminAPI. It is the right choice when you need automatic failover with architectural control and portability across clouds or on-premises: and you have, or will have, the operational cover to run it. When a managed service or an InnoDB ReplicaSet fits your situation better, we will tell you that in week one.

Oracle's fault-tolerance formula is n = 2f + 1. Three members tolerate one failure, five tolerate two, and a two-member group tolerates none at all. Members also need low enough round-trip latency between them for group consensus to stay healthy, which we validate before committing to a layout.

We set the target during the assessment and prove it with a failover test before production. Within a single cluster, Group Replication commits by consensus, so a clean automatic failover does not lose committed transactions. Across a ClusterSet link the replication is asynchronous, so the recovery point objective is not zero: we measure it on your workload rather than publish a headline number.

We deploy both, and the workload decides. MySQL Router is the native, metadata-aware option with the fewest moving parts and is best deployed on the application servers. ProxySQL is the choice when you need query-level routing rules, connection multiplexing across a large client fleet, query rewriting or mirroring, or a proxy tier with its own clustering. In either case the proxy layer needs its own high availability: a cluster with automatic failover behind a proxy with none is not a highly available system.

Yes if it is centralised, and Oracle's own community manager says so. The fix is to co-locate Router on the application tier, or to build proper redundancy for the proxy layer with health checking that fails over as fast as the database does. This is exactly the part we handle rather than leave to you.

We state the floor for the features you are actually using and map the upgrade path from where you are. InnoDB Cluster, Group Replication and MySQL Router each have minimum versions for specific capabilities, and 8.4 LTS is the current long-term-support line most teams target. The assessment names the exact version requirement for your topology.

Yes. The widely repeated claim that cluster-to-cluster replication “is not supported and does not work” was true before ClusterSet and is now out of date. ClusterSet replicates a primary InnoDB Cluster to a read-only replica cluster in another region. The link is asynchronous, so the recovery point objective across it is not zero, and promoting the replica is a controlled decision a person makes.

Under-15-minute incident response, 24/7, with a named escalation path and a war-room path for severity-one events. The full severity matrix is agreed with your team during onboarding.

Yes, and handover is the default. You keep the artefacts: build scripts, runbooks, the DR procedure and the recorded failover test. Ongoing cover is the option, not the obligation. It ends when you can answer “what do we do when the primary fails” without calling us.

Yes: troubleshooting existing InnoDB Clusters is a large part of what we do. Clusters that show every member OFFLINE, that report they are not tolerant to any failures, that have split-brained or lost quorum, or that fail over cleanly while the application does not recover are all recoverable. We start with a read-only assessment that gives you the diagnosis and the fix plan whether or not you go on to have us do the work.

It depends on what you are asking for, and we would rather scope it honestly than quote a number that will not hold. The assessment is what determines the shape of the work: a rescue is not a green-field build, and a handover is not a retainer. Tell us your topology and what is happening, and the first reply will be about scope, not a generic price.

They solve a different problem. Vitess and PlanetScale are a sharding-and-proxy model built for horizontal write scale-out; InnoDB Cluster is a consensus-replication model built for high availability on a single logical dataset. If your constraint is availability and failover, InnoDB Cluster is the closer fit; if it is sharded write throughput beyond one primary, that is a different conversation and we will say so.

Talk to a MySQL HA engineer

Tell us which of these you are, and the right engineer picks it up

If your cluster is downwe treat it as an incident and respond within 15 minutes.

You keep the diagnosis either waythe read-only assessment gives you a fix plan whether or not we do the work.

Certified MySQL DBAsISO 27001, AWS Advanced Tier Partner, PCI DSS Attestation of Compliance.

24x7 MySQL HA Consulting

Connect with a MySQL HA Engineer

Whether your cluster is down right now, flaking under production traffic, or you are deciding between InnoDB Cluster and another architecture, our DBAs review your setup directly.

Talk to a MySQL HA engineer →

Under-15-minute response for incidents · No commitment required

MySQL high availability, designed and proven before it goes live

Is InnoDB Cluster the right choice, or is something else?

The topologies we design, to scale

Every engagement ends with artefacts you own and can act on without us

Architecture & topology design

Build & cutover

Routing layer

Disaster recovery with ClusterSet

Kubernetes

Not sure which of these you need?

What failover actually looks like, and what we commit to

Already have a cluster, and it does not behave?

Every node shows OFFLINE and nothing is serving

“Cluster is NOT tolerant to any failures”

Split-brain, or a partition that lost quorum

Failover happens, but the application does not recover

Intermittent connection errors, nothing wrong server-side

An upgrade broke it

MySQL Router or ProxySQL, and how we make the proxy layer itself highly available

We deploy MySQL Router when

We deploy ProxySQL when

And in either case we solve the part most people skip

Five steps, each with an owner and an exit condition

Assessment

Design

Build

Cutover

Handover, or ongoing cover

Support that shows up in the metrics

Near-zero downtime with automatic failover and optimised routing

Availability held through failover testing on Route53 and Multi-AZ

Millions in revenue safeguarded after a catastrophic InnoDB engine corruption

A secure data layer with zero downtime and room to grow

We have been writing about InnoDB Cluster in public for years

How to set up an InnoDB Cluster using MySQL Shell

MySQL replication options: native vs InnoDB Cluster

MySQL Group Replication recovery

Transparent read/write splitting with MySQL Router 8.2

Mastering MySQL Group Replication primary-promotion techniques

Observability in Group Replication with Performance Schema

InnoDB Cluster consulting, answered

Tell us which of these you are, and the right engineer picks it up

Connect with a MySQL HA Engineer