MQ クラスター環境が 1 つあります。ある時点で、部分リポジトリ qmgr の 1 つが故障しSYSTEM.CLUSTER.REPOSITORY.QUEUE、別の qmgr のキューの深さが増加し続けました。
なぜこれが起こったのか、私にはちょっと理解できません。このリンクhttp://www-01.ibm.com/support/docview.wss?uid=swg21193012から技術情報を読みました が、理解できません。誰かがより詳細かつ明確に説明するのを手伝ってもらえますか?
ありがとう
リポジトリ キューには、クラスタの状態を表すメッセージが含まれています。フル リポジトリは、クラスター内のすべてのオブジェクトと QMgr の状態を追跡しますが、クラスター メンバーの QMgr は、知る必要のあるオブジェクトのみを追跡します。これは通常サブセットであるため、通常のクラスター QMgr は「部分リポジトリー」と呼ばれることがあります。これは、完全なリポジトリー情報の部分サブセットが含まれているためです。
リポジトリ キューのメッセージの実際の形式は公開されていません。Technote で説明されていることは、情報が頻繁に再配置および圧縮されるため、クラスター オブジェクトの数とリポジトリ キューの深さとの間に直線的な関係があるとは考えられないということです。タイミングによっては、リポジトリ キューの 1 つのメッセージが、複数のクラスター オブジェクトの状態を表している場合もあれば、1 つだけの状態を表している場合もあります。削除されたクラスター オブジェクトの状態を表すリポジトリ メッセージさえある場合があります。一般に、部分リポジトリーは、完全リポジトリーよりもリポジトリー・キューにあるメッセージが少なくなりますが、そうでない場合は通常、問題を示すものではありません。
Technote で説明されていないのは、リポジトリ キューのメッセージが同期点の下に保持され、これにより QDepth が歪むということです。たとえば、QMgr は起動時にすべてのクラスター リポジトリ メッセージを読み取ります。変更が必要な場合は、関連するメッセージの同期点で GET を実行します。これらのメッセージが同期点の下にある間、メッセージがまだそこにある場合でも、キューの深さは減少します。COMMIT見かけの深度と実際の深度は、またはの後にのみ一致しROLLBACKます。クラスターの状態が変化すると、新しいメッセージがキューに入れられ、新しい状態が反映されます。COMMITこれらは、トランザクションが保留中または保留中であっても、見かけの QDepth を即座に増加させます。ROLLBACK. また、書き込まれるメッセージの数は、キューの更新で得られる数よりも大幅に多いか少ない場合があります。
したがって、Technote と私のアドバイスの結論は、SYSTEM.CLUSTER.REPOSITORY.QUEUE が揮発性であることを受け入れ、その深さについてあまり心配しないことです。代わりに、監視エージェントを使用している場合は、キューに開いている入力ハンドルが常に存在するか、クラスター リポジトリ マネージャー プロセス ( amqrrmfa) が実行されているか、またはその両方を監視します。