DevOpsナレッジハブ
DevOpsナレッジハブ

PostgreSQLのフェイルオーバーとスイッチオーバーのシナリオの理解と実行

計画的なスイッチオーバーと緊急時のフェイルオーバー手順を明確に区別することで、PostgreSQLの高可用性をマスターしましょう。このガイドでは、重要な設定パラメーター（`wal_level`、`hot_standby`）、制御された移行のための実行手順、および障害発生時の迅速な復旧戦略を網羅しています。RepmgrやPatroniのようなツールが、本番環境のクラスターにおけるダウンタイムとデータ損失を最小限に抑えるために、安全なロール昇格をどのように自動化するかを学びましょう。

61 ビュー

PostgreSQLのフェイルオーバーとスイッチオーバーのシナリオを理解し、実行する

現代のデータベースアーキテクチャでは、高可用性（HA）による継続的な運用を保証することが最重要です。強力なオープンソースのリレーショナルデータベースであるPostgreSQLは、複数のノード間でデータの一貫性を維持するためにストリーミングレプリケーションを利用しています。しかし、プライマリサーバーに問題が発生したり、メンテナンスが必要になったりすると、データベース管理者はサービスを復旧するために正確な手順を実行しなければなりません。本記事では、2つの重要なHA操作であるフェイルオーバーとスイッチオーバーの違いを明確にし、スタンバイレプリカを新しいプライマリに安全に昇格させるための手順と考慮事項を詳しく説明します。

これらのイベントの違いを理解することは非常に重要です。スイッチオーバーは計画的で制御された移行であり、フェイルオーバーは予期せぬ障害に対する緊急対応です。どちらのシナリオも、適切な構成、堅牢な監視、およびレプリケーション管理ツールの習熟に大きく依存します。

レプリケーションの基礎：HAの基盤

PostgreSQLの高可用性はストリーミングレプリケーションに基づいて構築されており、1つのサーバーがプライマリ（またはマスター）として機能し、1つ以上のサーバーがスタンバイ（またはレプリカ）として機能します。プライマリはライトアヘッドログ（WAL）レコードをスタンバイにストリームし、それらを同期状態に保ちます。

これらの役割を効果的に管理するには、プライマリノードとレプリカノードの両方で特定の構成設定が必要です。

重要な構成設定

これらの設定は、レプリケーションの動作とノード間の識別方法を管理します。

  • wal_level: プライマリでreplica以上（論理デコーディングを必要とするツールを使用している場合はlogicalが理想的）に設定する必要があります。
  • max_wal_senders: スタンバイからの同時接続の最大数を定義します。すべてのスタンバイに対応するため、デフォルト（通常10）から増やす必要があります。
  • hot_standby: レプリケーション中に読み取り専用クエリを許可するために、スタンバイサーバーのpostgresql.confでonに設定する必要があります。
  • synchronous_commit: トランザクションの確認を制御します。スイッチオーバー中のデータ損失ゼロのためには、通常on（またはわずかな遅延許容のためにはremote_write）に設定されます。
  • primary_conninfo: スタンバイに設定され、現在のプライマリに接続するための接続情報（ホスト、ポート、ユーザー、パスワード）を詳細に示します。

ベストプラクティス: 堅牢なHAを実現するには、物理サーバーアドレスを抽象化し、アプリケーションにとってフェイルオーバーとスイッチオーバーをシームレスにする接続プーリング層（PgBouncerや、PatroniやRepmgrのような専用HAプロキシなど）を使用してください。

スイッチオーバー：計画された移行

スイッチオーバーとは、アクティブなプライマリノードを意図的に停止させ、指定されたスタンバイを昇格させてその代わりにする、制御された優雅なプロセスです。この手順は通常、計画されたメンテナンス、バージョンアップグレード、またはハードウェア交換のために使用されます。

制御されたスイッチオーバーの手順

スイッチオーバーの目標は、昇格前に進行中のすべてのトランザクションがレプリケートされるのを待つことにより、データ損失ゼロを保証することです。

  1. 現在のプライマリでの書き込みを停止: 最初のステップは、現在のプライマリで新しいトランザクションがコミットされるのを防ぐことです。これは通常、default_transaction_read_only = onを設定するか、クライアント接続を一時的にシャットダウンすることで達成されます。
  2. レプリケーションの追いつきを待機: 指定されたスタンバイが、プライマリからの残りのすべてのWALレコードを受信し、適用したことを確認します。レプリケーション遅延は、プライマリでpg_stat_replicationを使用するか、スタンバイのリカバリステータスを調べることで確認できます。
  3. スタンバイの昇格を開始: 選択したスタンバイサーバーをプライマリロールに昇格させるコマンドを実行します。具体的なコマンドは、使用する管理ツール（例：pg_ctl promoteまたはクラスタマネージャコマンド）によって異なります。
  4. 古いプライマリを再構成: スタンバイが正常に昇格した後、古いプライマリを新しいプライマリをスタンバイとしてフォローするように再構成する必要があります。これには、primary_conninfoの更新が含まれます。
  5. アプリケーションのリダイレクト: ロードバランサーまたは接続プーラーを更新し、新しいプライマリサーバーにトラフィックを向けます。

フェイルオーバー：緊急対応

フェイルオーバーとは、現在のプライマリサーバーが予期せぬ障害（例：ハードウェアクラッシュ、ネットワークパーティション、ソフトウェアエラー）によって迅速にオンラインに戻せない場合にトリガーされる、即時的な反応手順です。

フェイルオーバーは、障害が発生する前に最後の数件のコミット済みトランザクションがスタンバイにストリームされる時間が保証されないため、本質的にデータ損失のリスクが高くなります。

緊急フェイルオーバーの実行

フェイルオーバー手順は、スピードとリカバリを目的として設計されており、多くの場合、昇格を自動化するために特殊なツールが利用されます。

  1. 古いプライマリの状態を確認: 元のプライマリが一時的なネットワークの問題ではなく、本当に利用不能であることを確認します（これにより、危険な「スプリットブレイン」シナリオが防止されます）。
  2. 最適なスタンバイを選択: レプリケーション遅延が最も少ないスタンバイ（WALストリームで最も進んでいるもの）を選択します。
  3. スタンバイを昇格: 選択したスタンバイを昇格コマンド（pg_ctl promote）を使用して直ちに昇格させます。
  4. データ損失の処理（必要に応じて）： クラスターが非同期レプリケーションを利用している場合、障害が発生したプライマリで失われたデータは、アプリケーションの許容度に応じて、手動で調整するか、単に受け入れる必要がある場合があります。
  5. 元のプライマリを再構成: 元のプライマリが復旧したら、クリーンアップ、再初期化（多くの場合、新しいプライマリからのベースバックアップが必要）、および新しいプライマリをフォローするように構成する必要があります。

安全な昇格のためのツール：RepmgrとPatroni

pg_ctlを使用した手動昇格も可能ですが、堅牢なHA環境では、フェイルオーバーとスイッチオーバーに必要な複雑なオーケストレーションを管理し、構成変更とクラスタ状態管理を自動的に処理するために専用ツールに依存しています。

Repmgr（レプリケーションマネージャー）

repmgrは、レプリケーションを監視し、手動または自動フェイルオーバーを容易にする強力で軽量なツールです。主要なコマンドは次のとおりです。

  • スイッチオーバー: repmgr standby promoteに続きrepmgr switchover --sibling-nodes-wait（追いつきを保証するため）。
  • フェイルオーバー: repmgr failover

Patroni

Patroniは、分散合意ストア（etcd、ZooKeeper、Consulなど）を利用してクラスタ状態を管理し、障害検出時に新しいプライマリを自動的に選出します。Patroniは、API呼び出しやKubernetesオペレーターを通じてスイッチオーバーとフェイルオーバーの両方を大幅に自動化し、手動介入を劇的に削減します。

Patroniを使用した例（概念的な昇格コマンド）：

# PatroniのREST APIを介したスイッチオーバーのトリガー
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

スプリットブレインに関する警告: 自動フェイルオーバー中の最大の危険は、「スプリットブレイン」シナリオです。これは、ネットワークパーティションのために2つのノードが誤って自身をプライマリであると信じ込む状況です。Patroniのようなツールはクォーラムメカニズムを使用してこれを軽減しますが、手動設定では、プライマリが1つだけ存在するように厳格なフェンシングメカニズム（電源制御など）が必要です。

相違点のまとめ

機能 スイッチオーバー（計画的） フェイルオーバー（緊急）
トリガー メンテナンス、アップグレード、管理上の選択 プライマリの障害（クラッシュ、停止）
データ損失のリスク ほぼゼロ（適切にタイミングが合えば） 中〜高（レプリケーションモードによる）
ダウンタイムの予測 短く、制御されたダウンタイム 即時的な、反応的なダウンタイム
準備 事前調整とWAL同期の確認が必要 即時対応とスタンバイの健全性への依存が必要

PostgreSQLのフェイルオーバーとスイッチオーバーを実行するには、クラスタの状態とそれを管理するツールに関する深い理解が必要です。スイッチオーバーは協調を通じてデータ損失ゼロを目指しますが、フェイルオーバーは迅速なサービス復旧を優先し、多くの場合、最新のトランザクションが犠牲になります。レプリケーションパラメータの適切な設定と堅牢なクラスタ管理ツールの利用は、信頼性の高いPostgreSQL高可用性の基盤です。