浅谈数据库高可用及DB2 HADR的应用

在使用数据库的时候，数据库的高可用性是我们最关注的事情之一。

我们在谈论高可用性的时候，我们首先应该了解一下可用性。什么是可用性，如何度量？当一个业务系统被用户完全访问时，它就可以使用了。高可用性被测量为系统正常运行时间的百分比，在此期间系统可供其用户使用，也就是说，在它正常使用的所有时间内，系统是完全可访问的。计划的正常运行时间是系统管理员同意保持系统为用户运行的时间，经常是与用户组织的服务级协议的形式进行确认。

下图是META Group对可用性的定义，在图表的底部是基本可用性，它要求95%的可用性，并且通常可以通过标准的磁带备份和恢复设备来实现。下一个级别，增强可用性，需要更健壮的特性，如独立磁盘冗余阵列或RAID、存储系统，以防数据丢失。META说，高可用系统的范围从99.9%到99.999%可用，需要对应用程序丢失和数据丢失进行保护。在这个连续可用性的顶部是一个容错系统，其目的是避免任何停机时间，因为它被用于在生死情况下。

所以数据库的高可用设计一定要结合自己业务的情况，只要数据库的可用性满足自己的业务需求就可以了，不能片面追求可用性越高越好，一般而言，可用性越高，投资也会越大，系统的架构也会越复杂。

数据库系统一般包含主机和存储两个部分，所以在考虑高可用的时候要同时考虑主机和存储。

DB2数据库高可用设计包括以下几种：

1.采用共享存储的HA配置，借助于操作系统的Culster软件（如AIX HACMP和Veritas Cluster Server），一般都是自动接管；

2.DB2 HADR配置（可以自动接管，也可以手工接管）；

3.本地采用共享存储的HA配置，同时进行HADR配置（本地或者异地），一般共享存储的HA是自动接管，HADR是手工接管；

4.DB2 DPF数据库一般采用存储共享的HA配置；

5.DB2 PureScale本身就是高可用架构，一般本地不再做更加复杂的配置，异地采用GDPC或者HADR实现跨站点的双活方案。

下面对近年来广泛使用的DB2 HADR进行深入的分析。
HADR（High Availability Disaster Recovery ）是数据库级别的高可用性数据复制机制，它为部分和整个站点故障提供高可用性解决方案。HADR 通过将数据更改从源数据库（称为主数据库）复制到目标数据库（称为备用数据库）来防止数据丢失。

根据需要，可以利用HADR实现以下几种业务需求。

1.使用HADR代替传统的HA架构

很多客户的实际环境中，既配置了传统的HA，又配置了HADR，但由于使用HADR的经验不多，或者对HADR本身不信任，不敢用HADR完全取代HA。我个人的观点是HADR是完全可以取代HA的。

部分站点故障可能是由硬件、网络或软件（DB2 或操作系统）故障引起的。没有 HADR，部分站点故障需要重新引导数据库管理系统（DBMS）服务器或数据库所在的机器。重新启动数据库和数据库所在的机器所花费的时间长短是不可预测的。可能在几分钟时间后，数据库才会恢复为一致状态并可用。使用 HADR，则备用数据库可在数秒内接管。

客户担心的数据同步问题，在同步方式为nearsyc的情况下，只要不是两台机器同时发生故障，数据是不会丢失的。在同一个机房中的两台机器，nearsyc同步方式对性能的影响一般是可以接受的。
使用HADR代替HA又两种集群软件可以选择，一种是原来的HA软件，比如AIX HACMP，把数据库做为一种资源，加入集群软件，然后通过写脚本的方式实现自动切换；第二种方式是使用DB2自己提供的高可用组件TSA，来实现自动接管，TSA可以支持多种操作系统（AIX,Windows,Linux），可以减少不同操作系统使用不同集群软件的不便。

2.使用HADR实现读写分离架构

在DB2 9.7以后的HADR环境中，备机提供了只读查询的功能。可以通过应用端的控制，将一些只读应用部署到备机，从而实现读写分离，建议这些只读应用同时也部署到主机，按照一定的权重来分配到主机和备机的访问流量。这样如果一台机器发生故障，另一台机器可以无缝接管。

3.使用HADR实现同城灾备架构

以前很多的同城灾备是通过存储级复制实现的。其实使用HADR也能达到同样的效果，而且在HADR备机可以进行读写的情况下，甚至可以分配一些只读任务到同城灾备站点，这样既可以提高资源利用率，又可以确保应用是可用的。

4.使用HADR实现两地三中心灾备架构

DB2 10.1版本以后，HADR提供了至多3个备机的架构，这样我们可以在本地，同城和异地分别部署一台HAD备机，从而实现两地三中心架构。

在使用HADR方案时，有些公认的和自己总结的最佳实践，来和大家分享一下：

1.采用单独的网卡，用于HADR的数据传输，不同的数据报文在不同网络卡，避免互相影响和干扰，也提高了HADR的同步效率和性能。

2.关于HADR同步方式的选择，nearsync的同步方式可以满足大多数的应用场景，Super async方式对系统的影响最低。可以通过压力测试来比较几种同步方式对性能的影响，因为应用的差异是很大的，不能完全凭经验。

3.有些客户会使用LOB字段，LOB字段默认是不记日志的，所以这些保护LOB字段的表在HADR备机会出现无法访问的情况，如果LOB的长度小于32k，可以采用inline存储的方式，这样LOB字段也会记日志，复制到HADR备机就没有问题了。如果超过32k那就没有办法了。

4.关于HADR接管的问题，一定在设计的时候就要做好方案，是采用自动接管还是手工接管，如果是手工接管，接管的流程是什么，触发条件是什么，并做好演练，写好文档，如果没有这些，等真的出问题的时候，做决策的时间都会远远超过实际切换的时间。

5.关于HADR接管方式的选择，在平时的演练中使用普通接管即可，在实际生产环境需要接管的时候，建议采用by force的接管方式，因为这样可以缩短接管时间并确保接管成功。

小结：目前的发展趋势对数据库高可用的要求越来越高，所以必须根据自己的需要选择合适的高可用方案。如果采用DB2 HADR就可以满足要求，可用放心的采用。