Subscriber-only nodes and groups v5.6
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.
- On this page
- Subscriber-only nodes
- Subscriber-only groups