0Pricing
Advanced PostgreSQL: Indexing, Partitioning, Replication · レッスン

自動フェイルオーバーツール（Patroni）

Patroniなどのツールを使って自動フェイルオーバーを設定・管理し、プライマリサーバー障害時のダウンタイムを最小限に抑えます。

「自動フェイルオーバーツール（Patroni）」はCoddyKit上の無料Advanced PostgreSQL: Indexing, Partitioning, Replicationレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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:

  1. Installing Patroni and PostgreSQL on multiple servers.
  2. Configuring a DCS (e.g., a 3-node etcd cluster).
  3. Creating a patroni.yml configuration file for each PostgreSQL node.
  4. 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:

  1. The Patroni agent on the failed primary stops updating its status in the DCS.
  2. Other Patroni agents detect this absence through the DCS.
  3. The remaining healthy standbys compete to become the new primary.
  4. A new primary is elected by the DCS.
  5. 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）」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Advanced PostgreSQL: Indexing, Partitioning, Replicationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Advanced PostgreSQL: Indexing, Partitioning, Replicationコースには全4レッスンが含まれています。

「自動フェイルオーバーツール（Patroni）」で何を学びますか？

Patroniなどのツールを使って自動フェイルオーバーを設定・管理し、プライマリサーバー障害時のダウンタイムを最小限に抑えます。 ブラウザで直接実行するハンズオンコードでAdvanced PostgreSQL: Indexing, Partitioning, Replicationを演習し、24時間対応の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フィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 自動フェイルオーバーツール（Patroni）
  2. レプリケーションの健全性監視
  3. ディザスタリカバリ戦略
  4. PgBouncerとHAProxyによる接続ルーティング
← Advanced PostgreSQL: Indexing, Partitioning, Replicationに戻る