在哪些情况下，队列管理器会在集群环境中失去与存储库的连接？ 我有一个环境，其中队列管理器经常失去与存储库的连接，我需要刷新集群以解决此问题并重新建立与集群中其他队列管理器的通信。
我们的集群有 100 个队列管理器，其中有 2 个存储库。
【问题讨论】：
DIS CLUSQMGR 中？集群成员不再出现在存储库DIS CLUSQMGR？什么版本的 WMQ 以及发生这种情况时错误日志会显示什么？
标签： ibm-mq
有几个不同的问题可能导致此问题。一种是是否有明确定义的CLUSSDR 通道指向非存储库 QMgr。这会导致存储库消息到达非存储库 QMgr，这可能导致其 amqrrmfa 存储库进程终止。另一个是有一些 APARS（例如this one）可能导致该进程终止。解决方案分别是修复配置问题或应用最新的 Fix Pack。另一个不太常见的问题是，在新 QMgr 可以解析到本地 QMgr 之前，发给新 QMgr 的消息会出错。在这种情况下，REFRESH 实际上不会导致远程 QMgr 解析，它只是为解析完成提供时间。
调试这涉及隔离可能的原因。检查amqrrmfa 是否正在运行。检查所有非存储库 QMgrs 是否有一个且只有一个明确定义的 CLUSSDR 通道。验证所有存储库都有一个且只有一个明确定义的 CLUSSDR 到每个其他存储库。如果使用重叠集群，请确保不重叠通道。这意味着避免使用TO.QMGR 之类的频道名称，而更喜欢CLUSTER.QMGR 之类的名称。通过确保通道不使用CLUSNL 属性并改用CLUSTER 属性来验证这一点。最后，通过发出DIS CLUSQMGR(*) 和DIS QCLUSTER(*) 来协调存储库和非存储库中的对象。存储库应具有相同的对象清单。如果那是错误的，那么问题就来了。非存储库应该为其之前与之交谈的每个 QMgr 都有一个条目。
我过去看到的一件事是管理员安排了REFRESH CLUSTER。他的想法是，这是他们修复集群需要做的事情，那么为什么不定期运行它呢？所以他安排它每天运行。然后每天晚上它让 QMgr 忘记集群中的其他 QMgr，并且每天第一次应用程序解析远程 QMgr 时都会有大量的存储库流量。这导致了足够的延迟，以至于每天早上都会出现一些 2087 错误。并不是说你会做这样的事情。 :-)
【讨论】：
REFRESH CLUSTER 是用于在与存储库不同步时修复非存储库的命令。该命令使集群成员忘记集群并从存储库重新加载当前状态。如果您运行DIS CLUSQ 和DIS CLUSQMGR，您可以查看节点“了解”多少集群并将其与存储库进行比较。