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

楼上的斑竹说的全面啊，我也来凑凑热闹：
数据库作为信息系统ha规划的一个非常重要的一个节点，在整个系统遇到问题时，第一想到的必然是dba[经常是数据库连接失败等错误原因]，在整个基础架构产品层，dba不得不花大量的时间和精力去理清应用服务器，缓存服务器，中间件服务器，文件服务器，存储，网络等节点，整个系统的可用性可以说是各个节点的可用性的乘积。数据库服务器承载着IT系统的数据，并提供数据访问服务，数据库HA的重要性不言而喻。
还是老几样，首先考虑数据库的备份恢复机制，确保这套策略有效并得到经常性的演练，dba甚至被需要闭着眼睛就能做无误的备份恢复操作，有些可能要求在任何时间段。根据应用系统的特点和数据库的大小，及考虑其他综合因素【如备份时间窗口，网络存储资源等】，选择不同的备份策略，当然这个备份策略主要还是要根据恢复策略来制定的。超过10T的数据仓库系统建议开启归档日志，各表空间根据数据特性和刷新频率制定不同的备份策略，根据需要做好数据库备份，dba守则第一条就是要有备份。目的还是简单一个：万一出事时尽快恢复，提升数据库的可用性。
第二，根据企业it预算，可以选择服务器ha，即操作系统级别的ha，在机器硬件和系统运维期间继续提供系统服务，这个的重要性可就不用说了。虽然存储存在一定的数据孤岛。前不久我们的一台595更换换内存，oltp系统做了ha在计划内直接就切换出去了，否则又得是好几个小时停止提供服务。当然更能起作用的是通过心跳机制【磁盘、串口、网络，不建议第三者单独使用，否则ip协议失效就无法监测了】进行自动切换，ha到备机也是件容易的事情。
第三，上面一条提到了数据孤岛，为了解决这个问题，我们还可以推荐db级别的ha，比较成熟的产品有ibm的hadr[特别是v9.7以后备机可读特性在一定方面提升了系统的利用率，可以承载一定的数据读负载]。另外oracle的Standby/Data Guard方案也是值得考虑的，如果你用的oracle数据库产品。
第四，数据级别的ha。其实目前很多系统采用的都是这种方式的ha，通过数据复制的方式来提供数据库的可用性。适用于db2的产品就有如sql复制，Q复制，CDC复制等，oracle 的GoldenGate，sysbase和sql server等数据库也有相应的功能，这里就不一一介绍了。运用的比较好的当然还是各类灾备数据中心，实现了单活/双活。当然除了产品，更常见的是采用etl工具/人工开发的etl程序来实现，通过作业调度来进行数据的复制。
思路有点跟着macrozeng斑竹跑了，呵呵。
数据库这个节点做了ha，其他节点的ha也是蛮重要的，如应用服务器，缓存服务器，中间件服务器，文件服务器，存储，网络等节点。除了存储由于成本原因，可能只能有部分系统能做之外，其他都应该好好下考虑ha。
另外说到ha，除了像楼上说的oracle的rac和ibm的purescale，另外不得不提到syabase的ha方案:1.双机standby，主备。2.双机HA，双活互备，数据不共享。3、多机Cluster，最多64个节点的集群，共享数据，负载均衡，节点之间通过逻辑Cluster的方式设置备份以及应用级别。说道这里，其实人家sybase的东西做的不差的，可惜被sap收购了。收起

曾大师总结的不错！

    1、数据仓库由于其历史性长、变化慢、数据量大等特点, 我们在ORACLE上采用FLAT FILE来进行备份和加载(利用oracle 离线文件取)。  而且结合分区和压缩技术。效果还是比较令人满意的. 主要采用复制方法实时同步的维表 、STAGING或ODS中的相对“小”表。

    2、oracle rac / db2 purescale 相对于db2 dpf　由于采用的架构不同，更适合高可用性，但后者结构简单，管理和维护容易，看大家的具体需求了收起

让我来说说对可用性的理解，请各位批评指正
1. 备份和恢复演练 （任何生产数据库都必须的）,当然我们我听说过一些大型的 BI 系统的数据库，由于数据量太大，投入的时间以及存储成本过高而放弃备份的，但是我始终认为，有效可用的备份是数据库可用性的基本保证。
2. HA  OS 级别的，例如   HACMP 等 OS 级别的 HA ,这里的 DB2 对于 OS 来说只是一种应用，当DB2 所在的节点出现故障时，备用节点会把整个共享存储接管过去，可以实现数据库再可用。很多客户为了充分利用备机资源，往往在备机上部署其他的应用，实现双机互备。一点某个节点出问题就可以都所有的应用，包括 db2 都切换到备机上去。优点：技术成熟，可以通过脚本或者一些工具实现自动切换。缺点：切换过程中可能会有短暂停机,如果共享存储出问题，无法利用这种  HA 实现高可用性。
3. DB 级别的 HA , 也就是大家很熟悉的  HADR ,目前 IBM 对 HADR 进行了改进，备机可读可以进一步降低总体拥有成本。优点是不需要共享存储，怎样的话可能实现远程部署，进一步提高对自然灾害的抵抗力。但是切换也需要短暂停机。
4. CA（continue available），0 停机，一般通过 SQL 或者 Q 复制来保证两个或者多个数据库之间的同步，前端应用通过 cluster 的方式分别连接到不同的数据库，显示同时对多个数据库的读写访问。后台通过复制技术保证多个数据库的数据互相同步。这种技术基本上可以保证数据库的不停机，因为可以把各个数据库部署在不同的地方，实现灾备，我所接触的一些国内银行项目就是在北京和上海分别建立数据中心，用复制技术来保证同步，两个数据中心同时对外服务，实现了“双活”。
5. 说到可用性，不得不提的就是 Oracle RAC 和 DB2 purescale 技术，它们都是基于共享存储来实现数据库的集群，优缺点都很明显，想必我也不用多说了，目前 IBM 已经把复制技术和 purescale 结合起来，在提高单个 site 的可用性和并发性的同时，也实现了多个 site 之间的互相数据同步，这个方案也是结合了两者的优点，克服了两者的一些缺点。收起

楼上说的不错，简单就是一种美丽收起

我觉得HA+HADR就挺好，高可用性完全达到很高的标准，很多人说ha切换的时候会有一段时间连不上了 ，的确是事实，从实际的情况来说，在配置合理的情况下，HA在生产过程中发切换概率太小了。

所以很多人推荐rac这种结构，可以我接触的客户经常要问客户，rac可用性，经常是一个节点出问题，另一个节点也不是正常了，且维护的需要停机的事件挺多。

我个人认为，架构简单点挺好，好多人好大喜功，都用一些特别复杂的技术，把IT架构搞的特复杂，经常维护时，出问题。话有回来，如果维护成本低，我们又没有饭吃了。呵呵收起

RAC 或者 perscule 都是基于共享磁盘的，而且基本上都是处于一个数据中心里面的，所以对于类似  911 的灾难的防备能力还有欠缺，当年 911 ，很多数据库都遭到了灾难性的损坏收起

其实不可能有百分百的高可用数据库,要想完全保险有点不现实.
只要的问题应该是 在公司现有的预算和现有的环境下怎样做才能在未来某一个可能发生问题的时刻,尽最大可能使得意外的down机对客户的影响最小或者几乎感觉不到
我觉得
1 预算和要求都比较高的情况下,可以考虑类似于 RAC 或者 perscule 这样的结构。通常是用物理主机来运行节点，不过不知是否可以用 类似于VMware这样的技术把多个节点虚拟化，也许这样在费用上和管理上都会容易些。
2 可以在存储层面上下点功夫，存储是最基础最容易被忽视的一个地方，做好存储上的优化可是系统的基石。收起

:-)，说说你的实战经验收起

   对呗，最近出差一直在弄ha的事情。主要是运维，优化，备份，启停方面都要通过脚本自动化实现。收起

    计划停机 也是要考虑，虽然不属于“灾难”，但风险依旧存在(也许相对小一些)，特别是数据库升级、在线重定义、业务更新；

总之和原来dbms有差异的都要有所考虑，同时后续的调优、备份策略都要相应的更新收起