データベース接続消失の検出の調整

メッセージング・エンジンがデータ・ストアを使用するように構成されているが、例えばデータ・ストアが含まれているデータベースが実行していないなどの理由で、そのデータ・ストアに接続できない場合、メッセージング・エンジンは開始しません。 メッセージング・エンジンが正常に開始する可能性を向上させるために、システムを調整することができます。

このタスクについて

シングル・サーバー環境では、アプリケーション・サーバーを開始すると、メッセージング・エンジンは開始を試行します。 データベースの使用不可状態が 15 分を超えると、メッセージング・エンジンは停止状態に入る場合があり、手動で開始することが必要になります。

高可用性環境では、メッセージング・エンジンはサーバーまたはクラスター始動の一部として、あるいはフェイルオーバー・プロセスの一部として開始します。 メッセージング・エンジンの始動中に、メッセージング・エンジンはデータ・ストアへの接続を、デフォルトでは最大 15 分間試行します。 その時間中に以下の記述のいずれかが当てはまる場合、メッセージング・エンジンはサーバー上で開始できず、サーバーは高可用性に使用できません。
  • データベースが使用不可であるかまたは実行していない。
  • フェイルオーバー状況では、データベースは元のアプリケーション・サーバーへのネットワーク接続が失われていることを検出しないため、データ・ストアのロックを解放することはありません。
この使用不可状態は、クラスターのすべてのメンバーに伝搬する可能性があります。 高可用性環境を維持するには、手動でサーバーを再度使用可能にする必要があります。

15 分のデフォルトのタイムアウトなどのさまざまなパラメーターを、データベース・サーバーまたはアプリケーション・サーバー上で構成することで、メッセージング・エンジンが正常に開始する可能性を高めることができます。

手順

  1. データベース・サーバー上で、アプリケーション・サーバーへのネットワーク接続の消失の検出に取る時間量を最小限にするようにオペレーティング・システムを構成します。 詳しくは、オペレーティング・システムの資料を参照してください。 例えば、以下の表では Windows および AIX® オペレーティング・システム用の関連パラメーターをリストしています。
    表 1. TCP/IP パラメーター. 表の 1 列目には、Windows オペレーティング・システムの TCP/IP パラメーターがリストされています。表の 2 列目には、AIX オペレーティング・システムの TCP/IP パラメーターがリストされています。3 列目にはパラメーターの説明が示されています。
    Windows オペレーティング・システム上のパラメーター名 AIX オペレーティング・システム上のパラメーター名 説明
    KeepAliveTime tcp_keepidle 非アクティブ接続に対する keepalive 要求を送信する前に待機する時間量 (Windows オペレーティング・システムではミリ秒単位、AIX オペレーティング・システムでは 0.5 秒単位)。
    KeepAliveInterval tcp_keepintvl 応答を待機する時間量 (Windows オペレーティング・システムではミリ秒単位、AIX オペレーティング・システムでは 0.5 秒単位)。
    TCPMaxDataRetransmissions tcp_keepcnt 接続を終了する前に送信する要求の数。
    以下の公式を使用して、データベース・サーバーがアプリケーション・サーバーへの接続の失敗を検出するために取った合計時間量を計算できます。

    接続失敗の検出のための時間 = キープアライブ時間 + (キープアライブ間隔 x 要求数)

    例えば、以下の表に従ってパラメーターが設定されている Windows システムの場合、データベース・サーバーがアプリケーション・サーバーへの接続の失敗を検出するために取った合計時間量は、350 秒です。
    表 2. パラメーター値の例. 1 列目にはパラメーター名が示されています。2 列目にはパラメーターのサンプル値が示されています。
    パラメーター
    KeepAlive 300000 ミリ秒
    KeepAliveInterval 10000 ミリ秒
    TCPMaxDataRetransmissions 5
    データベース製品にはさらに、例えば DB2® for z/OS® の IDLE THREAD TIMEOUT パラメーターのような、構成可能な関連パラメーターもある場合があります。

    データベース・サーバーがアプリケーション・サーバーへの接続が失われていることを検出すると、データベースはデータ・ストアのロックを解放します。 こうするとメッセージング・エンジンはデータ・ストアにアクセスできるようになるので、正常に開始することができます。

  2. アプリケーション・サーバー上で、データ・ストアが使用可能になるのを適切な時間量だけ待機するように、メッセージング・エンジンを調整します。 デフォルトでは、メッセージング・エンジンは、2 秒おきのデータ・ストアへの接続試行を 15 分間行います。 この時間を調整する場合には、このステップの残りの部分を完了します。
    1. サービス統合 ->「バス」 -> 「bus_name -> [トポロジー (Topology)]「メッセージング・エンジン (Messaging engines)」 ->「engine_name -> [追加プロパティー (Additional Properties)]「カスタム・プロパティー (Custom properties)」 をクリックして、メッセージング・エンジンのカスタム・プロパティー・パネルにナビゲートします。
    2. 「新規」をクリックします。
    3. 「名前」フィールドには sib.msgstore.jdbcInitialDatasourceWaitTimeout を、「値」フィールドには適切な値を、それぞれ入力します。 このプロパティーは、データ・ストアが使用可能になるのを待機する、ミリ秒単位の時間です。 デフォルト値は 900000 (15 分) です。 この時間には、データベースへの接続を確立し、必要なテーブル・ロックを取得するために必要な時間が含まれます。

      このプロパティーの値は、ステップ 1 で構成した、データベース・サーバーがネットワーク接続の消失の検出に取る合計時間よりも必ず長くなるようにしてください。

    4. 「OK」をクリックします。
    5. 「新規」をクリックします。
    6. 「名前」フィールドには sib.msgstore.jdbcStaleConnectionRetryDelay を、「値」フィールドには適切な値を、それぞれ入力します。 このプロパティーは、データ・ストアへの接続試行の間に待機する、ミリ秒単位の時間です。 デフォルト値は 2000 (2 秒) です。 例えば、sib.msgstore.jdbcInitialDatasourceWaitTimeout プロパティーを 600000 に、sib.msgstore.jdbcStaleConnectionRetryDelay プロパティーを 3000 にそれぞれ設定した場合、メッセージング・エンジンは、10 分が経過するまで 3 秒おきに接続を再試行します。
    7. 「OK」をクリックします。
    8. 変更をマスター構成に保存します。
    9. アプリケーション・サーバーを再始動します。
    10. クラスターを使用している場合は、前のステップを繰り返して、クラスター内のすべてのメッセージング・エンジンにこれらのプロパティーを追加します。

タスクの結果

これらのパラメーターおよびカスタム・プロパティーを構成することで、データベース・サーバーがネットワーク接続の消失の検出に取る時間量を最小限にし、開始を試行する前に、メッセージング・エンジンに妥当な時間量だけデータベース接続の復旧を待機させることができます。

次のタスク

データベース接続障害の発生時にメッセージング・エンジンとサーバーを再始動するように構成することができます。 この動作により、データベース接続の復元時にメッセージング・エンジンが不整合状態になるというリスクが削減されます。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjm_tunedbconn
ファイル名:tjm_tunedbconn.html