| 简介：
DB2? 高可用性灾难恢复 (HADR) 是 IBM? DB2 for Linux, UNIX, and
Windows的一个易于使用的数据复制功能，为部分和整个站点故障提供高可用性 (HA) 解决方案。从 DB2
V9.5 Fix Pack 8 和 DB2 V9.7 Fix Pack 5 开始，引入了一个名为 SUPERASYNC
的全新 HADR 同步模式。本文将介绍 SUPERASYNC 模式的用途、使用该模式的一个 HADR 对的部署以及该模式下的备用状态转换。此外，本文还将提供一些用例场景，解释用于灾难恢复的
SUPERASYNC 模式的实现。本文将查看主要数据库如何克服背压，如何在具有单个备用数据库或多个备用数据库的情况下提供良好表现，以及使用此模式的优缺点。
简介和背景
HADR 是一个通过数据复制提供高可用性和灾难恢复的 DB2 功能。在启用该功能时，可以将主要数据库数据日志实时传送到
备用数据库。备用数据库继续重放已收到的日志，以便与主要数据库保持同步。
从 DB2 V9.5 Fix Pack 8 和 DB2 V9.7 Fix Pack 5 开始，SUPERASYNC
被指定为 hadr_syncmode，这样主要数据库在任何情况下都不会受阻。
本文将介绍 SUPERASYNC 模式的用途、如何在该模式中设置 HADR，以及该模式下不同的备用数据库的转换状态。本文提供了实现
SUPERASYNC 模式的用例，还介绍了使用它的优缺点。
SUPERASYNC 模式的用途
您可能会面对主要数据库受阻塞的问题，这是因为备用端日志重播缓慢所导致的，而备用端日志重播缓慢是因为备用系统缺少资源以及出现网络暂停。引入
SUPERASYNC 模式可以预防各种因为网络暂停或缓慢执行待机而导致的主要数据库背压（减慢/阻碍事务处理）。
HADR 如何在 SUPERASYNC 模式下工作
在 SUPERASYNC 模式下，HADR EDU 在后台进行日志发送，并且不会干扰事务处理的代码路径，这意味着日志发送不在提交事务的范围内。因此，它不会阻止主要数据库运行事务处理。
HADR 对永远不会进入 Peer 状态或 Disconnected Peer
状态。HADR 状态将逐渐从 local catch up 变为 remote catch up，然后停留在remote
catch up。HADR 总是从磁盘或归档日志的主要数据库发送日志。它不需要进入 Peer 状态，其中日志是从主要数据库日志缓冲区发送的，并且主要数据库日志的写入程序将会变缓。
在与图 1 所示的其他同步模式进行比较时，此模式提供了最佳性能。
图 1. SUPERASYNC 中的 HADR
的工作原理
主要数据库将日志记录写入主要数据库的日志文件。
然后提交事务，无需等待将日志复制到备用数据库。
在 SUPERASYNC 模式下设置 HADR 对
要在 SUPERASYNC 模式下设置 HADR 对，可以使用清单 1
至清单 3 所示的 SUPERASYNC 参数更新 HADR_SYNCMODE db cfg 参数。
清单 1. 更新 HADR_SYNCMODE
$ db2 update db cfg for hadrdb using HADR_SYNCMODE SUPERASYNC
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, the database
must be shutdown and reactivated before the configuration parameter changes
become effective. |
清单 2. 停用数据库
$ db2 deactivate db hadrdb
DB20000I The DEACTIVATE DATABASE command completed successfully.
|
清单 3. 激活数据库
$ db2 activate db hadrdb
DB20000I The ACTIVATE DATABASE command completed successfully.
|
使用 MON_GET_HADR（V9.7 中可能没有提供）表函数或有
-hadr 选项的 db2pd 命令监控主要数据库或备用数据库的状态。
例如，
SUPERASYNC 模式下的 HADR 状态转换
如图 2 所示，在启用备用数据库时，数据库将会进入 Local catchup
状态并读取本地日志路径上可用的日志文件。在读取本地日志文件之后，备用数据库将进入 Remote catchup
挂起状态，并等待主要数据库的连接。一旦主要数据库连接到备用数据库，它们将保持 Remote catchup
状态而且不再进入 Peer 状态，以避免产生主要数据库背压。
图 2. SUPERASYNC 模式下的备用数据库状态
当主要数据库和备用数据库在 SUPERASYNC 模式下建立连接时，备用数据库的状态将是图
3 所示的 RemoteCatchup。
图 3. 备用数据库的状态是 Remote
catchup
备用数据库不可用时，主要数据库的状态将为 Disconnected，如图
4 所示。
图 4. 备用数据库不可用时，主要数据库的状态是断开连接
当备用数据库与主要数据库断开连接时，备用数据库的状态将是 RemoteCatchupPending，如图
5 所示。
图 5. 备用数据库的状态是 RemoteCatchupPending
SUPERASYNC 在 DB2 灾难恢复场景中进行配置
以下小节描述了可以将 SUPERASYNC 配置为 hadr_syncmode
的用例场景，以及其如何帮助灾难恢复实现更好的主要数据库性能。
使用 HADR 和 HA 通过集群服务实现 DB2 灾难恢复
下列场景适用于 DB2 V9.7。
例如，在 Location 1 中建立主要数据库可以在使用 TSA 或
HACMP 集群服务的两台机器（M1 和 M2）之间实现高可用性。在 Location 2 中建立备用数据库，以便在
SUPERASYNC 模式下使用 HADR 复制过程实现灾难恢复，如图 6 所示。
图 6. 使用 SUPERASYNC 的灾难恢复
用户应用程序在主要数据库（如 M1）上连接并执行事务。日志将从 M1
发送到备用数据库。由于备用数据库是在 SUPERASYNC 模式下建立的，所以不会因为它远离主要数据库（高网络延迟）或网络暂停而产生主要数据库背压。因此，主要数据库性能比较好。
如果主要数据库（Location 1 中）上的 M1 速度下降，那么集群服务将会启动启用另一个设置为高可用性的节点（如
Location 1 中的 Machine M2）。
在完成 HA 故障转移之后，会通过 HADR 复制过程将日志从 M2 发送到备用数据库。如果
Location 1 速度下降（M1 和 M2 均下降）。备用数据库将被作为主要数据库启用。通过这种设置，您可以获得数据库高可用性最佳性能和数据库恢复，从而防止灾难发生。
在 SUPERASYNC 模式下使用 HADR 建立多个备用数据库来实现灾难恢
下列场景适用于 DB2 V10.1
在有多个备用数据库的 HADR 中，可拥有多达三个备用数据库，这是 DB2
V10.1 中的一个新功能。其中一个数据库可设计为 主要备用数据库（支持所有 HADR 同步模式），其他两个用作辅助备用数据库（只支持
SUPERASYNC 模式）。主要备用数据库在相同位置可部署为主要数据库。辅助备用数据库是远程进行部署的，可以为主要数据库和主要备用数据库提供保护，防止灾难发生。
以下是在 SUPERASYNC 模式下使用 HADR 建立多个备用数据库来实现灾难恢复的两个可能场景。
1、场景 1：使用 HADR 实现 DB2 高可用性灾难恢复
2、场景 2：使用 HADR 实现 DB2 高可用性和多个灾难恢复
场景 1：使用 HADR 实现 DB2 高可用性和灾难恢复
在该场景中，在 Location 1 上使用了 TSA 集群服务在主要数据库和主要备用数据库之间设置高可用性。辅助备用数据库被设置为实现
Location 2 上的灾难恢复，如图 7 所示。
图 7. 使用多个备用数据库实现高可用性和灾难恢复
用户应用程序在主要服务器上连接并执行事务。事务日志将从主要服务器发送到主要备用服务器和辅助备用服务器。因为辅助备用服务器是在
SUPERASYNC 模式下建立的，所以不会因为它远离主要服务器（高网络延迟）或网络暂停而在主要服务器上产生任何背压。
如果出现主要服务器中断，那么主要备用服务器将被作为主要服务器而使用集群服务
(TSA) 自动启用，现在新的主要服务器会将日志发送到 Location 2 的备用服务器上。
如果 Location 1 上发生灾难（主要服务器和主要备用服务器同时停机），那么
Location 2 上的备用服务器可作为主要服务器启用。因为您在灾难恢复站点上使用了 SUPERASYNC
模式，所以在主要服务器上可以通过避免因远距离或网络延迟而产生的背压来实现最佳性能。
场景 2：使用 HADR 实现 DB2 高可用性和多个灾难恢复
该场景中，可以在 Location 1 上使用 TSA 集群服务在主要服务器和主要备用服务器之间建立高可用性。对于灾难恢复，可在
Location 2 上建立辅助备用服务器 1，在 Location 3 上建立辅助备用服务器 2，如图
8 所示。
图 8. 使用多个备用服务器实现高可用性和多个灾难恢复
用户应用程序在主要服务器上建立连接并执行事务。事务日志从主要服务器传送到主要备用服务器，同时也传送到两个辅助备用服务器上。因为辅助备用服务器是在
SUPERASYNC 模式下建立的，所以不会因为距离或网络延迟而影响主要服务器上的活动。
如果主要服务器发生故障，那么会通过使用集群服务 (TSA) 自动启用主要备用服务器作为主要服务器，并且将日志从新的主要服务器发送到其他备用服务器。
如果在 Location 1 上发生灾难，其中一个辅助备用服务器将作为主要服务器启用，同时应用程序会连接到这个新的主要服务器，并将日志从新的主要服务器发送到其余备用服务器。因为您在灾难恢复站点上使用了
SUPERASYNC 模式，所以在主要服务器上可以通过避免因远距离或网络延迟产生的背压来实现最佳性能。
结束语
在本文中，您已经了解了使用 SUPERASYNC 模式的优点和缺点，分别是：
在 SUPERASYNC 模式下，事务响应时间比其他所有同步模式的时间都短。但是，如果主要系统发生故障，那么造成事务损失的可能性最大。如果您不想让主要系统上的事务因网络问题而受阻或遭遇更长的响应时间，那么该模式非常有用。
主要数据库上的事务提交不受 HADR 网络或备用服务器的影响。这可能导致主要数据库和备用数据库间的日志空白
(log gap) 不断增加。较大的日志空白会导致漫长的恢复时间。如果灾难发生在主要系统上，那么日志空白中的所有数据都将丢失。因此，使用
hadr_log_gap 监控元素或 db2pd –hadr 命令监控日志空白十分重要。如果您观察到无法接受的日志空白，那么应该调查网络性能或备用数据库的相对速度，并采取纠正措施来控制日志空白。
|
