An overview of Subscriber-only nodes v5.6

Overview

While many use cases rely on accessing a database node which can handle queries and updates, there are also use cases which only require access to a node that can handle read-only database queries. Read scaling like this, by moving the read-only traffic away from active database nodes in the cluster, can improve the performance of the core cluster, whilst making database access more widely available.

The basic idea of subscriber-only nodes is to provide a read-only node that can be used to offload read-only queries from the main cluster. How it connects to the other nodes in the cluster can be different from how other nodes connect to each other. The default topology of a PGD cluster is what we call a full mesh topology, where every node connects to every other node. This is the most robust and fault-tolerant way to connect nodes, but it can be inefficient for some use cases.

Each node in a subscriber-only group will, by default, receive replication from all other nodes in the cluster.

PGD provides this read scaling functionality through subscriber-only nodes and groups. Each subscriber-only group has a node which replicates changes to the other subscriber-only nodes in its group. You can have multiple subscriber-only groups, which can address different regions or different application demands.

In PGD 5.6 and later, this topology can be optimized. For clusters using groups for their data nodes, subscriber only groups can use a more efficient model which uses a group leader, similar to a write leader in PGD Proxies. See Optimizing subscriber-only groups for more information on this feature.

Subscriber-Only nodes and groups

Subscriber-Only (SO) nodes subscribe only to the replication changes from other nodes in the cluster and are created as both as nodes of the kind subscriber-only and as members of a group of the same kind. SO nodes can only join SO groups and SO groups can only have SO nodes as members.

← Prev

Subscriber-only nodes and groups

↑ Up