超级会员免费看
数据库复制队列异常情况监测与处理
在数据库复制过程中，可能会遇到各种异常情况，如接收队列停止、Q Apply 未运行、队列管理器未运行、接收队列或死信队列满等。本文将详细介绍这些异常情况的测试方法、现象及处理步骤。
1. 接收队列停止的情况
当接收队列停止时，我们可以通过以下步骤进行测试：
1.
确认复制是否正常工作
- 从 CLP - A 执行插入操作：
$ db2 "insert into eric.t1 values (7,7,'H')"
- 从 CLP - B 执行查询操作：
$ db2 "select * from fred.t1"
若能看到一条记录，则说明单向 Q 复制设置正常工作。
-
检查接收队列状态
从 CLP - B 执行以下命令：
$ db2 "SELECT recvq, state FROM asn.ibmqrep_recvqueues WHERE recvq = 'CAPA.TO.APPB.RECVQ' "
- 停止接收队列
$ asnqacmd APPLY_SERVER=db2b STOPQ='CAPA.TO.APPB.RECVQ'
再次使用上述命令检查状态。
4.
插入新行
$ db2 "insert into eric.t1 values (8,8,'H') "
由于接收队列已停止，此行不会被复制。
5.
重启接收队列
$ asnqacmd APPLY_SERVER=db2b STARTQ='CAPA.TO.APPB.RECVQ'
再次检查状态，并查询目标表：
$ db2 "select * from fred.t1"
此时应能看到两条记录。
2. Q Apply 未运行的情况
当 Q Apply 未运行时，Q Capture 会通过发送队列发送心跳消息。我们可以通过以下步骤进行测试：
1.
更改心跳间隔参数并重新初始化 Q Capture
将心跳间隔参数设置为 0，并重新初始化 Q Capture。
2.
停止 Q Apply
从 CLP - B 执行：
$ asnqacmd APPLY_SERVER=db2b STOP
-
插入记录
从 CLP - A 执行：
$ db2 "insert into eric.t1 values (2,2,'H') "
-
检查接收队列消息深度
从 CLP - B 执行：
$ runmqsc QMB
dis ql(CAPA.TO.APPB.RECVQ) curdepth
此时队列深度应为 1。
5.
启动 Q Apply
$ start asnqapp APPLY_SERVER=db2b
再次检查队列深度，此时应为 0。
3. Q Apply 队列管理器未运行的情况
当 Q Apply 队列管理器未运行时，我们可以通过以下步骤进行测试：
1.
停止队列管理器
从 CLP - B 执行：
$ endmqm –p QMB
-
插入记录
从 CLP - A 执行：
$ db2 "insert into eric.t1 values (3,3,'H') "
-
检查传输队列消息深度
从 CLP - A 执行：
$ runmqsc QMA
: display ql(QMB.XMITQ) curdepth
此时队列深度应为 1。
4.
启动队列管理器、监听器和 Q Apply
$ strmqm QMB
$ start asnqapp apply_server=DB2B
查询目标表，应能看到插入的记录。
4. 接收队列满的情况
当接收队列满时，我们可以通过以下步骤进行测试：
1.
更改接收队列的最大深度
从 CLP - B 执行：
$ runmqsc QMB
: alter ql(CAPA.TO.APPB.RECVQ) maxdepth(2)
: dis ql(CAPA.TO.APPB.RECVQ) curdepth,maxdepth
- 停止接收队列
$ asnqacmd apply_server=DB2B apply_schema=ASN stopq=CAPA.TO.APPB.RECVQ
-
插入多行记录
从 CLP - A 执行：
$ db2 "insert into eric.t1 values (4,4,'H')"
$ db2 "insert into eric.t1 values (5,5,'T')"
$ db2 "insert into eric.t1 values (6,6,'C')"
- 检查队列深度
$ runmqsc QMB
: dis ql(CAPA.TO.APPB.RECVQ) curdepth,maxdepth
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
此时接收队列深度达到最大值 2，死信队列深度为 1。
5.
启动接收队列
$ asnqacmd apply_server=DB2B apply_schema=ASN startq=CAPA.TO.APPB.RECVQ
再次检查队列深度，接收队列深度应为 0，死信队列深度仍为 1。
6.
插入新行
$ db2 "insert into eric.t1 values (7,7,'M')"
检查接收队列深度，应为 1。
7.
处理死信队列中的消息
$ runmqdlq DEAD.LETTER.QUEUE.QMB QMB < c:\temp\dlqrule.txt
- 检查死信队列深度
$ runmqsc QMB
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
此时死信队列深度应为 0，查询目标表应能看到所有插入的记录。
5. Q Apply 死信队列满的情况
当 Q Apply 死信队列满时，我们可以通过以下步骤进行处理：
1.
更改死信队列的最大深度
从 CLP - B 执行：
$ runmqsc QMB
: alter ql(DEAD.LETTER.QUEUE.QMB) maxdepth(1)
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
- 停止接收队列
$ asnqacmd apply_server=DB2B apply_schema=ASN stopq=CAPA.TO.APPB.RECVQ
-
插入多行记录
从 CLP - A 执行：
$ db2 "insert into eric.t1 values (8,4,'H')"
$ db2 "insert into eric.t1 values (9,4,'T')"
$ db2 "insert into eric.t1 values (10,4,'T')"
$ db2 "insert into eric.t1 values (11,4,'T')"
-
检查通道状态
从 CLP - A 和 CLP - B 分别执行：
$ runmqsc QMA
dis chstatus(QMA.TO.QMB)
$ runmqsc QMB
dis chstatus(QMB.TO.QMA)
此时通道 QMA.TO.QMB 停止。
5.
停止 Q Capture
$ asnqccmd CAPTURE_SERVER=db2a STOP
- 检查队列深度
$ runmqsc QMB
: dis ql(CAPA.TO.APPB.RECVQ) curdepth,maxdepth
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
此时接收队列和死信队列深度均达到最大值。
7.
解决通道疑问状态
$ runmqsc QMA
: resolve channel(QMA.TO.QMB) ACTION(BACKOUT)
- 检查传输队列深度
$ runmqsc QMA
: dis ql(QMB.XMITQ) curdepth,maxdepth
- 尝试启动通道
$ start runmqchl -m QMA -c QMA.TO.QMB
若失败，增加死信队列的最大深度：
$ runmqsc QMB
: alter ql(DEAD.LETTER.QUEUE.QMB) maxdepth(2)
再次尝试启动通道。
10.
启动接收队列
$ asnqacmd apply_server=DB2B apply_schema=ASN startq=CAPA.TO.APPB.RECVQ
- 处理死信队列中的消息
$ runmqdlq DEAD.LETTER.QUEUE.QMB QMB 0 < dlqrule.txt
- 检查死信队列深度和目标表
$ runmqsc QMB
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
$ db2 "select * from fred.t1"
此时死信队列深度应为 0，目标表应能看到所有插入的记录。
13.
启动 Q Capture
$ asnqcap capture_server=DB2A startmode=WARMSI
6. 未定义死信队列的情况
若未定义死信队列，这种情况与定义了死信队列且其已满的情况相同，可参考“Q Apply 死信队列满的情况”进行处理。
7. 队列监测命令总结
| 队列/通道 | 监测命令 |
|---|---|
| 发送队列 |
$ db2 "SELECT sendq, state FROM asn.ibmqrep_sendqueues"
|
| 传输队列 |
: dis ql(QMB.XMITQ) curdepth,maxdepth
|
| 通道（CLP - A） |
: dis chstatus(QMA.TO.QMB)
|
| 通道（CLP - B） |
: dis chstatus(QMA.TO.QMB)
|
| 接收队列 |
$ db2 "SELECT recvq, state FROM asn.ibmqrep_recvqueues"
|
| 死信队列 |
: dis ql(DEAD.LETTER.QUEUE.QMB) curdepth,maxdepth
|
8. 队列和通道定义
(C1) DEFINE QREMOTE(CAPA.TO.APPB.SENDQ.REMOTE) REPLACE +
PUT(ENABLED) XMITQ(QMB.XMITQ) RNAME(CAPA.TO.APPB.RECVQ) +
RQMNAME(QMB) DEFPSIST(YES)
(C2) DEFINE QLOCAL(QMB.XMITQ) REPLACE +
USAGE(XMITQ) PUT(ENABLED) GET(ENABLED) TRIGGER +
TRIGTYPE(FIRST) TRIGDATA(QMA.TO.QMB) INITQ SYSTEM.CHANNEL.INITQ)
(C3) DEFINE CHANNEL(QMA.TO.QMB) CHLTYPE(SDR) REPLACE +
TRPTYPE(TCP) DISCINT(0) XMITQ(QMB.XMITQ) +
CONNAME('127.0.0.1(1451)')
(C4) DEFINE CHANNEL(QMA.TO.QMB) CHLTYPE(RCVR) REPLACE +
TRPTYPE(TCP)
(C5) DEFINE QLOCAL(CAPA.TO.APPB.RECVQ) REPLACE +
PUT(ENABLED) GET(ENABLED) DEFSOPT(SHARED) DEFPSIST(YES)
(C6) DEFINE QLOCAL(DEAD.LETTER.QUEUE.QMB) REPLACE +
PUT(ENABLED) GET(ENABLED) SHARE DEFSOPT(SHARED) DEFPSIST(YES)
9. 异常情况消息存储位置总结
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(事件):::process --> B(消息存储队列):::process
A1(接收队列停止):::process --> B1(接收队列重启后处理):::process
A2(Q Apply未运行):::process --> B2(本地接收队列):::process
A3(Q Apply队列管理器未运行):::process --> B3(传输队列):::process
A4(接收队列满):::process --> B4(死信队列):::process
A5(Q Apply死信队列满):::process --> B5(处理后恢复复制):::process
A6(未定义死信队列):::process --> B5
通过以上详细的测试和处理步骤，我们可以更好地应对数据库复制过程中出现的各种异常情况，确保数据的正常复制和系统的稳定运行。
数据库复制队列异常情况监测与处理
10. 异常情况处理流程总结
为了更清晰地展示各种异常情况的处理流程，我们可以用以下 mermaid 流程图表示：
graph TD
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(异常情况发生):::process --> B{判断异常类型}:::process
B -->|接收队列停止| C(停止接收队列,插入记录,重启接收队列):::process
B -->|Q Apply未运行| D(停止Q Apply,插入记录,启动Q Apply):::process
B -->|Q Apply队列管理器未运行| E(停止队列管理器,插入记录,启动队列管理器和Q Apply):::process
B -->|接收队列满| F(更改最大深度,停止接收队列,插入多行,处理死信队列):::process
B -->|Q Apply死信队列满| G(更改死信队列最大深度,停止接收队列,插入多行,处理通道和队列):::process
B -->|未定义死信队列| G
C --> H(检查目标表):::process
D --> H
E --> H
F --> H
G --> H
H --> I{复制是否正常}:::process
I -->|是| J(系统恢复正常):::process
I -->|否| B
11. 异常情况处理的关键要点
在处理数据库复制队列的各种异常情况时，有一些关键要点需要注意：
-
及时监测
：定期使用监测命令检查各个队列和通道的状态，如发送队列、传输队列、接收队列、死信队列以及通道的状态，以便及时发现异常。
-
有序处理
：按照正确的步骤处理异常情况，例如在 Q Apply 死信队列满的情况下，要先停止 Q Capture，处理通道的疑问状态，再处理队列中的消息，最后启动相关服务。
-
备份和恢复
：在进行任何更改和处理之前，建议对相关数据和配置进行备份，以防处理过程中出现意外情况导致数据丢失或系统故障。
12. 常见问题解答
以下是一些关于数据库复制队列异常情况处理的常见问题解答：
| 问题 | 解答 |
| — | — |
| 接收队列停止后，插入的记录何时会被复制？ | 当接收队列重启后，之前未复制的记录会被复制到目标表。 |
| Q Apply 未运行时，消息会一直留在接收队列吗？ | 是的，消息会留在本地接收队列，直到 Q Apply 启动后进行处理。 |
| Q Apply 队列管理器未运行时，传输队列中的消息会丢失吗？ | 不会，消息会存储在传输队列中，当队列管理器和 Q Apply 启动后，消息会被处理。 |
| 接收队列满后，死信队列中的消息如何处理？ | 可以使用
runmqdlq
工具结合规则文件处理死信队列中的消息。 |
| Q Apply 死信队列满后，通道停止了怎么办？ | 先停止 Q Capture，处理通道的疑问状态，增加死信队列的最大深度，处理队列中的消息，最后启动相关服务。 |
13. 异常情况处理的最佳实践
为了更好地应对数据库复制队列的异常情况，以下是一些最佳实践：
-
定期维护
：定期检查队列和通道的状态，清理不必要的消息，确保队列的正常运行。
-
设置合理的参数
：如接收队列和死信队列的最大深度，根据实际情况进行合理设置，避免队列满的情况频繁发生。
-
自动化监测和处理
：可以编写脚本或使用监控工具对队列和通道进行自动化监测，当出现异常情况时自动触发处理流程。
14. 总结
数据库复制队列的异常情况处理是确保数据正常复制和系统稳定运行的重要环节。通过本文介绍的各种异常情况的测试方法、处理步骤、监测命令以及关键要点和最佳实践，我们可以更有效地应对各种异常情况。在实际应用中，要根据具体情况灵活运用这些方法和技巧，不断优化处理流程，提高系统的可靠性和稳定性。
希望以上内容能帮助你更好地理解和处理数据库复制队列的异常情况，确保数据的安全和系统的正常运行。
通过对这些异常情况的深入了解和有效处理，我们能够在数据库复制过程中及时发现并解决问题，保障数据的一致性和可用性，为业务的稳定运行提供坚实的基础。在实际操作中，还需要不断总结经验，结合具体的业务场景和系统环境，进一步优化处理流程和策略。
扫一扫
173万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
