Overview of durability options v5.6
Overview
EDB Postgres Distributed (PGD) allows you to choose from several replication configurations based on your durability, consistency, availability, and performance needs using commit scopes.
In its basic configuration, PGD uses asynchronous replication. However, commit scopes can change both the default and the per-transaction behavior.
It's also possible to configure the legacy Postgres synchronous replication
using standard synchronous_standby_names
in the same way as the built-in
physical or logical replication. However, commit scopes provide much more
flexibility and control over the replication behavior.
The different synchronization settings affect three properties of interest to applications that are related but can all be implemented individually:
Durability: Writing to multiple nodes increases crash resilience and allows you to recover the data after a crash and restart.
Visibility: With the commit confirmation to the client, the database guarantees immediate visibility of the committed transaction on some sets of nodes.
Conflict handling: Conflicts can be handled optimistically postcommit, with conflicts resolved when the transaction is replicated based on commit timestamps. Or, they can be handled pessimistically precommit. The client can rely on the transaction to eventually be applied on all nodes without further conflicts or get an abort, directly informing the client of an error.
Commit scopes allow four kinds of controlling durability of the transaction:
Group Commit: This kind of commit scope controls which and how many nodes have to reach a consensus before the transaction is considered to be committable and at what stage of replication it can be considered committed. This option also allows you to control the visibility ordering of the transaction.
CAMO: This kind of commit scope is a variant of Group Commit, in which the client takes on the responsibility for verifying that a transaction was committed before retrying.
Lag Control: This kind of commit scope controls how far behind nodes can be in terms of replication before allowing commit to proceed.
PGD Synchronous Commit: This kind of commit scope allows for a behavior where the origin node awaits a majority of nodes to confirm and behaves more like a native Postgres synchronous commit.
Legacy synchronization availability
For backward compatibility, PGD still supports configuring synchronous
replication with synchronous_commit
and synchronous_standby_names
. See
Legacy synchronous replication for more on this option. We
recommend that you use PGD Synchronous Commit instead.
- On this page
- Overview