Group Commit v5
Commit scope kind:
The goal of Group Commit is to protect against data loss in case of single node failures or temporary outages. You achieve this by requiring more than one PGD node to successfully confirm a transaction at COMMIT time. Confirmation can be sent at a number of points in the transaction processing, but defaults to "visible" when the transaction has been flushed to disk and is visible to all other transactions.
This example creates a commit scope where all the nodes in the left_dc group and any one of the nodes in the right_dc group must receive and successfuly confirm a committed transaction.
During normal operation, Group Commit is transparent to the application. Transactions that were in progress during failover need the reconciliation phase triggered or consolidated by either the application or a proxy in between. This activity currently happens only when either the origin node recovers or when it's parted from the cluster. This behavior is the same as with Postgres legacy built-in synchronous replication.
Transactions committed with Group Commit use two-phase
commit underneath. Therefore, configure
max_prepared_transactions high enough to handle all such transactions
originating per node.
See the Group Commit section of the Limitations section.
To use Group Commit, first define a commit scope. The commit scope determines the PGD nodes involved in the commit of a transaction.
The behavior of Group Commit depends on the configuration applied by the commit scope.
You can configure Group Commit to decide commits in three different ways:
group decision is the default. It specifies that the commit is confirmed
by the origin node upon it recieving as many confirmations as required by the
commit scope group. The difference is that the commit decision is made based on
PREPARE replication while the durability checks COMMIT (PREPARED) replication.
partner decision is what Commit At Most Once uses. This approach
works only when there are two data nodes in the node group. These two nodes are
partners of each other, and the replica rather than origin decides whether
to commit something. This approach requires application changes to use
the CAMO transaction protocol to work correctly, as the application is in some way
part of the consensus. For more on this approach, see CAMO.
raft decision uses PGDs built-in raft consensus for commit decisions. It can have low performance and is currently only required when using GROUP COMMIT with an ALL commit scope group.
Conflict resolution can be
Async means that PGD does optimistic conflict resolution during replication using the row-level resolution as configured for given node. This happens regardless of whether the origin transaction committed or is still in progress. See Conflicts for details about how the asynchronous conflict resolution works.
Eager means that conflicts are resolved eagerly (as part of agreement on COMMIT), and conflicting transactions get aborted with a serialization error. This approach provides greater isolation than the asynchronous resolution at the price of performance.
Using an ALL commit scope group requires that the commit
decision must be set to
raft to avoid reconciliation
For the details about how Eager conflict resolution works, see Eager conflict resolution.
To prevent a transaction that can't get consensus on the COMMIT from hanging
ABORT ON clause allows specifying timeout. After the timeout, the
transaction abort is requested. If the transaction is already
decided to be committed at the time the abort request is sent, the transaction
does eventually COMMIT even though the client might receive an abort message.
See also Limitations.