Managing High Availability in PostgreSQL: Part 3 — Patroni

In our previous posts, we discussed the capabilities and functioning of PostgreSQL Automatic Failover (PAF) by Cluster Labs and Replication Manager (repmgr) by 2ndQuadrant. In the final post of this series, we will review the last solution, Patroni by Zalando, and compare all three at the end so you can determine which high availability framework is best for your PostgreSQL hosting deployment.

• Managing High Availability in PostgreSQL: Part 1 — PostgreSQL Automatic Failover
• Managing High Availability in PostgreSQL: Part 2 — Replication Manager

Patroni for PostgreSQL

Patroni originated as a fork of Governor, a project from Compose. It is an open-source tool suite, written in Python, for managing high availability of PostgreSQL clusters. Instead of building its own consistency protocol, Patroni smartly leverages the consistency model provided by a Distributed Configuration Store (DCS). It also supports other DCS solutions like Zookeeper, etcd, Consul, and Kubernetes.

Patroni ensures the end-to-end setup of PostgreSQL HA clusters, including streaming replication. It supports various ways of creating a standby node and works like a template that can be customized to your needs.

This feature-rich tool exposes its functionality via REST APIs and also via a command-line utility called patronictl. It supports integration with HAProxy by using its health check APIs to handle load balancing.

Patroni also supports event notification with the help of callbacks, which are scripts triggered by certain actions. It enables users to perform any maintenance actions by providing pause/resume functionality. The Watchdog support feature makes the framework even more robust.

You may also like:  Scalability and High Availability

How It Works

Initially, PostgreSQL and Patroni binaries need to be installed. Once this is done, you will also need to set up an HA DCS configuration. All the necessary configurations to bootstrap the cluster needs to be specified in the YAML configuration file, and Patroni will use this file for initialization. On the first node, Patroni initializes the database, obtains the leader lock from DCS, and ensures the node is being run as the master.

The next step is adding standby nodes for which Patroni provides multiple options. By default, Patroni uses pg_basebackup to create the standby node and also supports custom methods like WAL-E, pgBackRest, Barman, and others for the standby node creation. Patroni makes it very simple to add a standby node and handles all the bootstrapping tasks and the setting up of your streaming replication.

Once your cluster setup is complete, Patroni will actively monitor the cluster and ensure it’s in a healthy state. The master node renews the leader lock every ttl second(s) (default: 30 seconds). When the master node fails to renew the leader lock, Patroni triggers an election, and the node, which will obtain the leader lock, will be elected as the new master.

How Does It Handle the Split-Brain Scenario?

In a distributed system, consensus plays an important role in determining consistency, and Patroni uses DCS to attain consensus. Only the node that holds the leader lock can be the master, and the leader lock is obtained via DCS. If the master node doesn’t hold the leader lock, then it will be demoted immediately by Patroni to run as a standby. This way, at any point in time, there can only be one master running in the system.

Are There Any Setup Requirements?

• Patroni needs python 2.7 and above.
• The DCS and its specific python module must be installed. For test purposes, DCS can be installed on same nodes running PostgreSQL. However, in production, DCS must be installed on separate nodes.
• The YAML configuration file must be present using these high-level configuration settings:

  Global/Universal This includes configuration such as the name of the host (name), which needs to be unique for the cluster, the name of the cluster (scope), and the path for storing config in DCS (namespace). Log Patroni-specific log settings including level, format, file_num, file_size, etc. Bootstrap configuration This is the global configuration for a cluster that will be written to DCS. These configuration parameters can be changed with the help of Patroni APIs or directly in DCS. The bootstrap configuration includes standby creation methods, initdb parameters, post initialization script, etc. It also contains timeouts configuration, parameters to decide the usage of PostgreSQL features like replication slots, synchronous mode, etc. This section will be written into /<namespace>/<scope>/config of a given configuration store after the initializing of the new cluster. PostgreSQL This section contains the PostgreSQL-specific parameters like authentication, directory paths for data, binary and config, listen ip address, etc. REST API This section includes the Patroni-specific configuration related to REST API’s, such as listen address, authentication, SSL, etc. Consul Settings specific to Consul DCS. Etcd Settings specific to Etcd DCS. Exhibitor Settings specific to Exhibitor DCS. Kubernetes Settings specific to Kubernetes DCS. ZooKeeper Settings specific to ZooKeeper DCS. Watchdog Settings specific to Watchdog.

Patroni Pros

• Patroni enables end-to-end setup up of the cluster
• Supports REST APIs and HAproxy integration
• Supports event notifications via callbacks scripts triggered by certain actions
• Leverages DCS for consensus

Patroni Cons

• Patroni will not detect the misconfiguration of a standby with an unknown or non-existent node in the recovery configuration. The node will be shown as a slave even if the standby is running without connecting to the master/cascading standby node.
• The user needs to handle setup, management, and upgrades of the DCS software.
• Requires multiple ports to be open for components communication:
  • REST API port for Patroni
  • Minimum 2 ports for DCS

High Availability Test Scenarios

We conducted a few tests on PostgreSQL HA management using Patroni. All of these tests were performed while the application was running and inserting data into the PostgreSQL database. The application was written using PostgreSQL Java  leveraging the connection failover capability.

Standby Server Tests

Master/Primary Server Tests

Network Isolation Tests

What’s the Best PostgreSQL HA Framework?

Patroni is a valuable tool for PostgreSQL database administrators (DBAs), as it performs end-to-end setup and monitoring of a PostgreSQL cluster. The flexibility of choosing DCS and standby creation is an advantage to the end-user, as they can choose the method they are comfortable with.

REST APIs, HaProxy integration, Watchdog support, callbacks, and its feature-rich management makes Patroni the best solution for PostgreSQL HA management.

PostgreSQL HA Framework Testing: PAF vs. repmgr vs. Patroni

Included below is a comprehensive table detailing the results of all the tests we have performed on all three frameworks — PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr), and Patroni.

Standby Server Tests

Master/Primary Server Tests

Network Isolation Tests

Further Reading

What Developers Can Do to Help Achieve High Availability