Skip to main content
High availability (HA) minimizes downtime in the event of failures and is crucial for production deployments. To achieve high availability, you need to have ParadeDB Enterprise deployed inside a CNPG Kubernetes cluster.

​
How High Availability Works

In a highly available configuration, ParadeDB deploys as a cluster of Postgres instances. One instance is designated as the primary while the other instances are designated as standby instances. The primary server sends write-ahead logs (WAL) to the standby servers, which replicate the primary by replaying these logs. If the primary server goes down, a standby server is promoted to become the new primary server. This process is called failover. For a thorough architecture overview, please consult the CloudNativePG Architecture documentation.

​
Enable High Availability

Prior to starting the CNPG cluster, modify the values.yaml file to increase the number of instances.
ParadeDB Enterprise
type: paradedb-enterprise
mode: standalone

cluster:
  instances: 3
  storage:
    size: 256Mi
The number of replicas is equal to instances - 1. Having at least 3 instances guarantees that a standby will be available even while a failover process is occurring.

​
Synchronous Replication

Between physical replicas, ParadeDB requires the use of a few settings (which are automatically set by CNPG) in order to avoid query cancellation due to ongoing reorganization of the data on the primary replica.
  • hot_standby_feedback=on - The hot_standby_feedback setting controls whether nodes acting as hot_standbys (the replicas in physical replication) send feedback to the leader about their current transaction status. ParadeDB uses this transaction status to determine when it is safe for the primary to garbage collect its segments.
  • primary_slot_name=$something - The primary_slot_name setting declares the name of the replication slot that a replica should use when it connects to the primary. In order for hot_standby_feedback to be used and persistent, a replication slot must be used.
Without these settings, ParadeDB physical replicas will see much more frequent query cancels, and will report a message recommending that they are used.

​
Synchronous Replication

By default, ParadeDB ships with asynchronuous replication, meaning transactions on the primary do not wait for confirmation from the standby instances before committing. Quorum-based synchronous replication ensures that a transaction is successfully written to standbys before it completes. Please consult the CloudNativePG Replication documentation for details.

​
Backup and Disaster Recovery

ParadeDB supports backups to cloud object stores (e.g. S3, GCS, etc.) and point-in-time-recovery via Barman. To configure the frequency and location of backups, please consult the CloudNativePG Backup documentation.