Understanding and implementing PostgreSQL High Availability with Patroni

Postgres has a rock-solid single master physical replication, but lacks built-in failover. A number of open-source and proprietary tools aim to fill this niche. Patroni stands apart because it doesn’t try to solve all hard problems by itself. Being a successor of Compose Governor, it relies on an external consistency layer supported by battle-proven solutions like Etcd, Consul, Zookeeper or the Kubernetes API to avoid split-brains and unnecessary failovers.

Patroni is customizable and extensible, recognizing the multitude of tools, such as those for creating new replicas, connection poolers, load balancers, monitoring solutions or watchdogs that it needs to interact with during or after the failover and therefore it can be adapted to a wide variety of database environments, from bare-metal data centers to cloud based computing units and docker-based environments like Kubernetes, without changing the core failover logic. It provides a tunable balance between availability and consistency, allowing the operator to choose how long to wait before recognizing a suddenly unresponsive primary as dead, or use synchronous replication to exclude the possibility of data loss altogether. Patroni also offers customizable retries to deal with network issues. It makes most of PostgreSQL physical replication by offering support for replication slots, pg_rewind, cascading and synchronous replication.

Patroni is trusted by various small and large companies, among them are Zalando, IBM Compose, TimescaleDB and, recently, Gitlab. It Is open-source and developed in the open by a group of contributors from various companies and locations around the world.

Based on our experience developing and running Patroni at Zalando, as well as providing support to the global community over GitHub issues and other channels, we will teach you:

• Common pitfalls of PostgreSQL automatic failover solutions and how Patroni avoids them.
• Patroni architecture and various options to tune it to your environment.
• How to manage PostgreSQL configuration with Patroni and keep your replicas configuration in-sync with the primary.
• Various REST API endpoints to help monitor and manage Patroni.
• How to use patronictl tool as a more human-friendly alternative to the REST API.
• How to make clients connect to the primary (or standby) PostgreSQL.
• Features, allowing to extend Patroni, supporting your favorite tool to create new replicas or even clone the whole cluster.
• Many useful features, such as scheduled switchovers and restarts, maintenance mode, standby clusters etc.
• How to read Patroni logs and troubleshoot common issues.

We expect participants to be familiar with basic PostgreSQL administration routines. A docker image will be provided for hands-on sessions, we advice to bring your own laptop and install docker.