​
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.