RUK-COM / MANAGED DATABASE CLUSTERS

Keep data moving.
Keep business running.

Database clusters for critical enterprise systems. Purposeful replication, failover and recovery, with Ruk-Com expertise from architecture design to real recovery.

Explore cluster architectures Talk to a database expert
HA + Recovery Expert Support SQL · NoSQL · K8s

HIGHLIGHT / CLOUDNATIVEPG

PostgreSQL on Kubernetes with CloudNativePG

CNCF CloudNativePG CNCF Sandbox Project Explore architecture & simulate failover
8 Database engines
16 Cluster architectures
4 Interactive lifecycle states
K8s CloudNativePG solution
+

KUBERNETES + CLOUDNATIVEPG

PostgreSQL on Kubernetes.
Designed for production.

Our recommended approach for teams managing PostgreSQL through the Kubernetes API. CloudNativePG handles cluster lifecycle, streaming replication and failover while keeping the PostgreSQL data path clear.

CLUSTER / ARCHITECTURE LAB
Show paths

Kubernetes + CloudNativePG

PostgreSQL on Kubernetes with distinct write/read services and WAL replication. The operator manages lifecycle and failover; optional PgBouncer pools connections, while dedicated PVCs, backups and PITR have separate roles.

Architecture simulation
Application Choose Read / Write endpoint
Ready
Kubernetes API Cluster CRD · primary Lease
Ready
PgBouncer Pooler Optional · HA connection pool
Ready
CloudNativePG Operator Reconcile · health · roles
Ready
cluster-rw Service → current Primary
Ready
cluster-ro Service → Ready replicas
Ready
Primary · Pod 1 Worker A · Read / Write
Ready
Replica A · Pod 2 Worker B · Read-only
Ready
Replica B · Pod 3 Worker C · Read-only
Ready
PVC 1 Dedicated persistent volume
Ready
PVC 2 Dedicated persistent volume
Ready
PVC 3 Dedicated persistent volume
Ready
Barman Cloud sidecar Inside Primary Pod · logical detail
Ready
Object Storage Base backups + WAL archive
Ready
New recovery cluster PITR workflow · on demand
Ready
Write request Read result Replication Monitor / Control Recovery / Sync PVC attachment

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Writes use PgBouncer → cluster-rw → primary. Replica read results return through cluster-ro. The primary streams WAL directly to replicas, and each Pod has its own PVC.

Architecture details and reference

Optional PgBouncer sits before cluster-rw. cluster-ro selects replicas; cluster-r (not drawn) allows reads from every instance. Operator/API form the control plane, not a SQL path. PITR creates a separate new cluster rather than performing failover. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Barman is shown separately as a logical stage for readability; it runs as a sidecar inside the current primary Pod selected as backup source in this example, not on a separate backup server.

Source documentation ↗
Connections in this state
  • Application → PgBouncer Pooler · Write request
  • PgBouncer Pooler → cluster-rw · Write request
  • cluster-rw → Primary · Pod 1 · Write request
  • Primary · Pod 1 → cluster-rw · Read result
  • cluster-rw → PgBouncer Pooler · Read result
  • PgBouncer Pooler → Application · Read result
  • cluster-ro → Application · Read result
  • CloudNativePG Operator → Kubernetes API · Reconcile Cluster / Lease
  • CloudNativePG Operator → cluster-rw · Follow elected primary
  • CloudNativePG Operator → cluster-ro · Ready replica membership
  • Replica A · Pod 2 → cluster-ro · Read result
  • Primary · Pod 1 → Replica A · Pod 2 · WAL streaming
  • Replica B · Pod 3 → cluster-ro · Read result
  • Primary · Pod 1 → Replica B · Pod 3 · WAL streaming
  • Primary · Pod 1 → PVC 1 · Dedicated PVC mount
  • Replica A · Pod 2 → PVC 2 · Dedicated PVC mount
  • Replica B · Pod 3 → PVC 3 · Dedicated PVC mount
  • Primary · Pod 1 → Barman Cloud sidecar · Base backup / WAL source
  • Barman Cloud sidecar → Object Storage · Backup + WAL archive
  • Object Storage → New recovery cluster · PITR · restore into new cluster

The operator manages.
SQL flows to the database.

Clients write through cluster-rw and read replicas through cluster-ro. cluster-r reads across all ready instances. Choose an endpoint for your freshness needs; add PgBouncer when connection pooling is required.

Backup + WAL.
Recover into a new cluster.

Use the Barman Cloud plugin for base backups and WAL archiving to object storage. Perform PITR into a new cluster and validate the data before moving clients.

Connect to Ruk-Com Object Storage →
01 Select recovery point 02 Restore base backup 03 Replay WAL 04 Validate new cluster

PRODUCTION CHECKLIST

Best practices for PostgreSQL on K8s

Separate failure domains

Spread instances across workers with anti-affinity and across zones where supported. Reserve capacity for recovery.

A PVC for every instance

Validate IOPS, latency, WAL headroom and CSI expansion support. Each instance maintains its own data volume.

Match sync policy to RPO

Async offers flexibility. Synchronous replication and failover quorum involve latency and availability trade-offs.

TLS + NetworkPolicy

Apply least privilege and manage secrets and certificates separately from database backups.

Monitor WAL and backups

Use metrics and logs to track lag, retained WAL, archiving and backups, with actionable alerts and runbooks.

Rehearse before production

Test switchover, restoration and reconnection. Set resource requests and PDBs; PDBs do not prevent hardware failures.

PITR requires a usable base backup, continuous WAL to the target, and accessible credentials and keys. A sync policy is not a universal zero-data-loss guarantee.

CloudNativePG Documentation ↗ Ruk-Com Managed Kubernetes →

CHOOSE YOUR DATABASE

Different engines. Different paths to resilience.

Choose an engine and mode. Simulate a failure, role change and rejoin, with separate client, replication and recovery paths.

MySQL

MariaDB

Percona

PostgreSQL

MongoDB

Redis

Couchbase

OpenSearch

CLUSTER / ARCHITECTURE LAB
Show paths

MySQL Primary–Primary

Clients send SQL through two ProxySQL nodes. Both primaries accept writes and exchange binary logs; extra secondaries serve reads.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Both existing primaries serve writes; ProxySQL routes reads and writes while binary logs replicate.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

MySQL Primary–Secondary

SQL passes through two ProxySQL nodes. One primary handles writes; secondaries can handle reads. ProxySQL health routing does not provide automatic primary promotion.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

One primary handles writes and asynchronously replicates binary logs to the secondaries. ProxySQL distributes read traffic.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

MariaDB Primary–Primary

Clients send SQL through two ProxySQL nodes. Both primaries accept writes and exchange binary logs; extra secondaries serve reads.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Both existing primaries serve writes; ProxySQL routes reads and writes while binary logs replicate.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

MariaDB Primary–Secondary

SQL passes through two ProxySQL nodes. One primary handles writes; secondaries can handle reads. ProxySQL health routing does not provide automatic primary promotion.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

One primary handles writes and asynchronously replicates binary logs to the secondaries. ProxySQL distributes read traffic.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

MariaDB Galera

Clients use two ProxySQL nodes to reach writable database peers. Write-set certification coordinates changes within the component that retains quorum.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Certified write sets
Ready
Primary 2 Certified write sets
Ready
Primary 3 Certified write sets
Ready
Primary 4 Certified write sets
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

All four illustrated members participate, including the optional extra peer. Write sets replicate among writable peers.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools. Replication lanes represent group writeset exchange, not chained replication.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • ProxySQL 1 → Primary 3 · Write request
  • Primary 3 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 4 · Write request
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • ProxySQL 2 → Primary 3 · Write request
  • ProxySQL 2 → Primary 4 · Write request
  • Primary 4 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Group writesets
  • Primary 2 → Primary 1 · Group writesets
  • Primary 2 → Primary 3 · Group writesets
  • Primary 3 → Primary 2 · Group writesets
  • Primary 3 → Primary 4 · Group writesets
  • Primary 4 → Primary 3 · Group writesets

Percona Primary–Primary

Clients send SQL through two ProxySQL nodes. Both primaries accept writes and exchange binary logs; extra secondaries serve reads.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Read / Write
Ready
Primary 2 Read / Write
Ready
Extra Replica 1 Read-only
Ready
Extra Replica 2 Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Both existing primaries serve writes; ProxySQL routes reads and writes while binary logs replicate.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • Extra Replica 1 → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • Extra Replica 2 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Binlog
  • Primary 2 → Primary 1 · Binlog
  • Primary 1 → Extra Replica 1 · Binlog
  • Primary 2 → Extra Replica 2 · Binlog

Percona Primary–Secondary

SQL passes through two ProxySQL nodes. One primary handles writes; secondaries can handle reads. ProxySQL health routing does not provide automatic primary promotion.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

One primary handles writes and asynchronously replicates binary logs to the secondaries. ProxySQL distributes read traffic.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary · Write request
  • Primary → ProxySQL 1 · Read result
  • Extra Replica → ProxySQL 1 · Read result
  • ProxySQL 2 → Primary · Write request
  • Secondary → ProxySQL 2 · Read result
  • Primary → Secondary · Binlog
  • Primary → Extra Replica · Binlog

Percona XtraDB

Clients use two ProxySQL nodes to reach writable database peers. Write-set certification coordinates changes within the component that retains quorum.

Architecture simulation
Database Client Read / Write
Ready
ProxySQL 1 Query routing
Ready
ProxySQL 2 Query routing
Ready
Primary 1 Certified write sets
Ready
Primary 2 Certified write sets
Ready
Primary 3 Certified write sets
Ready
Primary 4 Certified write sets
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

All four illustrated members participate, including the optional extra peer. Write sets replicate among writable peers.

Architecture details and reference

Two default ProxySQL nodes. Dashed extra nodes are active in this expanded example; illustrated counts are not deployment minima. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control. Read lanes are representative; both proxies share the same role-based backend pools. Replication lanes represent group writeset exchange, not chained replication.

Source documentation ↗
Connections in this state
  • Database Client → ProxySQL 1 · Write request
  • ProxySQL 1 → Database Client · Read result
  • Database Client → ProxySQL 2 · Write request
  • ProxySQL 2 → Database Client · Read result
  • ProxySQL 1 → Primary 1 · Write request
  • Primary 1 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 2 · Write request
  • ProxySQL 1 → Primary 3 · Write request
  • Primary 3 → ProxySQL 1 · Read result
  • ProxySQL 1 → Primary 4 · Write request
  • ProxySQL 2 → Primary 1 · Write request
  • ProxySQL 2 → Primary 2 · Write request
  • Primary 2 → ProxySQL 2 · Read result
  • ProxySQL 2 → Primary 3 · Write request
  • ProxySQL 2 → Primary 4 · Write request
  • Primary 4 → ProxySQL 2 · Read result
  • Primary 1 → Primary 2 · Group writesets
  • Primary 2 → Primary 1 · Group writesets
  • Primary 2 → Primary 3 · Group writesets
  • Primary 3 → Primary 2 · Group writesets
  • Primary 3 → Primary 4 · Group writesets
  • Primary 4 → Primary 3 · Group writesets

PostgreSQL Standard

Clients connect directly to PostgreSQL: writes use the primary and configured read connections use secondaries. There is no proxy or automatic failover manager.

Architecture simulation
Database Client Read / Write
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

The primary asynchronously streams WAL to its secondaries. Queries follow node roles; dashed members are enabled expansion examples.

Architecture details and reference

One primary, one secondary and one optional extra secondary. Dashed expansion nodes are enabled in this example. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Database Client → Primary · Write request
  • Primary → Database Client · Read result
  • Secondary → Database Client · Read result
  • Extra Replica → Database Client · Read result
  • Primary → Secondary · WAL
  • Primary → Extra Replica · WAL

PostgreSQL + Pgpool-II

Clients use the active Pgpool-II, coordinated with standby proxies through Watchdog. Writes reach the primary; secondaries serve reads. Pgpool-II monitors database health and manages failover.

Architecture simulation
Database Client Read / Write
Ready
Pgpool Active Read / Write routing
Ready
Pgpool Standby Watchdog
Ready
Pgpool Standby Watchdog
Ready
Primary Read / Write
Ready
Secondary Read-only
Ready
Extra Replica Read-only
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

The primary asynchronously streams WAL to its secondaries. Queries follow node roles; dashed members are enabled expansion examples.

Architecture details and reference

One active and two optional standby Pgpool-II nodes, plus three illustrated database members. WAL replication is asynchronous; this is not Patroni. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Database Client → Pgpool Active · Write request
  • Pgpool Active → Database Client · Read result
  • Pgpool Active → Pgpool Standby · Watchdog
  • Pgpool Standby → Pgpool Active · Watchdog
  • Pgpool Active → Pgpool Standby · Watchdog
  • Pgpool Standby → Pgpool Active · Watchdog
  • Pgpool Active → Primary · Write request
  • Primary → Pgpool Active · Read result
  • Secondary → Pgpool Active · Read result
  • Extra Replica → Pgpool Active · Read result
  • Primary → Secondary · WAL
  • Primary → Extra Replica · WAL
  • Pgpool Active → Primary · Monitor / role check
  • Pgpool Active → Secondary · Monitor / role check
  • Pgpool Active → Extra Replica · Monitor / role check

PostgreSQL HA · Patroni + HAProxy

HAProxy separates primary write and replica read endpoints, with optional per-node PgBouncer pools. Patroni coordinates roles through an etcd quorum; PostgreSQL streams WAL directly between database nodes.

Architecture simulation
Application Read / Write endpoints
Ready
HAProxy / Cloud LB Role-aware SQL routing
Ready
PgBouncer 1 Optional connection pool
Ready
PgBouncer 2 Optional connection pool
Ready
PgBouncer 3 Optional connection pool
Ready
PgBouncer 4 Optional connection pool
Ready
Replica · Node 1 PostgreSQL + Patroni
Ready
Primary · Node 2 PostgreSQL + Patroni
Ready
Replica · Node 3 PostgreSQL + Patroni
Ready
Extra Replica PostgreSQL + Patroni
Ready
etcd 1 DCS · quorum member
Ready
etcd 2 DCS · quorum member
Ready
etcd 3 DCS · quorum member
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Writes follow the leader lock to Node 2; replicas serve read results. PgBouncer pools connections while WAL streams directly from primary to replicas.

Architecture details and reference

Three PostgreSQL nodes plus an optional scale-out replica, with three etcd members. PgBouncer and VIP are optional. HAProxy checks Patroni roles; etcd carries no SQL or WAL. This is separate from CloudNativePG. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Application → HAProxy / Cloud LB · Write request
  • HAProxy / Cloud LB → Application · Read result
  • HAProxy / Cloud LB → PgBouncer 2 · Write request
  • PgBouncer 2 → Primary · Node 2 · Write request
  • Primary · Node 2 → PgBouncer 2 · Read result
  • PgBouncer 2 → HAProxy / Cloud LB · Read result
  • Replica · Node 1 → PgBouncer 1 · Read result
  • PgBouncer 1 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Replica · Node 1 · WAL streaming
  • Replica · Node 3 → PgBouncer 3 · Read result
  • PgBouncer 3 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Replica · Node 3 · WAL streaming
  • Extra Replica → PgBouncer 4 · Read result
  • PgBouncer 4 → HAProxy / Cloud LB · Read result
  • Primary · Node 2 → Extra Replica · WAL streaming
  • HAProxy / Cloud LB → Primary · Node 2 · /primary health
  • Primary · Node 2 → etcd 2 · Patroni · leader / member state
  • HAProxy / Cloud LB → Replica · Node 1 · /replica?lag health
  • Replica · Node 1 → etcd 1 · Patroni · leader / member state
  • HAProxy / Cloud LB → Replica · Node 3 · /replica?lag health
  • Replica · Node 3 → etcd 3 · Patroni · leader / member state
  • HAProxy / Cloud LB → Extra Replica · /replica?lag health
  • Extra Replica → etcd 3 · Patroni · leader / member state
  • etcd 1 → etcd 2 · Raft quorum
  • etcd 2 → etcd 3 · Raft quorum

MongoDB Replica Set

The driver discovers replica-set members and sends writes to the primary. Reads use the primary by default or secondaries according to read preference. No separate proxy is required.

Architecture simulation
MongoDB Driver Replica-set discovery
Ready
Primary Writes
Ready
Secondary 1 Oplog replica
Ready
Secondary 2 Oplog replica
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

The primary records writes in the oplog; secondaries replicate asynchronously. The driver selects destinations by role and read preference.

Architecture details and reference

Three data-bearing members. Elections require a voting majority; election timing is not an SLA, and secondary reads may lag. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • MongoDB Driver → Primary · Write request
  • Primary → MongoDB Driver · Read result
  • Secondary 1 → MongoDB Driver · Read result · secondaryPreferred
  • Secondary 2 → MongoDB Driver · Read result · secondaryPreferred
  • Primary → Secondary 1 · Oplog
  • Primary → Secondary 2 · Oplog
  • Secondary 1 → Secondary 2 · Heartbeat / voting

Redis Cluster

A cluster-aware client sends commands directly to the primary owning each hash slot. Each primary has one replica. This topology has no proxy or Sentinel.

Architecture simulation
Cluster Client Hash-slot routing
Ready
Primary 1 Shard 1
Ready
Replica 1 Shard 1 copy
Ready
Primary 2 Shard 2
Ready
Replica 2 Shard 2 copy
Ready
Primary 3 Shard 3
Ready
Replica 3 Shard 3 copy
Ready
Write request Read result Replication Monitor / Control Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Three shards divide the hash slots. Each primary handles its slots and asynchronously replicates to its paired replica.

Architecture details and reference

Three primaries and three replicas: six nodes. Scaling adds pairs and reshards; asynchronous replication can lose some writes during failover. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Cluster Client → Primary 1 · Write request
  • Primary 1 → Cluster Client · Read result
  • Primary 1 → Replica 1 · Async replication
  • Cluster Client → Primary 2 · Write request
  • Primary 2 → Cluster Client · Read result
  • Primary 2 → Replica 2 · Async replication
  • Cluster Client → Primary 3 · Write request
  • Primary 3 → Cluster Client · Read result
  • Primary 3 → Replica 3 · Async replication

Couchbase Cluster

The SDK routes directly using the vBucket map. Nodes hold active and replica vBuckets. Scaling redistributes data through rebalance; there is no separate query proxy.

Architecture simulation
Couchbase SDK vBucket routing
Ready
Couchbase 1 Active + replica vBuckets
Ready
Couchbase 2 Active + replica vBuckets
Ready
Couchbase 3 Active + replica vBuckets
Ready
Couchbase 4 Active + replica vBuckets
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

The SDK follows the vBucket map; replica partitions live on other members. Arrows illustrate partition placement, not full-database copies on every node.

Architecture details and reference

The source illustrates two solid and two dashed nodes to show expansion, not a two-node deployment baseline. The package defaults to three; this example activates all four. Configure replicas and failover appropriately. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Couchbase SDK → Couchbase 1 · Write request
  • Couchbase 1 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 2 · Write request
  • Couchbase 2 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 3 · Write request
  • Couchbase 3 → Couchbase SDK · Read result
  • Couchbase SDK → Couchbase 4 · Write request
  • Couchbase 4 → Couchbase SDK · Read result
  • Couchbase 1 → Couchbase 2 · vBuckets
  • Couchbase 2 → Couchbase 3 · vBuckets
  • Couchbase 3 → Couchbase 4 · vBuckets
  • Couchbase 4 → Couchbase 1 · vBuckets

OpenSearch Cluster

Beats sends data through Logstash into OpenSearch; Dashboards queries and visualizes it. This example expands OpenSearch into three nodes to explain shard recovery, not a package minimum.

Architecture simulation
Beats Data shippers
Ready
Logstash Transform / ingest
Ready
Dashboards Search / visualize
Ready
OpenSearch 1 Shard A primary
Ready
OpenSearch 2 Shard A replica
Ready
OpenSearch 3 Other shards
Ready
Write request Read result Replication Recovery / Sync

Write shows requests entering the database. Read shows results returning to clients; SELECT requests travel in the opposite direction.

Logstash ingests and Dashboards searches. Shard A has a primary on node 1 and replica on node 2; node 3 holds other shards.

Architecture details and reference

Reference flow: Beats → Logstash → OpenSearch ← Dashboards. Logstash and Dashboards are optional. Shard A placement is illustrative, not a global database writer. Red carries write requests into the database; green carries read results back to the client (SELECT requests travel in the opposite direction). Amber is replication; dashed blue is monitoring/control.

Source documentation ↗
Connections in this state
  • Beats → Logstash · Ingest events
  • Logstash → OpenSearch 1 · Index documents
  • Logstash → OpenSearch 3 · Index documents
  • OpenSearch 1 → Dashboards · Search result
  • OpenSearch 2 → Dashboards · Search result
  • OpenSearch 3 → Dashboards · Search result
  • OpenSearch 1 → OpenSearch 2 · Shard A replica

Automatic failover depends on topology, quorum and configuration. MySQL / MariaDB / Percona primary–secondary and standard PostgreSQL require operator-led promotion and routing changes.

AVAILABILITY + RECOVERABILITY

Protect availability.
Prepare for recovery.

Replication maintains live copies. Backups provide recovery points before deletion or unwanted changes. Enterprise protection needs both.

Replication matched to workload

Choose asynchronous, streaming or quorum-based replication according to engine, latency, consistency and RPO needs.

Failover with clear conditions

Validate the candidate, quorum and former-primary isolation before routing writes. Test client reconnection and retry behavior.

Recovery you can validate

Define retention, recovery points and restore drills. Keep backups separate from the cluster and verify restored data is usable.

REJOIN ≠ READY

Node returns → Check timeline / logs → Catch up or rebuild → Validate readiness → Restore traffic

RUK-COM / DATABASE OPERATIONS

Beyond cluster deployment.
Expertise across the data lifecycle.

Align service scope and SLA with system criticality, from performance through incident response and recovery planning.

Performance & observability

Track query latency, connections, replication lag, slow queries, storage and backup results to identify problems early.

Capacity & scaling

Plan read replicas, connection pools and storage growth for each engine, accounting for IOPS, WAL / binlog and recovery headroom.

Security by design

Design private connectivity, TLS and role-based privileges, with secrets, patching and audit practices aligned to your policies.

Expert incident support

Specialists investigate client connections, queries, proxies, replication and the underlying infrastructure.

Maintenance & recovery drills

Test switchover, failover, restore and rollback before production changes, with reusable runbooks and recorded results.

Ruk-Com Agent + specialists

Agent assistance summarizes anomalies and prioritizes investigation. Access and system changes follow agreed permissions and procedures.

ASSESS / MIGRATE / OPERATE

A planned migration.
A clear operating model.

01

Assess

Review engine, version, size, extensions and RPO / RTO.

DELIVERABLE Scope & system targets
02

Design & rehearse

Select the topology and rehearse with authorized data.

DELIVERABLE Architecture & test plan
03

Sync & cutover

Validate data, define write freeze and rollback for the migration method.

DELIVERABLE Validation & rollback plan
04

Operate & improve

Hand over runbooks, monitoring, backup and capacity plans.

DELIVERABLE Runbook & operations plan

BEFORE YOU DEPLOY

Before you deploy
a database cluster.

Do I still need backups with HA?

Yes. Deletion or unwanted changes can replicate to every copy. Maintain separate backups, suitable retention and regular restore tests.

Does every mode promote a primary automatically?

No. Some modes depend on quorum and health detection; others require manual promotion, notably the referenced MySQL-family primary–secondary and standard PostgreSQL modes.

Can a rejoining node serve traffic immediately?

Validate consistency and catch-up first. Recovery may use binlogs, WAL, oplog, IST / SST or a rebuild, depending on the engine and retained history.

What RPO / RTO can I expect?

Define and test each system against the standard 99.9% SLA using its sync policy, data size, networking, backups and recovery methods, with scope and exclusions stated clearly.

What should I prepare?

Provide engine/version, data size, read/write workload, peak connections, extensions, security requirements and a migration window.

YOUR DATA / OUR EXPERTISE

Start with your critical data.
Build the right cluster together.

Discuss architecture, migration and managed service scope with Ruk-Com.

Discuss your database solution