Subscriber-only nodes and groups v5

Suggest edits

Subscriber-only nodes

As the name suggests, a subscriber-only node subscribes only to replication changes from other nodes in the cluster. However, no other nodes receive replication changes from subscriber-only nodes. This is somewhat similar to logical standby nodes. But in contrast to logical standby, the subscriber-only nodes are fully joined to the cluster. They can receive replication changes from all other nodes in the cluster and hence aren't affected by unavailability or parting of any one node in the cluster.

A subscriber-only node is a fully joined PGD node and hence it receives all replicated DDLs and acts on those. It also uses Raft to consistently report its status to all nodes in the cluster. The subscriber-only node doesn't have Raft voting rights and hence can't become a Raft leader or participate in the leader election. Also, while it receives replicated DDLs, it doesn't participate in DDL or DML lock acquisition. In other words, a currently down subscriber-only node doesn't stop a DML lock from being acquired.

The subscriber-only node forms the building block for PGD Tree topology. In this topology, a small number of fully active nodes are replicating changes in all directions. A large number of subscriber-only nodes receive only changes but never send any changes to any other node in the cluster. This topology avoids connection explosion due to a large number of nodes, yet provides an extremely large number of leaf nodes that you can use to consume the data.

Subscriber-only groups

To make use of subscriber-only nodes, first create a PGD group of type subscriber-only. Make it a subgroup of the group from which the member nodes receive the replication changes. Once you create the subgroup, all nodes that intend to become subscriber-only nodes must join the subgroup. You can create more than one subgroup of subscriber-only type, and they can have different parent groups.

Once a node successfully joins the subscriber-only subgroup, it becomes a subscriber-only node and starts receiving replication changes for the parent group. Any changes made directly on the subscriber-only node aren't replicated.

See bdr.create_node_group to know how to create a subgroup of a specific type and belonging to a specific parent group.

Note

Since a subscriber-only node doesn't replicate changes to any node in the cluster, it can't act as a source for syncing replication changes when a node is parted from the cluster. But if the subscriber-only node already received and applied replication changes from the parted node that no other node in the cluster currently has, then that causes inconsistency between the nodes.

For now, you can solve this by setting bdr.standby_slot_names and bdr.standby_slots_min_confirmed so that there's always a fully active PGD node that's ahead of the subscriber-only nodes.

← Prev

Logical standby nodes

Next →

Viewing PGD topology