PGD Nodes and Groups
====================

A PGD cluster is made up of one or more nodes, with each node being an
instance of Postgres.

Each node in the cluster is a full Postgres instance with the BDR
extension installed and configured. Nodes can have different roles and
responsibilities within the cluster. Nodes are then organized into
groups, which are used to organize the replication of data between the
nodes. There’s also the “top level” group, which is the cluster itself;
every node in the cluster is also a member of this group, and it is the
parent of all other groups in the cluster.

Data Nodes
----------

The first node kind to know about is the data node. This is the basic
building block of PGD clusters. It is configured to replicate data to
and from the other data nodes in the cluster. Not the group, the
cluster. By design, all nodes in a PGD cluster replicate to all other
nodes in the cluster.

Groups
------

Groups are used to localize how the nodes **manage** themselves. Each
group selects it’s own Raft leader from the group members. If the group
is a data group that is made up of data nodes it also uses Raft to elect
a write leader node for that group. The write leader node will be sent
all the read/write client connections for that group and will be the
node that handles all write operations for that group, assuming that the
client connections come in through the connection manager of a node in
that group.

..  info::
   Raft is a consensus algorithm that is used to ensure that all nodes in a group agree on the state of the group. It allows a group of nodes to elect a leader node, and to ensure that all nodes in the group are in sync with each other over decisions. The most important thing to know about Raft is that it needs an odd number of nodes in any group to function correctly. That's because Raft uses a majority vote between the nodes to agree on the state of the group.

Witness Nodes
-------------

Witness nodes are like data nodes, but they do not replicate or store
any data. Their role is to provide a deadlock breaking vote in the event
of a group of data nodes losing sufficient nodes as to not be able to
complete a majority vote.

Witness nodes do not participate in the normal data replication process,
but they can be used to help resolve conflicts and ensure that the
cluster remains available even in the face of network partitions or
other failures.

Subscriber-only Nodes
---------------------

Subscriber-only nodes are used to provide a read-only replica of the
data in the cluster. In PGD 6, you can configure a subscriber-only node
as a member of a data group or a member of a subscriber-only group. The
latter has no write leader node, and all nodes in the group are
read-only and allow for some optional optimizations in the replication
process. The former allows for a read-only replica of the data in the
group, but it does not allow for any optimizations in the replication
process.

A subscriber-only node can be used to offload read queries from the
write leader node, which can help to improve performance and reduce the
load on the write leader node. It can also be used to provide a
read-only replica of the data in the cluster for reporting or analytics
purposes. You can connect to the read-only nodes like this using the
connection manager’s read-only connection string, which will direct the
connections to the pool of read-only nodes in the cluster.

Logical Standby Nodes
---------------------

Logical standby nodes are used to provide a read-only replica of the
data in the cluster. They are similar to subscriber-only nodes, but they
are designed to be more flexible and can be used in a wider range of
scenarios.