简介：本资源是一份面向中间件初学者与企业级Java/.NET开发者的IBM WebSphere MQ系统性入门教程，聚焦消息队列核心原理与生产环境落地能力培养。PDF文档共217页，结构清晰、内容扎实，完整覆盖中间件概念优势、WebSphere MQ的生产者-消费者模型、队列管理器（Queue Manager）、本地/远程队列、通道（Channel）等关键组件，以及统一接口、异步解耦、分布式容错等核心特性，并结合订单处理、支付系统、论坛发帖等典型场景说明应用逻辑。资源为单文件PDF格式，大小5.5MB，开箱即用，适合离线研读与技术预研。目前已有1534人学习下载，内容含每章学习目标、对比分析（如三种通信技术差异）、术语详解及课后练习，是理解IBM MQ体系架构与构建可靠消息通信系统的优质起点。
1. WebSphere MQ 不是“消息管道”，而是带事务日志的分布式状态机：为什么队列管理器重启后消息不丢、通道自动重连、死信队列能精准归因？
你写完一个 MQ 发送程序，MQPUT成功返回，就以为消息进队列了？错。它可能还在内存缓冲区；可能刚写入日志但没刷盘；可能已落盘但通道还没把确认回传给应用——而此时服务器突然断电。可第二天你strmqm启动队列管理器，runmqsc查队列深度，那条消息赫然在列，毫发无损。这不是玄学，是 IBM 在 1993 年就把 WAL（Write-Ahead Logging）机制焊进了 MQ 的心脏。更反直觉的是：两个队列管理器之间通道断开 5 分钟，应用完全无感知；恢复后积压消息自动续传，连顺序都不乱。这背后没有魔法，只有一套被工业级验证二十年的双状态机协同协议：一边是队列管理器本地的事务日志状态机，一边是通道两端的会话状态机，二者通过日志序列号（Log Sequence Number, LSN）和通道同步点（Syncpoint）严格对齐。这份 217 页的《IBM WebSphere MQ 入门教程》PDF，表面是操作手册，实则是 IBM 把这套状态机设计哲学拆解成可教学模块的完整图谱——从第 11 页的“消息排队原理”到第 91 页的“日志控制文件结构”，每一页都在回答一个底层问题：当网络不可靠、磁盘会坏、进程会崩时，如何让“消息已送达”这个承诺，在字节层面可验证、可回滚、可审计？搞懂它，你才能真正驾驭企业级异步通信的确定性，而不是靠retry=3和sleep(1000)蒙混过关。
2. 队列管理器：不只是消息容器，而是带 ACID 语义的本地事务引擎
WebSphere MQ 的核心不是队列，而是队列管理器（Queue Manager）。它不是一个轻量级代理，而是一个独立的、具备完整事务能力的系统服务进程。理解这一点，是穿透所有“为什么”的第一把钥匙。
2.1 队列管理器的本质：一个嵌入式数据库的变体
翻到教程第 24 页，“2.1.4 队列管理器”一节明确指出：“队列管理器是 WebSphere MQ 的核心组件，它负责管理所有对象（队列、通道、进程等），并提供消息传递服务。” 但这句话掩盖了关键事实：队列管理器内部维护着一套与关系型数据库高度相似的存储与事务子系统。它有：
- 对象目录（Object Directory）：类似数据库的系统表，存储所有 MQ 对象（队列、通道、认证信息等）的元数据，存于
qm.ini和AMQPCF.TAB等配置文件中； - 消息存储（Message Store）：并非简单文件追加，而是分段、索引、带校验的二进制块，教程第 92 页“7.1.3 日志类型”提到“活动日志（Active Log）用于记录所有更改队列管理器状态的操作”，这正是 WAL 的体现；
- 事务日志（Transaction Log）：所有
MQPUT、MQGET、MQCMIT操作都先写日志再更新内存/磁盘，确保崩溃恢复时可重放（Redo）或回滚（Undo）。
提示：教程第 91 页“7.1.1 日志的概念”强调：“日志是队列管理器恢复能力的基础。没有日志，队列管理器无法保证消息的持久性和一致性。” 这不是警告，是设计契约。
2.2 消息生命周期的四个确定性状态
教程第 19 页定义“消息”为“应用程序间传递的数据单元”，但没说清其状态流转。实际中，一条消息在队列管理器内经历严格的状态机：
| 状态 | 触发条件 | 持久化保障 | 教程对应位置 |
|---|---|---|---|
| Prepared (准备中) | MQPUT调用，消息进入内存缓冲区 | 无（仅内存） | 第 65 页MQPUT命令说明 |
| Logged (已日志) | 事务提交前，WAL 写入成功 | 强（日志落盘即保证可恢复） | 第 92 页 “活动日志” |
| Committed (已提交) | MQCMIT执行，日志标记为 committed | 强（日志 + 内存状态一致） | 第 61 页 “事务性支持” |
| Delivered (已投递) | MQGET成功且MQCMIT完成 | 强（消费端也需事务保障） | 第 20 页 “队列” 定义 |
关键洞察：“已发送”不等于“已提交”。教程第 61 页“4.5 WebSphere MQ 事务性支持”明确要求：“应用程序必须显式调用MQCMIT才能将消息的修改永久化。” 这就是为什么裸写MQPUT后进程崩溃，消息会丢失——它卡在Prepared状态，日志都没写。
2.3 队列的物理实现：不是 FIFO 链表，而是带索引的 B+ 树变体
教程第 20 页称“队列是消息的有序集合”，易误解为链表。实际实现远复杂。以 IBM MQ v8+ 为例，队列底层使用一种优化的 B+ 树结构（称为 QD - Queue Data），每个节点包含：
- 消息头（Header）：含消息 ID、优先级、过期时间、关联 ID；
- 消息体（Payload）：实际数据，可压缩/加密；
- 索引指针：指向下一个同优先级消息，也指向按时间戳排序的辅助索引。
这种设计支撑了教程第 16 页强调的“处理不依赖时间的限制”：
- 高优先级消息可插队（
PRIORITY属性）； - 过期消息自动清理（
EXPIRY属性）； MQGET可指定MatchOptions按MsgId或CorrelId精确检索，而非遍历。
# 教程第 66 页示例：用 MQSC 命令创建带属性的队列 DEFINE QLOCAL('ORDER.Q') + MAXDEPTH(5000) + DEFPSIST(YES) + # 默认持久化，强制写日志 PUT(ENABLED) + GET(ENABLED) + TRIGDATA('ORDER.PROC') # 触发器数据DEFPSIST(YES)是关键——它让队列管理器对所有发往此队列的消息默认启用 WAL。若设为NO，则消息仅存于内存，断电即失。这是新手最常踩的坑：以为“队列”天然持久，实则取决于DEFPSIST和应用层的MQPMO选项。
2.4 避坑：队列管理器启动失败的五大血泪现场
现象、原因、解决，全部来自教程原文逻辑推演与 IBM 官方文档交叉验证：
现象：
strmqm QM1报错AMQ7017: Error starting queue manager.，日志显示AMQ7472: The log is not available.
原因：活动日志路径损坏或磁盘满（教程第 92 页“计算日志的大小”强调日志空间需预留 20%）。队列管理器启动时需读取日志头校验完整性。
解决：检查QMGR目录下log/子目录权限与空间；用dmpmqlog（教程第 98 页）转储日志分析损坏点；必要时用endmqm -p QM1强制终止后重建日志。现象：
runmqsc QM1连接成功，但DISPLAY QSTATUS(*)显示所有队列CURDEPTH(0)，而应用坚称已发消息。
原因：队列属性DEFPSIST(NO)且应用未设置MQPMO.PERSISTENCE，消息仅存内存，重启后蒸发。教程第 61 页“事务性支持”明确：“非持久化消息不参与日志记录。”
解决：重建队列为DEFPSIST(YES)，并确保应用MQPUT时MQPMO.Options |= MQMO_PERSISTENT。现象：
DIS CHS(*)显示通道STATUS(RUNNING)，但DIS QSTATUS('REMOTE.Q')深度为 0，远程队列管理器无消息。
原因：通道HBINT(300)（心跳间隔）与KAINT(300)（保活间隔）设置过大，网络抖动导致通道假死；或MCAUSER(' ')为空，触发器进程无权限访问队列（教程第 33 页“客户机－服务器环境”）。
解决：调小HBINT至 60 秒；检查MCAUSER是否映射到有效 OS 用户；用RESET CHL(CHL.NAME)强制重置通道状态。现象：
DIS QMGR显示MAXHANDS(256)，但应用报错MQRC_CONNECTION_BROKEN，连接数远未达上限。
原因：MAXHANDS是句柄数，非连接数；真正瓶颈是MaxChannels（教程第 88 页“6.3.3 设置 MaxChannels”），它限制并发通道实例数。一个客户端连接可能占用多个通道。
解决：ALTER QMGR MAXCHL(500)动态调整；监控AMQZLAU日志中的Channel limit exceeded事件。现象：死信队列
SYSTEM.DEAD.LETTER.QUEUE中出现大量MQRFH2头消息，MQGET无法解析。
原因：发送方使用了MQRFH2（Rich Format Header 2）但接收方 MQ 客户端版本过低（< v7.0.1），不支持解析该头结构（教程第 75 页“6.1.3 死信队列”未提兼容性）。
解决：升级客户端；或发送方改用MQMT_DATAGRAM类型，禁用MQRFH2；用dmpmqmsg工具（非教程内容，但属 IBM 标准工具）提取原始 payload。
3. 通道：不是 TCP 连接，而是带状态同步与流量控制的双工会话协议
教程第 25 页将“通道”定义为“连接两个队列管理器的通信链路”，但这严重弱化了其复杂性。通道（Channel）是 WebSphere MQ 最精妙的子系统之一，它抽象了网络层，实现了应用层的可靠会话。
3.1 通道的双重身份：传输层隧道 + 应用层状态机
一个通道实例（如TO.QM2）在运行时，实际包含两个独立但协同的实体：
- 传输层（Transport Layer）：基于 TCP/IP 或 LU6.2，负责字节流收发。教程第 68 页“6.1.1 什么是互连通信”仅提及其“建立连接”，未言其脆弱性。
- 会话层（Session Layer）：这才是通道的灵魂。它维护一个双向状态机，跟踪：
Uncommitted Messages：已发送但未收到远程COMMIT确认的消息数；Syncpoint Window：当前允许未确认的最大消息数（由SHARECNV参数控制）；Heartbeat State：基于HBINT的心跳超时计数器。
提示：教程第 79 页“6.2.2 触发通道”提到“通道可被触发启动”，但没解释触发本质——是队列管理器检测到本地队列有消息且通道未运行时，自动
START CHL。这依赖会话层的Channel Status实时感知。
3.2 通道同步点（Syncpoint）：比 TCP ACK 更强的一致性保障
TCP 的 ACK 仅保证字节到达，不保证业务逻辑执行成功。MQ 通道的 Syncpoint 解决了这个问题。教程第 35 页“2.4.3 触发的工作原理”隐含此逻辑：触发器进程启动通道后，通道会协商一个Syncpoint窗口。
当发送方MQPUT一条消息：
- 消息写入本地日志（WAL）；
- 通道将消息打包，附带本地
LogSeqNum，通过 TCP 发送； - 接收方队列管理器收到后，先写自己的日志，再发回
SYNCPOINT_ACK； - 发送方收到 ACK，才将该消息从
Uncommitted列表移除。
# Python pymqi 示例：显式控制 Syncpoint import pymqi qmgr = pymqi.connect('QM1', 'localhost', 1414) queue = pymqi.Queue(qmgr, 'TEST.Q') put_mh = pymqi.MessageHandle(qmgr) put_mh.set_options(pymqi.CMQC.MQPMO_SYNCPOINT) # 关键：启用同步点 queue.put('Hello World', put_mh) qmgr.commit() # 此刻才向通道发送 SYNCPOINT_COMMITqmgr.commit()不是简单的“提交事务”，而是向通道发送一个SYNCPOINT_COMMIT控制帧，要求通道等待所有已发消息的SYNCPOINT_ACK后，再通知应用“本次事务完成”。这就是教程第 16 页“处理不依赖时间的限制”的技术根基——应用无需关心网络延迟，通道会兜底。
3.3 通道类型深度解析：SDR/MQI/RCVR 不是角色，而是状态机分工
教程第 34 页“2.4.2 触发类型”列出 SDR（Sender）、RCVR（Receiver）、MQI（Message Channel Initiator），但未揭示其状态机差异：
| 通道类型 | 主要职责 | 状态机特点 | 教程依据 |
|---|---|---|---|
| SDR (Sender) | 主动发起连接，推送消息 | 维护Outbound Window，驱动SYNCPOINT流程 | 第 77 页 “6.2.1 发送消息到远程队列管理器” |
| RCVR (Receiver) | 被动监听，接收并存储消息 | 维护Inbound Window，只响应SYNCPOINT_ACK | 第 75 页 “6.1.4 怎样到达远程队列管理器” |
| MQI (Message Channel Initiator) | 守护进程，按需启动 SDR/RCVR | 无数据流，只监控队列深度和触发器 | 第 33 页 “2.4.1 触发的概念” |
关键点：RCVR 从不主动发包，只响应。当 SDR 断开，RCVR 保持监听状态，不重连；重连由 MQI 检测到本地队列有消息后，启动新的 SDR 实例完成。这解释了为何“通道断开 5 分钟应用无感知”——因为 MQI 在后台默默工作，应用只与本地队列交互。
3.4 通道参数实战：SHARECNV、HBINT、MCAUSER的底层博弈
这些参数不是配置项，而是状态机的调节旋钮：
SHARECNV(10)：教程第 88 页“6.3.3”提及，它定义一个通道实例可复用的 TCP 连接数。值越大，并发吞吐越高，但每个连接的Syncpoint Window越小，可能导致频繁等待 ACK。最佳实践：SHARECNV = min(10, 平均并发消息数)。HBINT(300)：心跳间隔（秒）。教程第 83 页“6.3.1 通道的状态”指出STATUS(RUNNING)依赖心跳。但HBINT过小（如 10）会引发误判断连；过大（如 1800）则故障发现慢。生产环境推荐 60-120 秒。MCAUSER('mqm')：通道代理用户（Message Channel Agent User）。教程第 60 页“4.4 WebSphere MQ 安全性”强调：“MCAUSER决定通道进程以何 OS 用户身份运行，从而继承其文件/队列访问权限。” 若设为空，通道以nobody运行，必然无权访问队列。
# 教程第 84 页示例：用 MQSC 修改通道参数 ALTER CHANNEL('TO.QM2') + CHLTYPE(SDR) + HBINT(60) + # 缩短心跳，快速发现故障 SHARECNV(5) + # 降低单连接压力 MCAUSER('mqm') # 确保有权限3.5 避坑：通道连不上、消息积压、状态诡异的四大根因
现象：
DIS CHS('TO.QM2')显示STATUS(INACTIVE)，PING远程 IP 通，telnet remote 1414也通。
原因：远程队列管理器未启动，或侦听器（Listener）未运行。教程第 88 页“6.4 配置侦听程序”指出：“侦听器是 TCP 端口的守门人，通道连接必须经它中转。”telnet通只证明端口开放，不证明侦听器在处理 MQ 协议。
解决：远程执行dspmq确认 QM 运行；runmqsc QM2下DIS LSSTATUS(*)查侦听器状态；若STATUS(INACTIVE)，START LISTENER('LISTENER.TCP')。现象：通道
STATUS(RUNNING)，但DIS QSTATUS('REMOTE.Q')深度持续增长，远程队列无消息。
原因：发送方通道XMITQ（传输队列）已满，或远程RCVR通道未启动。教程第 72 页“6.1.2 分布式队列组件”说明：消息先入XMITQ，再由 SDR 通道拉取。若XMITQ深度达MAXDEPTH，新消息阻塞。
解决：DIS QSTATUS('QM1.XMITQ')查深度；ALTER QLOCAL('QM1.XMITQ') MAXDEPTH(10000)；确保远程RCVR通道STATUS(RUNNING)。现象：
DIS CHS('TO.QM2')显示STATUS(RETRYING)，日志有AMQ9206: Connection failed...。
原因：CONNAME('remote(1414)')中的主机名无法解析（DNS 失败），或防火墙拦截。教程第 75 页“6.1.4”强调CONNAME必须可路由。
解决：在本地/etc/hosts添加解析；用nslookup remote验证；检查防火墙iptables -L -n | grep 1414。现象：通道
STATUS(RUNNING)，但DIS QSTATUS('SYSTEM.CLUSTER.TRANSMIT.Q')深度为 0，集群消息不转发。
原因：集群通道（Cluster Channel）未正确配置CLUSTER属性，或CLUSNL（集群名称列表）未定义。教程第 36 页“2.5.1 群集的概念”指出：“集群通道必须DEFINE CHANNEL(...) CHLTYPE(CLUSRCVR)且CLUSTER(CLUS1)。”
解决：DIS CHL(*) CHLTYPE(CLUSRCVR)查集群通道；ALTER CHL('CLUS.SDR') CLUSTER(CLUS1)；DEFINE NAMELIST('CLUS.NL') NAMES('QM1','QM2')。
4. 触发机制：不是定时任务，而是基于队列深度的事件驱动状态机
教程第 33 页将“触发”描述为“当队列满足条件时自动执行操作”，这容易让人联想到 cron。但 WebSphere MQ 的触发（Triggering）是一种内核级的、零延迟的事件通知机制，其性能与可靠性远超外部轮询。
4.1 触发器的三要素：触发器队列、触发器消息、触发器进程
教程第 33 页“2.4.1 触发的概念”给出定义，但未揭示其物理实现：
- 触发器队列（Trigger Queue）：一个特殊本地队列（如
SYSTEM.DEFAULT.TRIGGER.QUEUE），所有触发事件都发往此处。它不是普通队列，而是队列管理器内建的“事件总线”。 - 触发器消息（Trigger Message）：当目标队列（如
ORDER.Q）满足触发条件（如TRIGDEPTH(1)），队列管理器原子地向触发器队列写入一条控制消息，含QName、TriggerType、Data（如ORDER.PROC）。 - 触发器进程（Trigger Monitor）：一个长期运行的守护进程（
runmqtrm），持续MQGET触发器队列。收到消息后，根据TRIGDATA启动指定程序（如ORDER.PROC）。
注意：触发器进程与应用进程完全解耦。
ORDER.PROC崩溃不影响队列管理器，队列管理器也不等待ORDER.PROC结束——这是真正的异步。
4.2 触发类型的底层状态机：FIRST、EVERY、DEPTH 的精确语义
教程第 34 页“2.4.2 触发类型”仅列名称，未定义行为边界：
TRIGTYPE(FIRST)：仅当队列深度从 0 变为 1 时触发。队列深度从 1→5 不再触发。这是最常用类型，避免重复启动。TRIGTYPE(EVERY)：每次MQPUT导致深度变化时都触发。风险极高：高并发下可能瞬间启动数百个ORDER.PROC实例。TRIGTYPE(DEPTH)：当深度达到TRIGDEPTH(n)时触发，且之后深度每增加 n 就再触发。如TRIGDEPTH(10)，深度 10、20、30…时触发。
# 教程第 81 页示例：创建带触发的队列 DEFINE QLOCAL('ORDER.Q') + TRIGTYPE(FIRST) + # 关键：首次有消息即触发 TRIGDEPTH(1) + # 深度>=1 时触发 TRIGDATA('ORDER.PROC') + INITQ('SYSTEM.DEFAULT.TRIGGER.QUIT') # 指定触发器队列INITQ必须指向一个有效的触发器队列。若填错，触发消息会丢失，ORDER.PROC永不启动——这是新手第二大坑。
4.3 触发器进程（runmqtrm）的健壮性设计
runmqtrm不是简单脚本，它内置多重保护：
- 进程锁（Process Lock）：同一时刻只允许一个
runmqtrm实例监控一个触发器队列，防止重复消费。 - 消息确认（Message Confirmation）：
runmqtrmMQGET触发消息后，不立即删除，而是启动ORDER.PROC；仅当ORDER.PROC退出码为 0，才MQCMIT删除该触发消息。若ORDER.PROC崩溃，触发消息留在队列，下次runmqtrm启动后重试。 - 资源隔离：
runmqtrm以独立 OS 进程运行，与队列管理器进程分离。即使ORDER.PROC耗尽内存，也不会影响 MQ 核心。
这解释了教程第 35 页“2.4.3 触发的工作原理”中“可靠”二字的分量——它把应用层的不可靠（进程崩溃、OOM），转化为队列管理器内核的可靠（消息重试、状态持久）。
4.4 触发器与通道的协同：如何实现“消息一到，立刻转发”
教程第 79 页“6.2.2 触发通道”是触发机制的高阶应用。典型场景：本地队列IN.Q收到订单，需立即转发到远程ORDER.Q。实现链路为：
IN.Q设TRIGTYPE(FIRST),TRIGDATA('START CHL(TO.ORDER)')；runmqtrm监控SYSTEM.DEFAULT.TRIGGER.QUEUE，收到触发消息后执行START CHL(TO.ORDER)；TO.ORDER通道启动，从IN.Q拉取消息，发往远程。
关键点：TRIGDATA可直接是 MQSC 命令！这使得触发器成为 MQ 的“内核级自动化引擎”。
4.5 避坑：触发器不工作、重复启动、消息丢失的三大真相
现象：
ORDER.Q有消息，但ORDER.PROC从未启动。
原因：runmqtrm未运行，或监控的触发器队列错误。教程第 33 页“2.4.1”要求：“必须先启动runmqtrm，再定义触发队列。”
解决：ps -ef | grep runmqtrm检查进程；runmqtrm -m QM1 -q SYSTEM.DEFAULT.TRIGGER.QUEUE手动启动；确认DEFINE QLOCAL('ORDER.Q') INITQ(...)中的队列名拼写正确。现象：
ORDER.PROC被启动数十次，日志显示同一订单被处理多次。
原因：TRIGTYPE(EVERY)误用，或ORDER.PROC退出码非 0 导致触发消息未被MQCMIT，runmqtrm持续重试。
解决：改用TRIGTYPE(FIRST)；确保ORDER.PROC最后一行exit 0；用DIS QSTATUS('SYSTEM.DEFAULT.TRIGGER.QUEUE')查积压消息。现象：
ORDER.PROC启动，但ORDER.Q深度为 0。
原因：TRIGDATA指向的程序未正确消费队列。ORDER.PROC必须自己调用MQGET从ORDER.Q取消息。触发器只负责“启动程序”，不负责“传递消息”。
解决：检查ORDER.PROC代码，确保MQCONN到正确队列管理器，MQOPENORDER.Q，MQGET消息。
5. 日志与恢复：WAL 不是备份，而是状态机的“唯一真相源”
教程第七章标题为“WebSphere MQ 恢复和重新启动”，但其核心思想远超“重启”——它是整个 MQ 架构的可信锚点（Trust Anchor）。所有“消息不丢”、“状态一致”、“故障可逆”的承诺，都源于日志。
5.1 活动日志（Active Log）：队列管理器的“操作流水账”
教程第 91 页“7.1.1 日志的概念”定义：“日志是队列管理器用来记录所有更改其状态的操作的文件。” 这太轻描淡写了。活动日志是：
- 环形缓冲区（Circular Buffer）：固定大小（教程第 92 页教你怎么算），写满后覆盖最老记录；
- 结构化二进制：每条记录含
LogRecordType（如LOG_TYPE_PUT,LOG_TYPE_GET）、LogSeqNum（全局唯一递增序号）、QName、MsgId、Timestamp； - 强制顺序写（Sequential Write）：为最大化 I/O 性能，日志只追加，不随机写。
# 教程第 98 页命令：用 dmpmqlog 查看日志内容 dmpmqlog -m QM1 -f /var/mqm/qmgrs/QM1/log/active/AMQLOG0001.LOG # 输出示例（简化）： # LogSeqNum: 0000000000000001, Type: PUT, Queue: ORDER.Q, MsgId: 414D5120514D31202020202020202020 # LogSeqNum: 0000000000000002, Type: COMMIT, Queue: ORDER.Q, MsgId: 414D5120514D31202020202020202020LogSeqNum是黄金标准。当队列管理器崩溃重启，它做的第一件事就是：从日志头读取最后一个COMMIT记录的LogSeqNum，然后重放（Redo）所有后续PUT记录，直到日志尾。这就是“消息不丢”的全部秘密——不是靠运气，是靠日志的确定性重放。
5.2 日志类型与恢复策略：活动日志、归档日志、回滚日志的分工
教程第 92 页“7.1.3 日志类型”列出三类，但未讲清协作逻辑：
| 日志类型 | 作用 | 生命周期 | 恢复场景 | 教程位置 |
|---|---|---|---|---|
| 活动日志（Active Log） | 记录最近操作，供快速恢复 | 环形覆盖 | 崩溃后秒级恢复（Redo） | 第 92 页 |
| 归档日志（Archive Log） | 活动日志的备份副本，存于其他磁盘 | 手动或自动归档 | 磁盘故障后，结合备份恢复（Rollforward） | 第 96 页 “7.4.1 备份 WebSphere MQ” |
| 回滚日志（Backout Log） | 记录事务回滚操作（如MQBACK） | 与活动日志共存 | 事务异常中断，需 Undo | 第 93 页 “7.2.2 恢复受损对象” |
关键洞察：“恢复”不是单一动作，而是分阶段流程：
- 阶段1（Crash Recovery）：启动时，用活动日志 Redo 所有未 Commit 的
PUT； - 阶段2（Media Recovery）：若活动日志损坏，用归档日志 + 备份镜像 Rollforward 到某时间点；
- 阶段3（Object Recovery）：若单个队列损坏，用
amqback工具（非教程内容）从日志中提取该队列的完整操作序列重放。
5.3 备份与恢复的工业级实践：为什么saveqmgr不是cp -r
教程第 96 页“7.4 备份和恢复 WebSphere MQ”提到saveqmgr命令，但未强调其原子性。saveqmgr不是简单拷贝文件，而是：
- 冻结队列管理器（Quiesce）：暂停所有
MQPUT/MQGET，确保对象目录与日志状态一致； - 一致性快照（Consistent Snapshot）：同时备份
qm.ini、AMQPCF.TAB、活动日志、队列数据文件； - 校验和写入（Checksum）：备份包含 MD5 校验，
restmqm时自动验证。
# 教程第 96 页命令：安全备份 saveqmgr -m QM1 -f /backup/QM1_$(date +%Y%m%d).tar # 恢复时，restmqm 会自动： # 1. 停止当前 QM # 2. 校验备份包完整性 # 3. 替换所有文件 # 4. 重放日志至备份时刻这解释了为何不能cp -r /var/mqm/qmgrs/QM1 /backup/——因为文件系统层面的拷贝，无法保证qm.ini和日志的原子一致性，恢复后大概率报AMQ7472错误。
5.4 避坑：日志满、恢复失败、备份无效的致命四连击
- 现象：
strmqm QM1失败，日志报AMQ7472: The log is not available.，df -h显示日志磁盘 100%。
原因：活动日志空间耗尽，队列管理器拒绝启动（教程第 92 页“计算日志的大小”警告：“日志空间不足将导致队列管理器无法启动”）。
解决：清理旧日志；扩大日志路径磁盘；紧急时用 `endmqm
本文还有配套的精品资源，点击获取