Advanced PostgreSQL: Indexing, Partitioning, Replication · 课时

自动故障转移工具（Patroni）

使用 Patroni 等工具配置和管理自动故障转移，在主服务器发生故障时最大限度地减少停机时间。

自动故障转移工具（Patroni） 是 CoddyKit 上的免费 Advanced PostgreSQL: Indexing, Partitioning, Replication 课时。这是第 1 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Advanced PostgreSQL: Indexing, Partitioning, Replication 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Advanced PostgreSQL: Indexing, Partitioning, Replication 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why Automatic Failover?

Imagine your main PostgreSQL database suddenly stops working. Without a plan, your application goes down, leading to unhappy users and lost business.

Automatic failover is a strategy to prevent this. It quickly switches to a backup database (a 'standby') when the primary fails, often without any manual intervention.

This ensures your service stays available, minimizing downtime and improving reliability.

Introducing Patroni

Meet Patroni – a powerful, open-source tool designed to manage highly available PostgreSQL clusters.

Patroni acts as a 'template' or 'framework' for PostgreSQL HA, handling complex tasks like primary election, failover, and standby management automatically.

It simplifies the setup and maintenance of robust, fault-tolerant PostgreSQL systems.

Patroni's Core Architecture

Patroni doesn't work alone. It orchestrates several components to achieve high availability:

PostgreSQL Instances: The actual database servers (primary and standbys).
Patroni Agents: A process running on each PostgreSQL node, monitoring its health and communicating with the cluster.
Distributed Consensus Store (DCS): A reliable external service (like etcd, Consul, or ZooKeeper) that stores the cluster state and facilitates primary election.

These components work together to ensure a healthy primary is always available.

The Distributed Consensus Store (DCS)

The Distributed Consensus Store (DCS) is Patroni's brain. It's a critical component for maintaining a consistent view of the cluster state across all nodes.

Popular DCS options include:

etcd: A highly-available key-value store.
Consul: A service networking solution with a key-value store.
ZooKeeper: A centralized service for maintaining configuration information.

Patroni uses the DCS to store information like the current primary, replication status, and configuration, enabling robust primary election and failover.

Patroni Agents & PostgreSQL

Each PostgreSQL server in your cluster runs a Patroni agent. This agent is responsible for:

Monitoring the health of its local PostgreSQL instance.
Communicating its status to the DCS.
Participating in primary election.
Performing actions like promoting a standby to primary or configuring replication.

The Patroni agent ensures that the PostgreSQL instance it manages is always in the correct state, whether it's a primary or a standby.

Setting Up Patroni: Overview

A typical Patroni setup involves:

Installing Patroni and PostgreSQL on multiple servers.
Configuring a DCS (e.g., a 3-node etcd cluster).
Creating a patroni.yml configuration file for each PostgreSQL node.
Starting Patroni on all nodes, allowing it to initialize PostgreSQL and form the cluster.

Patroni then automatically handles the initial primary election and sets up streaming replication.

Basic Patroni Configuration (YAML)

Patroni is configured using a YAML file, typically named patroni.yml. Here's a simplified example showing key sections:

This file defines the cluster name, REST API settings, and PostgreSQL-specific parameters.

scope: my_pg_cluster
name: pg1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.101:8008

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.101:5432
  data_dir: /var/lib/postgresql/data
  pgpass: /etc/patroni/pgpass
  replication:
    username: replicator
    password: supersecretpassword
  parameters:
    archive_mode: 'on'
    archive_command: 'cp %p /var/lib/postgresql/archives/%f'
    max_wal_senders: 10

Monitoring Your Patroni Cluster

You can check the health and status of your Patroni cluster using the patronictl command-line tool.

The patronictl list command provides a quick overview of all cluster members, their roles (primary/replica), status, and replication lag.

This helps you confirm that your HA setup is running as expected.

patronictl list my_pg_cluster

# Expected output similar to:
# + Cluster: my_pg_cluster (6956637370217961204)
# +-- Member + Host + Role + State + TL + Lag in MB | Pri. Txid + Conn. URL + 
# | pg1      | 10.0.0.1 | Primary | running | 1 |         0 | 123456789 | host=10.0.0.1 port=5432 user=admin dbname=postgres |
# | pg2      | 10.0.0.2 | Replica | running | 1 |         0 |           | host=10.0.0.2 port=5432 user=admin dbname=postgres |
# | pg3      | 10.0.0.3 | Replica | running | 1 |         0 |           | host=10.0.0.3 port=5432 user=admin dbname=postgres |

How Failover Happens

When the primary PostgreSQL server fails, Patroni initiates an automatic failover:

The Patroni agent on the failed primary stops updating its status in the DCS.
Other Patroni agents detect this absence through the DCS.
The remaining healthy standbys compete to become the new primary.
A new primary is elected by the DCS.
The new primary is promoted, and other standbys are reconfigured to follow it.

This entire process is automated, ensuring minimal disruption to your application.

Quick Check: Patroni Components

Which of the following are essential components that Patroni leverages to provide automatic failover capabilities for a PostgreSQL cluster?

Recap: Patroni for HA

In this lesson, we explored Patroni, a powerful tool for achieving automatic failover and high availability in PostgreSQL.

Patroni orchestrates PostgreSQL instances, using Patroni agents on each node.
It relies on a Distributed Consensus Store (DCS) like etcd for cluster state and primary election.
This architecture ensures that if a primary fails, a new one is automatically promoted, minimizing downtime.

Understanding Patroni is key to building resilient PostgreSQL systems.

常见问题解答

「自动故障转移工具（Patroni）」课时是免费的吗？

是的 — 「自动故障转移工具（Patroni）」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Advanced PostgreSQL: Indexing, Partitioning, Replication 课程的其余内容，请升级到 CoddyKit PRO。 Advanced PostgreSQL: Indexing, Partitioning, Replication 课程共包含 4 节课。

「自动故障转移工具（Patroni）」这节课中我会学到什么？

使用 Patroni 等工具配置和管理自动故障转移，在主服务器发生故障时最大限度地减少停机时间。你通过在浏览器中直接运行的动手代码来练习 Advanced PostgreSQL: Indexing, Partitioning, Replication，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Advanced PostgreSQL: Indexing, Partitioning, Replication 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Advanced PostgreSQL: Indexing, Partitioning, Replication 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 1 节课，共 4 节。

「自动故障转移工具（Patroni）」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Advanced PostgreSQL: Indexing, Partitioning, Replication 课中编写并运行代码吗？

能。每节 Advanced PostgreSQL: Indexing, Partitioning, Replication 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Advanced PostgreSQL: Indexing, Partitioning, Replication