Configuration
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
- Thehot_standby_feedback
setting controls whether nodes acting ashot_standby
s (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
- Theprimary_slot_name
setting declares the name of the replication slot that a replica should use when it connects to the primary. In order forhot_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.