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