数据库实现高可用方式探讨，参与活动IBM好礼相赠！

liuziquan

目前在客户以及我们自己这都是用的HACMP，主要是要兼顾到成本因素，两台IBM POWER730，一台平时主要做应用服务器，一台平时主要做数据库服务器，两台做HA，其中一台出现故障的话，另一台将同时做为应用服务器、数据库服务器；毕竟对于国内的公司来说，闲置一台机器的代价也太大了点。

wjlcn

跑在aix上的话，感觉用hacmp实现高可用性的会比较多吧？

cqy011

DB2分步式数据库开发，适用于大中型系统的开，而且IBM的东西，我喜欢，大力支持

zcl32

DB2共享存储HA集群或者HADR都可以实现DB2的高可用性。
使用DB2共享存储集群实现HA，相对来说，这种HA实现的一般是比较高端的配置，共享存储一般采用SAN或者至少DAS。而使用HARD来实现HA一般是部门里面的TB级的数据库，没有昂贵的SAN存储，只是简单的服务器上的RAID存储，这样通过HADR既可以保证服务器主机的可靠性，也可以保证存储设备的可靠性。
HA切换脚本我们一般倾向于采用TSA来实现。
我们选择使用TSA是基于以下几个方面考虑的：
一是它的开箱即用，简单易用。DB2 9.5/9.7里面AIX/Linux等平台本身就集成了TSA，通过db2haicu可以很方便地配置HA，对于HA的监控和管理也提供了相应的工具像lssam等。
二是，TSA感觉也是IBM今后的发展方向，毕竟它的优势是跨平台，PowerHA/HACMP只能用在AIX平台上，许多Linux平台就没法用。IBM的数据仓库一体化平台ISAS就使用的TSA。
三是这种高可用性的监控管理毕竟对于企业或者部门是非常重要的，自己写的脚本维护困难，还需要经过各种测试，而TSA作为一个产品已经经过了非常严格的测试。在使用中出现问题的情况下可以寻求IBM技术支持，自己写的脚本就需要慢慢检查了，一个不注意就可能搞错。

我们在测试使用TSA来自动管理DB2 DPF数据库的过程中，我们也遇到一些问题，主要是有时候故障切换的时候，文件系统好像mount地有问题，lssam看有的节点上始终显示红色的文件系统mount状态，现在在进行研究。但是双节点的DB2共享存储集群没有出现过问题。

feonabin

我会选择使用IBM的TSA软件来完成。

因为hadr发生故障时，需要手工进行takeover切换。 虽然在 AIX HACMP 或者 OS cluster里可以使用takeover脚本takeover hadr, 但hacmp and cluster本身都是监控OS RESOURCE的, 如果想要监控db2自己的进程, 就需要写event事件了. IBM 的 tivoli system automation 提供了进行db2 hadr 故障切换的功能，而且在db2 9.5之后集成安装了。

不过在db2 purescale的备份恢复这块，我感觉还有需要提高的地方。
比如说：
If you add or drop a member, the database is placed in backup pending state, and you must perform a full database backup operation before a connection to the database can be made.

也就是说在增减节点的时候必须有时间窗口停机做离线备份，这对某些关键应用来说，这个停机时间也许是不可接受的。也就是不能做到所谓的Continuous Availability。

7200770

我习惯使用HADR来实现，但是会借助TSA或者HACMP。

因为DB2 HADR作为一种高可用性的数据恢复模式，能够在数据库服务器发生故障时尽可能地抢救数据，挽

回损失并保障工作正常进行。但HADR环境下数据库自身无法自动切换，出现问题时只能人工进行主备切换，

这在一定程度上加大了DBA工作量和不稳定因素。在实际运用中可以结合Tivoli System Automation

（TSA）、High Availability Cluster Multi-Processing （HACMP）来实现HADR的故障自动切换。

还有另一个原因也许其他人不愿意说：正因为HADR需要手动，所以DBA才有存在的价值。主备切换的工作

难度并不大，但是在老板的眼中，会显得DBA很有价值。

~贝贝~

感谢大家的参与哦，都说了非常不错的内容
活动31日结束，结束后将会发送礼品啦，呵呵，欢迎更多的朋友抓紧时间参与一下呀！

nulizhuanqian

一直都用HADR，没有尝试TSA。
用HADR有一个感受，就是主机和备机在建立HADR机制时必须处于对等状态，否则备机将无法取得主机在建立HADR之前的日志文件。并且，在任何非对等状态下，主备发生角色互换都是HADR不允许的。因为仍有一部分在主机已经提交的数据操作未能在备机重放，这将造成数据的丢失。同时HADR在提供数据保护之前是需要一定的时间完成准备的，而这个准备过程是异步的，不随命令启动成功而完成，需要DBA通过对db2diag.log或者db2pd来查证确认，直到日志或db2pd中显示出对等（peer）状态时，数据才真正处于HADR的保护之下。因此如果进行强制切换的瞬间HADR处于对等之外的其他状态，这个切换将不可逆，并可能导致只有通过重建HADR来修复HADR环境。
    发生故障时主机和备机必须处于peer对等状态，也就是说主备之间不存在数据落差，这样主机切换到备机后再加入HADR就不会发生备机（原主机）的日志前滚点比主机（原备机）更新的情况。发生故障并切换后，对主机的所有访问请求都被路由到备机，原主机的数据未发生任何更改。此时必须依靠DBA手动进行双机数据同步，才能重新建立对等状态，这里有点费事。

师恩难忘

用的HADR。感觉它有几个优点：数据库同步；不需要更改应用程序或客户机；易于安装和维护；对于AIX和Linux，自动化故障转移是“开箱即用”的；对性能的影响非常小；可执行滚动升级。
缺点就是附加的服务器和存储需求，备用系统不能同时用于数据库工作负载，不复制无日志记录的操作。

help01

我用TSA。