有奖讨论：如何提高数据库的可用性？（送米送U盘）

一. HADR
HADR有一主一备数据库，在9.7之前备机不可读，9.7之后备机可读可以降低主数据库的负担（呵呵，这个oracle的dataguard逻辑备机可读做的就很好，但是为什么IBM会落后呢......）。在数据专线带宽足且稳定的情况下，在要求主备完全数据无损的时候，推荐用同步方式传送，或者能容忍一定少量的损失，可以用准同步，但是推荐在在生产中心和同城的灾备中心之间（LAN或者MAN），如果在1000公里以上带宽和时延都没什么保障的话，比如北京和上海，最好还是用异步的方式，如果更差或者对OLTP的实时性要求较高还可以用超级异步，当然这对流水的损失要有一定的容忍度。HADR一个很不好的特点是不能用于DPF，只能适合单分区数据库，这就限制了数据库在高可用下的规模以及并发性。HADR从一些实际应用来看，切换速度要比DG要快，而且切换出现故障的可能性要小些。谈到HADR绝对不能离开dataguard，实际上中国人民银行对两地三中心的规定就非常适合dataguard的两个备用数据库的方式，生产中心用主数据库，同城灾备中心用物理备用，异地灾备中心用逻辑备用。oracle的dataguard在网络故障恢复之后可以自动同步。HADR有一个弱点就是不能进行数据压缩和加密，如果没有VPN就麻烦了，但是HADR可以集成第三方的SSH软件。而DG本身就集成了SSH进行压缩和加密功能。HADR最要命的是不能支持异构数据库的复制，当然这个也不是他的主要场景。DB2异地灾备用HADR的比较多，在9.7之前用HADR的话备机不可读很麻烦，所以有的时候就要用Q复制，这样主备都可读，如果要零容忍和短切换时间的话，用HADR比较靠谱。

二. SQL复制和Q复制

SQL复制主要应用于相同局域网内。Q复制远程好一点，因为在网络比较差的时候，websphere MQ可以缓存一段时间数据。Q复制一般结合HADR比较多，用于实现数据远程异地复制（比如中国烟草总公司容灾中心）。Q复制可以通过分析事务日志来获取系统变化，对系统的性能影响比较小。是高效率的复制方案。但是Q复制只是对DB2支持的比较好，对oracle嘛就那样，其他的数据库支持的都不好。Q复制也支持表级别的复制。inforsphere CDC（原来叫data mirror）支持多种数据库的表复制。呵呵，oracle也有goldengate，这个熟悉的人也知道，支持ORACLE最好，其他的嘛不好说。但是CDC在表依赖上有些复杂，会有点问题，需要具体处理。


三. HACMP

HACMP cascading模式中，有主又备，节点有优先级，资源组在优先级搞的节点运行，高优先级节点故障恢复之后，资源组重新归位。cascading用于主备机硬件性能有较大差别的环境，节约成本，这个对于不差钱的运营商、航空、银行、政府绝对不会采用。rotating模式中，有主有备，节点优先级相同，资源组在先启动节点运行，节点故障恢复后，资源组不会前移。rotating适用于对可用性要求较高的场景，电信行业的数据业务，增值业务，彩铃等产品多采用这种方式。concurrent模式无主备，节点优先级同，资源组在所有节点运行，节点故障不会导致资源组切换，故障节点恢复后，资源组恢复可用，不发生前移，适合大容量据点。concurrent模式一般和oracle的RAC或者并行服务器（OPS）合用较多。电信业务中，增值特服大容量据点采用，智能网、BOSS也有应用，这种模式的结合和purescale十分类似。但是HACMP中数据库只有一份，如果数据库被破坏，主机和操作系统还好也没毛用，所以还要结合HADR才更安全。HACMP一般是由网卡和机器down机所触发的，软件改动不知道是否能够触发呢，我也不是很清楚？


其实HADR，HACMP在本地数据中心的效果最好，如果是异地的话最好是存储层的做，软件层面效率并不是很高，当然不同公司的选择是不一样的。


四.关于DPF


关于DPF，其实DPF本身并没有高可用性的方案。但是由于多节点技术，在某些条件满足的情况下有一定程度上的容灾。要求catalog节点不能down，如果非关键节点down，DPF数据库还是可以访问的。但是如果你要某些表可访问，只有在该表所在表空间所覆盖的分区节点没有down。DPF节点down有几种情况，如果是操作系统或者网络故障，可以通过HACMP恢复，如果是节点数据库损坏，就没有办法了。其实DPF这么多节点也是引入了故障点的概率，所以OLTP在没有HA保障的话，是不敢建在DPF上的。DPF在建库的时候，最好规划好关键节点的HA和备份工作，定期检查表，表空间的分布，并记录下来，有问题可以迅速定位和恢复。表空间级别的备份在DPF还是很重要的。如果资金保障比较充足的话，建议给所有几点都做HA，因为一般数据库本身导致的可用性问题要比OS和硬件网络导致的要少很多。DPF跨节点表和表空间特别多，千万不要因为节点本身的问题造成表空间不可用那个。


五.存储层的容灾

谈到高可用，不能离开存储层的容灾，比如磁盘镜像技术，和第三方的备份技术。当然，everyone都知道，存储层的技术避免不了宕机的，要有一段切换时间。SRDF一种比较复杂技术。SRDF在国外应用的非常多，国内银行也开始应用。SRDF可以实现分层的数据备份和恢复。可以跨大楼，可以实现全球的数据复制。同样的，和HADR和DG类似，也有同步，准同步和异步的模式。覆盖的距离可以多达几千公里，但是因为无
需考虑类似于HADR的实时性交易问题，另外SRDF支持所有的主机和数据库系统。这个一般在数据中心搬迁的时候用的比较多。如果在距离比较近的时候比如数公里的距离，可以使用裸光纤，如果较远的话，就要用华为或者cisco的DWDM进行光纤延伸，根据数据传输的需求制定线路的速率。SRDF非常昂贵，如果我们的数据和客户交易不强相关的话，就可以使用笨笨的磁带拷贝搬迁方法，建立应用系统，然后再用SRDF传输实时要求高的数据，启动新数据中心的系统，切换网络。

veritas大家也非常了解了，论坛上用过的人该很多。通过 veritas的BMR技术，可以直接连操作系统带数据全部备份到数据中心。更为强悍的是，无需LAN的SAN多磁盘并发备份，减少对网络带宽的影响。通过BMR可以制作启动光盘，进行系统恢复。针对于不同的数据库还提供相应的agent，提供在线热备份技术。（交通银行有具体应用，很多银行也有用）


六.网络和电力的高可用

网络就不用说了，网卡漂移，多子网，冗余光纤等。电力的话，要有备用电源和发电机。数据中心的电力和网络一定要给运营商第一流的保障要求，否则谁都付不起责任。当然还有温度、湿度等


七.制度上的控制

这个就不用说了，大规模的电信运营商、银行都有非常成熟的制度和流程。中国人民银行也有非常详尽的规范。各银行也制定自己的一些细节规定。制度一定要控制滥用权限、各种误操作、以及指明应急时候的操作。前面的兄弟也有一些阐述，比如双保险，及时进行灾备切换演练，整体级别的，应用软件级别的都要有。数据中心建成的时候，要各种切换和场景都要尝试。

写的累死了，等以后有时间，补充一下制度方面的信息。我经验不足，考虑的不是很全面和深入，很多思考也不是很准确，目的就是唤醒大家的讨论，纠正我的理解的偏差。欢迎交流和讨论。