Free Database Audit: Get a comprehensive health report for your database - no obligation, NDA protected
Learn MoreSchedule AuditIn short: JusDB designs MySQL resilience around observed failure modes: Group Replication or replica behavior, quorum, MySQL Router, application reconnects, post-failure capacity, independent backups, and tested recovery runbooks. Uptime, RTO, and RPO remain contracted objectives supported by drills—not automatic properties of a product name.
A healthy database cluster is not enough. Traffic must reach it, clients must reconnect safely, the remaining nodes must carry the load, and operators must know when automated recovery is unsafe.
These options solve different problems. The design starts with business impact, consistency needs, latency, write patterns, failure domains, and operational constraints.
Group Replication supplies membership, replicated transactions, and primary election; MySQL Router directs application connections. The default single-primary design needs quorum, healthy routing, compatible workloads, and tested client retry behavior.
ClusterSet links a primary InnoDB Cluster to replica clusters in other locations for disaster tolerance. Controlled switchover waits for synchronization; emergency failover can lose unreplicated transactions and requires fencing to manage split-brain risk.
Asynchronous or semisynchronous replication can serve read scaling, migration, and recovery designs. Semisynchronous acknowledgment improves durability relative to asynchronous replication but adds network latency and does not remove every loss or failover scenario.
| Failure mode | Required mechanism | Evidence to verify |
|---|---|---|
| MySQL member failure | Election or promotion, Router health, client reconnects | Quorum and surviving capacity |
| Availability-zone failure | Failure-domain placement and Router redundancy | Network reachability and capacity |
| Primary-region loss | ClusterSet or restore runbook, fencing, GTID review | Replication lag and transaction divergence |
| Operator or application error | Independent backup plus point-in-time recovery | Backup freshness and binary-log retention |
| Bad release or schema change | Change gates, rollback or forward-fix runbook | Compatibility and data-change reversibility |
A controlled ClusterSet switchover verifies synchronization before changing the primary. Oracle states that emergency failover can lose unreplicated or divergent transactions and can create split-brain risk. The runbook must fence the old primary, inspect GTID state, and control routing before recovery.
No architecture alone guarantees an uptime percentage. The objective depends on failure domains, quorum, routing, application retry behavior, capacity after a failure, maintenance practices, monitoring, and tested recovery procedures. Any SLA belongs in the signed service agreement and should be supported by observed failover and recovery evidence.
InnoDB Cluster uses Group Replication for membership and primary election. In the default single-primary mode, a secondary can be promoted when the primary fails, and MySQL Router can direct new connections to the new primary. Successful service recovery still depends on quorum, Router availability, connection handling, capacity, and application retries.
RTO and RPO are design targets, not product defaults. They depend on replication mode and lag, failure detection, promotion or restore steps, data volume, network conditions, routing, and application recovery. ClusterSet emergency failover can lose unreplicated transactions, so targets are contracted only after rehearsal and measured recovery exercises.
Within Group Replication, membership and quorum govern which partition can continue. Cross-cluster disaster recovery needs additional fencing and routing controls: Oracle documents transaction-loss and split-brain risk during ClusterSet emergency failover. The runbook therefore isolates the old primary, verifies GTID state, controls Router policy, and requires an authorized recovery decision.
A staged replica or cluster build can reduce the cutover window, but downtime cannot be promised without measuring the workload and application. Provisioning, synchronization, consistency checks, routing changes, write coordination, and rollback gates are rehearsed first. The agreed maintenance window reflects the evidence from that rehearsal.
Monitoring should cover member state and role, quorum, replication queues and applier errors, transaction lag, Router and connection health, write availability, disk and memory pressure, backup freshness, and recovery-test results. Alert thresholds and escalation paths are tied to the service objectives and the topology's actual failure modes.
No. Replication can copy accidental deletes, corruption, or unwanted application changes to other members. A resilient design keeps independently restorable backups, retains the binary logs needed for the intended point-in-time recovery window, and regularly proves restore procedures against the stated recovery objectives.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed . Cluster, routing, monitoring, failover, and data-loss boundaries are checked against the current Oracle MySQL 8.4 and MySQL Shell documentation.