IBM MQ集群连接问题

队列管理器可以在集群环境中将其连接到存储库的情况是什么？我有一个环境，队列管理器经常失去与存储库的连接，我需要刷新群集以解决此问题并重新建立与群集中其他队列管理器的通信。IBM MQ集群连接问题

我们的集群有100个队列管理器，我们有2个存储库。

2012-02-06 Vignesh

“你的意思是什么？”队列管理器经常失去与存储库的连接？频道重试？存储库不再显示在'DIS CLUSQMGR'中？集群成员不再出现在“DIS CLUSQMGR”存储库中？什么版本的WMQ以及错误日志在什么时候发生？ – 2012-02-06 12:58:57

Hello Rob，我没有在问题期间执行此检查。我只是试图将测试msg发送给远程q，即使队列存在于远程服务器上，它仍然无法使用MQRC 2087错误代码。群集刷新后，它工作正常。当我再次面对时，我会做这些检查。我们在MQV7和MQV6上的所有其他服务器上都有我们的存储库。 – Vignesh 2012-02-07 06:09:55

通道不处于重试状态。 – Vignesh 2012-02-07 11:28:45

有几个不同的问题可能导致此问题。一种是如果有明确定义的指向非存储库QMgr的通道CLUSSDR。这会导致存储库消息到达非回购QMgr，从而导致其存储库进程死亡。另一个是已经有几个APARS（如this one）可能导致该进程死亡。解决方案分别是解决配置问题或应用最新的修订包。另一个不太常见的问题是，在新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错误。不是说你会做这样的事情。 :-)

来源

2012-02-07 17:51:46

Hello Rob，何时需要“集群刷新”？ – Vignesh 2012-02-27 11:12:41

'REFRESH CLUSTER'是用于修复非存储库的命令，当它与存储库不同步时。该命令使群集成员忘记群集并从存储库重新加载当前状态。如果运行'DIS CLUSQ'和'DIS CLUSQMGR'，您可以看到节点“知道”了多少集群并将其与回购进行比较。 – 2012-02-27 13:44:49

IBM MQ集群连接问题

回答

相关问题