We use cookies and other similar technology to collect data to improve your experience on our site, as described in our Privacy Policy.
Run Production-Grade Databases on Kubernetes
Backup and Recovery Solution for Kubernetes
Run Production-Grade Vault on Kubernetes
Secure HAProxy Ingress Controller for Kubernetes
Kubernetes Configuration Syncer
Kubernetes Authentication WebHook Server
KubeDB simplifies Provision, Upgrade, Scaling, Volume Expansion, Monitor, Backup, Restore for various Databases in Kubernetes on any Public & Private Cloud
A complete Kubernetes native disaster recovery solution for backup and restore your volumes and databases in Kubernetes on any public and private clouds.
KubeVault is a Git-Ops ready, production-grade solution for deploying and configuring Hashicorp's Vault on Kubernetes.
Secure HAProxy Ingress Controller for Kubernetes
Kubernetes Configuration Syncer
Kubernetes Authentication WebHook Server
New to KubeDB? Please start here.
In PostgreSQL, multiple servers can work together to serve high availability and load balancing. These servers will be either in Master or Standby mode.
In master mode, server that can modify data. In standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive (see restore_command) or directly from the master over a TCP connection (streaming replication).
Standby servers can be either warm standby or hot standby server.
A standby server that cannot be connected to until it is promoted to a master server is called a warm standby server. Standby servers are by default warm standby unless we make them hot standby.
The following is an example of a Postgres
object which creates PostgreSQL cluster of three servers.
apiVersion: kubedb.com/v1alpha2
kind: Postgres
metadata:
name: warm-postgres
namespace: demo
spec:
version: "13.13"
replicas: 3
standbyMode: Warm
storageType: Ephemeral
In this examples:
Postgres
object creates three PostgreSQL servers, indicated by the replicas
field.spec.standbyMode
A standby server that can accept connections and serves read-only queries is called a hot standby server.
The following Postgres
object will create PostgreSQL cluster with hot standby servers.
apiVersion: kubedb.com/v1alpha2
kind: Postgres
metadata:
name: hot-postgres
namespace: demo
spec:
version: "13.13"
replicas: 3
standbyMode: Hot
storageType: Ephemeral
In this examples:
Postgres
object creates three PostgreSQL servers, indicated by the replicas
field.spec.standbyMode
Database servers can work together to allow a second server to take over quickly if the primary server fails. This is called high availability. When primary server is unavailable, standby servers go through a leader election process to take control as primary server. PostgreSQL database with high availability feature can either have warm standby or hot standby servers.
To enable high availability, you need to create PostgreSQL with multiple server. Set spec.replicas
to more than one in Postgres.
Master server along with standby server(s) can serve the same data. This is called load balancing. In our setup, we only support read-only standby server. To enable load balancing, you need to setup hot standby PostgreSQL cluster.
Read about hot standby and its setup in Postgres.
There are many approaches available to scale PostgreSQL beyond running on a single server.
Now KubeDB supports only following one:
These standby servers can also be hot standby server. This is the fastest type of replication available as WAL data is sent immediately rather than waiting for a whole segment to be produced and shipped.
KubeDB PostgreSQL support [Streaming Replication](/docs/v2023.12.28/guides/postgres/clustering/streaming_replication)