Replication slots created by PGD v5

Suggest edits

On a PGD master node, the following replication slots are created by PGD:

  • One group slot, named bdr_<database name>_<group name>
  • N-1 node slots, named bdr_<database name>_<group name>_<node name>, where N is the total number of PGD nodes in the cluster, including direct logical standbys, if any
Warning

Don't drop those slots. PGD creates and manages them and drops them when or if necessary.

On the other hand, you can create or drop replication slots required by software like Barman or logical replication using the appropriate commands for the software without any effect on PGD. Don't start slot names used by other software with the prefix bdr_.

For example, in a cluster composed of the three nodes alpha, beta, and gamma, where PGD is used to replicate the mydb database and the PGD group is called mygroup:

  • Node alpha has three slots:
    • One group slot named bdr_mydb_mygroup
    • Two node slots named bdr_mydb_mygroup_beta and bdr_mydb_mygroup_gamma
  • Node beta has three slots:
    • One group slot named bdr_mydb_mygroup
    • Two node slots named bdr_mydb_mygroup_alpha and bdr_mydb_mygroup_gamma
  • Node gamma has three slots:
    • One group slot named bdr_mydb_mygroup
    • Two node slots named bdr_mydb_mygroup_alpha and bdr_mydb_mygroup_beta

Group replication slot

The group slot is an internal slot used by PGD primarily to track the oldest safe position that any node in the PGD group (including all logical standbys) has caught up to, for any outbound replication from this node.

The group slot name is given by the function bdr.local_group_slot_name().

The group slot can:

  • Join new nodes to the PGD group without having all existing nodes up and running (although the majority of nodes should be up). This process doesn't incur data loss in case the node that was down during join starts replicating again.
  • Part nodes from the cluster consistently, even if some nodes haven't caught up fully with the parted node.
  • Hold back the freeze point to avoid missing some conflicts.
  • Keep the historical snapshot for timestamp-based snapshots.

The group slot is usually inactive and is fast forwarded only periodically in response to Raft progress messages from other nodes.

Warning

Don't drop the group slot. Although usually inactive, it's still vital to the proper operation of the EDB Postgres Distributed cluster. If you drop it, then some or all of the features can stop working or have incorrect outcomes.

Hashing long identifiers

The name of a replication slot, like any other PostgreSQL identifier, can't be longer than 63 bytes. PGD handles this by shortening the database name, the PGD group name, and the name of the node in case the resulting slot name is too long for that limit. Shortening an identifier is carried out by replacing the final section of the string with a hash of the string itself.

For example, consider a cluster that replicates a database named db20xxxxxxxxxxxxxxxx (20 bytes long) using a PGD group named group20xxxxxxxxxxxxx (20 bytes long). The logical replication slot associated to node a30xxxxxxxxxxxxxxxxxxxxxxxxxxx (30 bytes long) is called since 3597186, be9cbd0, and 7f304a2 are respectively the hashes of db20xxxxxxxxxxxxxxxx, group20xxxxxxxxxxxxx, and a30xxxxxxxxxxxxxxxxxxxxxxxxxx.

bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2
← Prev

Decoding worker

Next →

Node restart and down node recovery