From simple Primary/Replica replication to automatic InnoDB Cluster failover and multi-region ClusterSet architectures, we can design a MySQL environment around your application's requirements.
↔ Group Replication ↔
Illustrative example — actual topology depends on your requirements.
Exp. in Hosting Business
Cloud Deployments
Data Centers
Pay As You Go Pricing
Ticket Response Time
| Plan | vCPU | RAM | Hourly Price | Monthly Price | |
|---|---|---|---|---|---|
Popular | PROMO PRICE | Get StartedGet Started |
Third-party names and marks belong to their respective owners and are shown for identification only.
Pricing comparison based on equivalent configurations as of 1 August 2026.
Do you need a secondary copy of your database for redundancy or read workloads?
Should another database member take over automatically if the current Primary becomes unavailable?
Is the application primarily read-heavy, write-heavy or mixed?
Do you need another region or datacenter for disaster recovery?
How many database-node failures should the architecture be designed to tolerate?
Different MySQL architectures solve different problems. We help choose the appropriate topology rather than forcing every database into one fixed cluster package.
Share Your Requirementsoptional: additional replica
Best for: Simple Replication · Read Scaling · DR
InnoDB ReplicaSet uses asynchronous Primary/Replica replication and is a straightforward architecture for maintaining additional database copies. Typical starting configuration: 1 Primary + 1 Secondary. Additional replicas can be added where more redundancy or read capacity is required.
ReplicaSet does not provide Group Replication quorum or automatic Primary election. If the Primary fails, failover is administrator-controlled.
↔ Group Replication ↔
Optional: Application → MySQL Router → Cluster
3 Full MySQL Members · Best for: Production High Availability
InnoDB Cluster uses MySQL Group Replication. A common configuration is 1 Primary + 2 Secondary members — all three nodes are full MySQL database members containing data and participating in Group Replication. If the Primary fails and the group retains the required majority, another eligible member can become the new Primary. MySQL Router can direct application connections to the appropriate cluster member.
The third member is not a witness or arbiter. It is a full database member.
Best for: Workloads Designed for Multi-Master Writes
MySQL Group Replication can also operate in Multi-Primary mode, where compatible members can accept writes. Multi-Primary is available for workloads designed to operate safely with multiple writable database members — it is not automatically better than Single-Primary.
Application design, transaction conflicts and workload behavior should be reviewed before recommending Multi-Primary.
Discuss Multi-Primary MySQL↓ Asynchronous Cross-Cluster Replication ↓
DR RegionBest for: Geographic Disaster Recovery
InnoDB ClusterSet connects multiple InnoDB Clusters so a Primary Cluster can replicate to one or more Replica Clusters. A strong HA/DR topology: Region A — 3-node Primary Cluster; Region B — 3-node Replica Cluster. The Primary Cluster handles read/write operations while Replica Clusters are read-only under the normal ClusterSet model.
Replication between clusters is asynchronous, and emergency cross-cluster failover is administrator-controlled — this is not automatic active-active multi-region MySQL.
| Requirement | Typical Architecture |
|---|---|
| Simple database replication | InnoDB ReplicaSet |
| Read replicas | ReplicaSet |
| Automatic same-region HA | InnoDB Cluster Single-Primary |
| Application-aware routing | InnoDB Cluster + MySQL Router |
| Multiple writable members | InnoDB Cluster Multi-Primary |
| Multi-region DR | InnoDB ClusterSet |
| Specialized distributed MySQL workload | NDB Cluster |
| Custom requirements | Architecture Review |
These are common reference architectures, not fixed packages. Final topology depends on workload, latency, fault tolerance and recovery requirements.
Good for: automatic Primary election, database-node redundancy, lower inter-node network latency, local high availability, application routing.
Group Replication performs best when cluster members have reliable, low-latency connectivity. Within the same AccuWeb.Cloud region, database communication can use appropriate private networking where supported by the deployment design.
Rather than stretching one Group Replication cluster across distant regions, ClusterSet can use a local Primary Cluster and asynchronously replicate to a separate Replica Cluster in another location — local cluster HA, a geographic database copy, independent cluster members in each region, and controlled DR switchover/failover.
Because cross-cluster replication is asynchronous, the Replica Cluster may temporarily lag behind the Primary Cluster. For MySQL environments spanning different AccuWeb.Cloud regions or zones, secure inter-region connectivity must be configured separately using an appropriate routed solution such as WireGuard, site-to-site VPN or another supported private-connectivity design — private networks do not automatically span regions.
Keep another database copy.
Primary → Replica. Useful for redundancy, reads and recovery options.
Automatically elect another Primary.
InnoDB Cluster + Group Replication. Useful for database-node failure protection.
Maintain another regional cluster.
Primary Cluster → Replica Cluster. Useful for regional failure scenarios.
ReplicaSet = Replicate · InnoDB Cluster = HA · ClusterSet = Multi-Region DR
MySQL NDB Cluster is a separate distributed database architecture using NDB storage, SQL nodes, data nodes and management nodes. It is different from InnoDB Cluster and is intended for specialized workloads.
We review your workload and database criteria before recommending an architecture:
Pricing depends on the number and size of MySQL nodes, Router instances where required, storage, network design and regions selected.
Pay based on the resources you provision, with flexible hourly billing and no long-term contracts.
Please ask your queries. We are available 24/7
Whether you need simple replication, automatic database failover, multiple writable members or geographic disaster recovery, we'll help plan an appropriate MySQL architecture.
Custom MySQL cluster deployment available on request.
All third-party logos and trademarks displayed on AccuWeb Cloud are the property of their respective owners and are used only for identification purposes. Their use does not imply any endorsement or affiliation.
