repmgr（Replication Manager）は、PostgreSQL標準のストリーミングレプリケーションに、スタンバイの作成・監視・昇格・切り戻しの操作を足すEDB製のオープンソースツールです。この記事では、2026年10月28日にrepmgr 5.5.0をPostgreSQL 18.6向けにソースからビルドし、primary・standby・witnessの3ノードで構築から自動フェイルオーバー、旧プライマリの復帰までを実行した結果をもとに、手順と落とし穴を説明します。
まとめ：repmgrの要点
- 最新版は5.5.0（2024年11月20日）で、現行ドキュメントの対象はPostgreSQL 13〜18です。PostgreSQL 18は2026年10月2日のコミットで互換表に追記されました。Windowsは非対応です。
- 構成は、操作用のコマンド
repmgrと、監視と自動フェイルオーバーを担うデーモンrepmgrdの2つです。マルチマスターは扱いません。 - repmgrdが昇格を始めるまでの待ち時間は、主に
reconnect_attemptsとreconnect_intervalで決まります。最後の試行の後は待たないため、再接続の待機は「試行回数−1」回です。既定（6回・10秒間隔）なら待機だけで50秒、3回・2秒にした実測では停止から昇格完了まで6〜8秒でした。 - 旧プライマリの復帰は
repmgr node rejoin --force-rewindで行いますが、--dry-runが通っても本番でpg_rewindが失敗することがあります。実測ではwal_keep_sizeの設定と--config-filesの指定で解消しました。 - STONITH型のフェンシングは内蔵していません。新規にHA基盤を選ぶなら、リリースが続いているPatroni（4.1.5・2026年8月）を先に検討し、VM数台の単純な構成を既存の運用手順で回したい場合にrepmgrを選ぶのが妥当です。
repmgrの構成要素と対応バージョン
repmgr（コマンド）とrepmgrd（デーモン）の役割
repmgr は、ノードの登録（primary register / standby register / witness register）、pg_basebackupを使ったスタンバイの作成（standby clone）、手動の昇格や切替（standby promote / standby switchover）、状態確認（cluster show / node check）を行うコマンドです。repmgrd は各ノードで常駐し、上流ノードへの接続を監視して、途絶えたときに昇格候補を選び promote_command を実行します。クラスタの構成情報は、各ノードの repmgr データベースに入る拡張機能（shared_preload_libraries='repmgr' が必要）のテーブルで共有されます。
repmgrd を常駐させない運用もできます。その場合、障害時の昇格は人が repmgr standby promote を打つ手動フェイルオーバーになります。5.5.0のサンプル設定でも failover の既定値は manual です。
5.5.0の対応PostgreSQL（13〜18）と公式内の表記揺れ
repmgrの最新リリースは5.5.0で、リリースノートの日付は2024年11月20日、追加点はPostgreSQL 17への対応です。それ以降、2026年10月時点まで新しい版は出ていません。
PostgreSQL 18については、2026年10月2日のコミット（#921）でREADMEと互換表に18が追記されました。コミットの説明には、PostgreSQL 18で追加作業なしに動くことを確認済みと書かれています。現行ドキュメントの冒頭も対象を「PostgreSQL 13 – PostgreSQL 18」としています。
ただし、公式サイトの中で表記が揃っていません。repmgr.orgのトップは「PostgreSQL 12 ~ PostgreSQL 18」、公開中の要件ページの本文は「13.x以降のサポート中の版」と書いています。PostgreSQL本体のコミュニティサポートは12が2024年11月、13が2025年11月13日に終わっています。repmgrとの互換性があることと本体のサポート期間は別なので、新規に使うのはサポート中の14以降にしてください。
実際に、Homebrewで入れたPostgreSQL 18.6に対してrepmgr 5.5.0のソースをビルドし、以降の手順を実行しました。パッケージで入れる場合、Debian sidには postgresql-18-repmgr（5.5.0+debpgdg-3）が収録されています。
ライセンスと、repmgrが扱わない範囲
ライセンスはGPL v3で、開発はEDB（旧2ndQuadrant）です。EDBは24時間365日の本番サポートを案内しています。次の3点は対象外なので、要件にあれば別の手段が要ります。
- マルチマスター：書き込めるのは常に1台のプライマリです。複数ノードでの書き込みはEDB Postgres Distributed（旧BDR）やpgEdgeなど別製品の領域です。
- Windows：要件ページに「There is no support for Microsoft Windows」とあり、
repmgr.exeのような配布物はありません。LinuxやmacOSなどUNIX系で動かします。 - 接続先の切替とフェンシング：アプリケーションの接続先を新プライマリへ向ける仕組み（仮想IPやPgBouncerの書き換え）と、旧プライマリの強制停止は、
promote_commandやイベント通知から呼ぶスクリプトとして自分で用意します。
repmgrでPostgreSQL 18のHA構成を組む手順
ここでは、プライマリ（node1）、スタンバイ（node2）、witness（node3）の3ノードを組みます。検証は1台のmacOSでポートを分け、trust認証とpg_ctlの直接実行で行いました。以下の掲載例は、それを別サーバー3台・SCRAM認証・Debian系のパッケージ配置に置き換えたもので、設定項目の名前と役割は検証と同じです。witnessは本番では必ず別の物理ホストに置きます。公式ドキュメントは、他ノードと同じ物理ホストへのwitnessの設置を禁じています。レプリケーションの同期・非同期の考え方はデータベースレプリケーションの解説にまとめています。
postgresql.confとpg_hba.confの前提設定
プライマリに次の設定を入れます。wal_log_hints は後の node rejoin --force-rewind（pg_rewind）で必要になります。PostgreSQL 18は initdbの既定でデータチェックサムが有効になり、pg_rewindの要件（wal_log_hintsかデータチェックサムのどちらか）を満たすので、18で新規に作ったクラスタなら省略できます。17以前から pg_upgrade した場合はチェックサムが無効のままのことがあるため、入れておくのが安全です。
# postgresql.conf（プライマリ）
listen_addresses = '*' # 既定は localhost のみ。接続元は pg_hba.conf で絞る
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
wal_log_hints = on
wal_keep_size = '256MB' # node rejoin の失敗対策（後述）
shared_preload_libraries = 'repmgr'
# pg_hba.conf（repmgr ユーザーの接続と複製接続を許可する）
host repmgr repmgr 192.168.10.0/24 scram-sha-256
host replication repmgr 192.168.10.0/24 scram-sha-256続けて、repmgr用のユーザーとデータベースを作ります。検証では手順を単純にするため SUPERUSER にしました。スーパーユーザーにしない場合、PostgreSQL 15以降は pg_checkpoint ロールを付ければCHECKPOINTを実行でき、repmgr 5.5.0もこのロールの有無を確認します。ロールを付けないなら -S（--superuser）で別のスーパーユーザーを指定します。\password はpsqlのメタコマンドです。
パスワードは、repmgrを実行するOSユーザー（Debian系なら postgres）のホームに .pgpass を権限0600で置き、通常接続用と複製接続用の2行を書きます。データベース欄の replication は物理レプリケーション接続に一致します。
# ~postgres/.pgpass（chmod 0600）
*:5432:repmgr:repmgr:<パスワード>
*:5432:replication:repmgr:<パスワード>CREATE USER repmgr SUPERUSER;
\password repmgr
CREATE DATABASE repmgr OWNER repmgr;repmgr.confの最小構成
各ノードに1つずつ repmgr.conf を置きます。node_id・node_name・conninfo・data_directory の4つが必須で、自動フェイルオーバーを使うなら failover 以下を足します。conninfo の connect_timeout=2 は、落ちたノードへの接続待ちで監視が止まらないようにするための指定です。Debian系のパッケージでは service_*_command に pg_ctlcluster を書き、sudoersで postgres ユーザーにこの4コマンドだけを許可します。log_file のディレクトリは postgres ユーザーが書き込めるように作っておきます。
# /etc/repmgr.conf（node2 の例。node1/node3 は node_id・node_name・conninfo を変える）
node_id=2
node_name='node2'
conninfo='host=192.168.10.12 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/18/main'
pg_bindir='/usr/lib/postgresql/18/bin'
location='dc1'
# Debian系は pg_ctlcluster で起動・停止する（未設定だと pg_ctl を直接呼ぶ）
service_start_command='sudo /usr/bin/pg_ctlcluster 18 main start'
service_stop_command='sudo /usr/bin/pg_ctlcluster 18 main stop'
service_restart_command='sudo /usr/bin/pg_ctlcluster 18 main restart'
service_reload_command='sudo /usr/bin/pg_ctlcluster 18 main reload'
failover='automatic'
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
reconnect_attempts=3
reconnect_interval=2
monitor_interval_secs=2
log_file='/var/log/repmgr/repmgrd.log'primary register・standby clone・standby register・witness registerの実行
プライマリを登録し、スタンバイ側で standby clone を実行してデータディレクトリを複製します。先に --dry-run を付けると、walsenderの空き数や複製接続の可否を検査して、実行されるpg_basebackupのコマンド行を表示します。
# node1（プライマリ）
repmgr -f /etc/repmgr.conf primary register
# node2（スタンバイ）。データディレクトリは空にしておく
repmgr -h 192.168.10.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --dry-run
repmgr -h 192.168.10.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
pg_ctlcluster 18 main start
repmgr -f /etc/repmgr.conf standby register
# node3（witness）。別ホストで initdb・起動し、shared_preload_libraries='repmgr'、
# pg_hba.conf、repmgr ユーザーと repmgr データベースを node1 と同様に用意しておく
repmgr -f /etc/repmgr.conf witness register -h 192.168.10.11 -U repmgr -d repmgr実測では、スタンバイを起動した直後に standby register を打つと次のエラーで止まりました。walreceiverがまだプライマリへ接続していないためで、数秒待ってから再実行すると登録できました。
WARNING: node "node2" not found in "pg_stat_replication"
ERROR: local node not attached to primary node 1
HINT: specify the actual upstream node id with --upstream-node-id, or use -F/--force to continue anyway登録後の cluster show は次のとおりです。witnessはプライマリにぶら下がる形で表示され、Priorityは0（昇格候補にならない）になります。
$ repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Priority | Timeline
----+-------+---------+-----------+----------+----------+----------+----------
1 | node1 | primary | * running | | dc1 | 100 | 1
2 | node2 | standby | running | node1 | dc1 | 100 | 1
3 | node3 | witness | * running | node1 | dc1 | 0 | n/a最後に各ノードで repmgrd -f /etc/repmgr.conf を起動し（パッケージ版はsystemdのユニットで起動）、repmgr service status で3ノードとも repmgrd が running になっていることを確かめます。
repmgrdの自動フェイルオーバーの動作と昇格までの時間
停止から昇格まで：実測ログと秒数
プライマリ（node1）を pg_ctl -m immediate stop で落とし、スタンバイ（node2）の pg_is_in_recovery() が false になるまでを1秒刻みで測りました。同じ手順を3回行い、昇格まで6秒・7秒・8秒でした（1秒刻みの測定で、DBが書き込み可能になるまでの時間です。アプリケーションの接続先切替や再接続の時間は含みません）。3回目のnode2側のrepmgrdログは次のとおりです。
[2026-10-28 13:23:17] [WARNING] unable to connect to upstream node "node1" (ID: 1)
[2026-10-28 13:23:17] [INFO] sleeping up to 2 seconds until next reconnection attempt
[2026-10-28 13:23:19] [INFO] sleeping up to 2 seconds until next reconnection attempt
[2026-10-28 13:23:21] [WARNING] unable to reconnect to node "node1" (ID: 1) after 3 attempts
[2026-10-28 13:23:21] [NOTICE] promotion candidate is "node2" (ID: 2)
[2026-10-28 13:23:21] [NOTICE] this node is the winner, will now promote itself and inform other nodes
[2026-10-28 13:23:21] [DETAIL] promoting server "node2" (ID: 2) using pg_promote()
[2026-10-28 13:23:21] [NOTICE] waiting up to 60 seconds (parameter "promote_check_timeout") for promotion to complete
[2026-10-28 13:23:23] [DETAIL] server "node2" (ID: 2) was successfully promoted to primary時間の大半は再接続の試行です。最初の失敗の検知に監視間隔（monitor_interval_secs）ぶん、再接続の試行の間の待機に2秒×2回（試行3回なら待機は2回）の計4秒、pg_promote() の完了に約2秒かかっています。witnessは新プライマリへ自動で付け替わり、cluster event には repmgrd_failover_promote と repmgrd_failover_follow が記録されました。
reconnect_attemptsとreconnect_intervalの決め方
既定値は reconnect_attempts=6、reconnect_interval=10 です。repmgrdは最後の試行の後には待たないため、再接続の待機は5回・計50秒で、これに検知までの監視間隔、接続タイムアウト、昇格候補の選定と昇格処理の時間が加わります。Akamai（旧Linode）の構築ガイドに載っているログも、検知から昇格の判断まで約50秒です。
短くすれば停止時間は縮みますが、数秒のネットワークの瞬断やプライマリの高負荷でも昇格が走り、スプリットブレインの入口になります。目安として、再接続の待機の合計（(reconnect_attempts - 1) * reconnect_interval）は「平常時に観測される接続の途切れ」より十分長く取ります。そのうえで、検知・昇格・接続先の切替まで含めた書き込み停止時間を障害試験で測り、アプリケーションの許容時間に収まるかを確かめます。検証の2秒×3回は、対象環境で高負荷やネットワーク断の試験をして誤昇格が起きないと確認できた場合に限って使ってください。クラウドのマネージドDBの切替時間と比べたい場合は、RDSとAuroraのフェイルオーバー時間を実測した記事が参考になります。
witnessとlocationで誤った昇格を止める仕組み
2ノード構成でスタンバイとプライマリの間の回線だけが切れると、スタンバイは「プライマリが落ちた」と判断して昇格し、書き込めるノードが2台になります。witnessはこれを防ぐための投票役です。公式ドキュメントは、witnessをプライマリと同じ拠点に置き、スタンバイからプライマリもwitnessも見えないときは、分断の可能性があるとして昇格しない動作を説明しています。
複数拠点にまたがる場合は location を使います。ネットワーク分断の章によると、repmgrdは現在のプライマリと同じ location のノードが1台も見えなければ、別拠点のノードを昇格させません。拠点ごとに正しい値を入れておかないと、この判定が働かない点に注意してください。
旧プライマリの復帰（node rejoinとpg_rewind）
フェイルオーバー後の旧プライマリは、新プライマリが書いたWALと分岐しているため、そのままではスタンバイとして起動できません。repmgr node rejoin --force-rewind はpg_rewindで差分を巻き戻し、新プライマリのスタンバイとして再起動するところまでを1コマンドで行います。旧プライマリを停止した状態で、旧プライマリ側で実行します。
repmgr -f /etc/repmgr.conf node rejoin \
-d 'host=192.168.10.12 user=repmgr dbname=repmgr' \
--force-rewind --config-files=postgresql.auto.conf --dry-run
# postgresql.conf をデータディレクトリ内に置く構成では --config-files に postgresql.conf も並べるimmediate停止のようにクリーンでない停止のあとは、--force-rewind を付けないと ERROR: database is not shut down cleanly で止まります。実測では、ここから先で2種類の失敗が起きました。
dry-run成功後のpg_rewind失敗とWAL不足の原因
1回目は --dry-run が「prerequisites for executing NODE REJOIN are met」を返したのに、本番の実行でpg_rewindが次のエラーを出して失敗しました。
pg_rewind: servers diverged at WAL location 0/302B4F8 on timeline 1
pg_rewind: error: could not open file "pg_wal/000000010000000000000002": No such file or directory
pg_rewind: error: could not find previous WAL record at 0/20354F0
ERROR: pg_rewind execution failedpg_rewindは、分岐点から直前のチェックポイントまで旧プライマリ自身のWALをさかのぼって読みます。旧プライマリの pg_wal からそのセグメントが消えていると巻き戻せません。この回のログには、pg_rewindが前処理として走らせたクラッシュリカバリの直後のチェックポイントで、WALファイルが1つ再利用された（1 recycled）と出ており、さかのぼりに必要なセグメントが残っていませんでした。
同じ手順で wal_keep_size = '256MB' だけを足して組み直した2回目は、pg_rewindが成功しました（試行は各1回です）。pg_rewind単体なら -c（--restore-target-wal）でアーカイブからWALを取ってこられますが、repmgrが組み立てたコマンド行は pg_rewind -D ... --source-server=... だけで、このオプションは付いていませんでした。repmgrで node rejoin を使うなら、旧プライマリ側に wal_keep_size を確保しておくのが手早い対策です。256MBは検証で使った値で、必要な量は分岐点の前のチェックポイントからのWAL量（checkpoint_timeout・max_wal_size と書き込み量）で決まります。WALアーカイブを取っていれば、pg_rewindを -c 付きで手動実行する方法もあります。なお switchoverのドキュメントも、--dry-run の成功は前提条件を満たしたことしか意味しないと明記しています。
pg_rewindによる設定ファイルの上書きと保持方法
2回目は巻き戻しまで成功したものの、旧プライマリが could not bind IPv4 address "127.0.0.1": Address already in use で起動しませんでした。pg_rewindが新プライマリの postgresql.conf を丸ごと持ってきたため、検証でポートを分けていた旧プライマリの port が新プライマリと同じ値に変わっていました。
node rejoinのドキュメントにも、pg_rewindはローカルの設定ファイルをソース側のもので上書きするので --config-files で保持するよう書かれています。ノードごとに設定が違う（メモリ量や listen_addresses、ポートが違う）構成では必須です。対象はデータディレクトリ内のファイルで、Debian系のように postgresql.conf を /etc/postgresql/18/main に置く構成では、上書きされるのは postgresql.auto.conf などデータディレクトリ側だけです。--config-files=postgresql.conf,postgresql.auto.conf を付けた3回目は「NODE REJOIN successful」で終わり、旧プライマリは新プライマリから streaming で複製を受ける状態に戻りました。
rejoin不可時のstandby cloneによる再構築
pg_rewindが通らない場合は、旧プライマリのデータディレクトリを捨てて repmgr standby clone --force で新プライマリから複製し直し、standby register --force で登録を上書きします。データ量に比例して時間がかかりますが、WALの有無や分岐の状態に左右されません。ディレクトリを消す操作なので、旧プライマリにしか無い書き込みが残っていないか（非同期レプリケーションで送れなかった分）を確認してから実行してください。
standby switchoverによる計画切替
メンテナンスでプライマリを入れ替えるときは、昇格させたいスタンバイ側で repmgr standby switchover を実行します。旧プライマリにCHECKPOINTを打ってから停止し、スタンバイを昇格させ、旧プライマリを新プライマリのスタンバイとして戻すまでを自動で行います。
repmgr -f /etc/repmgr.conf standby switchover --siblings-follow --dry-run
repmgr -f /etc/repmgr.conf standby switchover --siblings-follow前提は、昇格させるスタンバイから現在のプライマリへのパスワードなしSSHです（切替の準備）。--siblings-follow を付けると、旧プライマリにつながっていた他のスタンバイやwitnessも新プライマリへ付け替えます。この場合は新プライマリからそれらのノードへのSSHも必要です。repmgr 4.2以降は、切替の間だけ全ノードのrepmgrdを自動で一時停止し、意図しない昇格を防ぎます（--repmgrd-no-pause で無効化できますが、その場合は自分でrepmgrdを止める必要があります）。
スプリットブレインとフェンシングの扱い
repmgrは、落ちたと判断した旧プライマリの電源を切る、ストレージから切り離す、といったSTONITH型のフェンシングを持ちません。プライマリが生きたまま分断された場合、旧プライマリはアプリケーションから書き込みを受け続けます。抑止に使える仕組みは次のとおりです。
primary_visibility_consensus=true：直近でプライマリを見ていたスタンバイが1台でもあれば、フェイルオーバーを進めません（全ノードで同じ値にする）。child_nodes_disconnect_command：プライマリ側のrepmgrdが、接続中のスタンバイが減ったことを検知したときに実行するコマンドです。自分を書き込み不可にするスクリプトをここに置けば、分断された側のプライマリが自ら書き込みを止められます。failover_validation_command：昇格の判断を外部のスクリプトで最終確認させます。
これらは誤った昇格を減らす仕組みで、旧プライマリを確実に止める保証にはなりません。金融取引のように2台同時の書き込みを1件も許せない要件なら、Pacemaker＋CorosyncのSTONITHか、Patroniでもwatchdogを有効にした構成を選び、プロセス停止・高負荷・VM停止を含む障害試験で確かめるべきです。Patroniの公式ドキュメントも、リーダーロックの失効までにPostgreSQLを止められない場合に備えてwatchdogを説明しています。可用性の要件を稼働率で置く方法は可用性と高可用性設計の解説を参照してください。
Patroni・pg_auto_failoverとの選び分け
PostgreSQLの自前HAでよく比べられる3つを、2026年10月時点の版で並べます。
| 項目 | repmgr | Patroni | pg_auto_failover |
|---|---|---|---|
| 最新版 | 5.5.0（2024-11-20） | 4.1.5（2026-08-12） | 2.2（2025-04-03） |
| リーダー判定 | repmgrd同士の投票＋witness | DCSのリーダーロック | 専用のmonitorノード |
| 追加で要るもの | なし（witnessは任意） | etcd・Consul・ZooKeeper・Kubernetes | monitor用のPostgreSQL |
| 接続先の切替 | 自作スクリプト | REST API＋HAProxy等 | libpqの複数ホスト指定 |
| ライセンス | GPL v3 | MIT | PostgreSQL License |
Patroniは2026年も版を重ねており、DCSとしてetcd・Consul・ZooKeeper・Kubernetesを使えます。pg_auto_failoverは2.2の後に正式版が出ていません。
- repmgrを選ぶ：VMや物理サーバー2〜3台で、etcdのような分散KVSを追加で運用したくない。障害時の切替を手順書とコマンドで管理したい。すでにrepmgrで運用していて、PostgreSQL 18へ上げたい。
- repmgrを避ける：Kubernetes上で動かす（PatroniベースのオペレーターやCloudNativePGの領域）。スプリットブレインを仕組みで排除したい。リリースが2年近く止まっているツールを新規の基盤に入れることを、社内の審査で説明できない。
自前のHAを持たない選択もあります。Azure Database for PostgreSQLのゾーン冗長HAやAuroraのクラスター構築とフェイルオーバー検証のようなマネージドサービスなら、昇格・接続先の切替・旧プライマリの処理をクラウド側が持ちます。自前HAと移行の比較を含めた検討は、データベース設計・移行支援でも相談を受けています。
よくある質問
repmgrの最新バージョンはPostgreSQL 18で使えますか？
使えます。最新版は5.5.0（2024年11月20日）のままで、2026年10月2日のコミットでREADMEと互換表にPostgreSQL 18が追記されました。PostgreSQL 18.6でビルドし、構築・自動フェイルオーバー・node rejoinまで動作しました。
repmgrdとは何ですか？
各ノードで常駐する監視デーモンです。上流ノードへの接続を monitor_interval_secs ごとに確認し、reconnect_attempts 回つながらなければ昇格候補を選んで promote_command を実行します。
repmgrはWindowsで動きますか？
動きません。要件ページに「There is no support for Microsoft Windows」とあり、公式の repmgr.exe もありません。Windows環境から使う場合も、PostgreSQLとrepmgrはLinuxサーバー（仮想マシンを含む）に置きます。
repmgrでマルチマスター構成は組めますか？
組めません。repmgrが管理するのは1台のプライマリと、そこから複製を受けるスタンバイ（カスケードを含む）です。複数ノードで書き込むにはEDB Postgres Distributedなど別の製品が必要です。
repmgrとPatroniはどちらを選ぶべきですか？
新規構築ならPatroniを先に検討してください。DCSのリーダーロックで書き込み権を1台に絞る仕組みを持ち、watchdogを併用すれば、ロック失効後も旧プライマリが書き続ける事態を抑えられます。2026年8月にも4.1.5が出ています。etcd等を運用したくない数台の構成や、既存のrepmgr運用を続ける場合はrepmgrで十分です。
