Failover Manager（EFM）5.3.0

日本語訳｜EDB Failover Manager（EFM）5.3.0

※GoogleのAutoML Translationを使用して翻訳しております。

英語原文｜EDB Failover Manager（EFM）5.3.0

概要

1. EFMとは何か
EDB Failover Manager (EFM) は、Postgresデータベースクラスターを管理するための高可用性（HA）ツールです。ストリーミングレプリケーションを用いたプライマリ・スタンバイ構成において高可用性を実現します。EFMはクラスターの健全性を監視し、ソフトウェアまたはハードウェアの障害が発生した場合に、プライマリデータベースノードからスタンバイデータベースノードへの自動フェイルオーバーを実行します。PostgreSQLおよびEDB Postgres Advanced Serverの両方に対応しています。

EFMクラスターは、通常以下のノードで構成されます。

• プライマリノード: クライアントへデータベースサービスを提供する稼働中のデータベースサーバー。
• スタンバイノード: プライマリノードに関連付けられた、1台以上のストリーミングレプリケーション用サーバー。
• ウィットネスノード（目撃者ノード）: 通常はデータベースを保持しないノード。フェイルオーバー時にプライマリまたはスタンバイノードの状態を確認し、クォーラム（定足数）の維持を支援します。

2. 機能

2-1. EFMがシステムのダウンタイムを防ぐ方法
EFMは、以下の仕組みにより、サービス中断を最小限に抑え、システムをダウンタイムから保護します。

• 継続的な健全性監視: EFMエージェントは、一定の間隔（local.period や local.timeout で定義）でローカルのデータベースサーバーを監視します。ローカルデータベースへの接続が途絶えた場合、エージェントはクラスター内の他のノードと連携して障害の有無を検証します。
• 自動的なスタンバイ昇格: プライマリデータベースの障害が確定すると、EFMは最もデータの進んでいるスタンバイノードを自動的に選択し、新しい書き込み可能なプライマリノードに昇格させます。
• 仮想IP（VIP）管理: 設定されている場合、EFMはプライマリノードに紐づけられた仮想IPアドレスを管理します。フェイルオーバーが発生すると、障害の発生したプライマリからVIPを自動的に解放し、新しく昇格したプライマリに割り当てます。これにより、アプリケーションは同じIPアドレスのまま接続を再開できます。
• ルーティングおよびロードバランシングツールとの連携: EFMは、仮想IP以外の接続管理方法もサポートしています。
  • クライアント接続フェイルオーバー: libpq や JDBC などの接続ライブラリを使用して、接続文字列に複数のホストを指定し、接続を順次試行します。
  • EDB PgBouncer / EDB Pgpool-II: フェイルオーバー時にEFMが再設定スクリプトを実行し、トラフィックを自動的に新しいプライマリへ転送します。
• イーガー・フェイルオーバー（Eager Failover）: systemd を利用したオプション機能。プライマリのEFMエージェントプロセスが停止または失敗した場合に、データベースを自動的に停止させ、スタンバイへのフェイルオーバーを即座にトリガーします。

2-2. EFMがスプリットブレインを回避する方法
スプリットブレイン（ネットワーク分断により複数のノードが同時に自身をプライマリと誤認する状態）を防ぐため、EFMは以下の機能を提供します。

• クォーラムとウィットネスノード: ネットワーク分断が発生した場合、プライマリノードが稼働を続けるには、クラスター全体の過半数（または半数以上）のノードが含まれるパーティション（グループ）に属している必要があります。ウィットネスノードは状態検証に参加し、過半数側のグループのみで昇格処理が行われるよう機能します。
• プライマリのフェンシング: プライマリノードがEFMクラスターの大部分から孤立したことを検知すると、孤立したプライマリのエージェントは自動的にローカルデータベースをシャットダウンし（stop.isolated.primary プロパティ経由）、仮想IPを解放して自身を隔離（フェンシング）します。これにより、2つのプライマリデータベースが同時に書き込みを受け付ける事態を防ぎます。
• 仮想IPの重複確認: スタンバイをプライマリに昇格させる前に、EFMは ping.server.command を使用して、仮想IPが他で既に使用されていないか、また到達不能になっているかを確認し、複数のノードが同じVIPを同時に配信するのを防ぎます。

3. EFMのメリット

• 自動化された高可用性: 計画外のプライマリノード障害が発生した際、手動でのスタンバイ昇格作業を不要にします。
• 柔軟な導入構成: 仮想IPの利用、クライアント側での接続フェイルオーバー、PgBouncerやPgpool-IIなどのプロキシやコネクションプーラーとの連携など、多様な構成に対応します。
• リソース競合の回避: クラウド環境でネットワークロードバランサー（NLB）を使用する構成など、データベースノードとコネクションプーラーを切り離すことで、システムリソースの奪い合いを防ぐことができます。
• 通知とカスタムスクリプトの連携: 重要度（INFO、WARNING、SEVERE）に応じたアラート通知（メールやカスタムスクリプト）を設定可能。昇格前後に実行するカスタムフェンシングスクリプトなどの仕組みも備わっています。
• 幅広いプラットフォーム対応: 主要なLinuxディストリビューション（RHEL、Rocky Linux、AlmaLinux、SLES、Debian、Ubuntu）で動作し、CPUアーキテクチャが混在する環境（例：プライマリ/スタンバイがIBM Power、ウィットネスがx86_64）もサポートしています。

4. バージョン5.3.0の新機能・変更点
リリースノートに記載されている主な機能強化およびバグ修正は以下の通りです。

• • SSLモード「verify-full」のサポート: jdbc.sslmode プロパティにおいて、より厳密な検証を行う verify-full モードがサポートされました。
  • スタンバイ再構築時の動作向上: スタンバイデータベースを再構築（再作成）する際、EFMが db.config.dir プロパティの値を適切に適用するようになりました。
  • レプリケーションスロット前進エラーの警告通知: スタンバイデータベース上で物理レプリケーションスロットの前進に問題が発生した場合に、警告通知を送信する機能が追加されました。
  • rewind前のチェックポイント実行: 一部のPostgreSQLバージョンとの互換性を保つため、障害の発生したプライマリデータベースを再構成する際、pg_rewind が必要かどうかを判断する前に、現在の稼働中プライマリでチェックポイントを強制実行するようになりました。
  • メモリ割り当ての拡張: efm ユーティリティ実行時のデフォルトメモリ割り当て量を増やし、「Notification; Unexpected error message」（メモリ不足エラー）が発生する問題を対策しました。
  • ライブラリのアップグレード:
    • Log4J のバージョンを 2.25.3 にアップグレード。
    • 暗号化ライブラリ Bouncy Castle のバージョンを 2.1.2 にアップグレード。

不具合の修正: 誤ってスタンバイノードに仮想IPを割り当ててしまった際に、EFMがそれを検知できなくなる不具合（リグレッション）を修正しました。

---