-
Notifications
You must be signed in to change notification settings - Fork 4
Multiple Synchronous Replication
- New configuration file for this feature (or new GUC is in postgresql.conf)
- Parsing configuration file.
- Only 1-level configuration with 'priority' method and its logic. (Maybe also 1-level 'quorum' method)
- New system catalog.
The each standbys has priority according to definition order, starting from left. If we want to set the set of standbys as a priority group, we can set by surrounding with '[' and ']'. The master server waits for "N" standbys having higher priority. priority 1 is highest priority.
The each standbys always has same priority 1, which means every standbys are equal priority. If we want to set the set of standbys as a quorum group, we can set by surrounding with '(' and ')'. The master server waits for "N" standbys from quorum group.
The comma separated node list surrounded by '( ... )' represents the standby will be handled as a quorum group. N means that the number of nodes/group to wait for in this group. Using ":" immediately after set of node name, we name the group name to it.
The comma separated node list surrounded by '[ ... ]' represents the standby will be handled as a priority group. N means that the number of nodes/group to wait for in this group. Using ":" immediately after set of node name, we name the group name to it.
If we configure
'2[local1, 1(london1, london2):london, [tokyo1, tokyo2]:tokyo]'.
it means:
- The 'london' group has two nodes; london1, london2, and is handled as quorum group. It means that 'london' group is active only when at least 1 standby returns ACK to master.
- The 'tokyo' group also has two nodes; 'tokyo1', 'tokyo2', and is handled as quorum group. It means that 'tokyo' group is active only when 'tokyo1' returns ACK to master. If 'tokyo1' is down, the master waits for 'tokyo2'.
- The 'main' group has one node(local1) and two groups(london, tokyo), and is handled as priority group.
- The master can do COMMIT when ACK is returned from local1 node and london group, because local1 and london priority are higher than tokyo group.
We have a new system view, says pg_stat_replication_group, to easily confirm the status of sync replication including each group.
The definition is,
Table "public.pg_stat_replication_group"
Column | Type | Modifiers
----------------+---------+-----------
name | text |
sync_type | text |
wait_num | integer |
sync_priority | integer |
sync_state | text |
member | text[] |
level | integer |
write_location | pg_lsn |
flush_location | pg_lsn |
apply_location | pg_lsn |
| column | description |
|---|---|
| name | node name or group name, or "main" meaning top level node. |
| sync_type | 'priority' or 'quorum' for group node, otherwise NULL. |
| wait_num | number of nodes/groups to wait for in this group. |
| sync_priority | priority of node/group in this group. |
| sync_state | 'sync' or 'potential' or 'quorum'. |
| member | array of members for group node, otherwise NULL. |
| level | nested level. "root" node is level 0. |
| write_location | group/node calculated LSN according to configuration. |
| flush_location | same as above |
| apply_location | same as above |