High availability databases

A high availability (HA) database runs as three nodes instead of one: a primary that takes writes and two replicas that keep a live copy of the data. If the primary goes down, a replica is promoted automatically and your connection string keeps working. Use HA for production databases where a few minutes of downtime from a node or region failure isn’t acceptable.

​

Availability

​

How it works

Each engine uses its own built-in replication: Every write goes to the primary and is copied to the replicas. When a failed node comes back, it rejoins the cluster as a replica and catches up on its own.

​

Create an HA database

1. Open the dashboard and click New project → Database.
2. Pick PostgreSQL, MySQL or MongoDB and a version from the table above.
3. Choose the primary region.
4. Turn on High availability (3 nodes).
5. Pick Secondary region A and Secondary region B for the two replicas. All three can’t be in the same region.
6. Set CPU, memory and storage. These apply to each node, and memory must be at least 1 GB.
7. Click Provision Service.

HA is chosen when the database is created. You can’t turn an existing single-node database into an HA cluster, or reuse an existing volume for one. To move a single-node database to HA, create a new HA database and restore a backup into it.

​

Connect to an HA database

Use the database’s CONNECTION_STRING (public) or PRIVATE_CONNECTION_STRING (from other Brimble services), the same as a single-node database. The best way is to link the database to your service so the values are wired in for you. The connection string is built so your app always writes to the current primary:

• PostgreSQL lists all three nodes and adds target_session_attrs=read-write, so the driver connects to whichever node is the primary. Your driver must support multiple hosts, for example libpq, psql, psycopg, pgx and the PostgreSQL JDBC driver. Node’s pg package doesn’t support multiple hosts.
• MySQL uses a single host that always points at the current primary. Any MySQL driver works.
• MongoDB lists all three nodes with the replicaSet option. Every official MongoDB driver finds the primary on its own.

During a failover, open connections to the old primary drop. Make sure your app reconnects and retries failed queries. Most connection pools do this by default.

​

TLS and public access

Public access to an HA database requires TLS. If public access is on, TLS is turned on automatically and can’t be turned off. Private connections from other Brimble services don’t need TLS.

​

Monitor the cluster

The database’s overview shows the Replication panel:

• Which node is the Primary and which are Replicas, with the region of each.
• Replication lag, how far the replicas are behind the primary.

After a failover the panel shows the new primary.

​

Resize an HA database

CPU, memory and storage changes apply to all three nodes. Brimble updates the nodes one at a time, replicas first and the primary last, so the cluster stays up throughout. When the primary’s turn comes, Postgres hands the primary role to an updated replica first, and MySQL and MongoDB elect a new primary as the old one restarts. Writes pause briefly while the primary changes.

​

Connection pooling (Postgres)

Turn on PgBouncer when you create the database or later from its connection pooling settings. On an HA database Brimble runs two PgBouncer instances on different nodes, so pooling keeps working if one of them fails. Both always send queries to the current primary. Use POOLED_CONNECTION_STRING (public) or POOLED_PRIVATE_CONNECTION_STRING (from other Brimble services). These are single-host strings, so any Postgres driver works, including Node’s pg.

​

Backups and point-in-time recovery

Backups work the same as on a single-node database and are taken from the current primary. Restoring a backup or point-in-time recovery (Postgres) into a new database keeps the HA setup, so a three-node cluster restores into a three-node cluster.

​

Cost

You’re billed for all three nodes. An HA database costs three times the CPU, memory and storage of a single node with the same size. Connection pooling on an HA database is $4/month for its two PgBouncer instances. The price shown in the create form already includes all of this.

​

Limitations

• Created as HA only. You can’t turn HA on or off after the database is created.
• Exactly three nodes. You can’t add more replicas.
• Writes go to the primary. Replicas aren’t exposed as a separate read-only endpoint.
• MySQL: InnoDB only. Every table needs a primary key, and MyISAM and other non-InnoDB storage engines are blocked. This is required by Group Replication.

​

Troubleshooting

“A high availability cluster needs at least 1 GB of memory per node.” Raise memory to 1 GB or more. “All three nodes can’t be in the same region.” Move at least one replica to a different region. “Choose exactly 2 secondary regions to create a 3-node HA cluster.” Pick a region for both Secondary region A and Secondary region B. “This database image does not support HA.” The engine or version you picked doesn’t support HA. See Availability. “You can’t reuse a volume on a high availability cluster.” HA databases always get new volumes. Create the HA database without a volume, then restore your data into it. The HA toggle is locked. HA needs the Developer or Team plan. Upgrade your plan to turn it on. My app errors for a few seconds and then recovers. That’s a failover. Add reconnect and retry logic so writes during the switch are retried instead of failing.

​

Next steps

• Deploy a database, engines, connection strings and regular backups.
• Point-in-time recovery for Postgres, restore to any second in the last 7 days.
• Regions, pick regions for your nodes.