|
2005 年 12 月 28 日
在IBM WebSphere Information Integrator产品系列中提供了新的数据库复制产品--Q复制，Q复制的架构提供了数据复制所需要的高性能（高事务量，低延时）。本文是作者在实施Q复制项目的经验积累，希望能够对准备实施Q复制的用户们有所帮助。
在IBM WebSphere Information Integrator产品系列中提供了新的数据库复制产品，因为其采用了MQ所以称为队列复制或Q复制，Q复制的架构提供了数据复制所需要的高性能（高事务量，低延时）。
尽管IBM有相应的红皮书对Q复制的配置和性能调优进行了阐述，但在实际的Q复制项目实施或技术支持过程中笔者积累了不少的实际经验，有些是书中未提及的，在此笔者做一个小的总结，希望能够对准备实施Q复制的用户们有所帮助，同时本文也阐述了一些Q复制的技术底层细节，能更好的帮助大家理解Q复制。另外对DBA来讲可能对MQ有些陌生，所以最后列出了一些Q复制中常见的MQ错误，希望能有所帮助。
Q复制简介
Q复制是一种高吞吐量、低延迟的复制方法，它使用WebSphere MQ的消息队列在源数据库与目标数据库之间，或者在源子系统与目标子系统之间传递事务。Q Capture程序通过读取DB2的恢复日志来获取你所指定的复制源表的变化情况；继而，Q Capture程序将事务作为消息，通过队列发送；最后，Q Apply程序从队列中读取这些消息，并将其应用于目标表。 Q复制具有以下几个优点：
- 低延迟：一旦提交了对源表进行的修改，并从日志中读取到这些修改，这些变化就立即发送出去。
- 高吞吐量：Q Capture程序始终可以跟踪在源表发生的快速变化，并且Q Apply程序使用多线程，使得它能够及时跟踪通信通道中的消息。
- 低网络流量：消息使用一种压缩格式在队列中传送，而且在发送数据的选项中允许选择传送最少量的数据。
- 异步性：消息队列使得Q Apply程序可以不连接源数据库或者源子系统就可以接收事务。如果Q Capture程序或者Q Apply程序停止，需要进行处理的消息在程序准备好之后，将仍然存在于队列中。由于消息是永久的，所以源表和目标表即使在系统或设备故障的情况下仍可以保持同步。
Q复制系统在性能方面具有很大的伸缩性，在不同的配置方案下Q复制系统的吞吐量和端到端的延迟都有很大变化。IBM的Redbook-《Integrator Tuning for Replication and Event Publishing Performance》中对Q复制系统的性能调优进行了详细的阐述，有兴趣的读者可以参阅，不过笔者在实际实施Q复制的项目中发现，还有一些因素也影响着Q复制的配置及性能调优，书中并未提及或给予详尽的讨论，在这里笔者就如下方面进行一些讨论，算是一点补充供大家参考：
- Q复制系统拓扑结构与性能。
- 索引对Q复制性能的影响
- DEFPSIST：消息的永久性
- MQ的日志配置
Q复制系统拓扑结构与性能
提高Q复制性能最显著的手段，根据我们前面提到的白皮书里所论述，是启用多实例的Q复制，尤其是在在多CPU的系统中，据官方测试数据表明，每增加一个Q Capture实例会带来50-70% 的性能提高，可见其效果还是非常明显的。但实施多实例Q复制需要遵循如下的原则：
- 单个交易所涉及的所有数据表必需只能被一个Q Capture读取数据变化，使用同一发送队列。
- 多个Q Capture程序不能使用同一个发送队列来发送消息。
- 每个接收队列只对应一个Q Apply程序。
可见启用多个实例的Q复制最重要的一个前提是需要根据你的事物交易组织你的源数据，即将源端的数据表按照交易分组，每一组数据表只能属于一个Q Capture实例，用同一个复制队列图进行复制，对应的唯一的Q Apply端接收消息并处理同一个事物交易信息。
Q复制系统的最小复制单元是单个的交易，对于单个交易的Q复制性能来讲，多实例系统对其是没有作用的，启用多实例提高的是Q复制系统处理多个交易的并行性。多实例的Q复制系统实施需要了解数据库的逻辑结构和应用的业务逻辑，这在实际实施中需要额外的计划成本。在笔者实施的一个Q复制系统中，源和目的端都只有一个数据库，系统中运行着多个业务系统，某些表在业务A中没有联系，但在业务B中却关联在某个交易中，这样按照业务交易分组就很难实现，所以经权衡决定建立单个实例的Q复制系统，并将性能调整集中在单实例的Q复制程序和MQ的配置上面。
索引与Q复制的性能
在实施Q复制系统期间，笔者发现在某一特定时间内系统端到端的延迟很高，无论怎么调整commit_interval、memory_limit等参数，系统延迟依然居高不下，查看监控表发现此时系统的单个交易达到了最大值，调研业务系统后知道此时系统运行的是一个删除数百万条记录的单个超大交易，此前在红皮书中已经提到，Q复制的相关参数调整对单个交易的复制性能是没有作用的，尽管我们可以增大内存，但是收效甚微。是不是对这样的交易我们就没有办法了呢，分析对应得数据表的结构我们发现数据表没有索引，在WII Q Rep V8.2.2（FixPack9）之前，如果一个数据表没有唯一索引那么它是无法建立Q预定进行复制的，在V8.2.3（FixPaxk10）后去掉了此限制，表有没有索引对Q复制性能的影响是怎样的呢？我们先做一个测试（这里我们暂且只考虑一般的索引，并不是每个表都会有唯一索引的）：
给定一个数据表RYAN.T1在源数据库和目的库，结构如下：
两边的表都有一万条记录并且相同，在源数据库端用DELETE命令清空数据表，用Q复制系统来复制这样一个大的交易，然后在两端的数据表SID列上加上索引，重复上述复制过程，对比两种情况下的延迟信息，测试结果如下图：
图1 索引对延迟的影响对比图
加上索引后系统端到段的延迟提高了11倍之多，其中最显著的是APPLY的延迟大大降低了，这是为什么呢？我们再作一次试验，再复制的同时截取两种情况下的MQ中的消息进行对比，下图是两种情况下的MQ消息片断：
图2 带索引的数据表在Q复制中的MQ消息
图3 没有索引的数据表在Q复制中的MQ消息
从表1的对比我们就可以得出结论，如果数据表具有索引，尽管交易是大小一样的，但在有索引的情况下，对于每一行删除的记录只需在消息中记录该行的索引信息，而对于没有索引的数据表，Q复制系统将其该行的所有记录都记录下来作为索引信息，这样单个记录的大小就增大了许多。在同样大小的消息体中，有索引的情况下每条消息包含了2339条记录信息，而没有索引的情况下只仅包含528条记录，所以前者只需5条消息就复制了整个交易，而后者需要20条之多。
在有索引的情况下，复制单个交易所需要的消息个数减小了许多，这样MQ的延迟就会降低，再Q Apply端一方面需要处理的消息减少了，同时Q Apply根据索引消息去更新目标表，速度无疑又快了很多，这也就是Apply的延迟显著降低的原因。
在一个交易吞吐量比较大的系统中，如果对Q复制系统和MQ进行调优还是无法降低延迟，这时你可以考虑是否系统中是否存在单个大尺寸的交易，并通过增加索引等相应手段降低单个大交易的复制延迟，从而在降低整体Q复制系统的延迟。
另外，调整目的数据库端和数据库性能有关的参数，提高Q Apply应用事务的效率，例如调整目的端数据库的缓冲池，Q Apply程序对目标数据库有大量的写操作，所以在目标数据库上需要建立满足性能需要的足够多，足够大的缓冲池。而且最好为Q Apply 控制表所在的表空间建立单独的缓冲池，这样无疑会收获更好的性能。
DEFPSIST（消息的永久性）
Q复制选择MQ 是因为MQ可以提供可靠性的消息传输，MQ有两种类型的消息，永久性的消息是通过MQ的日志记录在磁盘上的，而非永久性的消息是存储在内存当中的，采用非永久性的消息性能会高很多，但采用永久性的消息才会有可靠性的保证，在系统出故障或队列管理器重启后消息不会丢失，这对于数据库复制系统的数据一致性是非常重要的。
严格来讲DEFPSIST是消息的属性而不是队列的属性，不论你是否将队列设置成为永久的，只要消息类型是永久的，MQ就会将消息存储在磁盘日志文件中。Q复制系统采用的是永久类型的消息，Q复制的消息的不会因为队列管理器的重启或队列故障而丢失，这里我们可以做个试验进行验证：
1. 建立好一个Q复制系统，其使用的发送和接收队列、通道设置为非永久性的，并验证Q复制系统工作是否正常。
2. 停止Q Apply程序，然后在源数据库已经建立Q预定的数据表RYAN.T3中插入一条记录，因为Q Apply程序停止，消息将保留在接收队列中，从MQ资源管理器可以看到接收队列的深度为1，即有一条消息，如下图所示：
3. 用AMQSPUT命令在向发送队列压入一条字符串消息"ok"，这时接收队列的队列深度增加1，有两条消息，用MQ 资源管理器浏览接收队列的消息，一条是Q复制的消息，（Q复制的消息是压缩（COMPACT）的格式，其内容不可见），另一条是用MQ 命令压入得消息字符串"ok"见下图所示：
4. 重新启动接收端的队列管理器，启动后查看接收队列的深度，发现比重启前减少了1，这表明队列重启后有消息丢失，查看其内容，Q复制的消息依然存在，丢弃的是使用AMQSPUT命令压入的消息字符串"ok"，因为其并没有将消息设置成永久性的，见下图所示：
5. 再次启动Q Apply，接收队列的消息被接收处理，查看目的端的数据表RYAN.T3，尽管接收端的队列管理器被重新启动过，源端RYAN.T3表新增加的一条记录还是被正确的复制了过来，如下图所示：
通过以上测试我们即验证了消息的永久性是和队列的永久性无关的，同时也体现了MQ的可靠性传输特点，当然最好将Q复制使用的相关队列都设置成永久性的，这样队列里的消息都会记录日志，即所有的消息都是永久性的。
MQ的日志配置
上面我们提到了Q复制系统中的消息都是永久性的，所有的消息都记录日志，这样MQ的日志性能就很重要，首先在存储上考虑将队列管理器的数据和日志分开，并为其创建单独的文件系统可以提高性能，例如：
并尽可能的让上述文件系统分配在不同的磁盘上，这样可以充分利用I/O的并行性。
MQ日志的相关配置参数在红皮书中已有所讨论，这里给出更详细的优化配置参考：
- LogBufferPages：日志缓冲区的大小，增大该值可以提高性能，所以可以直接将此参数设置为其最大值512，此时Buffer大小为512个4K页，即２Ｍ。
- LogFilePages：定义了以4K页为单位的日志文件大小，为了避免额外的I/O操作分配文件可将其设为最大值16384，即单个日志文件大小为64M。
- LogPrimaryFiles和LogSecondaryFiles：类似DB2，这两个决定了日志文件的个数，一般主日志文件和第二个日志文件的数目比例为3：2，而且所有日志文件的总和不能超过63个。尽量分配较大的数值以减少分配文件的I/O开销。
- LogWriteIntegrity：MQ采用何种方式可靠的记录日志，它有三个选项：SingleWrite、DoubleWrite、TripleWrite。一般客户环境的硬件存储都能够保证写操作的可靠性，所以采用SingleWrite以提高性能。 LogType：为保证系统的可靠性IBM的红皮书上推荐使用线性日志，但需要注意以下几点：
a) 监控日志文件系统空间以免被撑满，对吞吐量较高的Q复制系统要考虑分配足够大的MQ日志文件系统。
b) 日志文件系统空间总是有限的，需要将过期的日志文件归档或删除，可以手工进行，通过查看队列管理器的日志查找过期的日志文件，也可以使用MQ提供的工具脚本自动删除，可以参见MQ SupportPacs中的ms01项目。
使用线性日志增加了日志维护的管理负担，在笔者实施的Q复制系统中，目的数据库是由源数据库备份恢复而来的，一旦系统出现故障导致同步复制中断，可以采用备份数据库恢复目的库并重新建立Q复制系统，所以MQ采用循环日志，并且主辅日志文件的个数分别设置为30、20。
Q复制中常见的MQ错误及解决措施
Q复制系统中最常见的错误一般都是由MQ引起的，以下列出一些常见的导致Q复制中断的MQ错误及解决措施，以供参考：
1． MQ ERROR 2045：Q Capture 发出 MQOPEN调用时出错，即打开队列出错。可能的原因：
- 此时请检查MQ队列管理器是否正常运行
- 检查Q复制队列图配置，是否写错了队列的名称
- 检查MQ队列配置，是否正确的配置了远程队列
2． MQ ERROR 2056：Q Capture 发出MQPUT命令调用时发现队列所在磁盘上没有空间了，一般是因为文件系统没有可用的空间导致，检查MQ相关的文件系统，如果空间满了请增大空间或删除不用的文件释放空间。
3． MQ ERROR 2053：Q Capture 发出MQPUT调用时失败，原因是队列满了，解决方法：
a) 检查队列的最大深度参数MAXDEPTH，并增大该值。
b) 如果队列深度的配置已经很大了，请查找队列堵塞得原因，一般是因为Q Apply的异常导致停止接收消息导致队列拥堵。
4． MQ ERROR 2009：与MQ队列管理器的连接丢失，队列管理器未启动或者异常停止，请检查MQ队列管理器是否正常运行。
5． MQ ERROR 2162：当进行一个MQI调用时失败了，因为队列管理器正在停止。请检查MQ队列管理器运行状态。
6． 在某些情况下重新启动了Q复制系统却发现系统不复制数据，查看日志也没有报错，这时请查看MQ系统的通道状态是否正常，一般是因为MQ通道的错误导致无法传输数据。
参考资料
作者简介
|
|
|
|
郭韫锋是 IBM 中国软件开发实验室（CSDL） WebSphere Information Integrator Solution Enablement 团队的工程师，专注于WebSphere Information Integrator产品基于Lab的技术支持和解决方案。您可以通过 guoyf@cn.ibm.com 和他联系。
|
|
|
|
|
张军宇来自IBM 中国软件开发实验室（CSDL） WebSphere Information Integrator Solution Enablement 团队。您可以通过 junyuz@cn.ibm.com 和他联系。
|
|
