High Availability and Cluster Solutions

A database server becomes unreachable sooner or later. What matters is how many seconds the system takes to notice the fault, and whether it fails over automatically.

We build uninterrupted database architectures

Building a cluster is not enough; the failover has to be proven to work. We design the architecture, build it, and verify the failover scenarios by rehearsing them.

Topology design

Synchronous or asynchronous replication, how many nodes, in which data centre. The decisions are taken from your RPO target and the latency budget you accept; no ready-made template is applied.

Quorum and split-brain

A two-node installation cannot reach a decision during a network partition. We design the node count, the voting rights and, where needed, an arbitrator node so the cluster produces a single decision in a partition scenario.

Traffic routing

If the application keeps connecting to the old primary after the failover has completed, the outage is still going on. With ProxySQL, MySQL Router and HAProxy we make the connection layer failover-aware.

Failover rehearsal

An untried failover is a failover assumed to work. With planned rehearsals we measure the failover time and observe the application's reconnection behaviour together with you.

The availability target determines the architecture

Like backup work, high availability work starts not with choosing a tool but with setting a target. The question to ask is this: how many seconds of downtime is acceptable for the system, and can data loss be tolerated during a failover?

Synchronous replication removes data loss; in return it adds network latency to every write. Asynchronous replication preserves write performance, but transactions not yet copied can be lost at the moment of failover. Which of the two is right depends on the business requirement, and the decision concerns the business units before the technical team.

We design the architecture around the agreed targets, not around a ready-made template.

MySQL InnoDB Cluster Consulting and MariaDB Galera Cluster installations

MySQL InnoDB Cluster is an integrated solution built on Group Replication and working together with MySQL Router. Group membership, automatic failover and recovery are managed by MySQL itself; administration is carried out through MySQL Shell. For organisations that want to stay inside the ecosystem it is the lowest-friction option.

Group Replication is the replication layer underneath InnoDB Cluster and can be used on its own. Writes are committed by consensus among the group members, so data consistency is preserved through node failures as well.

Galera Cluster is the multi-master solution used in the MariaDB and Percona XtraDB Cluster distributions. Every node can accept writes, but that flexibility can require conflict handling on the application side. We do not recommend a multi-master topology without examining the application’s write pattern; in many scenarios a Galera installation running with a single write node behaves more predictably.

ProxySQL and MySQL Router make the connection layer failover-aware. The value of a cluster architecture depends on the application being able to find the new primary; without a routing layer the outage continues even after the failover has completed.

PostgreSQL Patroni Cluster Setup and Management

For PostgreSQL we use Patroni. Patroni is a cluster manager that adds automatic failover on top of streaming replication; by holding the cluster state in etcd, Consul or ZooKeeper, it creates a single source of truth about which node is the primary.

The critical component in that installation is the distributed configuration store (DCS) itself: because the cluster decision is produced there, the store has to be highly available too. A Patroni cluster built on a single-node etcd installation does nothing but move the single point of failure from the database to the configuration store.

Connection routing is built with HAProxy connected to Patroni’s health check endpoints, so the application is always directed to the current primary.

Replica sets and sharding on the MongoDB side

High availability in MongoDB is provided by the replica set. The primary election runs automatically among the members; for the election to conclude soundly, the number of voting rights has to be odd. On two-member installations we complete the decision mechanism by adding an arbitrator.

When the data volume exceeds the capacity of a single cluster, sharding comes in. The shard key choice is a decision that is expensive to change later, and a key with a skewed distribution can pile the entire load onto one shard. We make that choice by examining your query patterns.

We verify the architecture we build by rehearsing it

The situation we meet most often in the field is a cluster whose installation is complete but whose failover has never been tried. Tried for the first time during a real fault, a failover mechanism may not behave as expected: the routing layer is not updated, the application connection pool insists on the old node, or the recovery takes longer than expected.

On every architecture we build we run a planned failover rehearsal. During the rehearsal the failover time is measured, the reconnection behaviour on the application side is observed, and the results are reported. The time measured is what the work has contributed to the organisation’s real RTO.

A cluster architecture does not replace backups; the two are designed together: Database Backup and Recovery

Audit logging and encryption configurations have to be applied consistently across every node: Database Security and KVKK Technical Measures

Replication lag and load distribution between nodes are within the scope of performance work: Performance Tuning and Monitoring

Our database support services

On the databases where we build the cluster architecture, we provide the full range of our support and consulting services.

MySQL Support

Performance, clustering, backup and security under one scope, including the move to Percona Server.

PostgreSQL Support

Patroni cluster installation and management, backup with pgBackRest, query and configuration tuning.

MariaDB Support

Galera Cluster installation, version upgrades and operational maintenance.

MongoDB Support

Replica set and sharding installation, monitoring stack and maintenance.

Frequently asked questions

You do. A cluster architecture provides availability against hardware and server failures; it does not protect against data loss. A DROP TABLE run by mistake propagates to every node instantly. High availability and backup solve different problems, and the two have to be designed together. We plan the backup and recovery side separately.

Not directly. A read replica is a scaling solution; for the replica to take over automatically when the primary becomes unreachable, a separate failover mechanism is needed. An unmanaged replica is a server waiting for manual intervention at the moment of a fault. Architectures that meet both needs can be built, but the design has to be made for that from the start.

A two-node installation cannot produce a decision in a network partition scenario: both nodes can assume the other has failed and take the primary role, and the data diverges β€” split-brain. A cluster decision needs three nodes, or two nodes together with an arbitrator. The hardware cost of an arbitrator is low; the cost of divergent data is not.

Transactions in flight are cut off and the application has to reconnect. A short failover time is not enough on its own; the application's connection pool also has to notice the failover and attempt to reconnect. That is why we run the rehearsals together with the application team.

In most scenarios, yes. The new nodes are built as replicas, production is unaffected until the data synchronisation completes, and only a short maintenance window is used for the role change. The length of that outage depends on the existing topology, the data volume and the application's connection behaviour; we do not commit to a figure without an examination.

When did you last test that your failover works?

Let's examine your current topology together, measure the failover time, and set out the split-brain risk if there is one.

Get in touch