本文へ移動

はじめに

Patroniの紹介、クイックスタート、高可用性の基本概念。

Patroniは、Pythonを使用した高可用性（HA）PostgreSQLソリューションのテンプレートです。PatroniはComposeのプロジェクトであるGovernor のフォークとして誕生し、多くの新機能を備えています。

背景については、次も参照してください。

開発状況

Patroniは活発に開発されており、貢献を受け付けています。詳しくは、貢献 のセクションを参照してください。

新しいリリースの情報はこちら でお知らせしています。

技術要件とインストール

各プラットフォームでのPatroniのインストールとアップグレードについては、こちら を参照してください。

PostgreSQLノード数の計画

Patroni/PostgreSQLのノードは、Patroni自身がRAFTを実装する場合を除き、DCSノードから独立しているため、最小ノード数に関する要件はありません。プライマリー一つとスタンバイ一つからなるクラスターでも問題なく動作します。後からスタンバイノードを追加できます。

2ノードのクラスター（プライマリーとスタンバイ）は一般的な構成で、高可用性を備えた自動フェイルオーバーを提供します。ただし、フェイルオーバー中は、障害が発生したノードが再参加するまで、一時的に冗長性がなくなることに注意してください。

DCSの要件：適切なコンセンサスと耐障害性を確保するには、DCS（etcd、ZooKeeper、Consul）を3または5ノードで実行する必要があります。単一のDCSクラスターに、異なるnamespaceとscopeの組み合わせを使用して、数百から数千のPatroniクラスターの情報を保存できます。

実行と構成

以下では、Patroniリポジトリをhttps://github.com/patroni/patroni からクローンしていることを前提とします。具体的には、構成ファイルの例であるpostgres0.ymlとpostgres1.ymlが必要です。pipでPatroniをインストールした場合は、gitリポジトリからこれらのファイルを取得し、以下の./patroni.pyをpatroniコマンドに置き換えられます。

開始するには、それぞれ別のターミナルで次を実行します。

> etcd --data-dir=data/etcd --enable-v2=true
> ./patroni.py postgres0.yml
> ./patroni.py postgres1.yml

これで高可用性クラスターが起動します。YAMLファイルの設定を変更して、クラスターの動作がどのように変化するか試してください。一部のコンポーネントを強制終了して、システムの動作を確認してください。

postgres*.ymlファイルを追加すると、さらに大きなクラスターを作成できます。

PatroniはHAProxy の構成を提供しており、アプリケーションからクラスターのリーダーへ接続するための単一のエンドポイントを用意できます。構成するには、次を実行します。

> haproxy -f haproxy.cfg

> psql --host 127.0.0.1 --port 5000 postgres

YAMLによる構成

etcd、Consul、ZooKeeperの設定に関する詳しい情報は、こちら を参照してください。例はpostgres0.yml を参照してください。

環境変数による構成

環境変数を使用して設定を構成、上書きする方法については、こちら を参照してください。

レプリケーションの選択肢

Patroniは、デフォルトで非同期となるPostgresのストリーミングレプリケーションを使用します。Patroniの非同期レプリケーションでは、maximum_lag_on_failoverを設定できます。この設定により、フォロワーがリーダーから一定のバイト数を超えて遅れている場合に、フェイルオーバーが発生しないことを保証します。業務要件に応じて、この設定値を増減することを推奨します。より強い永続性の保証を得るため、同期レプリケーションを使用することもできます。詳しくは、レプリケーションモードのドキュメント を参照してください。

アプリケーションでスーパーユーザーを使用しない

アプリケーションから接続するときは、常にスーパーユーザー以外を使用してください。Patroniが正しく動作するには、データベースへのアクセスが必要です。アプリケーションでスーパーユーザーを使用すると、superuser_reserved_connections設定でスーパーユーザー用に予約された接続まで含めて、コネクションプール全体を使い切る可能性があります。コネクションプールがいっぱいになってPatroniがプライマリーにアクセスできなくなると、望ましくない動作につながります。

HAソリューションのテスト

HAソリューションのテストには、多くの変数が関係し、時間がかかります。複数のプラットフォームに対応するアプリケーションでは、特にそうです。この作業には、訓練を受けたシステム管理者またはコンサルタントが必要です。ドキュメントで詳しく扱いきれるものではありません。

そのうえで、インフラストラクチャーの次の要素は、必ずテストすることを推奨します。

  • ネットワーク（システムの手前にあるネットワークと、NIC［物理または仮想］自体）
  • ディスクI/O
  • ファイル数の制限（Linuxではnofile）
  • RAM。oomkillerを無効にしていても、RAMを利用できなくなると問題が生じる可能性があります。
  • CPU
  • 仮想化環境のリソース競合（ハイパーバイザーのオーバーコミット）
  • cgroupによるあらゆる制限（上記に関連する可能性があります）
  • postgresプロセスに対するkill -9（postmasterは除く）。これはセグメンテーションフォールトの適切なシミュレーションになります。

行うべきでないのは、postmasterプロセスに対するkill -9です。これは、現実のシナリオを模倣しないためです。インフラストラクチャーが安全でなく、攻撃者がkill -9を実行できることを懸念しているのであれば、どのようなHAの仕組みでも解決できません。攻撃者は単にプロセスを再び強制終了するか、別の方法で混乱を引き起こすだけです。

最終更新 2026年9月8日 · refactor(docs): move component documentation under /docs (f643529)
Patroni documentation (v4.1.5)（Copyright (c) 2025 Compose, Zalando SE, Patroni Contributors、MIT License）を基に改変。帰属と変更履歴を参照してください。
このページは翻訳です。正式な内容は原文に従います。