使用 IBM InfoSphere Data Replication 进行模式复制,第 1 部分: DB2 for Linux, UNIX, and Windows 10.1 中的单向模式订阅

在主动/主动场景中建立 Q Replication 模式订阅

IBM® InfoSphere® Data Replication 支持在相同或不同操作平台上的两个或多个数据库管理系统之间进行数据同步。有很多不同使用场景。从 IBM InfoSphere Data Replication 10.1 开始,将支持模式级复制。这意味着已定义的数据库结构更改(比如创建新表)会自动添加到复制系统,无需任何管理或干预。当在主数据库中添加或更改表时,这不仅会取消或大大减少管理工作,而且会极大地增加复制系统的可靠性,特别在作为一个活动的灾难恢复站点的同步机制使用时。本文是系列文章的第一部分,将通过一个灾难恢复使用案例,解释如何为 Q Replication 技术中提供的单向复制拓扑结构建立模式级订阅,该技术是 IBM InfoSphere Data Replication v10.1.3 for Linux®, UNIX®, and Windows® 附带的。我们鼓励您重现此场景。为了尽可能的方便,本文下载部分会提供各种脚本。请查看本系列的更多文章,其中包含双向拓扑模式级订阅等内容。

Olaf Stephan, 领先服务专家 — 信息管理, IBM

作者照片Olaf Stephan 在 IBM Software Group Services 信息管理部门担任信息技术专员。他的工作重点是通过咨询、教育、概述和平台开发向 IBM 客户提供 IBM DB2 for Linux, UNIX, and Windows 数据库、Data Warehouse 技术和 Data Integration 知识。他曾在位于布林根的 IBM Development and Research 实验室从事过 IBM 产品 IBM Smart Analytics Optimizer 工作。Olaf 也是以下 IBM 出版物的合著作者。IBM 红皮书:“Data Mart Consolidation: Getting Control of Your Enterprise Information” (SG24-6653-00),IBM developerWorks 文章:“Porting workshop, Processor porting strategies”,“Introducing the 7-part, fast-read series on porting compute-intense applications to the Cell Broadband Engine Architecture” 。



Christian Lenke, 领先技术销售专业人士, IBM

作者的照片Christian Lenke 在 IBM 软件部的信息管理部门担任客户端技术专业人士。他的专业领域是信息管理,他非常关注信息集成,包括 ETL、数据质量、数据集成和元数据管理。Christian 从事 IBM 数据复制技术已有超过 15 年的时间,曾为众多德国以及国际客户介绍过企业级数据复制解决方案。Christian 也是以下 IBM 红皮书的主要作者:“My Mother thinks I'm a DBA - Cross-Platform, Multi-Vendor, Distributed Relational Data Replication with IBM DB2 DataPropagator and IBM DataJoiner - Made Easy!” (SG24-5463-00 )。



2013 年 11 月 28 日

场景

在当今的需求 市场中,企业越来越依赖电子数据和软件应用程序,利用它们为客户提供服务以及遵守政府和行业法规。这些企业不能承受由于计划或意外系统中断而造成的直接停机费用。更多停机造成的影响甚至可能是间接的、长久性的。

IT 部门通常运行各种(通常更多的)多个高可用性和灾难恢复解决方案来预防计划和意外停机。多数常用技术都基于硬件(要求主站点与辅助站点具有相同的硬件),需要提供一个闲置的大型主机(如果没有故障发生的话),还需要在近距离设置一个备用站点(这不能防止区域停机),不能预防应用程序故障,或者需要大量时间来激活辅助站点,以防止主站点停机。

带有 Q Replication 的主动/主动灾难恢复

IBM 使用 Q Replication 提供了一个基于近实时事务复制机制的软件,该机制可保证数据交付。从技术上讲,Q Replication 是一项异步日志捕获/事务重播技术,使用 WebSphere MQ 作为解决方案分散组件的运输和分段机制。Q Replication 可被配置成单向或多向的,因此所有数据都将从站点 A 流向站点 B,反之亦然。与物理 SR 解决方案相比,基于 MQ 的数据复制是一个有趣的替代或补充方案,因为:

  • 主站点和辅助站点之间没有距离限制。
  • 备用数据库是完全激活且可以访问(读和写)的,这允许执行以下操作:
    • 工作负载平衡。
    • 将专用任务(比如专用租户和实时报告)发送到辅助站点。
    • 如果发生灾难,则会立即重新路由应用程序。
  • 允许支持多个备用站点。
  • 允许支持主站点和辅助站点上的异构硬件,甚至不同的操作平台。
  • 允许数据构造子集。
  • 允许延时复制。
  • 允许支持地域上分散的应用程序,通常在本地数据库上运行,但是,如果发生灾难,则会切换到远程站点。
  • 辅助站点上没有闲置的大型主机。

DDL 复制和模式复制的优势

假设您使用一个数据复制解决方案将任务关键型 OLTP 数据库与一个远距离灾难恢复站点同步。此外,假设由于当地断电,您不得不将您的应用程序切换到远程站点。切换后您立即意识到,DBA 尚未添加 3 个重要的新表,这 3 个新表是新版本附带的用于进行复制设置的。通过使用 IBM Q Replication 技术引入的新模式级订阅,很容易避免这类可能出现的场景,IBM Q Replication 技术是 IBM InfoSphere Data Replication for Linux, UNIX, and Windows (IIDR) 的附带技术。模式级订阅和自动 DDL 复制将缓解破坏灾难恢复站点的风险(这种破坏是由于遗忘了一些检查清单项而导致的),而且为 DBA 留有一定的时间来关注更重要的任务。


解决方案的组成部分

IBM InfoSphere Data Replication (IIDR) 支持大容量低延迟的已更改数据的移动,范围从数据仓储和业务智能、数据库迁移、应用程序整合和主数据管理,到高可用性、业务连续性和双主动数据库。

InfoSphere Data Replication 为各种 IBM 和非 IBM 数据库管理系统提供了日志捕获支持,提供了三个主要数据复制技术,它们分别是 Change Data Capture、Q Replication 和 SQL Replication。InfoSphere Data Replication 用户可以选择独立使用或结合使用这些技术。

本文主要关注 IBM InfoSphere Data Replication (IIDR) 附带的 Q Replication 。Q Replication 解决方案的组成部分包括:相互独立的可操作的运行时组件、Q Capture 和 Q Apply、作为数据传输和缓冲机制的 MQ、基于图形和命令行的管理组件和一个基于浏览器的管理控制台 Q Replication Dashboard。

图 1 展示了 Q Replication 解决方案的分布式组件如何相互作用。

图 1. Q Replication 组件概述
该图展示了 Q Replication 组件概述

Q Replication Capture

Q Capture 程序通过标准 DB2 日志界面处理 DB2 恢复日志,确定相关日志记录,并在事务层发送 MQ 消息。Q Capture 处理作为 DML 语句结果的所有日志记录以及某些 DDL 相关日志记录。

Q Replication Apply

Q Apply 程序使用 MQ 重新构建从 Q Capture 收到的事务,并将该事务应用在目标表或存储程序中。Q Apply 程序旨在通过并行应用事务语言紧跟技术快速发展的步伐,同时维护相关目标表之间数据一致性和引用完整性。

MQ 服务器

WebSphere MQ 是 IBM 的通用消息平台。对于 Q Replication 来说,MQ 基础架构主要用于将捕获的事务从 Q Capture 传递到 Q Apply。集群的 MQ 服务器可用于实现高可用性。您可以选择使用 Q Capture 或 Q Apply 将 MQ 客户端界面连接到 MQ 服务器。

MQ Explorer

WebSphere MQ Explorer 是一个可选组件,用于显示队列管理器、队列和通道状态。

Replication Center 和 ASNCLP

Replication Center 是图形前端用于交互式定义复制订阅。作为替代方案,订阅设置可使用 ASNCLP 命令语言轻松地实现自动化,特别在设置了大量复制对象的时候。Replication Center 和 ASNCLP 都可以填充存储在源和目标数据库中的复制控制表。

Q Replication Control Tables

Q Replication Control Tables 是一组 DB2 表(一些位于复制源数据库中,一些位于复制目标数据库中),其中包含复制配置、复制状态和统计信息,这些信息可用于监控和调优。可以将 Q Replication Control Tables 理解为开放式接口。每一列都记录在 Q Replication 文献中。

Q Replication Dashboard

Q Replication Dashboard 是一个基于浏览器的前端,可显示所有复制脚本及其状态、报警情况、性能指标等。如果发生故障,该仪表板会自动向管理员发出警报,而且提供具体场景向导。


什么是模式级订阅

模式级订阅是一个设置大量数据表的数据复制的新方法,只需使用一组简命令即可。在创建并激活模式订阅之后,所有表的表级订阅都会自动定义,与模式订阅命名模式相对应。您可以选择在目标数据库中创建目标表。

此外,当在复制源数据库中创建一个新表时,通常会自动创建一个新表级订阅(包括目标数据上的目标表)。首次插入源表时,复制机制甚至可以创建目标表的所有索引,目标表位于源数据库中。可以选择设置一个选项(通常推荐这样做),其中某些 ALTER TABLE 语句也可复制到目标数据库,无需任何管理干预。目前已经支持添加列 (ALTER TABLE ... ADD COLUMN) 和更改列数据的类型 (ALTER TABLE ... ALTER COLUM) 。模式订阅是 DB2 for Linux, UNIX, and Windows V10.1 和 InfoSphere Data Replication V10.1.3 首先引入的概念。


开始之前

本小节概述了支持 Q Replication 的基本数据库配置任务(包括模式级订阅),还介绍了简单测试案例的设置来演示一些功能。

如果您愿意的话,可以重现该测试案例。对于每个设置步骤,本文 下载 小节都提供了经过测试的脚本。

简单测试案例的设置

测试案例由一个主数据库 OLTPDB 和一个新创建的作为灾难恢复站点的辅助数据库 DRDB 构成。只有专用表才对该场景有用。在本系列第 1 部分中,您将看到如何通过设置单向 Q Replication 来利用模式订阅的新功能。该使用案例是一个主动/主动灾难恢复解决方案的简单示例。如果主站点停用,那么应用程序可以切换到灾难恢复站点,但是由于数据复制仅在单向模式下定义,所有切换回来可能需要建立一个新的复制目录。如果不需要进行应用程序切换,那么灾难恢复站点可用来随时卸载报告和只读应用程序。图 2 概述了这个使用案例。

图 2. Q Replication 单向使用案例基础架构概述
该图显示了 Q Replication 单向使用案例基础架构的概述

表 1 展示了数据库 OLTPDB(主数据库)中的所有表,并指出是否应该将它们复制到 DRDB(辅助数据库)。

表 1. 单向使用案例中使用的表的清单
模式和名称是否复制
GREEN.TAB01Y
GREEN.TAB02Y
GREEN.TAB03Y
GREEN.TAB99N
RED.TAB01N
RED.TAB02N

总之,灾难恢复复制站点解决方案必须包含所有 GREEN 表,但不能包含 TAB99。TAB99 是一个本地配置表。RED 表一定不得与恢复站点同步。

要重现使用案例,本文 下载 部分提供了一个压缩文件,其中包含所有脚本。

DDL 脚本 CREATE_2_GREEN_TABLES.DDL 在模式 GREEN 下创建和填充了数据库 OLTPDB 的前两个表。DDL 脚本 CREATE_RED_TABLES.DDL 在模式 RED 下创建和填充数据库。特定于复制步骤或模式订阅定义的其他步骤将在下面小节详细介绍。

源和目标数据的配置

至少应该在主数据库(如果是双向复制场景则是两个数据库)中设置以下数据库配置参数来支持 Q Replication 模式订阅,如清单 1 所示。

清单 1. 源数据库配置
UPDATE DB CFG FOR  OLTPDB using LOGARCHMETH1   LOGRETAIN;
UPDATE DB CFG FOR  OLTPDB using LOG_DDL_STMTS   YES;
UPDATE DB CFG FOR  OLTPDB using DFT_SCHEMAS_DCC YES;
  • LOGARCHMETH1 LOGRETAIN:一个可切换到 LOGRETAIN 的转换(不管怎么样,如果没有设置的话)。将主日志文件从循环记录转换成一种日志模式的一个转换,日志模式中 DB2 保留归档日志(或者将归档日志传递到标准归档解决方案)。将数据配置参数 LOGARCHMETH1 设置成 LOGRETAIN 之后,需要一个数据库备份。
  • LOG_DDL_STMTS: 该参数是 DB2 for Linux, UNIX, and Windows, V10.1 中引入的。一个可切换到 YES 的转换,在创建或删除数据表时,支持 DB2 编写 Capture 可通过标准日志读取 API 检索的日志记录。
  • DFT_SCHEMAS_DCC:该参数是 DB2 for Linux, UNIX, and Windows, V10.1 中引入的。一个可切换到 YES 的转换,指出所有新模式下的所有表都是使用 DATA CAPTURE CHANGES 属性创建的。DATA CAPTURE CHANGES 属性对所有将要复制的表来说是必需的。

目标数据库的创建

清单 2 中的命令被用于创建目标数据库 DRDB。

清单 2. 目标数据库设置和配置
CREATE DB DRDB;
UPDATE DB CFG FOR DRDB USING LOGARCHMETH1 LOGRETAIN;
BACKUP DB DRDB TO /DEV/NULL;
UPDATE DB CFG FOR DRDB USING DFT_SCHEMAS_DCC YES;
UPDATE DB CFG FOR DRDB USING LOG_DDL_STMTS YES;
CONNECT TO DRDB;
CREATE SCHEMA GREEN DATA CAPTURE CHANGES;
CREATE SCHEMA RED   DATA CAPTURE CHANGES;
CREATE TABLESPACE GREEN_TS;
CREATE TABLESPACE RED_TS;

SQL 语句 CREATE SCHEMA schema_name DATA CAPTURE CHANGES 标志在该模式下创建的所有表都是使用 DATA CAPTRUE CHANGES 选项自动创建的。该选项对于所有用作复制源的表来说是必须的。

所有必要 MQ 对象的创建

DB2 9.7 引入了一个非常有趣的 ASNCLP 命令语言扩展,减少了创建 Q Replication 所需的 MQ 对象的复杂性,对于那些 MQ 知识有限的 DBA 来说,尤其应该关注该扩展。

清单 3 中的 ASNCLP 命令生成了 UNIX shell 脚本或一个 Windows 批处理脚本。这些脚本中包含创建所有必要 MQ 对象的命令,比如 Q ManagersAdministration QueueSend and Receive QueueRestart Queue

清单 3. ASNCLP 命令可以为单向复制的所有 MQ 对象创建一个脚本
ASNCLP SESSION SET TO Q REPLICATION;
CREATE MQ SCRIPT 
CONFIG TYPE U
MQSERVER 1 NAME OLTPDB MQHOST "192.168.8.145"  MQPORT 2014 QMANAGER QM_OLTPDB 
QNAME_QUAL QASN_OLTPDB,
MQSERVER 2 NAME DRDB   MQHOST "192.168.8.144" MQPORT 2014 QMANAGER QM_DRDB   
QNAME_QUAL QASN_DRDB;

注意:如果您对 ASNCLP 不太熟悉,请查看关于如何执行 ASNCLP 命令的文档。如果您将 ASNCLP 命令存储在一个文件中,那么运行该命令最简单的方法是使用 asnclp -f <filename>

Q Replication 控制表的创建

在复制订阅创建之前,必须先创建复制控制结构(也称之为控制表)。必须在充当复制源(本例中是 OLTDB)的各个表中都创建 Q Capture Control Tables,还必须在充当复制目标(本例中是 DRDB)的各个表中都创建 Q Apply Control Tables,如清单 4 所示。

清单 4. 创建 Replication Control Tables 的 ASNCLP 命令
ASNCLP SESSION SET TO Q REPLICATION;
SET SERVER CAPTURE TO DBALIAS OLTPDB ID USERID PASSW0RD "PASSW0RD";
SET SERVER TARGET TO  DBALIAS DRDB   ID USERID PASSW0RD "PASSW0RD";

SET QMANAGER QM_OLTPDB FOR CAPTURE SCHEMA;
SET QMANAGER QM_DRDB FOR APPLY SCHEMA;
SET CAPTURE SCHEMA SOURCE QASN_OLTPDB;
SET APPLY SCHEMA QASN_DRDB;
SET OUTPUT TARGET SCRIPT "create_control_tables.sql";

SET RUN SCRIPT LATER ;

CREATE CONTROL TABLES FOR CAPTURE SERVER 
USING RESTARTQ "QASN_OLTPDB.RESTARTQ" ADMINQ "QASN_OLTPDB.ADMINQ";

CREATE CONTROL TABLES FOR APPLY   SERVER ;

创建和激活单向模式级订阅

下列小节将介绍如何为 图 2 中介绍的表设置单向复制场景。Q Replication ASNCLP 命令可用于每个设置步骤,使您可以很容易地重新创建该场景,并促进了自动化复制的设置。

ASNCLP 模板准备

所有后续复制设置步骤都需要使用相同的 ASNCLP 头文件。因此,下列所有单向复制设置步骤的常见头文件都将记录在该代码小节中,如清单 5 所示。

清单 5. 所有下列 ASNCLP 命令的 ASNCLP 头文件
ASNCLP SESSION SET TO Q REPLICATION;
SET SERVER CAPTURE TO DBALIAS OLTPDB ID USERID PASSW0RD "PASSW0RD";
SET SERVER TARGET TO  DBALIAS DRDB   ID USERID PASSW0RD "PASSW0RD";

SET QMANAGER QM_OLTPDB FOR CAPTURE SCHEMA;
SET QMANAGER QM_DRDB FOR APPLY SCHEMA;
SET CAPTURE SCHEMA SOURCE QASN_OLTPDB;
SET APPLY SCHEMA QASN_DRDB;

SET RUN SCRIPT LATER ;

SET LOG "q_map.log";
SET OUTPUT CAPTURE SCRIPT "capture.sql";
SET OUTPUT TARGET SCRIPT "target.sql";

ASNCLP 头文件定义了源和目标数据库、队列管理器以及 Q Capture 和 Q Apply 模式。当 ASNCLP 生成 SQL 来填充复制控制表时,头文件包含 SQL 命令的输出文件命名。选项 RUN SCRIPT LATER 指出 SQL 命令不是立即执行的,需要在执行之前进行检查。或者,可以使用 RUN NOW 选项直接执行生成的脚本。

复制队列映射的创建

在定义一个 Q 订阅(一个模式级订阅或单一表订阅)之前,必须创建一个复制队列映射。队列映射将队列名称和定义一个复制的特定设置性能联系在一起,比如发送队列、接受队列、管理队列、Apply 代理数量等等,如清单 6 所示。 s

清单 6. 复制队列映射的创建
#requires header as listed in Listing 5			
CREATE REPLQMAP OLTPDB_TO_DRDB USING ADMINQ "QASN_OLTPDB.ADMINQ" 
RECVQ "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA" 
SENDQ "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA";

该命令需要使用之前 清单 5 中展示的 ASNCLP 头文件。

单向复制 Q Replication 设置验证

为了保证质量,必须在定义第一个订阅之前使用两个 ASNCLP 命令来验证 MQ 设置和消息流。

如清单 7 所示,VALIDATE WSMQ ENVIRONMENT 命令证实确实存在所需的 WebSphere MQ 对象,而且它们有正确的属性。VALIDATE WSMQ MESSAGE FLOW 命令发送了验证复制队列映射的 MQ 消息流的测试消息。

清单 7. 验证复制步骤的 ASNCLP 命令
#requires header as listed in Listing 5				
VALIDATE WSMQ ENVIRONMENT  FOR REPLQMAP OLTPDB_TO_DRDB;
VALIDATE WSMQ MESSAGE FLOW FOR REPLQMAP OLTPDB_TO_DRDB;

模式选项创建

Q 复制订阅可以采用许多方法进行灵活定制。模式选项指定完整订阅的定制属于复制模式。普通定制指定初始刷新行为、错误情况下的行为以及新列是否应自动添加到订阅以及复制目标。清单 8 中的示例显示,定义了下列模式订阅选项。

  • SUBTYPE U:指出这些选项适用于单向模式级订阅。
  • CAPTURE_LOAD W:如果一个属于模式订阅的表加载了一个实用程序,则允许 Q Capture 发出警报。请注意,实用程序操作不会以某种通过标准 DB2 日志接口使用 Q Capture 的方式来记录日志。
  • REPLICATE ADD COLUMN Y:指出 Q Capture 自动复制某些表变更,比如 ADD COLUMN 或 ALTER。
  • CONFLICT ACTION I:告知 Q Apply 忽略复制冲突。复制冲突处理对于单向订阅来说不是很重要,但是对于第二个示例(本系列第 2 部分中)中的双向订阅来比较重要。
  • ERROR ACTION Q:允许 Q Apply 停止所有订阅,如果出现错误的话(比如表空间充满),那么这些订阅将会通过相同的队列/映射进行复制。Q Capture 发送的所有变更都将缓存在队列中直至错误修复,Q Apply 继续运行。
  • LOAD TYPE 2 EXIST DATA REPLACE:在初始刷新的情况下,允许 Apply 调用 EXPORT/IMPORT(而不是 EXPORT/LOAD 或 Cross Loader)。
清单 8. ASNCLP 命令可以创建订阅选项
#requires header as listed in Listing 5
CREATE SUBSCRIPTION OPTIONS UNIDIR_STANDARD
SUBTYPE U
CAPTURE_LOAD W
REPLICATE ADD COLUMN Y
CONFLICT ACTION I
ERROR ACTION Q
LOAD TYPE 2 EXIST DATA REPLACE;

注意:由于 IBM InfoSphere Data Replication V10.1 Fixpack 2 中有一个尚未解决的问题,订阅选项 REPLICATE ADD COLUMN YES 不能传播到模式级订阅自动生成的表级订阅。在添加了新的表级订阅后,可以手动更新 Q Replication 控制表 IBMQREP_SUBS 来解决这一问题。创建了模式订阅之后,并且已经从模式订阅中自动生成新表级订阅之后,执行下列 SQL 更新语句,(问题解决后可跳过清单 9 中的 SQL UPDATE )。

清单 9. 更新表 IBMQREP_SUBS
UPDATE QASN_OLTPDB.IBMQREP_SUBS SET REPL_ADDCOL = 'Y';

模式订阅的创建

确保任务是复制 GREEN 模式下的所有表,TAB99 除外。此外,在本例中,RED 模式下的所有表都不能复制,因为 RED 模式下的所有表都包含敏感数据。ASNCLP 命令(CREATE SCHEMASUB)定义了相应模式订阅。

清单 10 中的模式订阅使用了之前定义的模式选项 UNIDIR_STANDARD。

清单 10. 创建模式订阅的 ASNCLP 命令
#requires header as listed in Listing 5
CREATE SCHEMASUB GREEN_SCHEMA SUBTYPE U REPLQMAP OLTPDB_TO_DRDB 
FOR TABLES OWNER LIKE GREEN 
EXCLUDE OWNER GREEN NAME TAB99, OWNER RED 
OPTIONS UNIDIR_STANDARD

请注意,这里有灵活的选项可包含和排除模式级订阅中的表。对于 GREEN.MYTAB%、GREE%.% 或者 %.% 之类的模式,很容易定义模式级订阅。但是对于一个队列映射来说,模式一定不能重叠,这会导致同一个表可能与两个模式级订阅相匹配。

活动的模式订阅

Q Capture 启动时,新模式订阅将自动激活(初始化)。如果创建一个新的模式订阅时 Q Capture 已经处于活动状态(而且您不想停止或重启 Q Capture ),那么该订阅必须使用 START SCHEMASUB 命令激活。该命令在 IBMQREP_SIGNAL 中生成一个 SQL INSERT,这使得 Q Capture 可启动所有特定模式变更捕获。

在我们的示例中,Q Capture 和 Q Apply 目前都没有启动。因此没有必要使用 START SCHEMASUB 命令来启动模式订阅,如清单 11 所示。

清单 11. 创建用于启动模式复制的 ASNCLP 命令
#requires header as listed in Listing 5
START SCHEMASUB GREEN_SCHEMA ALL;

操作 Q Capture 和 Q Apply

要最终获得数据复制,下一步是启动 Q Capture 和 Q Apply 流程。有几种方法可操作 Q Capture 和 Q Apply 并指定或变更 Q Capture 和 Q Apply 参数。您可以选择使用 Replication Center、系统命令或系统服务。在启动过程中,可以指出影响 Q Capture 或 Q Apply 行为的参数,或者将它们永久地存储在 Q 复制控制表 IBMQREP_CAPPARMS 或 IBMQREP_APPLYPARMS 中。

下列小节将介绍启动本例的 Q Capture 和 Q Apply 的所有必要步骤。

创建加密的 PASSW0RD 文件

如果 Q Capture 或 Q Apply 远程连接到源或目标数据库,或者 Q Capture 和 Q Apply 需要使用专用用户 ID 连接,则需要一个包含连接证书的加密 PASSW0RD 文件。需要注意的是,Q Capture 只能连接到复制源数据库,而 Q Apply 只能连接到源和目标数据库(只有当 Q Apply 执行一个完整刷新后才能连接到源数据库)。PASSW0RD 文件必须存储在 Q Capture 和 Q Apply 的工作目录中或参数 ASNPATH 指定的路径下。密码文件可创建或初始化,而且可使用 asnpwd 命令进行填充,如清单 12 所示。

清单 12. 创建用于捕获的 PASSW0RD 文件并应用它
asnpwd INIT USING encrypt.passwd
asnpwd add alias OLTDB id USERID PASSW0RD PASSW0RD USING encrypt.passwd
asnpwd add alias DRDB  id USERID PASSW0RD PASSW0RD USING encrypt.passwd

注意asnpwd 命令不是 ASNCLP 命令,因此不需要通用头文件。

Q Capture 和 Q Apply 启动命令

asnqcap 命令启动 Q Capture 任务。CAPTURE_SERVER 是惟一强制参数。其他参数是可选的,可选择在启动过程中或控制表 IBMQREP_CAPPARMS 中定义它们。

Hint:首次启动 Q Capture 和 Q Apply 时,推荐先启动 Q Capture,然后启动 Q Apply。如果 Q Capture 和 Q Apply 已经运行了一段时间,那么可以独立停止和启动,不再需要遵守启动顺序。

清单 13 中的命令可启动数据库 OLTPDB 的 Q Capture。

清单 13. Q Capture 启动命令
asnqcap capture_server=OLTPDB capture_schema=QASN_OLTPDB 
logstdout=y pwdfile=encrypt.passwd

下面是一个 Q Capture 启动参数说明。

  • CAPTURE_SERVER 指令 Q Capture 连接到复制源数据库。
  • CAPTURE_SCHEMA 必须是指定的,如果复制控制表不是在默认模式 QASN 中创建的的话。在这个使用案例中,选择使用 QASN_OLTPDB 作为 Q Capture 模式。
  • LOGSTDOUT=Y 支持 Q Capture 将所有日志消息编写成标准输出(此外还有日志表 IBMQREP_CAPTRACE 和日志文件 *.QCAP.LOG)。
  • PWDFILE=encrypt.passwd 指定使用之前 清单 12 中创建的密码文件。
  • asnqapp 命令可以启动 Q Apply 任务。APPLY_SERVER 是惟一的一个强制参数。其他参数是可选的,可选择在启动过程中或在控制表 IBMQREP_APPLYPARMS 中定义。

清单 14 中的命令启动数据库 DRDB 的 Q Apply。

清单 14. Q Apply 启动命令
asnqapp apply_server=DRDB apply_schema=QASN_DRDB 
logstdout=y pwdfile=encrypt.passwd

下列命令是 Q Apply 启动参数的说明。

  • APPLY_SERVER 指出 Q Apply 连接到复制目标数据库。
  • APPLY_SCHEMA 必须被指定,如果复制控制表不是在默认模式(QASN)中创建的话。在这个使用案例中,选择使用 QASN_DRDB 作为 Q Apply 模式。
  • LOGSTDOUT=Y 支持 Q Apply 将所有日志消息编写成标准输出(此外还有日志表 IBMQREP_APPLYTRACE 和日志文件 *.QAPP.LOG)。
  • PWDFILE=encrypt.passwd 指定使用之前 清单 12 中创建的密码文件。

如果 Q Capture 和 Q Apply 是在创建模式订阅后启动的,正如我们的场景所示,那么它们将自动激活模式订阅,并为该模式对应的所有表自动生成表级订阅。作为表级订阅创建的一部分,如果目标表不存在的话,Q Apply 会在数据库 DRDB 中创建目标表。在我们介绍的案例中,分别为表 GREEN.TAB01 和 GREEN.TAB02 创建了两个订阅。依据订阅命名模式,表级订阅的名称分别是 TAB010001 和 TAB020001。

作为订阅激活部分,Q Apply 执行目标表的初始加载。将这个可选行为指定为模式订阅选项 LOAD TYPE 2 EXIST DATA REPLACE 。

下列两个清单分别展示了 Q Capture 和 Q Apply 在启动阶段发出的最重要的日志消息。

Q Capture 消息 ASN7247I 记录了模式订阅被成功激活。消息 ASN7010I 记录自动创建的相应表级订阅(TAB01 对应于 TAB010001,而 TAB02 对应于 TAB020001)的激活,如清单 15 所示。

清单 15. 启动后的 Capture 日志片段
013-04-09-14.22.07.894361 ASN7247I  "Q Capture" : "QASN_OLTPDB" : "WorkerThread" : 
The Q Capture program successfully loaded the schema-level subscription "GREEN_SCHEMA" 
and its corresponding profile. 
The Q subscription uses replication queue map "OLTPDB_TO_DRDB" and specifies that 
Q subscriptions should automatically 
be created in schema "GREEN" for "TAB0%" objects.
2013-04-09-14.22.08.033952 ASN7010I  "Q Capture" : "QASN_OLTPDB" : "WorkerThread" : 
The program successfully activated publication or Q subscription "TAB020001" 
(send queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
publishing or replication queue map "OLTPDB_TO_DRDB") 
for source table "GREEN.TAB02".
2013-04-09-14.22.08.054131 ASN7010I  "Q Capture" : "QASN_OLTPDB" : "WorkerThread" : 
The program successfully activated publication or Q subscription "TAB010001" 
(send queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
publishing or replication queue map "OLTPDB_TO_DRDB") 
for source table "GREEN.TAB01".

清单 16 显示初次加载的目标表(本例中是 TAB01)的 Q Apply 消息 ASN7528I 和 ASN7529I 日志。ASN7606I 记录了订阅 TAB010001 已成功激活。Q Apply 记录了 TAB02 的相同消息。

清单 16. 启动后的 Apply 日志片段
2013-04-09-14.33.14.029664 ASN7528I  "Q Apply" : "QASN_DRDB" : 
"BR00000SP001" : The Q Apply program for the Q subscription "TAB010001" 
(receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB") 
will use the "IMPORT" utility to load table "GREEN.TAB01".
2013-04-09-14.33.14.785830 ASN7529I  "Q Apply" : "QASN_DRDB" : "BR00000SP001" : 
The "IMPORT" utility for table "GREEN.TAB01" completed successfully 
for the Q subscription "TAB010001" 
(receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB"). 
The message from the utility is "Rows imported: 100, Rows rejected: 0, Rows skipped: 0".
2013-04-09-14.33.16.566135 ASN8999D Browser 
for queue 'QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA' 
received a 'ASNMQ_LOADDONE_RCVD' message.
2013-04-09-14.33.18.591637 ASN7606I  "Q Apply" : "QASN_DRDB" : "BR00000" : 
Q subscription "TAB010001" (receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB") is active.

监控辅助状态

使用 Q Replication Dashboard 很容易监控整体复制状态、所有复制对象状态以及复制过程吞吐率。如图 3 所示,一个简要概述指出所有发送和接受队列都处于激活状态(菱形符号),一个队列映射中有两个表级订阅,所有表级订阅都处于激活状态(菱形符号)。

图 3. 使用 Q Replication Dashboard 监控的初始复制状态
该图显示了 Q Replication Dashboard - Summary

该柱状图展示了监控的延迟和吞吐率。Q Replication Dashboard 将检索 Q Replication 控制表的复制状态和吞吐率

或者,您可以使用简单 SQL 查询复制控制表。清单 17 中的查询将在复制源数据库 OLTPDB 中检索控制表 IBMQREP_SUBS 中的所有表级订阅。

清单 17. 模式 GREEN 的订阅
db2 select state, substr(subname,1,10) as subname from QASN_OLTPDB.IBMQREP_SUBS
STATE SUBNAME
----- ----------
A     TAB010001
A     TAB020001

  2 record(s) selected.

查询显示了两个 Q 订阅,即 TAB010001(面向 GREEN.TAB01)和 TAB020001(面向 GREEN.TAB02)。这些订阅是 Q Capture 和 Q Apply 自动创建的,作为模式订阅的结果。我们没有为 GREEN.TAB99 创建模式订阅,因为这个表无法与模式订阅命名模式匹配。


自动创建其他订阅

在本小节中,您可以学习如何将新表自动添加到复制解决方案,而不需要人工创建新的订阅。

表 GREEN.TAB03 的新订阅

要创建一个与模式订阅命名模式相匹配的新表(GREEN.TAB03),需要准备一个 SQL 脚本 CREATE_GREEN_TAB03,如清单 18 所示。

清单 18. 创建附加表 GREEN.TAB03
  db2 -tvf CREATE_GREEN_TAB03.DDL

注意:该脚本也包含在压缩文件中,可在本文 下载 部分中找到。

TAB03 创建完成后,Q Capture 立即识别 DB2 事务日志中的 CREATE TABLE DDL 语句(由于数据库配置参数 LOG_DDL_STMTS=Y)。Q Capture 确定该表与模式订阅 GREEN_SCHEMA 的命名模式匹配并立即在源数据库中创建新的表级订阅。

此外,Q Capture 也将消息发送到 Q Apply,以支持 Q Apply 在目标数据库中创建特定于订阅的元数据。Q Apply 还将创建一个与源表有相同结构的目标表。在将第一条记录插入源表时,Q Apply 会为现有目标表创建所有索引。Q Apply 立即激活新订阅,以便能够在创建表后即时复制所有插入、更新和删除内容。不需要完全刷新。

Q Capture 的日志消息 ASN7210I 指出表 GREEN.TAB03 的新表级订阅在源数据库中是自动创建的,如清单 19 所示。

清单 19. 表 GREEN.TAB03 创建过程中的 Q Capture 日志片段
2013-03-28-11.32.42.745000 ASN7210I  "Q Capture" : "QASN_OLTPDB" : "WorkerThread" : 
Q subscription "TAB030001"  
that corresponds to schema-level subscription "GREEN_SCHEMA" was successfully 
created for the source table "GREEN.TAB03"  
that uses  send queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA" 
and replication queue map "OLTPDB_TO_DRDB".

Q Apply 日志消息 ASN7711I 指出表 GREEN.TAB03 的新表级订阅在目标数据库中是自动创建的,如清单 20 所示。

清单 20. 表 GREEN.TAB03 创建过程中的 Q Apply 日志片段
2013-03-28-11.32.40.756229 ASN7711I  "Q Apply" : "QASN_DRDB" : "BR00000" : 
Q subscription "TAB030001" was successfully created 
for the target table ""GREEN".TAB03" 
that uses receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA" 
and replication queue map "OLTPDB_TO_DRDB" 
because a schema-level subscription "GREEN_SCHEMA" was defined at the source.

总之,Q Capture 和 Q Apply 将表 GREEN.TAB03 添加到复制设置阶段,并立即开始新表复制,不需要任何管理干预或应用程序停机。对于所有与模式订阅命名模式相匹配的新表而言,该操作是自动进行的。这个自动话操作不仅会大大减少管理工作,还会减少错误和降低停机风险。

监控复制状态

再次申明,您可以使用 Q Replication Dashboard 检查复制状态。Q Replication Dashboard 可立即将新订阅添加到概述页面。如果将图 4 和 图 3 中的摘要进行比较,您会发现订阅计数器从 2 增加到了 3。

图 4. 添加表 GREEN.TAB03 之后的 Q Replication Dashboard
该图显示添加了表 GREEN.TAB03 之后的 Q Replication Dashboard

注意,所有这三个订阅都是活动的,可通过菱形符号表现出来。

正如我们之前所说明的,Q Replication Dashboard 可用于进一步调查所有 Q Replication 对象(q maps、队列、q depth、订阅、源和目标表,等等),并监控 Q Replication 状态和吞吐量。查看 参考资料 部分,获取 Q Replication Dashboard 教程链接,详细查阅所有选项。

您可以使用 Q Replication Dashboard 接着检查模式订阅 GREEN_SCHEMA 的状态。如果打开 Q Replication Dashboard 的 Subscriptions 选项卡,将会显示所有已有的订阅。对于模式级订阅来说,可以显示所有按复制模式分组的表级订阅。请注意图 5,其中选中了 Group by schema-level subscription 复选框。

图 5. 按模式级别订阅分组
该图显示 3 个订阅都处于激活状态,而且正根据模式级别订阅复制进行分组

在本例中,您可以看到模式级订阅的属性(模式样式、对象样式、模式选项,等等)和所有根据复制模式自动创建的表级订阅。正如 图 5 所示,您可以看到 3 个表级订阅。State 列的菱形符号表示所有三个订阅都处于激活状态而且正在复制。

单击 Dashboard 视图的超链接将会显示更多的详细信息。例如,单击 UNIDIR_STANDARD 链接(模式订阅概要文件名称),模式概要文件中所有选项都会显示出来。图 5 展示了 清单 8 中定义的模式选项。其中一些选项在创建概要文件时并不是显式指定的。默认选项如图 6 所示。

图 6. 已定义的模式选项的概要文件信息
该图显示一个已定义的默认模式选项的概要文件信息。

表更改的自动复制

除了将新表添加到一个模式中之外,对现有表进行变更是另一个常见使用案例,现在可以使用 InfoSphere Data Replication V10.1.3 以其更高版本来自动实现表更改。可以将此应用于所有表级订阅,而不仅仅应用于那些从模式订阅中生成的表级订阅。并不是所有变更都受到支持,目前只支持最常见的变更。要注意的一点是,表变更的自动复制是可选的,必须显式切换。

表变更自动复制使用选项 REPLICATE ADD COLUMN Y 创建的订阅。您可以查看在 Q Capture 服务器控制表 IBMQREP_SUBS 中该选项是否是通过查询订阅属性(列 REPL_ADDCOL)进行设置的。

对于上述使用案例,我们假设表 GREEN.TAB01 需要附加列。清单 21 中的 ALTER TABLE 语句将 4 个列添加到表 GREEN.TAB01 中,该表已经被复制。

清单 21. 将列添加到表 GREEN.TAB01
  ALTER TABLE GREEN.TAB01 
  ADD COLUMN VALID_DESC CHAR(5) 
  ADD COLUMN IS_VALID CHAR(1) 
  ADD COLUMN VALID_START DATE 
  ADD COLUMN VALID_END DATE;

执行了 ALTER TABLE 语句之后,Q Capture 和 Q Apply 会自动向现有订阅中添加新列。DDL 语句将被复制到目标站点,而且 Q Apply 将这些列自动添加到目标表。

正如清单 22 所示,Q Capture 的日志消息 ASN7209I 表示一个新列已经自动添加到现有订阅。

清单 22. 在表 GREEN.TAB01 上添加新列的过程中的捕获日志的代码片段
2013-04-09-14.44.44.282765 ASN7209I  "Q Capture" : "QASN_OLTPDB" : 
"WorkerThread" : Column "VALID_DESC" of table "GREEN.TAB01" 
was automatically added to publication or Q subscription "TAB010001".
2013-04-09-14.44.44.293950 ASN7209I  "Q Capture" : "QASN_OLTPDB" : 
"WorkerThread" : Column "IS_VALID" of table "GREEN.TAB01" 
was automatically added to publication or Q subscription "TAB010001".

如清单 23 所示,Q Apply 将记录与消息 ASN7612I 相同的消息。

清单 23. 在表 GREEN.TAB01 上添加新列的过程中的应用日志的代码片段
2013-04-09-14.44.44.415914 ASN7612I  "Q Apply" : "QASN_DRDB" : "BR00000" : 
Column "VALID_DESC", has been added to Q subscription "TAB010001" 
(receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB").
2013-04-09-14.44.44.536721 ASN7612I  "Q Apply" : "QASN_DRDB" : "BR00000" : 
Column "IS_VALID", has been added to Q subscription "TAB010001" 
(receive queue "QASN_OLTPDB.OLTPDB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB").

另一个 DDL 复制示例是改变现有列的数据类型。我们假设列 VALID_DESC 是使用一个错误的数据类型(CHAR(5))创建的。新数据类型应该是 VARCHAR(20),如清单 24 所示。

清单 24. 改变表 GREEN.TAB01 的 VALID_DESC 列
ALTER TABLE GREEN.TAB01 
ALTER COLUMN VALID_DESC SET DATA TYPE VARCHAR(20);

执行上述语句后,Q Capture 和 Q Apply 会自动将 ALTER TABLE 语句复制到目标数据库,同时改变相应的订阅元数据。

如清单 25 所示,Q Capture 的日志消息 ASN7208I 指出检测到一个列变更,且该订阅是自动改变的。

清单 25. 改变表 GREEN.TAB01 的列 VALID_DESC 之后的捕获日志的代码片段
2013-04-09-15.06.38.795886 ASN7208I  "Q Capture" : "QASN_OLTPDB" : 
"WorkerThread" : An ALTER TABLE ALTER COLUMN statement was detected 
for column "VALID_DESC" of table "GREEN.TAB01" 
with a new data type of "VARCHAR(20)". 
The column was automatically altered for Q subscription "TAB010001"

如清单 26 所示,Q Apply 记录了与消息 ASN7718I 相同的消息。

清单 26. 改变表 GREEN.TAB01 的列 VALID_DESC 之后的应用日志的代码片段
2013-04-09-15.06.38.989796 ASN7718I "Q Apply" : "QASN_DRDB" : "BR00000" : 
Column "VALID_DESC" has been altered in table "TAB010001" 
(receive queue "QASN_OLTPDB.OLTPB_TO_QASN_DRDB.DRDB.DATA", 
replication queue map "OLTPDB_TO_DRDB")

目前的限制

以下是 Q Replication( InfoSphere Data Replication V10.1.3 一部分)中模式级订阅和自动 DDL 复制目前的限制。

平台支持:

  • InfoSphere Data Replication V10.1.3 仅支持针对 DB2 for Linux, UNIX, Windows 平台的模式级订阅。
  • DDL 复制(ALTER TABLE)支持 DB2 for Linux, UNIX, Windows 以及 DB2 for System z。

索引:

  • 如果表级订阅是自动创建的,因为与模式级订阅匹配,所有在将第一条记录插入原表时,会在现有目标表上创建所有索引。
  • 索引创建后就不能复制到目标数据库了。

受支持的 ALTER TABLE 语句:

  • ALTER TABLE ... ADD COLUMN ...
  • ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE.
  • 其他 ALTER TABLE 语句不能复制或者会导致复制出错。

目标表类型:

  • 模式订阅目前还不支持 CCD 或 History 表。

CREATE TABLESPACE:

  • Create Tablespace 不能自动复制。在源和目标数据库中创建新的表空间。

范围分区表:

  • ADD、ATTACH 和 DETACH 不能自动复制。

参考资料 部分,获取关于模式级订阅的更多常见限制的完整列表。


结束语

本文概述了一个使用 Q Replication 作为一个主动/主动灾难恢复解决方案同步机制的场景。我们还验证了使用诸如模式级订阅和 DDl 复制之类的新特性来维护和管理数据复制是多么容易,这些特性将作为 IBM InfoSphere Data Replication V10.1.3 的一部分同 IBM Q Replication 技术一起交付。我们认为模式订阅和自动化 DDL 复制都是非常有用的改进,因为复制解决方案的自动维护减少了管理工作,所以会大大节约了该解决方案的总拥有成本。想像一个容易包含数百个数据库模式更改的常见应用程序版本。

或许,自动处理变更减少了应用程序故障和停机风险也同样重要。这特别适合灾难恢复解决方案,同时也适用于依赖数据复制的其他使用案例。

模式订阅和 DDL 复制使得复制维护变得非常容易。

最后,如果您喜欢本文的话,请继续关注本系列的第 2 部分,后续文章会将主动/主动灾难恢复使用案例扩到双向模式复制。双向模式复制支持快速切换和来回切换,因为复制订阅是从主主数据库定义到备份站点的,反之亦然。


下载

描述名字大小
本文的样例 ASNCLP 和 DDL 脚本Scripts.zip41KB

参考资料

学习

获得产品和技术

  • 以最适合您的方式 评估 IBM 产品:下载产品试用版,在线试用产品,在云环境下试用产品。
  • IBM InfoSphere Data Replication Dashboard
  • Evaluate IBM WebSphere MQ IBM WebSphere MQ - 90 天免费使用版代码。确保您可以体验开放的、可扩展的行业级消息传递为您企业提供的服务。
  • 使用 IBM 试用软件 构建您的下一个开发项目,可直接从 developerWorks 下载这些软件。
  • 以最适合您的方式 评估 IBM 产品:下载产品试用版,在线试用产品,在云环境下试用产品,或者在 SOA Sandbox 中花费几个小时中花费几个小时来学习如何高效地实现面向服务的架构。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=954916
ArticleTitle=使用 IBM InfoSphere Data Replication 进行模式复制,第 1 部分: DB2 for Linux, UNIX, and Windows 10.1 中的单向模式订阅
publish-date=11282013