チュートリアル-単純なフェールオーバーマネージャークラスターの構成

このチュートリアルでは、テスト環境でのFailover Managerクラスターの迅速な構成について説明します。このガイドの他のセクションでは、運用展開用にフェールオーバーマネージャーを構成する前に読んで理解する必要がある重要な情報を提供します。

このチュートリアルでは、次のことを前提としています。

• データベースサーバーが実行されており、マスターと1つまたは2つのスタンバイノード間でストリーミングレプリケーションがセットアップされています。
• 各ノードにFailover Managerをインストールしました。

次の例では、 efmという名前のクラスターを作成します。

マスターまたはスタンバイノードで構成プロセスを開始する必要があります。次に、構成ファイルを他のノードにコピーして、時間を節約します。

ステップ1：作業用構成ファイルを作成する

提供されたサンプルファイルをコピーしてEFM構成ファイルを作成し、所有権を修正します。

cd /etc/edb/efm-3.6

cp efm.properties.in efm.properties

cp efm.nodes.in efm.nodes

chown efm:efm efm.properties

chown efm:efm efm.nodes

ステップ2：暗号化されたパスワードを作成する

暗号化されたパスワードを作成します（プロパティファイルに必要）：

/usr/edb/efm-3.6/bin/efm encrypt efm

画面の指示に従って、データベースパスワードの暗号化バージョンを作成します。

ステップ3：efm.propertiesファイルを更新する

cluster_name.propertiesファイルには、Failover Managerクラスターの接続プロパティと動作を指定するパラメーターが含まれています。プロパティ設定の変更は、フェールオーバーマネージャーの起動時に適用されます。

次のプロパティは、Failover Managerクラスタを構成するために必要な最小限のプロパティです。実稼働システムを構成する場合、プロパティの完全なリストについては、クラスタプロパティファイルを参照してください。

データベース接続プロパティ（ミラーリング監視でも必要なため、必要に応じて他のデータベースに接続できます）：

db.user

db.password.encrypted

db.port

db.database

データディレクトリの所有者（通常はpostgresまたはenterprisedb）：

db.service.owner

EFMは、再起動時にdb.service.nameおよびdb.binプロパティを使用します サーバ。 db.service.nameプロパティで提供されるサービス名は、 serviceまたはsystemctlサーバーを再起動するときに使用されます。 db.binプロパティ（Postgres binディレクトリへのパス）で指定した値は、 pg_ctl呼び出しに使用されます。 db.binは必須フィールドであることに注意してください。データベースをサービスとして実行している場合、 db.service.nameが必要です。

db.service.name

db.bin

EFMがrecovery.confファイルを検索または作成するデータディレクトリ：

db.recovery.conf.dir

電子メール通知を受信するように設定します（通知テキストはエージェントログにも含まれます）。

user.email

これは、ノードのローカルアドレスとEFMに使用するポートです。他のノードはこのアドレスを使用してエージェントに到達し、エージェントはこのアドレスを使用してローカルデータベースに接続します（ローカルホストに接続するのではなく）。形式の例を以下に示します。

bind.address=1.2.3.4:7800

監視ノードでこのプロパティをtrueに設定し、マスターまたはスタンバイの場合はfalse設定します。

is.witness

インターネットにアクセスせずにネットワークで実行している場合、これをネットワークで利用可能なアドレスに変更します。

pingServerIp=8.8.8.8

実稼働クラスターを構成するとき、以下のプロパティーは、システム構成および使用法に応じてtrueまたはfalseになります。 EFMテストクラスターを構成する場合は、両方をtrueに設定して起動を簡素化します。

auto.allow.hosts=true

stable.nodes.file=true

ステップ4：efm.nodesファイルを更新する

cluster_name.nodesファイルは、クラスターの残りの部分を見つける方法をエージェントに伝えるために起動時に読み込まれます。または、最初に起動したノードの場合、後続のノードの承認を簡素化するために使用できます。

クラスター内の各ノードのアドレスとポートをこのファイルに追加します。 1つのノードがメンバーシップコーディネーターとして機能します。リストには、少なくともメンバーシップコーディネーターの住所を含める必要があります。例えば：

1.2.3.4:7800

1.2.3.5:7800

1.2.3.6:7800

Failover Managerエージェントはコンテンツを検証しないことに注意してください efm.nodesファイルの;エージェントは、ファイル内の一部のアドレスに到達できないことを予期しています（たとえば、別のエージェントがまだ開始されていないなど）。 efm.nodesファイルの詳細については、クラスターメンバーファイルを参照してください。

ステップ5：他のノードの構成

efm.propertiesおよびefm.nodesファイルを、サンプルクラスター内の他のノードの/etc/edb/efm-3.6ディレクトリにコピーします。ファイルをコピーした後、ファイルの所有権を変更して、ファイルがefm:efmによって所有されるようにします。 efm.propertiesファイルは、次のプロパティを除き、すべてのノードで同じにすることができます。

• ノードのローカルアドレスを使用するようにbind.addressプロパティを変更します。
• ノードがis.witnessノードである場合、 is.witnessをtrue設定します。ノードが監視ノードである場合、ローカルデータベースのインストールに関連するプロパティは無視されます。

ステップ6：EFMクラスターを開始する

任意のノードで、Failover Managerエージェントを起動します。エージェントの名前はefm-3.6です。プラットフォーム固有のサービスコマンドを使用して、サービスを制御できます。たとえば、CentOSまたはRHEL 7.xホストでは、次のコマンドを使用します。

systemctl start efm-3.6

CentOSまたはRHEL 6.xホストでは、次のコマンドを使用します。

service efm-3.6 start

エージェントが起動したら、次のコマンドを実行して、シングルノードクラスターのステータスを確認します。 Allowed node hostリストに他のノードのアドレスが表示されます。

/usr/edb/efm-3.6/bin/efm cluster-status efm

他のノードでエージェントを起動します。任意のノードでefm cluster-status efmコマンドを実行して、クラスターの状態を確認します。

エージェントの起動に失敗した場合は、起動ログで問題の詳細を確認してください。

cat /var/log/efm-3.6/startup-efm.log

スイッチオーバーの実行

マスターとスタンバイが同期していることがクラスターステータス出力に示されている場合は、次のコマンドでスイッチオーバーを実行できます。

/usr/edb/efm-3.6/bin/efm promote efm -switchover

このコマンドは、スタンバイを昇格させ、マスターデータベースをクラスター内の新しいスタンバイとして再構成します。元に戻すには、コマンドを再度実行します。

オンラインヘルプにすばやくアクセスするには、次のコマンドを呼び出すことができます。

/usr/edb/efm-3.6/bin/efm promote efm --help

efmコマンドラインツールの使用の詳細については、「 EFMユーティリティの使用 」 を参照してください。