Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
PostgreSQLの自動フェイルオーバーとは、現行プライマリノードが利用不可になった際、スタンバイデータベースを自動的にプライマリに昇格させる仕組みのことです。
PostgreSQLに自動フェイルオーバー機構を導入することは、データベースの高可用性を実現するために不可欠です。データ災害、サイバー攻撃、システムクラッシュが発生した場合でも業務継続性を確保し、停止時間を最小限に抑えます。
PostgreSQLは堅牢なレプリケーション機能を標準搭載していますが、自動フェイルオーバーを統制する仕組みは備えていません。そのためDBAは障害検知、ノード状態確認、スタンバイの手動昇格を行う必要があり、停止時間の長期化や人的操作ミスのリスクが生じます。
適切な自動フェイルオーバーツールを選定するには、フェイルオーバーに伴う課題を把握する必要があります。
続いて、PostgreSQLの自動フェイルオーバー・切り替えに広く活用される代表的なツールを紹介します。
オープンソースのPostgreSQL拡張機能で、フェイルオーバーを自動化し高可用性を実現します。依存要素が少なく、比較的簡単に構築できる環境を求める運用チームに適しています。
監視ノードを用いてプライマリ・スタンバイの健全性を監視し、プライマリ障害時に監視ノードがスタンバイを自動昇格させます。分散コンセンサスシステムの複雑な設定なしで簡易的なHAを構築したい場合に最適です。
手順1. pg_auto_failoverのインストール
公式パッケージリポジトリを追加し、インストールを実行します。
Ubuntu/Debianの場合
apt install -y postgresql-14 pg-auto-failover
RHEL/CentOSの場合：
yum install -y pg-auto-failover
手順2. 監視ノードの作成・起動
監視ノードはクラスタ状態管理とフェイルオーバー判定を担います。
pg_autoctl create monitor --pgdata /var/lib/pgsql/14/monitor
pg_autoctl run monitor
手順3. プライマリノードの初期化
pg_autoctl create postgres \
--pgdata /var/lib/pgsql/14/data \
--monitor postgres://監視ノードIP:5432/pg_auto_failover \
--name node-primary
pg_autoctl run
手順4. スタンバイノードの追加
2台目のサーバー上でホットスタンバイとして登録します。
pg_autoctl create postgres \
--pgdata /var/lib/pgsql/14/data \
--monitor postgres://監視ノードIP:5432/pg_auto_failover \
--name node-standby
pg_autoctl run
手順5. クラスタ状態の確認
pg_autoctl status
pg_autoctl events
クラスタは自動的にストリーミングレプリケーションを有効化し、PostgreSQL自動フェイルオーバーの準備が完了します。
PatroniはPostgreSQL HAで最も普及しているツールの一つで、etcdやConsulといった分散設定ストアを利用し、リーダー選出とフェイルオーバーを制御します。
動作原理：
手順1. 3台構成のetcdクラスタを構築
etcdは分散コンセンサスを提供し、スプリットブレインを防止します。
# etcdインストール
yum install -y etcd
# 全ノードでetcdを設定・起動
systemctl enable --now etcd
手順2. Patroniと依存パッケージのインストール
pip3 install patroni python-etcd psycopg2-binary
手順3. Patroni設定ファイル(patroni.yml)作成
scope: postgres-ha
namespace: /service/
name: node1
restapi:
listen: 0.0.0.0:8008
etcd:
host: node1-ip:2379
postgresql:
listen: 0.0.0.0:5432
connect_address: node1-ip:5432
data_dir: /var/lib/pgsql/14/data
pgpass: /tmp/pgpass
replication:
username: replicator
password: secure-password
手順4. Patroniサービス起動
patroni /etc/patroni.yml
手順5. クラスタ状態確認
patronictl -c /etc/patroni.yml list
Patroniはプライマリ昇格、レプリケーション、PostgreSQL自動フェイルオーバーを一括で自動管理します。
repmgrはレプリケーション管理とフェイルオーバー自動化に特化したシンプルなツールで、完全自動運用にはカスタムスクリプトと併用することが多いです。小規模な環境に適しています。
動作原理：
以下にPostgreSQL自動フェイルオーバーにrepmgrを導入する手順を記載します。
手順1. repmgrインストール
sudo apt install repmgr
手順2: repmgr.conf設定
node_id=1
node_name=node1
conninfo='host=node1 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/data'
手順3: プライマリノード登録
repmgr primary register
手順4: スタンバイノード複製・登録
repmgr standby clone
repmgr standby register
手順5: 自動フェイルオーバー有効化
repmgrd -f /etc/repmgr.conf
i2Availabilityはエンタープライズ向け高可用性ソリューションで、あらゆる障害シナリオにおいて停止時間とデータ損失を限りなくゼロに抑え、予測可能な復旧を実現します。
i2Availabilityの主な機能：
本セクションでは、データベース運用チームがPostgreSQL自動フェイルオーバー導入時に直面する主要な課題に対し、各ツールに応じた実行可能な解決策を記載します。
Q1：PostgreSQL自動フェイルオーバーにおけるスプリットブレインを回避する方法は？
スプリットブレインとは、2台以上のノードが自身をプライマリと認識し、データ破損を引き起こす現象です。
Q2：レプリケーションラグとは何か、フェイルオーバーにどのような影響を与えるか？
レプリケーションラグとは、プライマリの書き込み処理完了からスタンバイへ反映されるまでの遅延時間のことです。
Q3：フェイルオーバー後、旧プライマリを復旧させる方法は？
フェイルオーバー完了後、データ不整合を防ぐため旧プライマリはスタンバイとして再参加する必要があります。
Q4：自身のPostgreSQLクラスタに適したツールの選び方は？
ツール選定はクラスタ規模、運用スキル、要件に依存します。
Q5：フェイルオーバー導入時の一般的な障害のトラブルシューティング方法は？
信頼性の高いPostgreSQL自動フェイルオーバーを導入することで、停止時間を抑え重要データを保護し業務の継続稼働を保証する、耐障害性の高い本番用データベースクラスタを構築できます。Patroni、repmgr、pg_auto_failoverといったオープンソースツールからエンタープライズ向けプラットフォームまで、クラスタ規模、運用の複雑さ、可用性要件に応じて最適な選択肢が存在します。
中小規模環境では軽量なオープンソース製品で基礎的な高可用性を比較的簡単に実現できます。しかし、データ損失ゼロ、運用簡素化、強固な障害隔離が必須となるミッションクリティカルシステムには、Info2Softのi2Availabilityがより完全なエンタープライズ向けソリューションを提供します。二重仲裁によるスプリットブレイン防止、自動フェイルバック、統合Webコンソール、マルチデータセンター標準対応といった機能により、DCS依存型アーキテクチャに伴う多くの課題を解消します。
オンプレミス、クラウド、ハイブリッド環境いずれに導入する場合でも、適切に設計された自動フェイルオーバー戦略により、PostgreSQLクラスタはあらゆる障害状況下で稼働維持、データ整合性、復旧可能性を確保します。適切なソリューションを選定し、確立されたベストプラクティスに従うことで、最重要業務においてほぼゼロのRTOと堅牢なデータ完全性保証を達成できます。
