EDB Failover Manager User Guide 4.2

EnterpriseDB

EDB Failover Manager User Guide

** EDB Failover Manager **

EDB Postgresのフェイルオーバーマネージャー（EFM）は、プライマリ上のソフトウェアまたはハードウェア障害が発生しイベントにスタンバイ・ノードに自動的にフェイルオーバーするPostgresのプライマリノードを可能EnterpriseDBのより高可用性モジュールです。

このガイドでは、フェールオーバーマネージャーのインストール、構成、および使用に関する情報を提供します。 Failover Managerがサポートするプラットフォームとバージョンの詳細については、次のEnterpriseDB ウェブサイトしてください。

https://www.enterprisedb.com/services-support/edb-supported-products-and-platforms#efm

このドキュメントでは、 PostgreSQLまたはEDB Postgres Advanced Serverデータベースを意味するPostgresを使用しています。

whats_new failover_manager_overviewinstalling_efmconfiging_efmusing_efmmonitoring_efm_clusterusing_efm_utilitycontrolled_efm_servicecontroling_logging通知supported_scenarios upgrade_existing_clusterトラブルシューティングconfiguring_streaming_replicationconfiguring_ssl_authenticationの結論

</ div>

What’s New

バージョン4.2を作成するために、 EDB Postgres Failover Managerに次の変更が加えられました。

  • 非sudoモードでPgpool EFM統合を有効にするサポートが追加されました。
  • フェイルオーバーマネージャーは現在、プライマリエージェントで障害が発生した場合に、ロードからノードを切り離す必要はありませんが、データベースがまだ到達可能であるかどうかを指定するためのオプションを提供します。
  • 特定のプライマリノードに適用可能なスタンバイの優先度を定義するサポートが追加されました。
  • スタンバイを再構成する方法が強化され、アーカイビングが使用されるときにスタンバイが新しいプライマリに適切に従うようになりました。
  • 以前は古いプライマリがアクティブのままで監視されていなかった状況でのフェールオーバーを可能にするために、文書にEager Failoverという実行モードが追加されました。
  • stop-clusterコマンドを無効にするオプションが追加されました。

Failover Manager Overview

EDB Postgres Failover Manager（EFM）クラスターは、ネットワーク上の次のホストに存在するFailover Managerプロセスで構成されます。

  • プライマリノード-プライマリノードは、データベースクライアントにサービスを提供しているプライマリデータベースサーバです。
  • 1つ以上のスタンバイノード-スタンバイノードは、プライマリノードに関連付けられたストリーミングレプリケーションサーバーです。
  • 監視ノード-監視ノードは、フェイルオーバーシナリオでプライマリまたはスタンバイのアサーションを確認します。クラスターに3つ以上のノードが含まれる場合、クラスターには専用の監視ノードは必要ありません。データベースホストである3番目のクラスターメンバがない場合は、専用の監視ノードを追加できます。クラスターには、複数の監視ノードが含まれる場合があります。

従来、クラスターはマルチプルのデータベースを管理するPostgresの単一インスタンスです。このドキュメントでは、クラスターという用語はフェールオーバーマネージャークラスターを指します。フェールオーバーマネージャークラスターは、クラウドまたは従来のネットワーク上のサーバーに存在し、JGroupsツールキットを使用して通信するプライマリエージェント、1つ以上のスタンバイエージェント、およびオプショナルの監視エージェントで構成されます。

An EFM scenario employing a virtual IP address
  • 仮想IPアドレスを使用するEFMシナリオ*

非監視エージェントが起動すると、ローカルデータベースに接続し、データベースの状態を確認しデータベース。

  • エージェントがデータベースに到達できない場合、アイドルモードでスタートします。
  • データベースがリカバリであることがわかると、エージェントはスタンバイのロールを引き受けます。
  • データベースがリカバリでない場合、エージェントはプライマリのロールを引き受けます。

フェイルオーバーが発生しイベント、フェイルオーバーマネージャーの試みが進めスタンバイ内の最新スタンバイであることを保証します。スタンバイノードがプライマリノードと同期していない場合、データロスれる可能性があることにノートてください。

JGroupsは、フェールオーバーマネージャーが、メンバノードが相互に通信してノード障害を検出できるクラスターを作成できるようにする技術を提供します。

上記の図は、仮想IPアドレスを使用するFailover Managerクラスターを示しています。あなたが再構成するために、データベースが追加または削除されるたびにロードを独自に提供している場合は、代わりにロードを使用することができます。また、高可用性のためにネイティブEFM-Pgpool統合を有効にすることもできます。

前提条件

Prerequisites

フェールオーバーマネージャークラスターを構成する前に、以下で説明する前提条件を満たす必要があります。

** Java 1.8（以降）をインストールします**

Failover Managerを使用する前に、最初にJava（バージョン1.8以降）をインストールする必要があります。フェイルオーバーマネージャーはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。 Installation instructions for Javaはプラットフォーム固有です。

** SMTPサーバーを提供する**

ユーザー定義の通知スクリプト、メール、またはその両方で指定されたとおりに、フェールオーバーマネージャーから通知を受信できます。

  • メール通知を使用している場合、フェールオーバーマネージャーシナリオの各ノードでSMTPサーバーが実行されている必要があります。
  • スクリプトに値を指定した場合。通知プロパティでは、ユーザを残すことができます。メールフィールドは空白です。 SMTPサーバーは必要ありません。

イベントが発生すると、フェールオーバーマネージャーはスクリプト（提供されている場合）を呼び出し、ユーザで指定された任意のメールアドレスに通知メールを送信することもできます。クラスタプロパティファイルのメールパラメータ。 SMTPサーバーの使用の詳細については、次のWebサイトをご覧ください。

https://access.redhat.com/site/documentation

ストリーミングレプリケーションの構成

Failover Managerでは、 PostgreSQLストリーミングレプリケーションがプライマリノードとスタンバイノード間で構成されている必要があります。フェールオーバーマネージャーは、他の種類のレプリケーションをサポートしていません。

データベースバージョン11（またはそれ以前）では、-sourcenodeオプションで指定しない限り、スイッチオーバー中にrecovery.confファイルがランダムスタンバイノードから停止したプライマリにコピーされます。スイッチオーバーを実行する前に、スタンバイノードのrecovery.confファイル内のパスが一貫していることを保証する必要があり経路。 -sourcenodeオプションの詳細については、Promoting a Failover Manager Nodeを参照してください。

データベースバージョン12以降では、スイッチオーバー中にprimary_conninfoおよびrestore_commandプロパティがランダムスタンバイノードから停止したプライマリにコピーされます（-sourcenodeオプションで指定されていない場合）。

** pg_hba.confファイルを変更します**

プライマリノードとスタンバイノードでpg_hba.confファイルを変更し、クラスター内のすべてのノード間の通信を許可するエントリを追加する必要があります。次の例は、プライマリノード上のpg_hba.confファイルに作成される可能性のあるエントリを示しています。

#  access for itself
host fmdb efm 127.0.0.1/32 md5
#  access for standby
host fmdb efm 192.168.27.1/32 md5
#  access for witness
host fmdb efm 192.168.27.34/32 md5

どこで：

efmは、有効なデータベースユーザの名前を指定します。

fmdbは、efmユーザが接続できるデータベースの名前を指定します。

デフォルトでは、pg_hba.confファイルはPostgresインストールのdataディレクトリにあります。 pg_hba.confファイルを変更た後、変更を有効にするには、各ノードで構成ファイルをリロードロードする必要があります。次のコマンドを使用できます。

# systemctl reload edb-as-x

xはPostgresバージョンを指定します。

データベースサーバーの自動起動の使用

プライマリノードが再起動した場合は、フェイルオーバーマネージャーは、データベースがプライマリノード上でダウンして検出し、プライマリのロールにスタンバイ・ノードをプロモートことができます。これが発生した場合、（リブートされた）プライマリノードのFailover Managerエージェントはrecovery.confファイルを書き込む機会を得られません。 recovery.confファイルは、データベースサーバの起動を妨げます。これが発生した場合、再起動されたプライマリノードは、2番目のプライマリノードとしてクラスタに結果ます。

これを防ぐために、フェイルオーバーマネージャー・エージェントの自動データベースサーバの前に開始されることを保証。エージェントはアイドルモードでスタートし、クラスター内に既にプライマリがあるかどうかを確認します。プライマリノードがある場合、エージェントはrecovery.confまたはstandby.signalファイルが存在することを確認し、データベースは2番目のプライマリとしてスタートしません。

ファイアウォールを介した通信を保証

Linuxファイアウォール（iptables）がFailover Managerノードのホストで有効になっている場合、クラスター内のFailover Managerプロセス間のTCP通信を許可するルールをファイアウォール構成に追加する必要があります。例：

#  iptables -I INPUT -p tcp --dport 7800 -j ACCEPT
/sbin/service iptables save

上記のコマンドは、ポート7800を開きます。フェールオーバーマネージャーは、クラスタープロパティファイルで指定されたポートに対応するポートを介して接続します。

データベースユーザに十分な権限があることを確認してください

efm.propertiesファイルのdb.userプロパティで指定されたデータベースユーザには、フェールオーバーマネージャーに代わって次の機能を呼び出すための十分な権限が必要です。

pg_current_wal_lsn()

pg_last_wal_replay_lsn()

pg_wal_replay_resume()

pg_wal_replay_pause()

reconfigure.num.syncまたはreconfigure.sync.primaryプロパティがtrueに設定されている場合：

  • データベースバージョン9.6の場合、db.userはスーパーユーザニーズがあります。

  • バージョン9.6以降のデータベースバージョンの場合、db.userにはpg_reload_conf()を実行するためのpg_read_all_stats権限と権限が必要です。

これらの各機能の詳細については、PostgreSQL core documentationをご覧ください。

ユーザには、構成変数の値を読み取る権限も必要です。データベーススーパーユーザは、 PostgreSQL GRANTコマンドを使用して、必要な権限を提供できます。

GRANT pg_read_all_settings TO user_name;

pg_read_all_settingsの詳細については、PostgreSQL core documentationを参照してください。

Installing Failover Manager