我们利用 DB2 所提供的 ">Tivoli System Automation (TSA) 功能来自动化在发生故障时对 Q Replication 的重新启动。
在使用 TSA 时，您是在一个已定义的资源组上使用命令管理复制操作，而不是显式调用 asnqcap 和 asnqapp 程序。例如，如果一个定义将 Q Capture、Q Apply 和队列管理器划分到为一个名为“ibmqrep-rg”的命名资源组中，那么您可以使用 TSA 更改资源组 (chrg) 命令使此资源组上线，从而在该站点上开始复制。可从该站点的任何成员执行此操作：
chrg –o online ibmqrep-rg
通过使该资源组离线来停止复制：
chrg –o offline ibmqrep-rg
该资源组离线后，您就可以通过锁定它让其摆脱 TSA 的控制，这使您能够在 TSA 外部停止和启动程序。有时这对测试很有用，比如在实验不同的 Q Capture 运行时参数时。
rgreq -o lock ibmqrep-rg
要解锁一个资源组并将控制权交回给 TSA，可以使用以下命令：
rgreq –o unlock ibmqrep-rg
配置 TSA 需要：
1) 定义资源和资源之间的依赖关系。例如，Q Replication 程序具有对队列管理器的依赖关系和对可用的 DB2 的依赖关系。
2) 配置 TSA 还需要使用脚本来监视复制程序是否可正常运行，以及是否启动/停止它们。
我们在“附录 5：使用 TSA 自动化 Q Replication 故障转移”中提供了资源定义和脚本。下图显示了我们用来自动化 pureScale 环境中的 Q Replication 故障转移的依赖关系：
图 9：用于自动化 Q Replication 故障转移的依赖关系
Q Replication 主要依赖 DB2。Q Replication 可从任何成员使用 DB2，所以我们定义影子资源来监视 DB2 实例。如果运行队列管理器和 Q Replication 服务器的一个节点上的 DB2 成员发生故障，这些服务器（队列管理器和 Q Replication 服务器）会在仍在运行 DB2 成员实例的另一个节点上启动。如果运行队列管理器和 Q Replication 程序的节点出现故障，它们会在另一个节点上重新启动。