Tiers and replication
MySQL tiers on Bahriya: single node, a primary with asynchronous read replicas, or Group Replication with automatic failover — and how to choose.
Every MySQL instance has a tier, chosen at creation. The tier decides how many nodes run in each region and what happens when one fails. It cannot be changed later: switching the failover model of a live database is a migration, not a setting. To move tiers, create a new instance and move the data.
single | replicated | ha | |
|---|---|---|---|
| Nodes per region | 1 | 2 or 3 | 3 or 5 |
| Read replicas | — | 1 or 2 | — |
| On primary failure | Restarts from its own disk | No automatic failover | Automatic failover |
| Good for | Development, internal tools, data you can restore | Read-heavy applications | Production systems that must stay writable |
Single
One node. If it fails, it restarts and recovers from its own disk — there is a short outage while it does, and no data loss for committed transactions. The simplest and cheapest shape.
Replicated
A primary plus one or two asynchronous read replicas (replicas = 1 or 2). All writes go to the primary; replicas apply them shortly afterwards and serve reads, so read traffic scales out without touching the primary.
Because replication is asynchronous, a replica can trail the primary by a moment. Send reads that must see a write you just made to the primary; send everything else to the replicas.
There is no automatic failover in this tier. If the primary fails it restarts from its own disk, as in single, while the replicas keep serving reads. A replica that falls behind or loses its data rebuilds itself from the primary automatically.
Highly available
Three or five members running MySQL Group Replication (replicas = 3 or 5, counting the primary). A write is committed only once a majority of the group has it, so losing a member loses no acknowledged data. If the primary fails, the group elects a new one automatically and your application reconnects to the same address.
- 3 members tolerate one failure.
- 5 members tolerate two.
Group Replication requires every table to have a primary key. Tables without one cannot be written in this tier.
Nodes and cost
The node count is derived from the tier and replicas — single is one node, replicated with one read replica is two, ha with three members is three. Every node runs the plan you choose and has its own storage, so the node count is the multiplier on CPU, memory and storage. The console shows the derived node count as you choose. The volume encryption add-on and backup storage are billed per region, not per node. The pricing page lists the current rates and estimates an instance's monthly cost.
Regions are independent
Each region you select runs its own copy of the instance — with the same tier, plan and databases — and its own data. There is no replication between regions. A container connects to the copy in its own region.