为了使团队成员在分布式环境中共享需求管理以及缺陷跟踪等资产，IBM Rational ClearQuest提供了ClearQuest Multisite, 一个跨越多地点对本地数据存储同步化的工具。分布在不同地区的数据库会定期地自动或者人工同步，这使得数据的更新更加简单易行。同时Multisite机制也可以为本地数据提供备份，这是它的另外一种应用场景。

1.0 ClearQuest Multisite安装

　　使用ClearQuest Multisite，必须安装Rational ClearQuest Administration Tools，Rational ClearQuest MultiSite Administration Tools以及Rational Shipping Server。Rational ClearQuest Multisite使用shipping server在不同站点间传递数据包(packet)。在Windows上，用户可以在安装ClearQuest时，选择这些组件，如图1所示。
图1 在Windows上选择组件安装IBM Rational ClearQuest Multisite

　　Rational ClearQuest MultiSite Administration Tools和Rational ClearQuest Administration Tools只运行于Windows上，那么当在UNIX/Linux上安装ClearQuest Multisite时，该如何选择及安装组件，使得ClearQuest Multisite正常工作呢？如同ClearQuest需要一台Windows的主机做辅助来帮助建立数据库连接一样，ClearQuest Multisite也同样需要这台主机，用于在Windows上安装Rational ClearQuest MultiSite Administration Tools和Rational ClearQuest Administration Tools，同时在UNIX/Linux上安装ClearQuest。

2.0 ClearQuest Multisite术语说明

　　在ClearQuest的应用中，用于存放资源数据的数据库集(database set)，必须用到两种物理数据库的类型：模式库(schema repository)和用户数据库(user database)。因此Multisite中对数据库集的复制，就是同时对这二者的复制。在了解ClearQuest Multisite的结构之前，我们对一些常见的术语做简单的说明。

　　site: 某模式库的一个复本和相关联的一个或多个用户数据库复本。

　　clan: 某模式库的所有复本以及相关联的用户数据库的所有复本。

　　family: 某个用户数据库(user database)的所有复制集，或者某个模式库(schema repository)的所有复制集。对于用户数据库的复制，family的名称就是原用户数据库的名称（比如SAMPL）, 而对模式库的复制而言，family的名称统一为MASTER。

3.0 ClearQuest Multisite实现思路

　　ClearQuest Multisite的复制和同步的实现过程基本上是一致的。它们都由以下三个主要过程组成：

　　源站点数据导出
　　站点间数据包传输
　　目标站点数据导入
　　如图2所示。源站点和目标站点都是相对的概念，当第二个站点发生了更新，需要同步到第一个站点时，第二个站点就称为我们这里所说的源站点了。
图2 复制同步原理

在Multisite实施过程中，站点之间的同步关系可以采用多种灵活的模式。根据用户的特点，可以自行选择配置。这里展示常见的几种类型。

3.1 简单模式

一对一模式（图3）和环形模式（图4）是相对简单的模式。

图4环形模式

这两种模式适合于复本数量不多的情况，随着复本数量的增多，数据复本可能需要经过多个站点间的传递才能到达并更新本地的数据，数据传递的时间也会随之增加，因而同步的时间差就会增大。

3.2 一对多模式

一对多模式里面，有很多分类，可以是单中心点模式、多中心点模式（图5），也可以是树形模式（图6）。

图5 多中心点模式

图6树形模式

　　中心点模式通过中心点复本与辐射节点复本交换数据，树型模式通过根节点复本与枝叶节点复本交换数据，一对多模式通过比简单的环形的模式的好处在于，它们都通过一个或多个主要的站点复本交换数据，这样就比简单模式提高了同步的效率。但是缺点也很显然，如果中心点复本或者根节点复本所在站点出现意外，就会影响整个同步网络的正常工作。

　　除此之外，还有多对多模式，在这种模式中，每个复本都和其他所有的复本交换数据，好处是使得站点间的同步最大可能地消除差别，保持一致，同时某站点的暂时不可用，也不会影响全局。然而它占用了相当的时间用于站点间的数据交换。

　　究竟采用什么样的结构，需要根据站点的数量，重要性等特点进行定制，寻求数据同步和同步服务器性能的平衡点。

4.0 ClearQuest Multisite操作

4.1 数据库复本创建

　　创建数据库的复本，包括以下几个步骤:

　　1．存储转发配置 如果使用存储转发(store-and-forward)机制，必须首先在导出和导入的复制上进行配置。在Windows和UNIX平台上，操作有所不同。Windows上通过Multisite控制面板配置，UNIX上通过修改shipping.conf文件配置。

　　2．激活数据库集 首次对某数据库集的复制操作前，必须激活该数据库集。

　　3．导出 通过导出命令，产生用于创建复本的数据包。

　　4．传递 将创建复本的数据包发送到一个或多个其它目标站点

　　5．数据库创建 在新复本产生处，创建空的模式库和用户数据库，用于接受待导入数据。

　　6．导入 在新复本产生处，导入创建复本的数据包。

　　下面就将详细描述各个步骤。

4.1.1 存储转发配置

　　Rational Shipping Server为Multisite提供了直接的存储转发功能，使得数据包在不同站点间的传送能够自动地执行。只要安装了这个组件，在Windows平台上，打开控制面板，就可以看到Multisite图标，双击此图片，进行必要的配置。为了简化操作，这里只做必须的修改，如图7所示。

1. 创建一个存储类(storage class)

　　ClearQuest Multisite管理工具multiutil命令通过-sclass参数指定cq_default类供没有指定存储类的数据包使用。但是在Multisite安装后，cq_default类并没有自动创建。因此我们首先需要创建这个类。

　　2. 为cq_default存储类指定存储池路径(storage bay path) 我们可以在C：盘创建bay目录，并把它作为存储池路径C:\bay。这里需要注意，如果你正在同时使用ClearCase Multisite和ClearQuest Multisite，你必须为vob的复本数据包和ClearQuest数据库的复本数据包指定不同的路径。设置确定后，incoming和outgoing目录就已经在存储池目录下自动生成了，用于存放转发或者接收的数据包。

图7 存储转发配置

　　在UNIX和Linux平台上，通过修改shipping.conf文件来进行如上的配置。通常，该文件位于ccase-home-dir/config/shipping.conf。找到存储池路径(storage bay)和返回池路径(return bay)的设置语句：

4.1.2 数据库集激活

　　在创建数据库集合的第一个复本之前，必须先激活该数据库集合。

　　激活数据库集合，通过activate命令实现。只需要激活一次，以后就可以对该数据库进行多次复制。命令格式如下：

　　在激活操作后，数据库集合的名称也会被自动地更改为CQMS.<clan name>.<site name>，在本例中，就是CQMS.RATLC.SITEBJ。如图8所示。

图8 激活后数据库集合的名称改变

4.1.3 导出复本创建数据包

　　在将要被复制的数据库集所在的站点上，通过mkreplica -export命令产生创建复本的数据包，并将它发送到将要产生复本的站点上去。需要注意的是，在导出的过程中，该导出命令将会锁定数据库集，任何登录请求都将被禁止。所以在此操作前，要检查确认没有用户正在登录，否则，所有在导出前登录所做的修改，都将在命令结束释放锁定后丢失。还有一点需要注意的是，ClearQuest数据的代码页（code page）必须和待导入复本创建包所在站点的代码页一致，如果不兼容，也会导致导入时的失败。命令格式及运行结果：

workdir指定了一个工作目录，这个目录不能是已经存在的，操作者对它要有写权限，而且它的空间大小要充足。hostB是目标站点上的同步服务器。

4.1.4 传递数据包

　　前面提到，我们用shipping server可以将数据包自动地发送到目标站点上。根据导出操作的命令选项不同，传送的方式有所不同。

-fship：如果导出命令中使用-fship参数，数据包被立刻发送到目标站点上；
-ship：如果是-ship参数，则必须通过传送服务器(shipping_server)来发送，比如命令：shipping_server -sclass cq_default -poll 。
-out：如果使用-out参数，这意味着packet被写到了文件上，因此需要我们自己将该文件传送到目标上。我们可以利用电子邮件、ftp甚至其它物理媒介作为数据包传送的工具，这里不再详细描述。
4.1.5 创建空的数据库

　　在目标站点上，必须预先创建空的后台数据库准备容纳模式库和用户数据库的复本数据。这里要强调，一定不要预先使用ClearQuest Maintenance Tool或者ClearQuest Designer创建ClearQuest数据库，因为导入数据包时，命令会自动创建。

4.1.6 导入复本创建包

　　导入操作在目标站点上进行。如果使用的是-fship参数，首先我们要确定数据包已经被发送到这个站点上来。命令格式及运行结果：

　　如果命令结果正确显示了数据包，我们就可以接着进行下面的操作了。

　　由于复本创建数据包里面包含了与数据库类型无关的数据信息，导入操作首先要创建ClearQuest数据库，然后将包内数据信息存放到新数据库中。命令格式及运行结果(示例中采用SQL_SERVER数据库)：

　　导入成功后，复本创建包就可以被删除了。

4.2 数据库复本同步

　　数据库的同步在复本创建后，需要经常地进行，以保持数据的一致性。同步操作和复本创建的过程类似，主要包括导出、传送、导入三个过程。导出过程在一个复本上利用syncreplica命令和-export参数创建一个数据包；传送过程将这个数据包发送到其他的一个或多个复本；而导入过程利用带有-import参数的syncreplica命令将数据包的内容应用到当前的复本。命令格式：

　　在siteBJ上导出数据包

　　在siteSH上导入数据包：

　　这里需要注意的一个问题是：当原站点上的模式（schema）的版本升级后，在目标站点上运行syncreplica -import命令会产生错误提示：

　　这说明必须首先升级目标站点上的用户数据库，然后再次运行syncreplica命令。

　　由于篇幅所限，本文不讨论自动同步。

5.0 Mastership管理

　　由于multisite机制，多个复本同时存在，必然会产生修改冲突。为了避免数据损坏，同时跟踪和管理变更，multisite采用了"独占更改权"规则，这就是mastership机制，这意味着用户只可以更改主复本(master replica)中的数据。大多数ClearQuest数据库中的对象都有自己的主复本, 它往往就是这个对象被创建时所属的复本。一般说来，一个对象只能在它的主复本上被修改和删除。但是哪个复本是主复本是可以更改的。

　　如果在ClearQuest查询结果的某个记录里显示了一个锁形标记，那么说明当前的复本并非这个记录的主复本，如图9所示。那么如何改变主复本呢？有两种方式：命令行修改和图形界面修改。它们的执行思路是一样的：
图9 Mstership不是本地站点时，记录显示锁型标记

　　1． 在主复本中，修改该对象的mastership为目的复本；

　　2． 在原主复本中，导出一个变更数据包到目的复本；

　　3． 在目的主复本中，导入这个数据包。

5.1 通过GUI界面改变某记录的Mastership

　　记录中有个系统保留字段ratl_mastership, 这就是指明主复本的字段，只要在主复本上修改这个字段可以了。但是通常这个字段并没有显示在记录细节中，必须由用户将它手工添加到记录类型的显示窗体里面，并且检入模式（schema），升级用户数据库。如图10所示。当然，最后不要忘了在原主复本上导出变更数据包，然后在新主复本上导入数据包。

图10 用GUI方式改变Defect的Mastership

5.2 通过chmaster命令改变某记录的mastership

　　用命令方式修改mastership更为一目了然。例如将标识为SAMPL000013的缺陷的主复本从siteBJ更改到siteSH，命令如下：

　　1． 在主复本上（siteBJ），键入chmaster命令

　　 2． 在原主复本上，导出变更数据包

　　 3． 在新主复本上，导入变更数据包

　　 4． 在新主复本上，验证更改已经成功

总结

　　本文介绍了IBM Rational ClearQuest MultiSite的基本概念及其安装、配置、激活、创建复制站点、同步、Mastership管理等实际操作。希望对读者能有所帮助。

免责说明

　　本文档是作者在实际工作中总结的经验，仅仅代表个人观点，请以参考及怀疑的观点阅读。任何由此造成的损失，作者不承担责任。谢谢！
参考文档

　　IBM Rational ClearQuest MultiSite Administrator's Guide