データベース多重化運用では、以下の監視を行います。
OSやサーバのダウンおよび無応答
各サーバのMirroring Controller間でハートビートを行うことで、相互にOSやサーバの異常を検知します。
データベース多重化運用を行う環境や運用方法に最適な動作を以下から選択が可能です。
裁定サーバを利用して自動縮退(切り替え/切り離し)を行う
デフォルトの動作です。
裁定サーバがデータベースサーバの状態を客観的に判断し、状態が不安定なデータベースサーバのクラスタシステムからの隔離と縮退を行います。
“裁定サーバによるデータベースの縮退”を参照してください。
縮退の判断を行うユーザー出口(ユーザーコマンド)を呼び出して自動縮退を行う
物理的に裁定サーバを配置できない場合に、利用者が代わりに裁定処理を行うことが可能な場合に選択します。
Mirroring Controllerがユーザー出口へ縮退有無の判断を問い合わせます。本出口では、データベースサーバの状態を判断し、Mirroring Controllerに縮退を行うか否かを通知します。
“裁定コマンドを利用したデータベースの縮退”を参照してください。
メッセージを通知する
データベースサーバの2台構成でシステムを構築する場合に選択します。
Mirroring Controllerが異常検出時にメッセージをイベントログに出力します。そのため、ハートビート異常によりスプリットブレインを引き起こすことはありませんが、プライマリサーバのOSやサーバがダウンまたは無応答の場合に自動切り替えが行われません。
ハートビート異常で無条件に自動縮退を行う
本動作はFUJITSU Enterprise Postgres 9.6以前のバージョンからの互換扱いです。
Mirroring Controllerがハートビート異常で無条件に自動縮退を行うため、推奨できません。
データベースプロセスのダウンおよび無応答
Mirroring Controllerが、定期的にデータベースのプロセスにアクセスして状態を確認します。アクセスの可否やタイムアウトの監視によって、プロセスの異常を検知します。
ディスクの障害
Mirroring Controllerが、定期的に以下のデータ格納先ディスクにファイルを作成し、I/Oエラーの有無によってディスクの異常を検知します。
データ格納先のディスク
トランザクションログ格納先のディスク
テーブル空間格納先のディスク
検知可能な障害とは、ディスクヘッダや装置の電源不良などのシステム全体におよぶ物理的な障害です。
ストリーミングレプリケーションの異常
Mirroring Controllerが、定期的にPostgreSQLのシステムビューにアクセスすることで、ストリーミングレプリケーション(ログ転送用ネットワークおよびWAL送信/受信プロセス)の異常を検知します。
Mirroring Controllerプロセスのダウンおよび無応答
Mirroring Controllerでの監視処理を継続するために、Mirroring Controllerプロセスのダウンや無応答も合わせて監視しています。
Mirroring Controller監視プロセスが、定期的にMirroring Controllerプロセスに問い合わせを行うことで、Mirroring Controllerプロセスのダウンおよび無応答を検知します。異常が検知されるとMirroring Controller監視プロセスにより自動でMirroring Controllerの再起動が行われます。
ポイント
OSまたはサーバの生死監視においてハートビート異常を検出した場合の動作として、メッセージを出力する選択を行った場合には、ハートビート異常により自動縮退は行われません。
しかし、プライマリサーバでWAL送信プロセスの異常を検知した場合には、スタンバイサーバを切り離すため、結果的にスタンバイサーバでOSやサーバのダウンまたは無応答が発生した場合でも自動切り離しが行われる場合があります。
データベースプロセスの無応答やテーブル空間格納先のディスク障害を検知した場合にプライマリサーバの切り替えを行うか否かをパラメータで選択することができます。詳細は、“付録A パラメータ”を参照してください。
スタンバイサーバを切り離した場合には、Mirroring Controllerが自動的にプライマリサーバのpostgresql.confファイルのsynchronous_standby_namesパラメータをコメントアウトします。これによって、プライマリサーバにおけるアプリケーション処理が停止することを防止します。
注意
プライマリサーバが切り替わって縮退運転になった場合には、もとのプライマリサーバは自動ではスタンバイサーバとして組込まれません。異常原因を取り除いてから組込みを実施してください。詳細は、“4.1 縮退運転になった場合の対処”を参照してください。
裁定サーバによるデータベースの縮退
裁定サーバによるデータベースの縮退では、データベースサーバ間のネットワーク異常やサーバが不安定な状態に陥ることが原因で、データベースサーバが相互の状態を確認できない場合に、裁定サーバがデータベースサーバの状態をハートビートにより再確認します。
ハートビートの結果、状態が不安定であると判断した場合は、対象のデータベースサーバをクラスタシステムから隔離します(フェンシング)。
フェンシングは、Mirroring Controllerを使用している環境に応じて、処理をカスタマイズすることが可能です。
また、データベースサーバは、運用中にいつでも裁定サーバに確認依頼ができるように、裁定サーバに対して常にハートビートを行っています。
図1.3 裁定サーバによるデータベースの縮退
注意
裁定サーバは、クラスタシステムを構成するデータベースサーバで業務停止を伴うハードウェアやソフトウェアの障害が発生した場合に、これらの障害が波及しないサーバに配置してください。データベースサーバの障害時にMirroring Controllerによる自動切替えが行えなくなります。
例えば、裁定サーバはデータベースサーバと異なる物理サーバに配置してください。
裁定コマンドを利用したデータベースの縮退
裁定コマンドは、裁定サーバの代わりに裁定処理を行うユーザーコマンドです。裁定サーバを配置できない場合は、裁定コマンドを使用することで、データベースサーバの裁定処理を行うことが可能です。
図1.4 裁定コマンドを利用したデータベースの縮退
参照
ユーザーコマンドの詳細については、“2.6 データベースサーバのユーザー出口の作成”または“付録C ユーザーコマンド”を参照してください。
