--- title: "repmgrとは：PostgreSQL 18での構築手順と自動フェイルオーバー・node rejoinを実測【5.5.0】" url: "https://www.issoh.co.jp/tech/details/3756/" published: 2024-10-07 updated: 2026-10-28 categories: ["データベース"] publisher: "株式会社一創" --- # repmgrとは：PostgreSQL 18での構築手順と自動フェイルオーバー・node rejoinを実測【5.5.0】 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のサンプル設定](https://github.com/EnterpriseDB/repmgr/blob/v5.5.0/repmgr.conf.sample)でも `failover` の既定値は `manual` です。 ### 5.5.0の対応PostgreSQL（13〜18）と公式内の表記揺れ repmgrの最新リリースは5.5.0で、[リリースノート](https://www.repmgr.org/docs/current/release-5.5.0.html)の日付は2024年11月20日、追加点はPostgreSQL 17への対応です。それ以降、2026年10月時点まで新しい版は出ていません。 PostgreSQL 18については、[2026年10月2日のコミット（#921）](https://github.com/EnterpriseDB/repmgr/commits/master/)でREADMEと互換表に18が追記されました。コミットの説明には、PostgreSQL 18で追加作業なしに動くことを確認済みと書かれています。[現行ドキュメントの冒頭](https://www.repmgr.org/docs/current/)も対象を「PostgreSQL 13 – PostgreSQL 18」としています。 ただし、公式サイトの中で表記が揃っていません。[repmgr.orgのトップ](https://repmgr.org/)は「PostgreSQL 12 \~ PostgreSQL 18」、公開中の[要件ページ](https://www.repmgr.org/docs/current/install-requirements.html)の本文は「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）](https://packages.debian.org/sid/postgresql-18-repmgr)が収録されています。 ### ライセンスと、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は本番では必ず別の物理ホストに置きます。[公式ドキュメント](https://www.repmgr.org/docs/current/repmgrd-witness-server.html)は、他ノードと同じ物理ホストへのwitnessの設置を禁じています。レプリケーションの同期・非同期の考え方は[データベースレプリケーションの解説](/tech/details/16276/)にまとめています。 ### postgresql.confとpg\_hba.confの前提設定 プライマリに次の設定を入れます。`wal_log_hints` は後の `node rejoin --force-rewind`（pg\_rewind）で必要になります。PostgreSQL 18は [initdbの既定でデータチェックサムが有効](https://www.postgresql.org/docs/18/release-18.html)になり、[pg\_rewindの要件](https://www.postgresql.org/docs/18/app-pgrewind.html)（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）の構築ガイド](https://www.akamai.com/cloud/guides/manage-replication-failover-on-postgresql-cluster-using-repmgr/)に載っているログも、検知から昇格の判断まで約50秒です。 短くすれば停止時間は縮みますが、数秒のネットワークの瞬断やプライマリの高負荷でも昇格が走り、スプリットブレインの入口になります。目安として、再接続の待機の合計（`(reconnect_attempts - 1) * reconnect_interval`）は「平常時に観測される接続の途切れ」より十分長く取ります。そのうえで、検知・昇格・接続先の切替まで含めた書き込み停止時間を障害試験で測り、アプリケーションの許容時間に収まるかを確かめます。検証の2秒×3回は、対象環境で高負荷やネットワーク断の試験をして誤昇格が起きないと確認できた場合に限って使ってください。クラウドのマネージドDBの切替時間と比べたい場合は、[RDSとAuroraのフェイルオーバー時間を実測した記事](/tech/details/18074/)が参考になります。 ### witnessとlocationで誤った昇格を止める仕組み 2ノード構成でスタンバイとプライマリの間の回線だけが切れると、スタンバイは「プライマリが落ちた」と判断して昇格し、書き込めるノードが2台になります。witnessはこれを防ぐための投票役です。[公式ドキュメント](https://www.repmgr.org/docs/current/repmgrd-witness-server.html)は、witnessをプライマリと同じ拠点に置き、スタンバイからプライマリもwitnessも見えないときは、分断の可能性があるとして昇格しない動作を説明しています。 複数拠点にまたがる場合は `location` を使います。[ネットワーク分断の章](https://www.repmgr.org/docs/current/repmgrd-network-split.html)によると、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 failed ``` pg\_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のドキュメント](https://www.repmgr.org/docs/current/repmgr-standby-switchover.html)も、`--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のドキュメント](https://www.repmgr.org/docs/current/repmgr-node-rejoin.html)にも、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です（[切替の準備](https://www.repmgr.org/docs/current/preparing-for-switchover.html)）。`--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の公式ドキュメント](https://patroni.readthedocs.io/en/latest/watchdog.html)も、リーダーロックの失効までにPostgreSQLを止められない場合に備えてwatchdogを説明しています。可用性の要件を稼働率で置く方法は[可用性と高可用性設計の解説](/tech/details/13423/)を参照してください。 ## 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](https://patroni.readthedocs.io/en/latest/releases.html)は2026年も版を重ねており、DCSとしてetcd・Consul・ZooKeeper・Kubernetesを使えます。[pg\_auto\_failover](https://github.com/hapostgres/pg%5Fauto%5Ffailover/releases/tag/v2.2)は2.2の後に正式版が出ていません。 - **repmgrを選ぶ**：VMや物理サーバー2〜3台で、etcdのような分散KVSを追加で運用したくない。障害時の切替を手順書とコマンドで管理したい。すでにrepmgrで運用していて、PostgreSQL 18へ上げたい。 - **repmgrを避ける**：Kubernetes上で動かす（PatroniベースのオペレーターやCloudNativePGの領域）。スプリットブレインを仕組みで排除したい。リリースが2年近く止まっているツールを新規の基盤に入れることを、社内の審査で説明できない。 自前のHAを持たない選択もあります。[Azure Database for PostgreSQLのゾーン冗長HA](/tech/details/16974/)や[Auroraのクラスター構築とフェイルオーバー検証](/tech/details/17844/)のようなマネージドサービスなら、昇格・接続先の切替・旧プライマリの処理をクラウド側が持ちます。自前HAと移行の比較を含めた検討は、[データベース設計・移行支援](/service/system/database/)でも相談を受けています。 ## よくある質問 ### 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で十分です。 ## 関連記事 - [データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計を実装者目線で解説【2026年版】](/tech/details/16276/) - [可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】](/tech/details/13423/) - [RDSとAuroraの違いを実測で比べる：東京の月額・フェイルオーバー時間と選び分け](/tech/details/18074/) - [PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所](/tech/details/18247/) - [カオステストとは？障害注入の実験設計とツール選定・本番実施の判断を実装者向けに解説](/tech/details/16269/) --- 出典: [repmgrとは：PostgreSQL 18での構築手順と自動フェイルオーバー・node rejoinを実測【5.5.0】]()（株式会社一創）