• Overview
• Installation
• Testing
• Terms
• References

Overview of the Architecture of Postgres-R

The article "Postgres-R (8) Architecture" explains the concept and architecture of Postgres-R. Note that the current prototype implementation doesn't cover all aspects mentioned.

Structure of a Postgres-R cluster

Postgres-R is designed to run on shared-nothing clusters with a low latency interconnect. It provides conflict-free (eager), multi-master replication on the basis of binary changeset replication. It features a modular design, with interfaces for multiple group communication systems and parallelized change set application.

Components of a Postgres-R node

The main component of Postgres-R is the replication manager. This is a separate process added to Postgres which mainly coordinates messages. It arranges and maintains the connection to the group communication system, to the backends which process local transactions as well as to the helper backends which process remote transactions.

In Postgres there are backend processes which handle transactions. Each backend can only process one transaction at a time. To replay transactions from remote nodes the replication manager starts helper backends which do not have a connection to a client but which are under the control of the replication manager.

Lifecycle of a Replicated Transaction

Read-only transactions are handled locally and are treated no different than in standard single node operation of Postgres. As soon as a transaction writes data (update, insert or delete SQL commands) the new data is collected into a changeset. The local backend continues to processes the transaction and continuously collects the changes in the changeset until it receives the commit request from the client.

Before confirming the commit to the client the local backend sends the changeset to the replication manager, which in turn sends it out to all other nodes using a reliable multicast. In addition it requests an agreement about the ordering of this transaction within a totally ordered series of transactions to apply. The local backend which started the transaction can commit as soon as the agreement is reached. On another node, which receives the changeset for replay, the replication manager passes the changeset on to a helper backend, which replays the transactions in the agreed order from the data in the changeset.

Conflict handling

In Postgres-R writing transactions get virtually serialized so that in case of a conflict, all nodes participating in the replication cluster agree on which transaction is first and which comes later. This guarantees consistency of the data between the nodes, without requiring expensive and full synchronization. A transaction which successfully commits on one node is therefore able to commit on all the other nodes as well. This prevents having to wait for other nodes and lets each node run at full speed.