Build a MariaDB environment for database redundancy, High Availability, read scaling or geographic disaster recovery using an architecture selected for your workload.
↔ certification-based 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 mainly need additional copies of your database?
Should the database continue operating when a database node becomes unavailable?
Do you need additional database nodes to handle read traffic?
Should applications connect through a database-aware routing layer rather than individual database nodes?
Do you need a second geographic region for recovery from a regional outage?
MariaDB provides different technologies for different goals. We help select the appropriate architecture instead of placing every workload into the same cluster design.
Share Your RequirementsBest for: Replication · Read Scaling · Redundancy · DR
The Primary handles writes while one or more Replicas receive and apply database changes. A basic environment may use 1 Primary + 1 Replica; a stronger production design can use 1 Primary + 2 Replicas. Replication may be asynchronous or semi-synchronous depending on the required design.
Standard Primary/Replica replication alone does not automatically promote a Replica after Primary failure. Automatic failover requires an appropriate failover/routing solution such as MaxScale when configured for that purpose.
3 Full Database Nodes · Best for: Same-Region High Availability
Galera provides a multi-primary MariaDB cluster using certification-based, virtually synchronous replication — not ordinary asynchronous replication. All three nodes contain database data, participate in cluster quorum, can be writable, and participate in replication.
Typical starting topology: 3 Galera Nodes (larger: 5). With 3 nodes, a majority of 2 is required — one node can fail while quorum remains.
Common architecture: 3 Galera Nodes + 2 MaxScale Instances · Best for: Production HA + Intelligent Routing
Applications connect through MaxScale rather than needing to track individual database nodes. MaxScale can monitor the Galera topology and route connections to appropriate healthy synchronized members. Galera provides the database clustering and quorum; MaxScale provides the routing and monitoring layer.
MaxScale is not a Galera database node, does not store database data and does not participate in Galera quorum.
↓ Asynchronous WAN Replication ↓
DR RegionBest for: Geographic Disaster Recovery
Instead of stretching one Galera cluster across distant regions, a local Galera cluster can asynchronously replicate to a separate MariaDB server or another Galera cluster in a DR region — local traffic avoids WAN latency, and each Galera cluster maintains its own local quorum.
Cross-region replication is asynchronous, so the DR copy can lag behind the primary region. Regional DR promotion is an administrator-controlled recovery process, not automatic Galera failover between regions.
| Requirement | Typical Architecture |
|---|---|
| Basic replication | Primary + Replica |
| Read scaling | Primary + Multiple Replicas |
| Same-region HA | 3-Node Galera |
| HA + database-aware routing | Galera + MaxScale |
| Higher Galera redundancy | 5-Node Galera |
| Remote DR copy | Primary/Galera → Remote Replica |
| HA in primary + DR region | Galera → Galera Hybrid Replication |
| Special requirements | Custom architecture review |
These are reference architectures, not fixed packages. Final topology depends on workload, consistency requirements, latency, failover expectations and recovery objectives.
Good for: database-node failure tolerance, lower inter-node latency, local quorum, database-aware traffic routing.
Within the same region, database nodes can use appropriate private networking where supported by the deployment design.
Stretching Galera directly across geographically distant locations is technically possible, but WAN latency can directly affect transaction commit performance. For distant regions, Hybrid Replication can keep the main Galera cluster local while maintaining a remote DR copy.
For MariaDB deployments 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. The same private cloud network does not automatically extend between different regions.
Keep additional copies of the database.
Primary → Replica. Useful for redundancy, read scaling and DR.
Keep database services available through node failures.
Galera + appropriate routing. Useful for production HA.
Maintain database copies in another geographic location.
Primary Region → Remote Region. Useful for regional recovery.
Replication = Copy · Galera = Local HA · Hybrid Replication = Geographic DR
We review your workload and database criteria before recommending an architecture:
Pricing depends on the number and size of database nodes, MaxScale instances where required, storage, network architecture 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 replication, Galera High Availability, intelligent routing or geographic disaster recovery, we'll help design an appropriate MariaDB architecture.
Custom MariaDB 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.
