repmgrとは？PostgreSQLのレプリケーション管理と自動フェイルオーバー構築を解説【2026年版】

repmgr（レップマネージャー）は、PostgreSQLのストリーミングレプリケーションを一元管理し、プライマリ障害時にスタンバイを自動昇格させてフェイルオーバーするオープンソースツールだ。開発元はPostgreSQL支援企業のEDB（旧2ndQuadrant）、ライセンスはGPLv3。手動での昇格やスタンバイの追随を、repmgrコマンドと監視デーモンrepmgrdに肩代わりさせるのが役割で、自前運用のPostgreSQLクラスタで高可用性（HA）を確保したいときの定番になっている。この記事では最新版の対応状況、repmgr.confとコマンドによる構成手順、そして誤解されやすいスプリットブレイン対策の仕組みまでを実装目線で整理する。

まとめ：repmgrの要点

• repmgrは単一プライマリ＋スタンバイ構成を管理するCLI（repmgr）と、常駐監視・自動フェイルオーバーを担うデーモン（repmgrd）の2部構成。
• 最新はrepmgr 5.5.0（2024年11月リリース）で、PostgreSQL 13〜17に対応（PostgreSQL 18は5.5.0時点で未対応。対応範囲は版で変わるため導入前に公式で確認）。
• HA構成はrepmgr.confにノード情報とフェイルオーバー設定を書き、primary register→standby clone→standby register→repmgrd起動、の順で組む。
• 自動フェイルオーバーはrepmgrdがクォーラムで障害を判定し、witnessサーバとlocationによる多数決でスプリットブレインを抑止する。
• repmgr自体はSTONITH型のフェンシングを内蔵しない。厳密な強制停止が要る要件ではPacemakerなど別ツールと組み合わせる。
• repmgrはマルチマスターではない。書き込み可能なノードは常に1台で、複数ノード同時書き込みは対象外。

以降で、構成要素の役割、HA構成の具体的な手順、フェイルオーバーとスプリットブレイン対策の中身、そして「repmgrを選ぶべきか」の判断基準を順に見ていく。

repmgrの構成要素と対応バージョン

repmgr（CLI）とrepmgrd（デーモン）の役割分担

repmgrは名前が同じでも中身は2つに分かれる。1つ目のrepmgrコマンドは、クラスタの登録・スタンバイのクローン・手動昇格・状態表示といった管理操作を人間（または運用スクリプト）が実行するためのCLIだ。2つ目のrepmgrdはバックグラウンドで常駐し、プライマリの死活を監視して障害を検知したら自動でスタンバイを昇格させる。手動運用だけならrepmgrコマンドのみでも足りるが、無人での自動フェイルオーバーを求めるならrepmgrdの常駐が前提になる。両者はクラスタ全ノードに保存される共通のメタデータスキーマ（repmgr拡張）を通じてノード構成を共有する。

対応PostgreSQLバージョン・ライセンス・開発元

最新版はrepmgr 5.5.0で、2024年11月にリリースされPostgreSQL 17への対応が加わった。公式の互換表ではPostgreSQL 13から17までを対象としており、PostgreSQL 18は5.5.0時点では未対応のため、18で運用する場合は後継版のリリースノートを確認する。ライセンスはGNU GPLv3以降、開発はEDBが主体で、旧2ndQuadrantから引き継がれている。PostgreSQL本体のメジャーバージョンとrepmgrの対応関係は版ごとに切り替わるため、古いPostgreSQLを運用している環境では、repmgrのどのマイナー版がその系列をサポートするかを公式リリースノートで必ず確認したい。

repmgrが解決する課題

PostgreSQL単体でもストリーミングレプリケーション自体は構築できる。問題はその先、つまりプライマリが落ちたときだ。素のPostgreSQLではスタンバイの昇格（pg_ctl promote）も、残りのスタンバイを新プライマリへ追随させ直す作業も手動になる。深夜の障害で担当者が起きて対応する、という運用は復旧時間（RTO）を悪化させる。repmgrはこの昇格と追随、そしてクラスタ状態の可視化を自動化・コマンド化することで、手動運用の属人性と遅延を取り除く。

repmgrが管理するレプリケーション構成

プライマリ・スタンバイ・witnessの3ノードモデル

repmgrが扱う基本形は、書き込みを受けるプライマリ1台と、その内容を非同期または同期で受け取るスタンバイ複数台の構成だ。ここにもう1つ、レプリケーションには参加しないがrepmgrのメタデータだけを持つwitness（証人）ノードを加えると、後述のスプリットブレイン判定が安定する。witnessはデータを複製しないため小さなインスタンスで足り、通常はプライマリと同じ拠点に置く。

「マルチマスター」との違い

検索では「postgresql multi master」でこの記事に到達するケースがあるが、repmgrはマルチマスター構成のツールではない。repmgrが管理するのはあくまで単一プライマリ（書き込み可能ノードは常に1台）＋読み取りスタンバイのクラスタで、複数ノードで同時に書き込みを受け付ける仕組みは提供しない。PostgreSQLで双方向・多方向の書き込みを行うマルチマスターが必要なら、pgEdgeやEDB Postgres Distributed（旧BDR）といった別系統の製品が候補になる。repmgrに求めるべきは「1台のプライマリを確実に切り替える」ことであり、そこを取り違えると設計を誤る。

repmgrでHA構成を構築する手順

インストールとrepmgr.confの主要設定

repmgrはパッケージ（EDBのリポジトリやOSのパッケージ管理）で導入し、PostgreSQL側にshared_preload_libraries = 'repmgr'を設定する。各ノードにはrepmgr.confを1つ置き、ノードを一意に識別する情報とフェイルオーバー時の振る舞いを記述する。最小構成の例を示す。

node_id=1
node_name='node1'
conninfo='host=192.0.2.11 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/pgsql/16/data'
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'
location='tokyo'
priority=100

node_idとconninfoはノードごとに変える。failover='automatic'とpromote_command/follow_commandはrepmgrdが自動フェイルオーバーする際に実行するコマンドで、この3つが揃って初めて無人切替が成立する。locationとpriorityは後述のスプリットブレイン判定と昇格順位に効くため、拠点をまたぐ構成では必ず設定する。

プライマリ登録とスタンバイのクローン

構成ファイルを置いたら、まずプライマリでrepmgrにクラスタを認識させ、次にスタンバイ側でプライマリの複製を作って登録する。

# プライマリで実行
repmgr -f /etc/repmgr.conf primary register

# スタンバイで実行（--dry-runで事前確認してから本実行）
repmgr -h 192.0.2.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --dry-run
repmgr -h 192.0.2.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
repmgr -f /etc/repmgr.conf standby register

standby cloneはpg_basebackup相当の処理でプライマリのデータをコピーし、レプリケーション接続を設定する。--dry-runを付けると実際のコピー前に接続や権限の問題を洗い出せるので、本番では必ず先に空実行しておきたい。クローン後にPostgreSQLを起動し、standby registerでrepmgrのメタデータへスタンバイを登録する。

repmgrdの起動と動作確認

自動フェイルオーバーを有効にするには、各ノードでrepmgrdをサービスとして起動する。起動後はクラスタ全体の状態をコマンドで確認する。

repmgr -f /etc/repmgr.conf cluster show
repmgr -f /etc/repmgr.conf node status
repmgr -f /etc/repmgr.conf node check

cluster showは登録済みノードの役割（primary/standby）と接続可否を一覧化し、node statusは個々のノードのレプリケーション状態を返す。node checkは監視ツールに組み込みやすい形でノードの健全性を検査する。構築直後はこの3コマンドで、想定どおり1台がprimary・残りがstandbyとして見えているかを確認する。

自動フェイルオーバーとスイッチオーバーの動作

repmgrdによる障害検知とクォーラム判定

repmgrdはプライマリへの接続を定期的に試み、応答が途絶えると即座に昇格へ進むのではなく、他のノードと「本当にプライマリが落ちているか」をクォーラム（多数決）で確認する。単一ノードの視界だけで昇格を判断すると、実際にはネットワークが一時的に切れていただけのときに誤って新プライマリを作ってしまうためだ。合意が取れて初めて、priorityが高く追随が進んでいる最適なスタンバイが昇格し、他のスタンバイはfollow_commandで新プライマリへ追随し直す。

計画的なstandby switchoverによる無停止に近い切替

障害対応とは別に、OSやPostgreSQLのメンテナンスで意図的にプライマリを入れ替えたい場面がある。このときはstandby switchoverを使う。昇格させたいスタンバイ上で実行し、現プライマリを正しく降格させてから新プライマリへ切り替えるため、突然の障害昇格より安全にロールを交換できる。実行には現プライマリへのパスワードなしSSH接続が必要になる点に注意したい。

# 昇格させたいスタンバイ上で実行
repmgr -f /etc/repmgr.conf standby switchover --dry-run
repmgr -f /etc/repmgr.conf standby switchover

旧プライマリの復帰（node rejoin と pg_rewind）

フェイルオーバー後に復旧した旧プライマリは、そのままではタイムラインがずれてクラスタに戻せない。ここでrepmgr node rejoin --force-rewindを使うと、内部でPostgreSQLのpg_rewindを呼び出し、分岐したWALを巻き戻して旧プライマリを新プライマリのスタンバイとして再参加させられる。手動でWALセグメントを整理する必要がなく、復旧の手間と時間を大きく減らせる。ただしpg_rewindは差分適用のため、wal_log_hintsの有効化かデータチェックサムが前提になる（full_page_writesは既定のonのまま）点は事前に押さえておく。

スプリットブレインを防ぐ設計（repmgrの誤解しやすい点）

witnessサーバとlocationによる多数決

スプリットブレインは、ネットワーク分断で「プライマリが2台」になり、両方が書き込みを受けてデータが食い違う最悪の状態だ。repmgrはこれをwitnessサーバとlocationで抑止する。witnessは「casting vote（決選投票）」の役割を持ち、あるスタンバイが自分を昇格してよいかを判断する材料になる。スタンバイがプライマリもwitnessも見えないなら、それは自分側がネットワークから孤立している疑いが強いので昇格しない。witnessは見えるがプライマリだけ見えないなら、ネットワークは生きていてプライマリ自体が落ちたと判断でき、昇格に進む。locationを拠点ごとに設定しておくと、repmgrdは同一拠点にプライマリ候補が残っているかも加味して判定する。

repmgrにフェンシング（STONITH）は内蔵されない

ここが最も誤解されやすい。HA一般論では、旧プライマリを電源やネットワークから物理的に強制排除する「フェンシング（STONITH）」がスプリットブレイン対策の要とされる。しかしrepmgr自体はSTONITH型のフェンシングを実装していない。repmgrができるのは、witnessとクォーラムによって「不用意に二重昇格しない」ことと、復帰時のnode rejoinによるタイムライン整合であって、暴走した旧プライマリのプロセスを外部から強制停止する機能ではない。したがって、金融系のように「絶対に二重書き込みを起こさない」レベルの保証が要る要件では、repmgr単体では不足する。その場合はPacemaker＋Corosyncのようなクラスタスタックにフェンシングデバイス（IPMI、クラウドのAPI等）を組み合わせ、repmgrはレプリケーション管理層として併用する構成を検討すべきだ。旧来「repmgrがフェンシングをやってくれる」という前提で設計すると、いざ分断時に守れない。

スプリットブレインが起きた後の復旧

抑止策をすり抜けて二重書き込みが起きてしまった場合、両系のデータをそのまま統合する自動手段はない。片方を正とし、もう片方に入った差分は業務ルールに沿って人手で救済するしかない。だからこそ、監視でプライマリの多重化を早期に検知し、被害範囲を狭めることが実運用では最重要になる。node checkや外部監視でプライマリ数が常に1であることを継続的に確認する仕組みを、構築段階で用意しておきたい。

repmgrを導入すべきか、の判断基準

repmgrが向く構成・向かない構成

repmgrが生きるのは、オンプレやEC2上などで自前のPostgreSQLを運用し、レプリケーションとフェイルオーバーの挙動を自分でコントロールしたいケースだ。逆に、単に冗長化された可用性が欲しいだけで運用工数を抑えたいなら、Amazon Aurora Serverless v2のようなマネージドサービスに任せた方が合理的なことが多い。マネージドDBはフェイルオーバーやパッチ適用をクラウド側が肩代わりし、repmgrで自作するHAロジックの多くを不要にする。「どこまでの可用性を、どれだけの運用コストで買うか」という観点は、可用性の指標と高可用性設計の考え方を踏まえて先に決めておくと選定を誤らない。厳密なフェンシングが必須の要件なら、前述のとおりrepmgr単体は選ばず、クラスタスタックとの併用かマネージドを選ぶ。

よくある質問

repmgrの最新バージョンと対応するPostgreSQLは？

最新はrepmgr 5.5.0（2024年11月リリース）で、公式の互換表ではPostgreSQL 13〜17に対応する（PostgreSQL 18は5.5.0時点で未対応）。対応範囲はマイナー版で更新されるため、運用中のPostgreSQLに合うrepmgrの版は公式リリースノートで確認するのが確実だ。

repmgrでマルチマスター構成は組めますか？

組めない。repmgrは単一プライマリ＋スタンバイのクラスタを管理するツールで、複数ノードでの同時書き込み（マルチマスター）は対象外だ。双方向書き込みが必要ならpgEdgeやEDB Postgres Distributed（旧BDR）など別製品を検討する。

repmgrでスプリットブレインは完全に防げますか？

完全には防げない。witnessとクォーラムで二重昇格を強く抑止できるが、repmgrはSTONITH型フェンシングを持たないため、暴走した旧プライマリを強制停止する保証はない。厳密性が要る場合はPacemaker等のフェンシングと併用する。

repmgrとPatroniはどう違いますか？

どちらもPostgreSQLの自動フェイルオーバーを担うが、Patroni（Zalando発）は分散合意ストア（etcd、Consul、ZooKeeper等）を前提にしたリーダー選出型で、Kubernetesとの親和性が高い。repmgrは外部の合意ストアを必須とせず、PostgreSQLと同じ運用感で導入できる軽量さが持ち味だ。既存のオンプレ／VM運用に素直に載せたいならrepmgr、コンテナ基盤で組むならPatroniが選ばれやすい。

フェイルオーバー後に旧プライマリを再びクラスタへ戻すには？

repmgr node rejoin --force-rewindを実行する。内部でpg_rewindが分岐したWALを巻き戻し、旧プライマリを新プライマリのスタンバイとして再参加させる。事前にwal_log_hintsの有効化またはデータチェックサムが必要になる。

関連記事

• 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説
• PostgreSQLにおけるGINインデックスとは何か？その特徴と基本概要および役割について徹底解説
• Psycopg3とは何か – Python用PostgreSQLデータベースアダプターの概要と主要な特徴