Legacy synchronous replication using PGD v5.6

Important

We highly recommend PGD Synchronous Commit instead of legacy synchronous replication.

Postgres provides physical streaming replication (PSR), which is unidirectional but offers a synchronous variant.

For backward compatibility, PGD still supports configuring synchronous replication with synchronous_commit and synchronous_standby_names. Consider using Group Commit or Synchronous Commit instead.

Unlike PGD replication options, PSR sync persists first, replicating after the WAL flush of commit record.

Usage

To enable synchronous replication using PGD, you need to add the application name of the relevant PGD peer nodes to synchronous_standby_names. The use of FIRST x or ANY x offers some flexibility if this doesn't conflict with the requirements of non-PGD standby nodes.

Once you've added it, you can configure the level of synchronization per transaction using synchronous_commit, which defaults to on. This setting means that adding the application name to synchronous_standby_names already enables synchronous replication. Setting synchronous_commit to local or off turns off synchronous replication.

Due to PGD applying the transaction before persisting it, the values on and remote_apply are equivalent for logical replication.

Comparison

The following table summarizes what a client can expect from a peer node replicated to after receiving a COMMIT confirmation from the origin node the transaction was issued to. The Mode column takes on different meaning depending on the variant. For PSR and legacy synchronous replication with PGD, it refers to the synchronous_commit setting.

VariantModeReceivedVisibleDurable
PSR Asyncoff (default)nonono
PSR Syncremote_write (2)yesnono (3)
PSR Syncon (2)yesnoyes
PSR Syncremote_apply (2)yesyesyes
PGD Legacy Sync (1)remote_write (2)yesnono
PGD Legacy Sync (1)on (2)yesyesyes
PGD Legacy Sync (1)remote_apply (2)yesyesyes

(1) Consider using Group Commit instead.

(2) Unless switched to local mode (if allowed) by setting synchronous_replication_availability to async', otherwise the values for the asynchronous PGD default apply.

(3) Written to the OS, durable if the OS remains running and only Postgres crashes.

Postgres configuration parameters

The following table provides an overview of the configuration settings that you must set to a non-default value (req) and those that are optional (opt) but affect a specific variant.

Setting (GUC)Group CommitLag ControlPSRLegacy Sync
synchronous_standby_namesn/an/areqreq
synchronous_commitn/an/aoptopt
synchronous_replication_availabilityn/an/aoptopt

Migration to commit scopes

You configure the Group Commit feature of PGD independent of synchronous_commit and synchronous_standby_names. Instead, the bdr.commit_scope GUC allows you to select the scope per transaction. And instead of configuring synchronous_standby_names on each node individually, Group Commit uses globally synchronized commit scopes.

Note

While the grammar for synchronous_standby_names and commit scopes looks similar, the former doesn't account for the origin node, but the latter does. Therefore, for example, synchronous_standby_names = 'ANY 1 (..)' is equivalent to a commit scope of ANY 2 (...). This choice makes reasoning about majority easier and reflects that the origin node also contributes to the durability and visibility of the transaction.