Q 复制与DB2 pureScale （一）

简介

    本文将介绍DB2 pureScale 方案与Q复制方案结合，实现DB2 pureScale的高可用灾备及负载分担。在第二篇中将 介绍一个Q复制实现DB2 pureScale灾备的方案。

Q复制为DB2 pureScale环境提供的能力

Q复制是在2004年发布的，它基于数据库日志捕获和传输重现，为DB2 LUW及在z/OS上的DB2提供高性能的数据复制。Q复制可以在亚秒的时间延迟上，跨越上千公里，为上千张表复制大量的变化数据。Q复制利用WebSphere MQ为复制变化数据提供有效的传输和暂存。Q复制可以为DB2 pureScale提供的能力包括：

    保护磁盘或者站点时效 – DB2 pureScale环境提供了近乎无限的扩展能力和个别成员服务器失效时的连续可用性，但是采用的是传统的把数据库放置在RAID磁盘组上的单一数据拷贝方式。把数据库复制到远程的站点提供了从磁盘阵列时效到站点失效的额外的数据保护能力。使用Q复制，在距离上几乎没有限制，并且数据复制是近乎实时的，数据库的恢复可以是几乎即时的，其RTO在几秒钟之内。

    在升级和维护时的连续可用性 – 计划内的系统维护和升级会导致比灾难事故更多的业务中断。通过把应用转移到由Q复制同步数据的另一个站点，你可以在系统维护和升级的时候获得业务连续性。

    工作负载的卸载和实时报表 – 在DB2 pureScale实例中，分析和报表应用会与在线业务事务产生锁争用，妨碍数据库性能。通过迁移分析和报表应用到另外一个数据库，你可以在实时数据上产生报表和实现分析而不会影响关键业务应用。Q复制是异步的并且不会影响到业务响应时间。Q复制可以在两个差异很大的系统之间复制数据甚至转换数据。例如，主站点可以是一个16个MEMBER的DB2 pureScale实例，使用Q复制近实时的复制数据库的一个子集到另一个具有更少MEMBER的DB2 pureScale实例，或者一个DB2 ESE 实例（单机实例），或者甚至到一个非DB2数据库（联邦模式）。Q复制提供了复制一个数据库子集或者一个数据库事务子集的能力。

    利用延时拷贝保护数据损坏 – 对于时间点恢复，Q复制可以维护一个比主数据库落后一段时间的第二拷贝。这个第二拷贝可以应用于从主数据库的人工和应用错误的恢复。因为从数据源捕获的变化数据可以在目标端的MQ接收队列里积累，Q复制技术可以非常容易的实现数据库的延迟拷贝。在目标端的Q Apply 程序可以设置applydelay参数，并在数据源变化提交后的特定时间（秒）之后执行这些变化。变化数据也可以在applyupto参数下实现批量应用，这样Q Apply程序将应用变化数据到一个预先设定的时间点并且停止。

Q复制在DB2 pureScale环境中的特殊要求

    Q复制的在DB2 pureScale环境中与在其他DB2环境中没有主要的区别，包括产品特性、工具、管理、操作和用例几乎完全相同。Q复制在DB2 pureScale环境中的特殊要求包括：

• 理解在数据共享环境中实现数据复制时对性能的影响。

• 为复制目标提供共享磁盘。

• 选择MEMBER运行复制程序。

• 在复制程序运行的MEMBER出现失效或者停机的情况下，为其选择另外一个MEMBER，并且为其定义自动启动的资源。

Q复制配置选择-确定目的

    如果你的首要目的是实时报表，复制目标可以是DB2 ESE或者非DB2数据库。在这种情况下，目的是通过迁移源系统的一些应用来消除源系统中的争用。例如，如果你有一个报表应用需要很多的索引扫描，那么在你运行此报表应用的时候你的OLTP负载的性能会受损。为了解决这个问题，迁移报表应用到另外一个服务器。对实时报表，复制通常配置为单向的，从数据源到数据目标系统。

    如果你的复制数据目的是连续可用性，并期望在另一个站点运行相同应用，那么需要在运行应用的两方站点复制应用所需的所有数据。一个通常的配置是在主站点部署一个大的系统而在第二站点部署一个小的系统，并只保护那些对业务连续性非常关键的数据。

    对Q复制来说，源系统和目标系统可以是非常不同的。它们不需要运行相同的操作系统和DB2版本。

Q复制流程介绍

    Q复制使用 log-capture/transaction-replay技术；变化数据被从DB2恢复日志中捕获，通过网络由WebSphere MQ传输，然后在目标系统做为DB2 SQL事务执行。

     使用Q 复制，变化数据由队列管理器通过一个传输队列（XMITQ）在网络上传送。每个MQ消息传输一个从日志中捕获的DB2事务。每个消息都非常的简洁，只包含数据值和非常小的头信息。如果网络或者目标系统宕机，变化数据仍然能被捕获并缓存在源系统的传输队列中。一旦传输成功，事务被缓存在接收队列中，并被并行Q Apply代理并行应用到目标数据库。事务的一致性会被维持。如果目标数据库或者Q Apply任意一个宕机，变化数据将被缓存在目标系统的接收队列中，直到Q Apply和DB2 都可用。

    未完待续