政府机关
有奖讨论：如何提高数据库的可用性？（送米送U盘）
作为一个 DBA ，如何提高数据库的可用性是我们无法回避的一个问题。
其实提高数据库可用性的概念是很广的，小到我们每天做的备份，大到异地建立灾备中心，所有的这些工作都是为了提高在问题或者意外发生时的数据库的可用性。
针对这个问题，各大数据库厂商也提供了对应的特性，用户也根据自己的需求去实现自己的高可用性，
请论坛中的各位朋友结合自己日常工作中，讨论一下实现和使用数据库高可用性过程中遇到过的各种问题、困惑、经验和教训，以及自己心目中理想的高可用应该是怎么样的？
具体奖品，楼下公布 ：）
----------------------------------------------------------------------------------------------------------------------------
论坛【有奖讨论】有奖征集讨论话题及主持人
http://www.db2china.net/club/thread-25276-1-1.html
此次有奖讨论的获奖名单已经出来了:
五位讨论最积极的会员：
tree ,
leo,
WUJJ0828 ,
marvelyu ,
Felix
每人获得奖励200大米。
讨论最认真的会员：
kt563
获得U盘一个
PS:后续大家也可以在里面进行互动，继续加分哦。
大米已经为大家加上，请获得大米的五位朋友核实是否收到。
奖品均已经寄送出去，请大家近期注意查收。
其实提高数据库可用性的概念是很广的，小到我们每天做的备份，大到异地建立灾备中心，所有的这些工作都是为了提高在问题或者意外发生时的数据库的可用性。
针对这个问题，各大数据库厂商也提供了对应的特性，用户也根据自己的需求去实现自己的高可用性，
请论坛中的各位朋友结合自己日常工作中，讨论一下实现和使用数据库高可用性过程中遇到过的各种问题、困惑、经验和教训，以及自己心目中理想的高可用应该是怎么样的？
具体奖品，楼下公布 ：）
----------------------------------------------------------------------------------------------------------------------------
论坛【有奖讨论】有奖征集讨论话题及主持人
http://www.db2china.net/club/thread-25276-1-1.html
此次有奖讨论的获奖名单已经出来了:
五位讨论最积极的会员：
tree ,
leo,
WUJJ0828 ,
marvelyu ,
Felix
每人获得奖励200大米。
讨论最认真的会员：
kt563
获得U盘一个
PS:后续大家也可以在里面进行互动，继续加分哦。
大米已经为大家加上，请获得大米的五位朋友核实是否收到。
奖品均已经寄送出去，请大家近期注意查收。
47同行回答
很精彩，看到的晚了，路过2句
数据库的高可用性，可以划分为三类：
第一类：主机可读写，备机不可读写
第二类：主机可读写，备机可读
第三类：主机可读写，备机可读写
每一类的实现方式有所不同，对于DB2数据库来讲，每类的实现方式如下：
第一类：采用共享磁盘的服务器集群方式，例如：AIX-HACMP,REDHAT-CLUSTER等，可以在服务器、网络、网卡故障时进行故障转移。
当然实施这类集群，也涉及到双交换机（避免单交换机造成的网络故障），网卡集群（热备或负载均衡模式）。目前用的比较
多的架构是：双防火墙，双负载均衡器，双交换机，双网卡的数据库服务器主备模式。
第二类：Q/SQL单向复制的方式，DB V9.7 HADR备机可读。这两种方式属于：非共享磁盘，可防止磁盘损害造成的宕机，可用性高了一层。
但是需要启用归档日志，对于一般的客户来讲，维护的要求比较高，特别是涉及到数据库备份和恢复，如果不配备相关的详细操作
文档和自动处理脚本，很麻烦的，不能要求每个客户都配备DBA吧。
第三类：非共享磁盘模式，Q/SQL双向复制的方式可实现双活，或者使用Q复制实现对等复制的多活模式。共享磁盘模式，DB2 purescale。采
用复制的方式可能会出现一些冲突，DB2 purescale架构应该会好点。
综上应该属于基础平台架构方面的事情。但是这并不能解决所有的事情。
有人误操作了，把操作系统中某数据文件给干掉了，怎么办？当然这类问题可以通过严格操作规程来尽量避免。
最坏的情况发生了，怎么办？数据库的备份就派上用场，那么真的能解决吗？有备份就一定能恢复成功吗？或者在可以忍受的时间内恢复成功？
所以备份很重要，可成功的恢复更重要，能在最短的时间内恢复更更重要。
对于备份和恢复，我觉得不能单单从数据库的操作层面去考虑，更要结合实际的系统，实际的数据架构，去制定最优的备份和恢复策略。
当然这方面的考虑，也会反向影响实际系统的数据架构。收起
数据库的高可用性，可以划分为三类：
第一类：主机可读写，备机不可读写
第二类：主机可读写，备机可读
第三类：主机可读写，备机可读写
每一类的实现方式有所不同，对于DB2数据库来讲，每类的实现方式如下：
第一类：采用共享磁盘的服务器集群方式，例如：AIX-HACMP,REDHAT-CLUSTER等，可以在服务器、网络、网卡故障时进行故障转移。
当然实施这类集群，也涉及到双交换机（避免单交换机造成的网络故障），网卡集群（热备或负载均衡模式）。目前用的比较
多的架构是：双防火墙，双负载均衡器，双交换机，双网卡的数据库服务器主备模式。
第二类：Q/SQL单向复制的方式，DB V9.7 HADR备机可读。这两种方式属于：非共享磁盘，可防止磁盘损害造成的宕机，可用性高了一层。
但是需要启用归档日志，对于一般的客户来讲，维护的要求比较高，特别是涉及到数据库备份和恢复，如果不配备相关的详细操作
文档和自动处理脚本，很麻烦的，不能要求每个客户都配备DBA吧。
第三类：非共享磁盘模式，Q/SQL双向复制的方式可实现双活，或者使用Q复制实现对等复制的多活模式。共享磁盘模式，DB2 purescale。采
用复制的方式可能会出现一些冲突，DB2 purescale架构应该会好点。
综上应该属于基础平台架构方面的事情。但是这并不能解决所有的事情。
有人误操作了，把操作系统中某数据文件给干掉了，怎么办？当然这类问题可以通过严格操作规程来尽量避免。
最坏的情况发生了，怎么办？数据库的备份就派上用场，那么真的能解决吗？有备份就一定能恢复成功吗？或者在可以忍受的时间内恢复成功？
所以备份很重要，可成功的恢复更重要，能在最短的时间内恢复更更重要。
对于备份和恢复，我觉得不能单单从数据库的操作层面去考虑，更要结合实际的系统，实际的数据架构，去制定最优的备份和恢复策略。
当然这方面的考虑，也会反向影响实际系统的数据架构。收起
浏览1201
一. 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，提供在线热备份技术。（交通银行有具体应用，很多银行也有用）
六.网络和电力的高可用
网络就不用说了，网卡漂移，多子网，冗余光纤等。电力的话，要有备用电源和发电机。数据中心的电力和网络一定要给运营商第一流的保障要求，否则谁都付不起责任。当然还有温度、湿度等
七.制度上的控制
这个就不用说了，大规模的电信运营商、银行都有非常成熟的制度和流程。中国人民银行也有非常详尽的规范。各银行也制定自己的一些细节规定。制度一定要控制滥用权限、各种误操作、以及指明应急时候的操作。前面的兄弟也有一些阐述，比如双保险，及时进行灾备切换演练，整体级别的，应用软件级别的都要有。数据中心建成的时候，要各种切换和场景都要尝试。
写的累死了，等以后有时间，补充一下制度方面的信息。我经验不足，考虑的不是很全面和深入，很多思考也不是很准确，目的就是唤醒大家的讨论，纠正我的理解的偏差。欢迎交流和讨论。收起
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，提供在线热备份技术。（交通银行有具体应用，很多银行也有用）
六.网络和电力的高可用
网络就不用说了，网卡漂移，多子网，冗余光纤等。电力的话，要有备用电源和发电机。数据中心的电力和网络一定要给运营商第一流的保障要求，否则谁都付不起责任。当然还有温度、湿度等
七.制度上的控制
这个就不用说了，大规模的电信运营商、银行都有非常成熟的制度和流程。中国人民银行也有非常详尽的规范。各银行也制定自己的一些细节规定。制度一定要控制滥用权限、各种误操作、以及指明应急时候的操作。前面的兄弟也有一些阐述，比如双保险，及时进行灾备切换演练，整体级别的，应用软件级别的都要有。数据中心建成的时候，要各种切换和场景都要尝试。
写的累死了，等以后有时间，补充一下制度方面的信息。我经验不足，考虑的不是很全面和深入，很多思考也不是很准确，目的就是唤醒大家的讨论，纠正我的理解的偏差。欢迎交流和讨论。收起
浏览1190
此帖子收益良多，很受启发，学习dreamsea214 发表于 2012-8-11 08:16
这就是我们讨论的目的和意义所在此帖子收益良多，很受启发，学习收起
浏览1252