-
Notifications
You must be signed in to change notification settings - Fork 251
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Dj Walker-Morgan <[email protected]>
- Loading branch information
Showing
6 changed files
with
239 additions
and
174 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
--- | ||
title: Administering | ||
navTitle: Administering | ||
--- | ||
|
||
When running a PGD cluster with Group Commit, there are some things you need to | ||
be aware of when administering the system, such as how to safely shut down and | ||
restart nodes. | ||
|
||
## Planned shutdown and restarts | ||
|
||
When using Group Commit with receive confirmations, take care | ||
with planned shutdown or restart. By default, the apply queue is consumed | ||
prior to shutting down. However, in the `immediate` shutdown mode, the queue | ||
is discarded at shutdown, leading to the stopped node "forgetting" | ||
transactions in the queue. A concurrent failure of the origin node can | ||
lead to loss of data, as if both nodes failed. | ||
|
||
To ensure the apply queue gets flushed to disk, use either | ||
`smart` or `fast` shutdown for maintenance tasks. This approach maintains the | ||
required synchronization level and prevents loss of data. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
--- | ||
title: Comparing Durability Options | ||
navTitle: Comparing | ||
--- | ||
|
||
## Comparison | ||
|
||
Most options for synchronous replication available to | ||
PGD allow for different levels of synchronization, offering different | ||
tradeoffs between performance and protection against node or network | ||
outages. | ||
|
||
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. For commit scopes the Mode | ||
column refers to the confirmation requirements of the | ||
[commit scope configuration](commit-scopes#configuration). | ||
|
||
| Variant | Mode | Received | Visible | Durable | | ||
|---------------------|-----------------------|----------|---------|---------| | ||
| PGD Async | off (default) | no | no | no | | ||
| PGD Lag Control | 'ON received' nodes | no | no | no | | ||
| PGD Lag Control | 'ON replicated' nodes | no | no | no | | ||
| PGD Lag Control | 'ON durable' nodes | no | no | no | | ||
| PGD Lag Control | 'ON visible' nodes | no | no | no | | ||
| PGD Group Commit | 'ON received' nodes | yes | no | no | | ||
| PGD Group Commit | 'ON replicated' nodes | yes | no | no | | ||
| PGD Group Commit | 'ON durable' nodes | yes | no | yes | | ||
| PGD Group Commit | 'ON visible' nodes | yes | yes | yes | | ||
| PGD CAMO | 'ON received' nodes | yes | no | no | | ||
| PGD CAMO | 'ON replicated' nodes | yes | no | no | | ||
| PGD CAMO | 'ON durable' nodes | yes | no | yes | | ||
| PGD CAMO | 'ON visible' nodes | yes | yes | yes | | ||
|
||
Reception ensures the peer operating normally can | ||
eventually apply the transaction without requiring any further | ||
communication, even in the face of a full or partial network | ||
outage. A crash of a peer node might still require retransmission of | ||
the transaction, as this confirmation doesn't involve persistent | ||
storage. All modes considered synchronous provide this protection. | ||
|
||
Visibility implies the transaction was applied remotely. All other | ||
clients see the results of the transaction on all nodes, providing | ||
this guarantee immediately after the commit is confirmed by the origin | ||
node. Without visibility, other clients connected might not see the | ||
results of the transaction and experience stale reads. | ||
|
||
Durability relates to the peer node's storage and provides protection | ||
against loss of data after a crash and recovery of the peer node. | ||
This can either relate to the reception of the data (as with physical | ||
streaming replication) or to visibility (as with Group Commit). | ||
The former eliminates the need for retransmissions after | ||
a crash, while the latter ensures visibility is maintained across | ||
restarts. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
--- | ||
title: Configuring Commit Scopes | ||
navTitle: Configuring | ||
--- | ||
|
||
## Configuration | ||
|
||
You configure commit scopes using an SQL function just like other administration | ||
operations in PGD. | ||
|
||
For example, you might define a basic commit scope that does Group Commit on a majority | ||
of nodes in the example_group PGD group: | ||
|
||
```sql | ||
SELECT bdr.add_commit_scope( | ||
commit_scope_name := 'example_scope', | ||
origin_node_group := 'example_group', | ||
rule := 'ANY MAJORITY (example_group) GROUP COMMIT', | ||
wait_for_ready := true | ||
); | ||
``` | ||
|
||
You can then use the commit scope either by setting the configuration variable (GUC) | ||
`bdr.commit_scope` either per transaction or globally to that commit scope: | ||
|
||
```sql | ||
BEGIN; | ||
SET LOCAL bdr.commit_scope = 'example_scope'; | ||
... | ||
COMMIT; | ||
``` | ||
|
||
You can also set the default commit scope for a given PGD group: | ||
|
||
```sql | ||
SELECT bdr.alter_node_group_option( | ||
node_group_name := 'example_group', | ||
config_key := 'default_commit_scope', | ||
config_value := 'example_scope' | ||
); | ||
``` | ||
|
||
The `default_commit_scope` is checked in the group tree that the given origin | ||
node belongs to from bottom to top. The `default_commit_scope` can't be set to | ||
the special value `local`, which means there's no way for the commit scope to use | ||
the `bdr.commit_scope` configuration parameter. | ||
|
||
For full details of the commit scope language with all the options described, | ||
see [Commit scopes](commit-scopes). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.