MQ SYSTEM.CLUSTER.REPOSITORY.QUEUE深度不斷增加

Question

我有一個MQ集羣環境。在某一點上，部分存儲庫qmgr中的一個崩潰了，而另一個qmgr的隊列深度卻在不斷增加，而排隊SYSTEM.CLUSTER.REPOSITORY.QUEUE的深度不斷增加。

我有點不明白爲什麼會發生這種情況。我從這個鏈接走過了技術說明http://www-01.ibm.com/support/docview.wss?uid=swg21193012 但我不明白。有人能幫助解釋更詳細，更清楚嗎？

由於

Answer 1

的存儲庫隊列包含表示羣集的狀態的消息。完整的存儲庫跟蹤羣集中所有對象和QMgrs的狀態，而羣集成員QMgrs僅跟蹤他們需要了解的對象。由於這通常是一個子集，因此普通集羣QMgrs有時稱爲「部分存儲庫」，因爲這是它們包含的內容 - 完整存儲庫信息的部分子集。

存儲庫隊列中消息的實際格式未公開記錄。 Technote解釋說，信息經常被重新排列和壓縮，因此您不應該期望集羣對象數量和存儲庫隊列深度之間存在線性關係。根據時間的不同，存儲庫隊列中的一條消息可能表示多個集羣對象的狀態或僅一個。甚至可能存在代表已刪除羣集對象狀態的存儲庫消息。通常情況下，部分存儲庫在存儲庫隊列中的消息數少於完整存儲庫的消息數量，但如果不是，通常不會顯示任何問題。

Technote沒有解釋的是，存儲庫隊列中的消息被保持在同步點之下，並且這會扭曲QDepth。例如，QMgr將在啓動時讀取所有集羣存儲庫消息。如果需要進行更改，則會在相關消息的同步點下執行GET操作。在這些消息處於同步點時，即使消息仍然存在，隊列深度也會降低。表觀深度和實際深度只能在COMMIT或ROLLBACK後匹配。隨着羣集狀態的變化，新的消息被放入隊列以反映新的狀態。即使交易正在等待COMMIT或ROLLBACK，這些會立即增加明顯的QDepth。此外，寫入的消息數量可能遠遠多於或少於任何隊列更新所獲得的數量。

所以Technote的結果和我的建議是接受SYSTEM.CLUSTER.REPOSITORY.QUEUE是不穩定的，不要太在意它的深度。相反，如果您有監視代理程序，請監視隊列上總是有打開的輸入句柄，或者正在運行集羣資源庫管理器進程（amqrrmfa），或者兩者都運行。