经过二十多年与客户的共同成长,InfoSphere Data Replication(IIDR)产品的 Q 复制已成为很多银行、电信、保险等大型企业首选的数据复制方案。作为传统的软件产品,开发团队一直以来都是采用了业内通用的瀑布型开发模式,每个版本发布通常需要几个月。但是近年来,随着业界开发模式的发展以及新兴企业的涌现,无论是产品本身还是客户都受到了互联网的冲击。客户本身以及客户的客户对产品的功能改进的需求越来越多,也越来越迫切。随着公司的 Agile 转型,IIDR 产品团队也在进行着开发模式的转型以及产品发布方式的变化。而从技术层面,为了达到持续交付的目的,在最新的版本 IIDR zOS 11.4 中,产品引入了功能水平(Function Level)等一系列新概念,打破了以往版本发布的限制,实现了增量发布。在新版本发布后,由于该特性改变了以往的行为模式,实施团队、客户遇到了一定的挑战,本文将详细介绍该新特性的基本原理和使用方法,帮助用户刷新产品相关的技能,相信会对将要使用新版本的客户和正在寻求高效复制数据到数据库方案的读者大有帮助。
Q 复制经过多年的发展,已经发布了多个版本,每个版本都提供了不同的功能。如图 1 所示,一个 Q 复制至少包含一对 Q Capture 和 Q Apply 程序。每个源服务器上至少应该创建一组 Q Capture 控制表,而每个目标服务器上则至少应该创建一组 Q Apply 控制表。控制表中记录着 Q 复制的定义、状态、监控等信息。Q Capture 和 Q Apply 程序同时还会各自生成日志记录日常活动。用户一般通过控制表和程序日志来了解当前运行的 Q 复制的版本。
Q 复制中的版本信息
具体来说,Q Capture 端的控制表 IBMQREP_CAPPARMS 和 Q Apply 端的控制表 IBMQREP_APPLYPARMS 中的 ARCH_LEVEL 字段,指明了当前控制表的版本,它通常也是与程序版本一致的。程序版本变化通常也会带来控制表的变化,特别是有同时涉及到 Q Capture 程序和 Q Apply 程序的行为的新功能时,所以这个字段值的变化与程序版本的变化存在一定的联系。Q Capture 和 Q Apply 程序,以及 Q 复制配置、管理工具,通过获取 ARCH_LEVEL 的值来了解当前运行中的控制表的 Schema。例如,ARCH_LEVEL 为 1021,Q 复制程序会认为控制表中所有涉及到 LSN 的列的数据类型都是 VARCHAR(16) FOR BIT DATA。换句话说,Q 复制程序在检测到 ARCH_LEVEL 为 1021 后,会默认以该列为 VARCHAR(16) FOR BIT DATA 这种数据类型来产生 query,以及进行其它操作。而当 Q 复制程序检测到 ARCH_LEVEL 低于 1021 时,他们将以 CHAR(10) FOR BIT DATA 的方式来查询、操作 LSN 相关的列。
与此同时,Q Capture 端的控制表 IBMQREP_CAPPARMS 中还有一个字段叫 COMPATIBILITY。该字段是 Q Capture 程序用来决定以何种协议与目标端的 Q Apply 程序通信的。在一个复杂的复杂拓扑中,一个 Q Capture 程序可能需要与多个不同版本的 Q Apply 程序通信,因此,对于 Q 复制来说,COMPATIBILITY 的值通常需要是目标端所有 Q Apply 的 ARCH_LEVEL 的最小值。也就是说,Q Capture 中,如果 COMPATIBILITY 的值与 ARCH_LEVEL 的值相同,对于 Q Capture 在该 ARCH_LEVEL 上所做的功能、变化,目标端的 Q Apply 程序与 Q Capture 程序至少是同一版本的,它都能够识别并配套使用 Q Capture 程序支持的新功能、新变化。但如果 COMPATIBILITY 的值低于 ARCH_LEVEL 的值,则说明目标端的 Q Apply 程序是低版本的,Q Capture 程序只能使用该低版本 Q Apply 程序支持的或者说能够识别的功能。
通过控制表的这两个字段,用户通常就能了解当前 Q Capture 和 Q Apply 程序的版本,或者准确的说,运行中的版本,因为就如上一段所描述,高版本的 Q Capture 程序可能因为与低版本的 Q Apply 程序配对而使用了与之匹配的低版本的行为。对于准确的程序版本信息,用户可以在 Q Capture 和 Q Apply 程序各自生成的日志中找到。
已有方案的潜在问题
随着市场需求的演变,较长的产品计划与频繁的客户需求之前的矛盾逐渐暴露出来。在一些情况下,新功能、新的控制表变化在没有改变 ARCH_LEVEL 值的情况下被引进来,虽然这些变化的详细描述会被放在产品发布文档中随着产品发布,但这其实已经破坏了上一节所介绍的,Q 复制程序与控制表间的约定,一方面增加了用户的遇到问题的可能性,一方面也加大了产品的维护成本。由于 COMPATIBILITY 是基于 ARCH_LEVEL 的,不清晰的 ARCH_LEVEL 含义也导致了 Q Capture 和 Q Apply 程序之间通信的困难。
另一方面,已有方式下,ARCH_LEVEL 值的变化通常对应与一个大的版本,其中涉及到诸多流程,周期通常比较长,这就大大限制了产品发布新功能的频率。此外,有些客户可能只想拿到最新的产品修复,但一些情况下不得不把产品升级到最新版来获得该修复,因此,产品亟需一种简单但又有效的版本管理方式,既有技术可行性又能满足不同的客户需要。
持续交付功能的设计目标是非常明确的,即在既有功能的基础上,它既能快速发布仅含产品修复的交付物,也能快速发布包含新功能和产品修复的交付物。具体说来,就是:
为了达成以上目标,在最新的 11.4 版本中,引入了三个全新的关于版本的属性 POSSIBLE_LEVEL,用于表明当前程序安装的版本;CONTROL_TABLES_LEVEL,用于表明当前控制表的版本;CURRENT_LEVEL,用于当前程序运行的版本。用户可以使用 Q Capture 程序或 Q Apply 程序的 Activate 参数来指定和激活程序运行时的版本。
持续交付功能的引入,对控制表、Q Capture 和 Q Apply 程序以及相关的配置、管理工具都带来了一系列的变化。
控制表的变化
首先,关于 LEVEL, 无论是 POSSIBLE_LEVEL、CONTROL_TABLES_LEVEL 还是 CURRENT_LEVEL 等与 LEVEL 相关的新增列,我们都统一用一个字符串来表示,格式大致为 RRRR.LLLL,其中 RRRR 代表大版本号,LLLL 代表小版本号,即水平号,例如 1140.0100 代表 11.4 版本下水平为 100 的程序或控制表。
具体说来,在源端控制表 IBMQREP_CAPPARMS 中新增了 POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL。对于 POSSIBLE_LEVEL,Q Capture 程序在每次启动时都会更新该列以保证准确性。CURRENT_LEVEL 必须小于或等于 POSSIBLE_LEVEL、CONTROL_LEVEL。Activate 操作会失败如果指定的水平比 CONTROL_LEVEL 高。对于已存在的 ARCH_LEVEL 将保留原意,但最新只会停留在 1140。而对于 COMPATIBILITY,在 ARCH_LEVEL 为 1140 时,将不再被使用。新增列的具体定义如表 1 所示。
名称 | 位置 | 数据类型 | 取值范围 | 说明 |
POSSIBLE_LEVEL | IBMQREP_CAPPARMS | VARCHAR(10) | 可空,默认值 NULL | 对于安装的 Q Capture 程序可设置的最大的功能水平。 |
CURRENT_LEVEL | IBMQREP_CAPPARMS | VARCHAR(10) | 可空,默认值 1140.0 | 当前运行的 Q Capture 程序所在的功能水平。 |
CONTROL_TABLES_LEVEL | IBMQREP_CAPPARMS | VARCHAR(10) | 可空,默认值 1140.0 | 当前控制表的水平。 |
源端另一张控制表 IBMQREP_SENDQUEUES 中新增了 APPLY_LEVEL。该列在 Q Capture 新安装完成或激活时并不会被更新,而是在 Q Capture 程序收到目标端 Q Apply 程序发来的消息后更新。需要注意的是,Q Apply 程序只会对 CAPTURE_LEVEL 为 1140 或以上的 CG,才会给 Q Capture 程序发送相关的信息。换句话说,当 Q Capture 和 Q Apply 程序在 1140 及以上时,Q Capture 程序在激活 send queue 之前会等待 Q Apply 发送给他的消息,这样 Q Capture 程序才会知道应该给对应的 Q Apply 发送什么格式和版本的消息。对于 Q Apply 程序不可用的而该列还未被正式赋值的情况,用户可手工更新该列并重启 Q Capture 程序。Q Capture 程序会根据此信息发送对应版本的信息,需要注意的是,如果手工设置错误,目标端的 Q Apply 程序接受到了他处理不了的消息,Q Apply 程序将会遵循错误解决机制的设置进行处理。该列的具体定义如表 2 所示。
名称 | 位置 | 数据类型 | 取值范围 | 说明 |
APPLY_LEVEL | IBMQREP_SENDQUEUES | VARCHAR(16) | 非空 | 该 send queue 对应的目标端 Q Apply 程序所在的功能水平。这个值与目标端的控制表 IBMQREP_APPPLYPARMS 中的 CURRENT_LEVEL 列的值一致。 |
相应地,在目标端,控制表 IBMQREP_APPLYPARMS 中新增了 POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL。相关列的含义与 IBMQREP_CAPPARMS 相似。新增列的具体定义如表 3 所示。
名称 | 位置 | 数据类型 | 取值范围 | 说明 |
POSSIBLE_LEVEL | IBMQREP_APPLYPARMS | VARCHAR(10) | 可空,默认值 NULL | 对于安装的 Q Apply 程序可设置的最大的功能水平。 |
CURRENT_LEVEL | IBMQREP_APPLYPARMS | VARCHAR(10) | 可空,默认值 1140.0 | 当前运行的 Q Apply 程序所在的功能水平。 |
CONTROL_TABLES_LEVEL | IBMQREP_APPLYPARMS | VARCHAR(10) | 可空,默认值 1140.0 | 当前控制表的水平。 |
而在控制表 IBMQREP_RECVQUEUES 中新增了 CAPTURE_LEVEL。该列的情况与 APPLY_LEVEL 类似。在 Q Apply 程序安装或激活时,该列并不会更新,而是在 Q Apply 程序接受 Q Capture 程序发送来的消息后被 Q Apply 更新。需要注意的是,与 CAPTURE_LEVEL
同,我们并不建议用户手工更新该列,我们必须依赖 Q Apply 程序接收到 Q Capture 程序后正确设置该值,否则会引发不控的错误。该列的具体定义如表 4 所示。
名称 | 位置 | 数据类型 | 取值范围 | 说明 |
CAPTURE_LEVEL | IBMQREP_RECVQUEUES | VARCHAR(16) | 可空,默认值 NULL | 该 receive queue 对应的源端 Q Capture 程序所在的功能水平。这个值与源端的控制表 IBMQREP_CAPPARMS 中的 CURRENT_LEVEL 列的值一致。 |
ASNCLP 新功能及语法变化
首先,为了生成上节介绍的控制表的变化,对于已有的 CREATE CONTROL TABLE 命令,对 RELEASE 参数增加了对主机平台的支持,用户需要显示地指定 RELEASE LEVEL "11.4.0" 来获得 1140 水平的控制表。具体语法如清单 1 所示。:
- >>-CREATE CONTROL TABLES FOR------------------------------------>
- >--+-CAPTURE SERVER--+--------------------------------------------------------------+-+-->
- | '-| proxy-clause |-- USING--| capparms-clause |--|
- +-APPLY SERVER--+------------------------------+-------------------------+
- | '-USING--| applyparms-clause |-'
- proxy-clause
- |--AS PROXY WITH REMOTE SOURCE DBNAME--zdbname------------------|
- node-options
- |--+--------------------------------+--+----------------------------------+--|
- '-CAPPARMS--| capparms-clause |-' '-APPPARMS--| applyparms-clause|-'
- capparms-clause
- |--+----------------------------+--------------->
- '-RELEASE--"capture_release"-'------------'
- ----->
- applyparms-clause
- |--+--------------------------+--------------->
- '-RELEASE--"apply_release"-'------------'
- ----->
捕获和应用程序的新参数
在已发布的 11.4 的第一个版本中,Q Capture 程序和 Q Apply 程序的启动参数加入了一个新的启动参数 ACTIVATE,如清单 2 所示。在确保控制表里的各项配置与预期匹配的情况下,用户在启动 Q Capture 程序和 Q Apply 程序时可通过 ACTIVATE 参数指明运行时的程序版本。
- >>-asnqcap--capture_server=db_name--+-----------------------+--->
- '-capture_schema=schema-'
- >--+-------------------+--+--------------------+---------------->
- '-capture_path=path-' '-activate=rrrr.nnnn-'
- >-->
- >>-asnqapp--apply_server=db_name --+---------------------+------>
- '-apply_schema=schema-'
- >--+-----------------+--+--------------------+------------------>
- '-apply_path=path-' '-activate=rrrr.nnnn-'
- >-->
其它变化
为了进一步支持持续交付功能,在后续版本中将会提供更多的方法方便用户在不同功能水平之间灵活变换。
本节将通过三个具体的常见场景,介绍该功能的使用。包含给 Q Capture 程序或 Q Apply 程序打补丁,启用 Q Capture 程序或 Q Apply 程序的新功能,启用涉及 Q Capture 程序和 Q Apply 程序的新功能。其它更为复杂的场景,都可以通过分解归结为这三种场景的情况。
场景 1: 客户只想给 Q Capture 程序或 Q Apply 程序打一个补丁
当前 Q 复制的运行版本是 300,也就是说对于 Q Capture 程序 POSSIBLE_LEVEL 为 1140.300,CURRENT_LEVEL 为 1140.300,CONTROL_TABLES_LEVEL 为 1140.300,APPLY_LEVEL 也是 1140.300,也就是说 Q Capture 程序和 Q Apply 程序之间的通信是使用版本 300 的格式和消息。此时,客户发现并报告了一个 Q Capture 的问题,而后被告知该问题的补丁已包含在功能版本 800 中。在这种情况下,客户需要做的是在 Q Capture 端安装版本为 800 的代码,重启 Q Capture 程序即可。注意此时,Q Capture 程序的 POSSIBLE_LEVEL 自动更新为 1140.800,而 CURRENT_LEVEL、CONTROL_TABLES_LEVEL 仍为 1140.300,由于 Q Apply 程序并没有发生任何变化,APPLY_LEVEL 也仍是 1140.300,也就是说尽管 Q Capture 端安装了新程序,补丁已经生效,Q Capture 程序和 Q Apply 程序之间的通信也仍然是使用版本 300 的格式和消息。另外,即使有若干水平 300 以上的新功能已经包含先当前的代码中,因为 CURRENT_LEVEL = 1140.300 并没有发生变化,新增加的功能也不会在当前运行的程序中被打开,从而可以有效控制新加的功能对客户现有业务处理产生影响。
同样,如果 Q Capture 端没有问题,客户是在 Q Apply 端发现了一个问题,而后被告知问题在版本 800 中得到了解决。客户只需在 Q Apply 端安装新代码,重启 Q Apply 使之生效。注意此时,只是 Q Apply 端的 POSSIBLE_LEVEL 发生了变化,自动更新为 1140.800,其它功能水平相关的参数并未发生变化,Q Capture 程序和 Q Apply 程序之间的通信也仍然是使用版本 300 的格式和消息。
场景 2: 客户想启动 Q Capture 程序或 Q Apply 程序的一个新功能
假设当前 Q 复制运行在版本 300 上,即在 Q Capture 端,POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL 为 1140.300,APPLY_LEVEL 也是 1140.300;而在 Q Apply 端,POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL 为 1140.300,CAPTURE_LEVEL 也是 1140.300, Q Capture 程序和 Q Apply 程序之间的通信是使用版本 300 的格式和消息。此时,客户被告知某个 Q Capture 的新功能包含在版本 600 中。客户需要做的是:
注意在这种场景中,Q Apply 端并未发生变化,Q Capture 程序和 Q Apply 程序之间的通信仍然是使用版本 300 的格式和消息。但 Q Capture 端的版本 600 的新功能已启用。通常针对的是一些 Q Capture 程序的性能改进等。以上步骤同样适用于仅启动 Q Apply 程序新功能的情况。
场景 3: 客户想启动一个端到端的新功能
同样假设当前 Q 复制运行在版本 300 上,即在 Q Capture 端,POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL 为 1140.300,APPLY_LEVEL 也是 1140.300;而在 Q Apply 端,POSSIBLE_LEVEL、CURRENT_LEVEL、CONTROL_TABLES_LEVEL 为 1140.300,CAPTURE_LEVEL 也是 1140.300, Q Capture 程序和 Q Apply 程序之间的通信是使用版本 300 的格式和消息。此时,客户被告知某个新功能包含在版本 600 中,当前的最新版本是 800。客户打算安装最新版本的代码,但只想要启动水平 600 上的新功能,这种情况下,客户需要做的是:
本文首先回顾了 Q 复制的简单配置以及其中关于版本的信息和使用方法,进而提出了当前面临的大环境下的快速持续交付的挑战,提出了产品的改进方案,而后具体介绍了产品关于持续交付功能的实现和使用方法,希望对使用新版本、新模式的用户有帮助。随着产品的不断演进,相信的更多的新功能、新方法也会通过持续交付的方式提供给用户。
来源: http://www.ibm.com/developerworks/cn/analytics/library/ba-cn-infosphere-data-replication-zos-continuous-delivery/index.html