Commit Scopes v5.6
EDB Postgres Distributed (PGD) offers a range of synchronous modes to complement its default asynchronous replication. These synchronous modes are configured through commit scopes. Commit scopes are rules that define how operations are handled and when the system considers a transaction committed.
Introducing
Overview introduces the concepts and some of the essential terminology that's used when discussing synchronous commits.
Durability terminology lists terms used around PGD's durability options, including how nodes are referred to in replication.
Commit scopes is a more in-depth look at the structure of commit scopes and how to define them for your needs.
Commit scope rules looks at the syntax of and how to formulate a commit scope rule.
Comparing compares how each option behaves.
Commit scope kinds
Group Commit focuses on the Group Commit option, where you can define a transaction as done when a group of nodes agrees it's done.
CAMO focuses on the Commit At Most Once option, in which applications take responsibility for verifying that a transaction has been committed before retrying. This ensures that their commits only happen at most once.
Lag Control looks at the commit scope mechanism which dynamically throttle nodes according to the slowest node and regulates how far out of sync nodes may go when a database node goes out of service.
Synchronous Commit examines a commit scope mechanism that works in a similar fashion to legacy synchronous replication, but from within the commit scope framework.
Working with commit scopes
Administering addresses how to manage a PGD cluster with Group Commit in use.
Limitations lists the various combinations of durability options that aren't currently supported or aren't possible. Refer to this before deciding on a durability strategy.
Legacy synchronous replication shows how traditional Postgres synchronous operations can still be accessed under PGD.
Internal timing of operations compares legacy replication with PGD's async and synchronous operations, especially the difference in the order by which transactions are flushed to disk or made visible.