WebSphere MQ应急预案-CSDN博客

本文链接：https://blog.csdn.net/hbhe0316/article/details/122701335

1.1 WMQ类场景一队列管理器挂起
场景一及描述：mqm组用户，使用dspmq命令显示队列管理器状态时，无法显示队列管理器状态，命令挂起无返回；使用runmqsc 进入MQ操作界面时，同样无返回结果，无法进入界面，遇到这种情况，判断为MQ挂起。

应急措施:
1.停止相关MQ应用
顺序停止相关的MQ进程，停止顺序为amqzmuc0 amqzxma0 amqfcxba amqfqpub amqpcsea amqzlaa0 amqzlsa0 runmqchi runmqlsr amqcrsta amqrrmfa amqrmppa amqzfuma amqzdmaa amqzmuf0 amqzmur0 amqzmgr0，使用 ps 命令查找正在运行的队列管理器程序的
进程PID，命令如下：

ps -ef | grep <qmgr_name>
kill -9 <PID>

2.清除MQ相关的IPC资源，命令如下：

/usr/mqm/bin/amqiclen -x -m <qmgr_name>

3.以mqm用户重新启动队列管理器

strmqm <qmgr_name>

4.检查队列管理器启动是否成功，检查监听是否启动以及能够进入runmqsc界面，并检查通道状态：

ps –ef |grep runmqlsr |grep <qmgr_name>
runmqsc <qmgr_name>
dis chs(*)
dis lsstatus(*)

5.重新启动MQ相关应用，并进行应用业务验证

1.2 WMQ类场景二队列管理器异常终止
场景二及描述：在手动停止MQ队列管理器的情况下，dspmq命令显示队列管理器已经异常终止。

应急措施:
1.停止相关MQ应用
2.确认队列管理器相关进程是否完全停止，执行以下命令：

ps -ef | grep <qmgr_name>

如系统中仍然存在相关队列管理器进程，则使用kill -9命令强制结束正在运行的任何队列管理器进程，停止顺序为：amqzmuc0 amqzxma0 amqfcxba amqfqpub amqpcsea amqzlaa0 amqzlsa0 runmqchi runmqlsr amqcrsta amqrrmfa amqrmppa amqzfuma amqzdmaa amqzmuf0 amqzmur0 amqzmgr0
3.清除MQ相关的IPC资源，命令如下：

/usr/mqm/bin/amqiclen -x -m <qmgr_name>

以mqm用户重新启动队列管理器
```
strmqm <qmgr_name>
```
5.检查队列管理器启动是否成功，检查监听是否启动以及能够进入runmqsc界面并检查通道状态：：
ps –ef |grep runmqlsr |grep
runmqsc
dis chs( )
dis lsstatus()
6.重新启动MQ相关应用，并进行应用业务验证

1.3 WMQ类场景三集群内单个队列管理器集群信息错误
场景三及描述：在集群内不同的队列管理器上，通过runmqsc的命令dis qc()或者dis clusqmgr()显示的信息不一致，并且导致了类似以下日志报错：
AMQ4584 Queue manager is not available for cluster connection.
或者
AMQ9544 Messages not put to destination queue.

应急措施:
1.针对报错的队列管理器，首先确认其集群信息确实存在错误，方法是与其他完全仓储队列管理器比较集群信息，命令如下：

runmqsc <qmgr_name>
dis qc(*)
dis clusqmgr(*)

需要比较QMID、QMTYPE、CONNAME、CLUSQMGR这四个参数
2.确认有消息不一致的问题后，通过refresh cluster命令刷新本地队列管理器的集群信息，命令如下：

runmqsc <qmgr_name>
refresh cluster(*)

3.刷新本地集群信息后，检查新的信息已经一致：

runmqsc <qmgr_name>
dis qc(*)
dis clusqmgr(*)

4.通过应用的业务数据验证问题已经解决，错误信息不再出现

1.4 WMQ类场景四队列管理器启动失败并且报错日志损坏或不可用
场景四及描述：重启MQ队列管理器后，错误日志报数据日志损坏或不可用，并且队列管理器启动失败。错误日志：
AMQ7017 queue manager log not available or corrupted

应急措施方法一(没有备用节点，仅使用本节点):
到/var/mqm/qmgrs，备份队列管理器配置，将目录改名：

mv <qmgr_name> <qmgr_name>.OLD

删除队列管理器，命令如下：

dltmqm <qmgr_name>

确认/var/mqm/log目录下没有命名的目录，如果还有，删除该目录：

rm -rf <qmgr_name>

再次创建队列管理，命令如下：
crtmqm -lf 16384 -lp5 -ls4
16384表示每个数据日志大小为16384*4KB=65536KB=64MB
-lp5表示主数据日志为5个
-ls4表示辅数据日志为4个
将新的amqalchk.fil拷贝到备份的队列管理器目录：

cd /var/mqm/qmgrs
cp <qmgr_name>/amqalchk.fil <qmgr_name>.OLD/

删除新的队列管理器配置目录，并用旧的目录替换：

cd /var/mqm/qmgrs
rm -rf <qmgr_name>
mv <qmgr_name>.OLD <qmgr_name>

启动队列管理器，命令如下：

strmqm <qmgr_name>

重新启动MQ相关应用，并进行应用业务验证

https://www.cndba.cn/hbhe0316/article/4827

应急措施方法二(有备用节点，且备有节点没有同名队列管理器):
在本节点，到/var/mqm/log目录，备份队列管理器数据日志，将目录改名：

mv <qmgr_name> <qmgr_name>.OLD

在备用节点，创建同名队列管理器，注意保证数据日志的大小、个数一致，创建队列管理器的命令如下：

crtmqm -lf 16384 -lp5 -ls4 <qmgr_name>

16384表示每个数据日志大小为16384*4KB=65536KB=64MB
-lp5表示主数据日志为5个
-ls4表示辅数据日志为4个
拷贝备用机的新建的同名队列管理器的amqalchk.fil文件到原节点，amqalchk.fil文件所在目录为：

https://www.cndba.cn/hbhe0316/article/4827

/var/mqm/qmgrs/<qmgr_name>/amqalchk.fil

拷贝备用机的新建的同名队列管理器的数据日志到原节点，需要拷贝的整个文件夹，文件夹为：https://www.cndba.cn/hbhe0316/article/4827

/var/mqm/log/<qmgr_name>

启动队列管理器，命令如下：

strmqm <qmgr_name>

重新启动MQ相关应用，并进行应用业务验证

https://www.cndba.cn/hbhe0316/article/4827

1.5 WMQ类场景五通道状态not running
场景五及描述：监控报警WMQ通道状态not running，并且通过runmqsc命令dis chs( )显示STATUS为非running状态。

应急措施:
确认通道类型，命令如下：

runmqsc <qmgr_name>
dis chl(<chl_name>) chltype

如果是发送通道，需要针对不同的通道状态进行分别处理：
Retrying状态
首先检查两端队列管理器错误日志/var/mqm/qmgrs/< >/errors/AMQERR01.LOG
排除两端通道名称不一致、传输队列配置不正确、接收通道被手动停止、通道消息序列号不一致(详见场景八)的情况，MQ要求发送方的发送通道名与接收方的接收通道名一致；发送通道必须设置有传输队列(usage属性为xmitq的本地队列)，并且传输队列已经定义；接收通道的状态为stopped状态时，会拒绝发送通道的连接；如果两端通道消息序列号不一致，当有消息传递时，通道会被断开；
排除这些错误后，重新启动通道并检查通道状态，进入对应状态场景进一步处理；
Bingding状态
该状态表示MQ尝试向目标IP和端口发起连接，但是暂时没有响应，通过ping命令确认IP可连接，通过telnet命令确认IP和端口可连接，如果不能连接，需要检查对端的侦听是否正常，排除侦听后，检查网络状况，排除网络问题；
Stopped状态
手动启动通道，命令如下：

Start chl(<chl_name>)

运行启动命令后，查看通道状态，如果进入running状态表示进入正常状态，如果非running，进入以上两个步骤进行处理；
如果是接收通道，确认本地监听状态：

runmqsc <qmgr_name>
dis lsstatus(*)

如果侦听正常，需要检查发送方队列管理器问题
4，如果是服务器通道，确认本地监听状态：

runmqsc <qmgr_name>
dis lsstatus(*)

如果侦听正常，需要客户端应用程序问题

1.6 WMQ类场景六传输队列队列深度持续增长
场景六及描述：传输队列队列深度持续增长，用runmqsc命令dis ql( )显示usage属性为xmitq，并且dis qs( )显示curdepth持续增长。

应急措施:

检查双方通道是否正常连接，先查出发送通道，然后查看通道状态：
```
runmqsc <qmgr_name>
dis chl(*) where(xmitq eq <q_name>)
dis chs(chl_name)
```
查看通道状态是否为RUNNING，如果非running，检查通道异常原因，并进入通道异常场景处理
查看队列管理器错误日志，查找此通道相关信息，看是否经常断开连接，并使用ping命令跟踪网络通讯中是否存在丢包现象，如果丢包现象比较严重说明双方网络存在问题，MQ消息不能完成正常提交，需要先解决网络问题
以上步骤不能解决的情况下，检查队列commit状态，命令如下：
```
runmqsc <qmgr_name>
display qs(<q_name>) uncom
```
如果显示UNCOM(YES)状态，说明队列有不确定消息存在，使用以下命令回退：
```
runmqsc <qmgr_name>
resolve channel(Channel_name) action(backout)
```
观察队列深度，确保队列深度持续下降直至全部传输完成

1.7 WMQ类场景七本地队列队列深度持续增长
场景七及描述：本地队列队列深度持续增长，用runmqsc命令dis ql( )显示usage属性为normal，并且dis qs( )显示curdepth持续增长。

应急措施:

先排除本地IO问题导致，MQ操作会记录到数据日志中，特别是持久消息都会写到本地磁盘文件中，如果消息量比较大，同时系统IO出现堵塞，会导致消息堆积发生，检查IO使用状态：
iostat 5 5
如果确认IO异常繁忙，可修改MQ log的默认写方式，默认情况下，qm.ini文件中的log段的LogWriteIntegrity参数：
LogWriteIntegrity=TripleWrite
这种默认方法能在硬件不保证写完整性的条件下，确保日志的写完整性，但IO操作多，效率低。为改善IO性能，可修改
LogWriteIntegrity= SingleWrite
修改后需要重启队列管理器使修改生效，检查IO性能应该得到改善
如IO不存在异常繁忙情况下，消息数持续上升，需要检查读取消息的应用程序是否正常：
```
runmqsc <qmgr_name>
dis qs(<q_name>) type(handle)
```
从输出结果中找到应用进程PID，检查连接MQ的应用程序的数量和名称是否正确，如果不正确，联系应用维护团队启动对应应用，并观察队列深度是否下降
如果应用程序的数量和名称都正确，需要联系应用维护团队检查应用日志，分析不能正常读取MQ消息的原因，常见有两种情况，一种是应用程序效率问题，导致处理速度慢于MQ消息到达速度，这种情况下只能等待应用自动完成；另一种情况是，有一笔消息由于应用某种原因，应用程序无法处理，导致阻塞了后续消息的处理，这种情况下配合应用维护团队处理问题消息即可
在应用维护团队确认恢复后，观察队列深度，确保队列深度持续下降直至全部处理完成

1.8 WMQ类场景八通道序列号不一致导致通道停止
场景八及描述：通道频繁自动重启，监控报警通道状态not running，错误日志显示类似以下内容：
————————————————————————————-AMQ9526: 通道 ‘ ‘ 的消息序号出错。说明：本地和远程队列管理器对下一个消息序号不一致。当希望消息序号 1 时，发送了序号为 6 的消息。操作：确定该不一致的原因。有可能同步信息已损坏, 或已被逆序恢复成先前的版本。如果问题不能解决, 可用 RESET CHANNEL 命令在通道的发送端人工复位此序号。 https://www.cndba.cn/hbhe0316/article/4827

应急措施:

确认通道类型，命令如下：

runmqsc <QMNAME>
dis chl (<CHLNAME> chltype

如果chltype显示通道类型是SDR，即发送通道，则执行命令重置发送和接收双方的通道序列号：
```
runmqsc <QMNAME>
stop chl<CHLNAME>
reset chl<CHLNAME>
start chl<CHLNAME>
```
如果通道类型是RCVR，即接收通道，则执行命令将本地消息号重置为对方希望的序列号：
```
runmqsc <QMNAME>
stop chl<CHLNAME>
reset chl <CHLNAME> SEQNUM(<对端序列号>)
start chl<CHLNAME>
```
以场景描述的消息为例，<对端序列号>为6
消息序列号重置后，需重启通道，并在重启后第一条消息经过时生效

1.9 WMQ类场景九通道连接数达到最大值
场景九及描述：监控报警通道异常终止，同时错误日志显示类似以下信息：
AMQ9513 Maximum number of channels reached

应急措施：https://www.cndba.cn/hbhe0316/article/4827

统计当前队列管理器中活动通道数：
```
echo “dis chs(*)”|runmqsc <qmgr_name>|grep CHANNEL|wc –l
```
通过多次执行上述命令，统计出当前活动连接数
确认队列管理器当前配置的最大通道数及最大活动通道数，检查配置文件/var/mqm/qmgrs/ /qm.ini，有类似以下信息：
CHANNELS:MaxChannels=3000 (参数标准值)MaxActiveChannels=3000 (参数标准值)
缺省值是100，如果当前通道连接数持续达到最大值，且没有下降，需要调整队列管理器最大通道数的设置，并重启队列管理器使新设置值生效
如果调整了MaxActiveChannels值，需要同时调整侦听的backlog值，命令如下：
```
runmqsc <qmgr_name>
alter listener(<lsn_name>) backlog(<最大通道数>)
```
<最大通道数>与第2步MaxChannels/MaxActiveChannels值大小一样
重启队列管理器后，继续观察当前活动连接数，检查是否达到预期

1.10 WMQ类场景十队列深度达到最大值
场景十及描述：监控报警队列堆积，同时错误日志显示类似以下信息：
AMQ4042 Queue full. The queue contains the maximum number of messages.

应急措施:
确认当前队列深度和队列最大深度：

runmqsc <qmgr_name>
dis ql(<q_name>) curdepth maxdepth

如果curdepth已经达到maxdepth，一方面按照场景六、七处理，另一方面需要考虑是否需要增加队列最大深度
增加队列最大深度前，确认对列是否默认为持久消息，命令如下：

runmqsc <qmgr_name>
dis ql(<q_name>) defpsist maxdepth MsgLength

如果DEFPSIST为yes，需要考虑/var/mqm/qmgrs/ /的磁盘空间是否足够，每个持久队列需要预留maxdepth * MsgLength的空间；
增加队列最大深度的命令如下：

runmqsc <qmgr_name>
alter ql(<q_name>) maxdepth(<新设置值>)

1.11 WMQ类场景十一恢复死信队列中的消息
场景十一及描述：监控报警死信队列堆积。
注：恢复死信队列中的消息有可能会对应用业务造成影响，请务必看完该章节全部内容后谨慎实施。
当持久性消息无法被放入目的队列，WMQ队列管理器会尝试将其放入死信队列。
目前为止，中行遇到的消息被放入死信队列的情况主要有以下三种：
1、外围系统目标队列配置错误，导致消息进入目标队列管理器后，由于没有定义发送方指定的队列，而被放入死信队列。代表系统CTIS，系统变更时几十家分行配置的目标队列同总行队列管理器中配置的队列名称不符。
2、目标队列满，导致消息被放入死信队列。代表系统murex。
3、目标队列损坏，导致消息被放入死信队列。代表系统，人行参与行。
消息一旦被放入死信队列，即使以上问题得到恢复，消息也不会自动被再次投递。如欲恢复死信中的消息至目的队列，一定要从系统及应用角度进行充分论证后，方可实施。针对以上三种情况逐一说明如下：
针对第一种情况，技术角度，可以在总行队列管理器中创建分行指定的目标队列，并将死信队列中的消息恢复至该队列，但是这会导致两个问题：一、各分行配置不一致；二、总行系统需要改应用配置。显然针对这种情况，不适合恢复死信队列中的消息，应由各配置错误的分行自行修改配置。
针对第二及第三种情况，需要同应用确认，应用对消息是否有实时性要求？如消息进入队列30秒未被处理，则作废。如有实时性要求，即使恢复死信中的消息至应用队列，对应用也没有意义；应用是否已经重新提交了死信队列中的业务？如果是，则恢复死信队列中的消息会造成消息重复发送。
恢复死信队列消息前，务必同应用团队进行充分确认。

应急措施:
配置规则文件
WAIT(NO)ACTION(FWD) FWDQ(&DESTQ) FWDQM(&DESTQM) HEADER(NO)
注意配置规则文件最后要有一空行。
名称无特别要求，如保存为：recover.rul。
执行runmqdlq <死信队列> <死信队列所在队列管理器> < <规则文件> 命令进行恢复。
例：

runmqdlq DLQ TESTQM <recover.rul

附：配置规则说明：
WAIT：YES DLQ 处理程序无限期地等待。NO DLQ 处理程序检测到 DLQ 是空的或不包含它能处理的消息，则 DLQ 处理程序结束。nnn DLQ 处理程序检测到队列是空的或不包含它能处理的消息后，在结束前 DLQ 处理程序等待 nnn 秒以等待新工作到达。ACTION：FWD 转发RETRY 重试DISCARD 丢弃FWDQ、FWDQM：转发目的队列及队列管理器，&DESTQ、&DESTQM变量表示使用消息自身配置的目的队列及队列管理器；也可以通过明文指定的方式个性化配置，从而将死信队列中的消息放入任意指定队列。HEADER：NO 转发的消息不带死信头

1.12 WMQ类场景十二对象文件损坏
场景十二及描述：MQ产品使用的队列、通道、侦听等对应的文件损坏，较常见的是队列对应的“q”文件损坏，对象文件损坏会导致相关对象不可用。经充分测试对象文件损坏不会影响队列管理器启动、停止。故应急方法为，删除已损坏对象，重建。
故障再现方法：
手动破坏对象文件，如队列对象对应的“q”文件。
在runmqsc交互界面中执行被损坏对象的显示命令，会报出该对象已损坏，同时错误日志显示信息如下：
AMQ7472: Object xxx, type queue damaged.
操作被损坏文件的队列，显示以下信息：
AMQ8149: WebSphere MQ object damaged.https://www.cndba.cn/hbhe0316/article/4827

应急措施:
以队列文件损坏为例，恢复方案如下：
重新启动队列管理器：
endmqm -i
strmqm
使用dis ql( )会显示：
AMQ8149: WebSphere MQ object damaged.
删除消息文件被损坏的队列：

runmqsc <qmgr_name>
delete ql(<q_name>)

根据中行标准，使用MS03工具恢复受损对象。在/install/ibm_tools/wmq/config/目录下找到受损对象对应队列管理器的备份文件，格式 .mqrc.yyyymmdd，在该文件中找出受损对象的定义信息并保存至相关文件，如/tmp/TESTQ.txt
执行以下命令进行恢复。

runmqsc <qmgr_name> < /tmp/xxx.txt

1.13 WMQ类场景十三 MQ集群的一个集群节点从MQ集群中隔离
场景十二及描述：MQ集群的一个集群节点MQ消息能正常发送到，但节点上的应用程序、CICS等异常，对发送到的消息无法正常处理，而另一个节点对消息能正常处理；或该节点需下机维护；需要将该节点将MQ从集群中隔离出来
应急措施:
UMQ_TEST_GW(MQ集群的网关)
UMQ_TEST_CL1(MQ集群的节点一)
UMQ_TEST_CL2(MQ集群的节点二)
需从MQ集群中隔离节点一的MQ队列管理器，MQ队列管理器名CLUSTEST
1、登陆故障节点MQ队列管理器，确定MQ集群名

runmqsc  UMQ_TEST_CL1
dis clusqmgr(*)

2、隔离故障节点MQ队列管理器
SUSPEND QMGR CLUSTER(CLUSTEST)
dis clusqmgr(CLUSTEST) all ##查看该故障节点MQ队列管理器在集群中Suspend状态为Yes
3、检查隔离故障节点MQ队列管理器从网关已无消息分发

runmqsc  UMQ_TEST_CL1
dis chstatus(*) MSGS

4、进行故障节点的处理、维护
5、节点恢复后，恢复隔离MQ队列管理器到MQ集群中

runmqsc  UMQ_TEST_CL1
   RESUME QMGR CLUSTER(CLUSTEST)

6、恢复后检查

dis clusqmgr(CLUSTEST) all  ##查看该故障节点MQ队列管理器在集群中Suspend状态为no
   dis chstatus(*) MSGS

1.14 WMQ类场景十四 MQ集群信息缓存损坏
场景十二及描述：MQ集群信息缓存损坏故障是由于MQ 7.0.1.10以下版本存在的一个产品bug造成的，该故障的现象多种多样，目前已知的症状如下：
MQ的存储库进程amqrrmfa异常终止，生成probe id为RM296000的FDC文件，MQ集群停止工作。
找不到目标集群队列，导致消息被放入死信队列。
应用程序无法连接到队列管理器。
在未升级前，若出现”MQ集群信息缓存损坏”的故障，需按照下面应急措施进行集群冷启动，重新构建MQ集群信息。
应急措施:
前提准备。
需要确认所有业务消息均已被处理后，停止所有与MQ关联的应用程序。
备份所有队列管理器信息

endmqm -i <qmgr_name>
 tar -cvf <备份文件名> /var/mqm/*
strmqm <qmgr_name>

停止全部集群队列管理器的集群发送/接收通道，使成员间相互隔离。停止后，需等待2~3分钟。操作如下：
查看正在运行的集群通道信息

runmqsc <QMNAME>
dis chs(*) where (chltype eq CLUSSDR)
dis chs(*) where (chltype eq CLUSRCVR)

针对查询的每一个集群通道，逐一停止

stop chl(<chl_name>)

杀掉每个队列管理器的存储库进程amqrrmfa

https://www.cndba.cn/hbhe0316/article/4827

ps -ef | grep amqrrmfa
kill -9 <id> 杀掉上述命令执行结果中的进程。

针对每个队列管理器，逐一清空以下队列中的消息

runmqsc <QMNAME>
CLEAR QL(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
CLEAR QL(SYSTEM.CLUSTER.COMMAND.QUEUE)
CLEAR QL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
CLEAR QL(SYSTEM.CLUSTER.HISTORY.QUEUE)

执行完上述信息后，通过以下命令验证上述队列当前深度是否为0。
dis ql(SYSTEM.CLUSTER.*) curdepth
停止所有队列管理器

endmqm -i<QMName>

依次启动队列管理器，先启动完全存储库队列管理器，再启动部分存储库。

strmqm <QMName>

刷新集群信息

runmqsc <QMNAME>

在主存储库执行refresh cluster() 命令刷新集群信息。
在部分存储库执行refresh cluster() repos(yes) 命令刷新集群信息。
启动所有集群成员的集群发送/接收通道https://www.cndba.cn/hbhe0316/article/4827

runmqsc <QMNAME>
dis chl(*) where (chltype eq CLUSSDR)
dis chl(*) where (chltype eq CLUSRCVR)

启动查询到的每一个集群通道

start chl(<chl_name>)

1.15 MQ产生错误时需要收集的日志

/var/mqm/qmgrs/<<qmgr_name>>/errors/AMQERR0*.LOG
/var/mqm/errors/AMQERR0*.LOG
/var/mqm/errors/*.FDC (问题发生时的FDC日志)

WMQ

WebSphere MQ应急预案

“相关推荐”对你有帮助么？