Postgres Distributed (PGD) presets on Cloud Service
Suggest editsCommit scope
Commit scopes in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance.
The actual behavior depends on the kind of commit scope a commit scope's rule uses: Group Commit, Commit At Most Once, Lag Control, Synchronous Commit, or a combination of these.
This flexibility means that selecting a balanced combination of rules can take time. To speed up deployment, Cloud Service's PGD has a preset selection of commit scopes for typical user requirements. These presets don't prevent you from creating and applying your own commit scopes as needed.
Cloud Service's commit scope preset options
The presets include a rule for high consistency in a subgroup and a separate setting for lag control both inside and outside the subgroup. You can use combinations of these rules for high consistency in a subgroup. You can also use lag control for other subgroups and high consistency within the subgroup and with one or more nodes of another subgroup.
Preset ID | Local group | External groups | Use case |
---|---|---|---|
ba001 | MAJORITY, SYNCHRONOUS_COMMIT | N/A | High consistency for critical data |
ba002 | ALL, LAG_CONTROL | ALL, LAG_CONTROL | Manages replication lag locally and externally |
ba003 | MAJORITY, SYNCHRONOUS_COMMIT | ANY 1, LAG_CONTROL | Combines high consistency locally with lag control for external |
ba004 | MAJORITY, SYNCHRONOUS_COMMIT | ANY 1, SYNCHRONOUS COMMIT | Higher consistency via external validation |
Note
ba001 is also the only Cloud Service preset that works with PGD clusters that have only one data group. All of the presets, including ba001, work with PGD clusters that have two or more data groups.
ba001
ba001 offers a default setup that optimizes data consistency and reliability across distributed environments. This example shows a definition for transactions originating from the group of nodes location-a
. The full name of the actual commit scope for this specific group is ba001_location-a
.
This rule says that for transactions originating from a node in location-a
, the majority of the nodes in location-a
must acknowledge the transaction before it's committed.
ba001 uses MAJORITY
instead of ALL
so that in the case of 3 data nodes, the third can be updated asynchronously. This ability allows for a node failure without interrupting a single region service.
ba001 is the baseline commit scope provided by Cloud Service and the default commit scope for all new subgroups.
ba002
ba002 allows for asynchronous commits but with lag control for tighter consistency (that is, tighter than the system's default asynchronous behavior) across the distributed system. The following is an example definition of ba002 for nodes in location-a
:
The first part of the rule says that all nodes of location_a
, which is the origin_node_group
in this case, are monitored according to max_lag_size=100MB
and max_commit_delay=1s
. Specifically, as lag size approaches the set max of 100MB, the system begins injecting commit delays on the origin node of up to 1 second so that replication to the other nodes in the group can catch up.
The second part of the rule (after AND
) says that for all nodes not in location_a
, those nodes are monitored according to max_lag_size=1000MB
, max_lag_time=30s
, and max_commit_delay=4s
. Specifically, as lag size or time approaches either of their respective limits (1000MB or 30s), the system begins injecting commit delays on the origin node of up to 4 seconds. This capability allows replication to those nodes outside the origin node group to catch up.
ba003
ba003 is a combination of Synchronous Commit for the local group with Lag Control parameters being met by at least one external node.
This example definition of a ba003 commit scope uses the bdr.add_commit_scope
command, again applying to nodes in location-a
:
The first part of the rule states that for any transaction originating on a node in the origin_node_group
(in this case location-a
), a majority of the nodes in location_a
must confirm the transaction before it's committed.
The second part of the rule states that at least one node not in location_a
must keep lag within the LAG_CONTROL
parameters (max_lag_size=1000MB, max_lag_time=30s
) with respect to its replicating transactions originating from a node in the origin_node_group
(here location_a). Otherwise, a commit delay of up to 4 seconds will be used to slow down processing on the originating node to allow for the lagging node to catch up.
ba004
ba004 says that for all transactions originating from a node in the origin_node_group
(location-a
in the example), a majority of the nodes of location-a
, and at least one node not in location-a
, must confirm the transaction before it's committed.
Just as in ba001 and ba003, ba004 uses SYNCHRONOUS_COMMIT
to keep potential data loss at near zero, as the data is replicated before commit success is signaled to the application. Again, MAJORITY
is used so that in a three-node scenario in a region, one node can experience failure without compromising the cluster. However, to confirm the transaction, in this case the commit scope also requires confirmation from one node outside of the group.
Setting default_commit_scope
As mentioned, the default Cloud Service PGD commit scope preset is an instantiation of ba001.
To change the default commit scope, you need to know the names of your commit scope presets and the name of the origin node group for your cluster. To see the Cloud Service presets as defined for your cluster's groups, connect to the cluster using psql, and enter:
Note the commit_scope_name
of the preset you want to set as your default. The origin node group follows ba00<#>_
. In this case, it's p-mbx2p83u9n-a
.
To make a commit_scope the default_commit_scope
for a node group, use the command bdr.alter_node_group_option
. Replace <origin_node_group>
with the origin node group (in this case p-mbx2p83u9n-a
). Replace <commit_scope_name>
with the commit_scope_name
of the desired preset.
Note
Commit scopes can be applied per transaction. In that case, they override a Cloud Service preset.
For more information, see Commit scopes and Commit scope rules in the PGD documentation.
Could this page be better? Report a problem or suggest an addition!