An Overview of Durability options ================================= 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: - :: :ref:`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. - :: :ref:`CAMO or commit-at-most-once ` : This kind of commit scope is a variant of Group Commit in which the client takes on the responsibility for verifying that a transaction has been committed before retrying. - :: :ref:`Lag Control ` : This kind of commit scope controls how far behind nodes can be in terms of replication before allowing commit to proceed. - :: :ref:`PGD Synchronous Commit ` : This kind of commit scope allows for a behaviour where the origin node awaits a majority of nodes to confirm and behaves more like a native Postgres synchronous commit. .. Note Legacy synchronization availability :: For backward compatibility, PGD still supports configuring synchronous replication with `synchronous_commit` and `synchronous_standby_names` . See :ref:`Legacy synchronous replication using PGD ` for more on this option. We recommend users instead use :ref:`PGD Synchronous_Commit ` . !!!