数据的重要性在现今信息化社会变得尤其突出，数据库系统也成为了企业在IT投资中最关心的课题。DB2作为传统的关系型数据库， 在本地高可用和异地容灾的手段选择上，已经产生了很多经久验证的解决方案。
DB2在本地高可用的解决方案里面用的比较多的是使用HACMP，TSA等集群软件管理主备机，主备机挂载同一存储。这种方案在HA的切换时间上其实并不是最好的。备机在HA接管的过程中需要做一系列的接管和激活操作,例如挂载存储,启动实例,激活数据库等。现在企业越来越倾向于使用DB2 pureScale集群来替换现有的HA策略。DB2 pureScale的成员节点都是激活的，客户端也能够自动接管。所有这些对于应用都是透明的。
DB2的异地容灾解决方案一般会使用DB2的HADR功能。HADR在单机版的DB2环境中应用非常广泛，几乎是企业在选择DB2的容灾解决方案中唯一考虑的方案。从DB2 V10.5版本开始，DB2 pureScale功能和HADR功能能够共存。
所以对于对本地高可用和异地容灾有需求的企业，DB2 pureScale 加上HADR就成为了最佳的解决方案。 下面我来介绍下这个方案的一些技术特点。
DB2 pureScale集群HADR特性介绍
DB2 pureScale是典型的数据库集群架构，多个成员同时为一个数据库服务。每个成员会记载各自的日志。HADR是基于日志传输的同步手段，在存在多个成员日志的情况下，备集群的成员需要合并日志流，然后重放，从而达到同步的功能。
DB2 pureScale集群HADR容灾架构
在DB2 pureScale集群HADR容灾架构的体系中，备端也需要是DB2 pureScale集群。并且备集群的成员数量要大于或等于主集群的成员数量。这是因为在现有的体系架构下，对于所有在主集群的成员ID，备集群需要有同样的ID的成员结构才能做日志回放。
图1. DB2 pureScale HADR架构
Replay Member概念
从图中可以看出DB2 pureScale环境下HADR的实现机制。在备集群，只有一个成员会执行重做的工作。所有的日志流都是通过TCP/IP网络传输至此成员。所以选取合适的Replay Member非常重要。备集群的Replay Member可以安排资源比较充分的节点。例如可以选择分配更多的CPU和内存资源给这个LPAR。
Replay Member是一个逻辑的概念，仅仅是指在做回放的成员。用户可以指定偏好的成员来成为Replay Member。这种又称之为Prefer Member，意思是尽可能选择这个prefer的member上做Replay Member。
DB2 pureScale集群HADR的容灾架构中，备集群的Replay Member上数据库是激活并工作的。其他的成员上该数据库是非激活状态。Replay Member这个角色在pureScale集群里面同样具有高可用性。一旦当前的Replay Member出现故障，DB2会在集群里面其他的成员上选择一个激活数据库，成为新的Replay Member。在选择的过程中，如果有prefer member，就会选择prefer member。如果故障的是prefer member，则随机选择一个。所以prefer member并不是强制的概念。Replay Member也可以是任何一个成员。
DB2 pureScale集群HADR同步模式
HADR 同步方式确定高可用性灾难恢复 (HADR)数据库解决方案对事务损失的保护程度。同步方式决定主数据库服务器根据备用数据库上记录的状态，何时认为事务已完成。 同步方式配置参数值越严格，数据库解决方案就越能防止事务数据丢失，但事务处理速度也越慢。所以必须在防止事务丢失的需求与对性能需求之间取得平衡。
普通HADR同步模式主要有四种：SYNC（同步），NEARSYNC（接近同步），SUPERASYNC（超级异步）和 ASYNC（异步）。在DB2 pureScale环境下暂时只支持其中的两种同步模式：SUPERASYNC（超级异步）和 ASYNC（异步）。
现在DB2 pureScale集群暂时只支持异步和超级异步这两种模式，需要考虑数据丢失的可能性。因为主数据库上的事务落实操作不会受到相对较慢的 HADR 网络或备用 HADR 服务器的影响，所以主数据库与备用数据库之间的日志间隔可能会继续增大。监视日志间隔很重要，这是因为在主系统上发生真正的灾难时，日志间隔是可能丢失的事务数的间接度量。在灾难恢复方案中，日志间隔期间落实的任何事务都对备用数据库不可用。因此，请使用 hadr_log_gap 监视元素来监视日志间隔；如果出现日志间隔不可接受的情况，请调查网络中断次数或备用数据库节点的相对速度，并采取纠正措施以减小日志间隔。
在现有的DB2 pureScale仅支持SUPERASYNC和ASYNC的情况下，为了数据的安全性考虑，推荐使用ASYNC模式。如果在多点容灾的情况下，其他点采用SUPERASYNC。
DB2 pureScale集群HADR切换方式
与普通单机版DB2数据库的HADR功能一样，DB2 pureScale集群下的HADR功能延续了简单易用的切换方式。仅仅是一条takeover命令，就可以完成整个数据库的主备切换。切换的效率非常高，同时切换过程中也进行的数据的保护，杜绝各种脑裂等情况的发生。DB2 pureScale集群下的HADR的切换也分为正常切换和强制切换这两种。
在主备集群相连通的情况下，正常切换会先关闭原主端的数据库，备端接受完全部日志并回放完成后变为新的主端，原主端会激活数据库变为新的备端，整个切换过程就完成了，数据库也可以提供服务了。HADR也正常工作。
在主备集群相连通的情况下，强制切换会强行关闭原主端的数据库并阻止它激活，也没有改变它的HADR角色属性。然后备端接受完全部日志并回放完成后变为新的主端，整个切换过程就完成了，数据库也可以提供服务了。HADR处于非启动状态。
在主备集群不连通的情况下，备端感受不到主端的状态。这种情况只能进行强制切换。强制切换会将备端的日志回放完成后变为新的主端，数据库提供服务，HADR处于非启动状态。一旦与原主端的网络恢复，就会出现脑裂的场景。DB2会选择杀掉原主端，从而保证不出现脑裂的现象。
DB2 pureScale集群HADR架构下客户端连接方式
DB2 pureScale集群的实现机制里面使用的是TSA集群软件，基础是RSCT。一台机器只能有一俄格RSCT集群，所以先前通用的HACMP等虚拟IP的方式来配置应用来连数据库已经不可行了。如果是虚拟IP，对于pureScale集群来说也很难做到负载均衡等各种连接方式。所以在DB2 pureScale集群HADR架构下，现有的pureScale集群的连接方式做了增强，加上了备集群的信息后，能够达到自动切换路由（ACR）的功能。在DB2 10.5里面，客户端主要有三种连接方式：
WLB：工作负载均衡是现有的应用方式之一，能够根据成员上资源的消耗来安排新的工作到空闲的成员上去做，从而达到资源的有效利用。在引入了HADR功能之后，WLB依然适用。只要配置好了Alternate Server的信息指向备集群，在HADR切换之后，客户端会自动连接到新的主集群，WLB也能正常生效。
Client Affinity: 在这种方式下，DB2的客户端不需要获取所连接集群的信息，只需要按照自己的偏好列表里面定义的策略去访问节点。所以在偏好列表里面加上备集群的成员节点信息，就能够做到应用的自动切换。
Member Subsetting: 这是在DB2 10.5开始加入的一种新的连接方式。在这种方式下，用户可以控制应用可以跑在指定的成员节点上。在这些成员节点上，应用还可以采用WLB，Affinity或者Round Robin的负载方式。对于HADR来说，这些定义都是存储在数据库内部的，所以切换之后，配置信息不会丢，应用还会延续先前的连接方式。
DB2 pureScale集群HADR架构高可用性
DB2 pureScale集群最大的特点就是具有高可用性，高扩展性和应用透明性。那么加入的HADR的容灾机制之后，这些特性并没有收到影响。一方面应用连接数据库所使用的原有机制并没有改变。一旦集群里的节点出现故障，原有的集群保护机制依旧生效。那么对于HADR的工作机制来说，这种高可用性也是延续的。
主集群一旦成员节点发生故障，那么该节点的数据库服务会被其他节点所接管。HADR服务也是一样，其他健康的成员节点会帮助传输日志到备集群（日志在共享存储上），从而达到高可用性。
备集群如果发生节点故障，一方面备集群的自我恢复能力和普通pureScale集群是一样的。另一方面，如果发生的故障下好影响到HADR功能，例如Replay Member被关机，那么HADR的功能也是会自我恢复的。例如选择一个健康的成员成为新的Replay Member。
所以pureScale集群里的HADR功能也同样是高可用的。
DB2 pureScale集群HADR架构容灾特性
DB2 pureScale集群通过HADR功能，传输日志到备端。这种方式高效而安全，也是延续了普通单机版DB2久经验证的HADR机制。只有生成日志的事务才需要被同步到备集群。HADR的spooling功能能够在Replay Member来不及回放的情况下将日志先保存的磁盘，避免高峰期对性能的影响和保证了数据的安全。
