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实现跨站点的双活方案。
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就可以满足要求，可用放心的采用。