速習！ PostgreSQL専用HAソフトウェア: Patroni（PostgreSQL Conference Japan 2023 発表資料）

速習！ PostgreSQL専用HAソフトウェア: Patroni
2023/11/24
株式会社NTTデータグループ
鳥越淳

© 2023 NTT DATA Group Corporation 2
自己紹介
鳥越淳(とりこしあつし)
@atorik_shi on X/Twitter
• 2008年頃からオープンソースソフトウェアを扱う業務に従事
• 2015年頃からPostgreSQLのサポート・開発
• 『PostgreSQL徹底入門第4版』(翔泳社) 8～13章執筆

アジェンダ
01. PostgreSQLとHA
02. Patroniの概要・仕組み
03. 動作から理解するPatroni
04. Patroniの運用
05. まとめ

（セッションの注意事項）
• 本講演で紹介する機能や仕様は、将来的に変更される可能性があることにご注意くださ
い。
• その他、記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商
標です。

HAとは [1]
• 可用性が高い状態のことで、システムが提供している機能やサービスが停止・
中断する頻度や時間を極力少なく抑えること
• 狭義には、複数のコンピュータを束ねて一体的に運用し、あたかも一台のコン
ピュータであるかのように振る舞わせるクラスタリング（clustering）技術により、
一台が停止しても全体が停止しないようにした状態（高可用性クラスタ）
PostgreSQL
プライマリ
PostgreSQL
レプリカ1
PostgreSQL
レプリカN
[1] https://e-words.jp/w/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7.html
クラスタ
…
本資料での呼称
インスタンスインスタンスインスタンス

PostgreSQLとHA ～PostgreSQLができること～
• レプリケーション
✓ WALを転送してDBを複製
✓ レプリカへのレプリケーション完了を待つ同期, 待たない非同期方式がある
• クラスタの各種操作
✓ レプリカの作成・昇格など
PostgreSQL
プライマリ
PostgreSQL
レプリカ
WAL転送 WALリプレイ

PostgreSQLとHA ～PostgreSQLがしないこと～
• PostgreSQLクラスタの状態に応じた自動運用
✓ プライマリの障害を検知し、適切なレプリカを昇格
✓ 同期レプリカの障害を検知し、当該レプリカをプライマリから切り離し
✓ プライマリがcluster全体で1台であること
など
⇒ “PostgreSQLがしないこと”は、HAソフトウェアを利用して補完

02.
Patroniの概要・仕組み
9

Patroniの概要
• PostgreSQL用HAソフトウェア
• オープンソースソフトウェア(MIT License)
• 主な開発元はZalando SE
• Zalando (ザランド)は、ヨーロッパ地域を対象に、ファッションおよびライフスタイル関連商品を取り扱うウェブサイ
トおよびアプリ[1]
• Python実装
• Kubernetesでは、いくつかのPosgreSQL Operator(Zalando, PGO,
StackGres)の内部で利用
[1] https://ja.wikipedia.org/wiki/Zalando

Patroniの特徴
• 各インスタンスの状態は、etcdなど一貫性が保証されたDistributed
Consensus Store(DCS)に保存
✓ DCSの存在がアーキテクチャ上の大きな特徴。cf. Pacemaker
✓ Kubernetes環境では、Kubernetesが利用するetcdに保存可能※。別途DCSを構
築する必要なし
• 2インスタンスのほか、3インスタンス以上のPostgreSQLクラスタも構成可能
• REST APIを提供。主な用途は以下:
✓ ユーザによるコマンド操作(patronictlコマンド)
✓ HA ProxyやLBがクラスタのプライマリを把握
✓ Patroni自身が利用
※ ConfigMapまたはEndpoint等を利用。パラメータuse_endpointsが有効な場合、Endpointを利用

Patroniのアーキテクチャ
• PostgreSQLインスタンスごとに1つのPatroniを起動
• 各Patroniは自身が担当するPostgreSQLの状態を取得し、DCSに格納
• 他のPatroniともやりとりしながら、必要に応じてPostgreSQLを操作
PostgreSQL Patroni
etcd
etcd
DCS
①DBの状態を取得
PostgreSQL Patroni
②DCSを更新/他の
ノードの状態を取得
③他のPatroniとREST
APIでやりとり
④DB操作

DCS
• Distributed Consensus Store
• たとえばetcdでは以下の特徴:
• Key-Valueの形でデータを保存
• TTL経過後オブジェクトを自動削除することも可能
• プライマリダウンの検知などに利用
• 合意アルゴリズムであるRAFTを実装
• DCS自体も複数ノードから構成可能。多数決原理で動作するため通常奇数台で
構成
• 高い一貫性を保証可能。例えば、複数ノード構成でもあたかも単一ノードしかない
かのように振舞ってくれる

03.
動作から理解するPatroni
①基本動作
1

Patroniの基本動作
• 以降同期レプリカ1台、非同期レプリカ1台の3インスタンス構成を想定して説明
• loop_wait(デフォルト10秒)で、①，②を繰り返す
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
非同期レプリカ
Patroni
Patroni
Patroni
etcd
etcd
DCS
②DCSを更新、確認
①DBの状態を取得 ②DCSを更新、確認
#1
#2
#3

Patroniの基本動作(DB状態取得)
• 自ノードのPostgreSQLへクエリを実行、レプリケーションの状況などDBの状態を取得
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
Patroni
Patroni
Patroni
etcd
etcd
DCS
#1
#2
#3
例
・現在WAL位置: pg_current_wal_flush_lsn()
・レプリケーション状況: pg_stat_replication相当
例
・SELECT pg_stat_get_wal_receiver()
・SELECT pg_last_wal_receive_lsn()
・SELECT pg_is_wal_replay_paused()
例
・リカバリ状況: pg_stat_wal_receiver相当
・リカバリ停止中か: pg_is_wal_replay_paused()

Patroniの基本動作(DCS更新、確認)
• PostgreSQLから取得した情報をDCSへ格納
• DCSにはだれがプライマリか(leader)、クラスタに参加しているノード(member)などを保存
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
Patroni
Patroni
Patroni
etcd
etcd
DCS
#1
#2
#3
・PUT: members/[自分]
・PUT: leader
など。リースを設定し、更新が
ない場合自動削除
・leader
・members
・config
などを保存
• PUT: members/[自分]
• GET: leader
• PUT: members/[自分]
• GET: leader

03.
②プライマリ故障
1

プライマリ故障時の動作
• #1故障後、#2がプライマリになる場合
PostgreSQL
プライマリ
PostgreSQL
プライマリ
PostgreSQL
Patroni
Patroni
Patroni
etcd
etcd
DCS
②primary不在を検知
①leaderキーがexpire
③自分が
primary候補に
相応しいか確認
例
・同期レプリケーションしていたレプリカか
・Patroniの設定上リーダーになるのを禁止
されていないか
・watchdogが有効か
⑤primaryに昇格
⑥primary変更を検知
⑦同期先
を変更
⑧#3をsync
standbyに
登録
#1
#2
#3
④leaderキーに自身を登録

旧プライマリ復旧時の動作
• 非同期レプリカとしてクラスタに組み込まれる
PostgreSQL
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
Patroni
Patroni
Patroni
etcd
etcd
DCS
#1
#2
#3
①DCS確認、#2がプライマリ
#3が同期レプリカと把握
②#2の非同期レプリカ
として参加

03.
③同期レプリカ故障
2

同期レプリカ故障時の動作
• #2障害発生後、#3が同期レプリカになる場合
• 同期レプリカ障害時にはクラスタから切り離す※。さもないと書き込みリクエストが完了しない
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
同期レプリカ
Patroni
Patroni
Patroni
etcd
etcd
DCS
①pg_stat_replication
から#2のダウンを検知
例.
・許容値※以上の遅延が発生していな
いか
#1
#2
#3
②同期レプリカに相応しい
レプリカを選出し、
PostgreSQLの設定を変更 ③選出した
同期レプリカを
DCSに登録
※パラメータmaximum_lag_on_syncnodeで
指定可能

旧同期レプリカ復旧時の動作
• 非同期レプリカとしてクラスタに組み込まれる
PostgreSQL
プライマリ
PostgreSQL
PostgreSQL
同期レプリカ
Patroni
Patroni
Patroni
etcd
etcd
DCS
#1
#2
#3
①DCS確認、
#1がプライマリ、
#3が同期レプリカと把握
②#1の非同期レプリカ
として参加
SELECT

03.
④DCS故障
2

DCS故障時の動作
• DCS全台停止やDCSとのNW障害を想定
• プライマリが降格され全インスタンスがレプリカとなり、書き込み処理できなくなる
PostgreSQL
レプリカ
PostgreSQL
レプリカ
PostgreSQL
レプリカ
Patroni
Patroni
Patroni
etcd
etcd
DCS
②降格(PostgreSQLを
停止し、読込専用で起動)
①DCSアクセスに失敗
#1
#2
#3

DCS故障後の復旧
• リーダー選出が行われプライマリに昇格、書き込み処理が可能になる
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
Patroni
Patroni
Patroni
etcd
etcd
DCS
①DCSアクセスに成功
①DCSアクセスに成功
①DCSアクセスに成功、
Leader electionが動作
#1
#2
#3
②leaderとして動作

DCS故障時の動作(failsafe_mode有効時)
• v3.0.0から、DCS故障時も、プライマリが他の全Patroniにアクセス可能であれば、プライマリと
して継続動作可能とするオプションfailsafe_modeが追加
3.0.0~
PostgreSQL
プライマリ
PostgreSQL
同期レプリカ
PostgreSQL
Patroni
Patroni
Patroni
etcd
etcd
DCS
②降格せずにPrimaryのま
ま動作
#1
#2
#3
①クラスタを構成する全ての
Patroniにアクセス可能なら..

Patroniが対応しない故障
Pacemakerなど他のHAソフトウェアと異なり、
以下の故障については、Patroniは系切替などの操作は実施しない。
Patroniとしては、これらの故障は別途監視システムで監視すべきという考え方の
模様※
• PostgreSQL動作に影響を与えないディスク障害
• Patroniが通信に利用しないネットワークの障害
※ -- https://github.com/zalando/patroni/issues/665
It is basically your responsibility to set up an extensive monitoring system, which will do lots of checks, like
CPU Utilization, free space on different partitions, hardware failures, number of open and active
connections and many many more.

04.
Patroniの運用
2

Patroniの設定の定義先
Patroniの設定の定義先は3つ:
• DCS
• クラスタの全てのノードに適用される設定
• patronictlコマンドのedit-configまたはREST API経由で変更
• Patroni自体の設定のほか、PostgreSQLの設定も含まれる(次ページで解説)
• 設定ファイル
• patroni.yml
• SIGHUP、patronictl reloadコマンド、またはREST API経由で変更
• DCS上の設定より優先される
• 環境変数
• 設定ファイルで記載するパラメータについて環境変数で設定可能

PostgreSQLのパラメータの扱い
• PostgreSQLの設定も基本的にPatroni経由で設定する必要があるので注意
• Patroniのpostgresql.confの扱い
• オリジナルのpostgresql.confはpostgresql.base.confにリネーム
• DCS上のPostgreSQLの設定をpostgresql.confに出力、 postgresql.base.confをinclude
• さらに一部のパラメータをPostgreSQL起動時に指定
• クラスタを構成する全ノードで同じ値にすべきPostgreSQLのパラメータは、DCSに設定が
必要。具体的なパラメータはマニュアル[1]を参照
例. max_connections, max_locks_per_transaction, wal_levelなど
[1] https://patroni.readthedocs.io/en/latest/patroni_configuration.html
postgres -D data/postgresql1
--config-file=/Users/tori/data_patroni/data/postgresql0/postgresql.conf
--listen_addresses=127.0.0.1 --port=5432 …
Patroniから起動されたpostgresプロセスのpsコマンド出力抜粋

PostgreSQLのパラメータの扱い
• クラスタを構成する全ノードで同じ値にすべきPostgreSQLのパラメータは、DCSに設定が
必要。具体的なパラメータはマニュアル[1]を参照
例. max_connections, max_locks_per_transaction, wal_levelなど
• patroni.ymlのbootstrap.dcs.postgresql.parameters以下にPostgreSQLのパラメータ
値が列挙できるが、Patroni初回起動時のみ作用するので注意。初回起動以外は
patronictl edit-configコマンドなどで変更が必要
• PatroniのパラメータによってPostgreSQLのパラメータが決まるものもあるので注意
例. postgresql.listen -> listen_addresses、port

PostgreSQLのパラメータの反映タイミング
反映にPostgreSQLの再起動が必要なパラメータ※は即時には反映せず、次回起動時に反
映される。該当インスタンスには、パラメータ反映までPatroni上pending_restartというフラグが
立てられる:
※contextがpostmasterのGUCパラメータ
$ patronictl list
+ Cluster: batman (7302698360463234666) ------------------------------------------------------+
| Member | Host | Role | State | TL |Lag in MB | Pending restart |
+-------------+--------------------+----------------+-----------+---+------------+------------------+
| postgresql0 | 127.0.0.1:15432 | Sync Standby | streaming | 13 | 0 | * |
| postgresql1 | 127.0.0.1:15433 | Leader | running | 13 | | |
| postgresql2 | 127.0.0.1:15434 | Replica | streaming| 13 | 0 | |
+-------------+--------------------+----------------+------------+---+-----------+------------------+

PostgreSQL管理についての注意
• PostgreSQLを再起動する際は、直接PostgreSQLを再起動するとF/Oが発生する可能
性あり。-> patronictl restartコマンドなどを利用する
• PatroniのみにPostgreSQLを制御させる。Patroni以外がPostgreSQLを起動停止でき
る場合、プライマリが2重起動などするおそれ
例. systemd

PostgreSQLの非同期レプリケーションに関する主なPatroni設定
• maximum_lag_on_failover
• 範囲内のデータサイズで遅延している非同期レプリカをプライマリに昇格
• ただし、Patroniはリアルタイムでレプリケーションの遅延量を把握していないので、実際に
はこれ以上のデータが失われる可能性がある点注意

PostgreSQLの同期レプリケーションに関する主なPatroni設定
• synchronous_mode
• 有効にすると、レプリカを同期レプリケーションとして選択
• プライマリが故障した場合、同期レプリカを昇格する。非同期レプリカが存在してもこちら
は昇格させない
• synchronous_modeをonにしても、同期レプリカが存在しない状況は発生する
例. 同期レプリカ故障後、適切な同期レプリカ候補が見つかっていないタイミング
• この状況でプライマリが故障すると、プライマリに昇格できるノードが存在せず
PostgreSQLクラスタは書き込みできなくなる
• synchronous_mode_strict
• 有効にすると、同期スタンバイが動作するまでPostgreSQLへの書き込みを禁止するこ
とも可能

05.
まとめ
3

• Patroniは、PostgreSQLのクラスタを構成できるHAソフトウェア
• etcdなどのデータストアを利用してクラスタの状態を管理。3ノード以上のクラスタも構成可能
• 他のHAソフトウェアとは系切替をする障害が異なる点に注意
• PostgreSQLの設定やinitdbなどもPatroniが実施するため、通常のPostgreSQLと運用が
変わる点も注意
まとめ

速習！ PostgreSQL専用HAソフトウェア: Patroni（PostgreSQL Conference Japan 2023 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 速習！ PostgreSQL専用HAソフトウェア: Patroni（PostgreSQL Conference Japan 2023 発表資料）

Similar to 速習！ PostgreSQL専用HAソフトウェア: Patroni（PostgreSQL Conference Japan 2023 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (10)

速習！ PostgreSQL専用HAソフトウェア: Patroni（PostgreSQL Conference Japan 2023 発表資料）