IBM MQクラスタ接続の問題

キュー・マネージャーがクラスター環境内のリポジトリーへの接続を緩めることができるケースは何ですか? 私は、キューマネージャがリポジトリへの接続を頻繁に失っている環境があります。これを修正し、クラスタ内の他のキューマネージャとの通信を再確立するために、クラスタをリフレッシュする必要があります。

私たちのクラスターには100のキュー・マネージャーがあり、そこには2つのリポジトリーがあります。

3
「キュー・マネージャーがリポジトリーへの接続を頻繁に失っていますか」ということは、正確にはどういう意味ですか?チャンネルが再試行されますか?リポジトリが DIS CLUSQMGR に表示されなくなりましたか?クラスタメンバが DIS CLUSQMGR リポジトリに表示されなくなりましたか?この場合、WMQのバージョンとエラーログには何が表示されますか?
追加された 著者 T.Rob,
こんにちはロブ、私は問題の中でこのチェックをしていませんでした。私はちょうどリモートqにテストmsgを入れようとしましたが、キューがリモートサーバ上に存在してもMQRC 2087エラーコードで失敗しています。クラスタの更新後、正常に動作しています。私は再びそれに直面するときにこれらのチェックを行います。私たちはMQV7のリポジトリとMQV6の他のすべてのサーバを持っています。
追加された 著者 Vignesh,
チャネルは再試行状態にありません。
追加された 著者 Vignesh,

1 答え

これを引き起こす可能性のあるいくつかの異なる問題があります。 1つは、非リポジトリQMgrを指し示す CLUSSDR チャネルが明示的に定義されている場合です。これにより、リポジトリのメッセージがリポジトリ以外のQMgrに届くため、 amqrrmfa リポジトリプロセスが終了する可能性があります。もう1つは、いくつかのAPARSがあります(この1つ)、それはそのプロセスの死を招く可能性があります。解決策は、構成の問題を修正するか、最新のフィックスパックを適用することです。あまり一般的ではない別の問題は、新しいQMgrがローカルQMgrに解決される前に、新しいQMgrへのメッセージがエラーになることです。この場合、 REFRESH は実際にリモートQMgrを解決させることはありません。

これをデバッグするには、考えられる原因を切り分けます。 amqrrmfa が実行されていることを確認します。すべての非リポジトリQMgrsに1つの明示的に定義されたCLUSSDRチャネルがあることを確認します。すべてのリポジトリに1つのリポジトリと1つの明示的に定義されたCLUSSDRがそれぞれ別のリポジトリにあることを確認します。重複するクラスタを使用する場合は、チャンネルを重ならないようにしてください。これは、 TO.QMGR のようなチャンネル名を避け、 CLUSTER.QMGR のような名前を好むことを意味します。チャネルが CLUSNL 属性を使用しないようにして、代わりに CLUSTER 属性を使用してこれを確認してください。最後に、 DIS CLUSQMGR(*)および DIS QCLUSTER(*)を発行して、両方のリポジトリと非リポジトリのオブジェクトを調整します。リポジトリには、オブジェクトインベントリが同一である必要があります。それが間違っている場合、問題があります。非リポジトリには、以前に話したすべてのQMgrのエントリが必要です。

過去に私が見たことの1つは、管理者が REFRESH CLUSTER をスケジュールしていたことです。彼の考えは、これがクラスタを修正するために必要なものだったので、定期的にそれを稼働させるのはなぜですか?だから彼は毎日実行するようにスケジュールしました。その後毎晩、QMgrはクラスタ内の他のQMgrsについて忘れてしまい、毎日アプリがリモートQMgrを解決したときに、慌ただしいリポジトリトラフィックが発生しました。このため、毎朝2087のエラーが発生していました。 あなたはそのようなことをするわけではありません。 :-)

1
追加された
REFRESH CLUSTER はリポジトリとの同期が外れたときに非リポジトリを修正するコマンドです。このコマンドは、クラスタメンバにクラスタを忘れさせ、リポジトリから現在のステータスをリロードします。 DIS CLUSQ DIS CLUSQMGR を実行すると、ノードがどれくらいの量のクラスタを知っているかを知ることができます。
追加された 著者 T.Rob,
こんにちは、ロブ、いつ "クラスタの更新"が必要ですか?
追加された 著者 Vignesh,