政府机关
有奖讨论：如何提高数据库的可用性？（送米送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同行回答
楼上的斑竹说的全面啊，我也来凑凑热闹：
数据库作为信息系统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收购了。收起
数据库作为信息系统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收购了。收起
浏览423
要做到数据库的高可用性，HA和备份技术方案是一方面，还有管理制度层面来配合技术方案，最基本的就是定期巡检制度和维护制度：
1 建立定期巡检制度
定期巡检需要维护人员定期检查系统软件的运行日志和硬件运行状态，发现问题及时处置。我去年就遇到过一次，一个系统使用的磁盘阵列已经报警了，机房值班人员没有发现，好在只是坏了一块硬盘，有热备盘，如果硬盘坏的多了，可能数据损失就大了。查看日志时，不仅要看数据库日志也需要查看操作系统日志，操作系统的错误有时也会导致系统HA失效。
2 建立严格的运维制度
维护制度对于数据中心的维护人员尤为重要，最基本的就是双人复核后，才能对数据库进行增、删、改操作，并且操作之前必须要做好备份和操作记录。这个我也遇到过一次，一个银行业务系统部分省市的网点分批上线，有个网点的移植数据搞错了，同事作删除时，忘了加where条件，好在当时上线网点还不多，采取了一些补救措施，现在想起来还后怕。以后在生产系统维护时，我自己就没再敢单独做过增删改操作，总是两个人都看过之后，再回车。收起
1 建立定期巡检制度
定期巡检需要维护人员定期检查系统软件的运行日志和硬件运行状态，发现问题及时处置。我去年就遇到过一次，一个系统使用的磁盘阵列已经报警了，机房值班人员没有发现，好在只是坏了一块硬盘，有热备盘，如果硬盘坏的多了，可能数据损失就大了。查看日志时，不仅要看数据库日志也需要查看操作系统日志，操作系统的错误有时也会导致系统HA失效。
2 建立严格的运维制度
维护制度对于数据中心的维护人员尤为重要，最基本的就是双人复核后，才能对数据库进行增、删、改操作，并且操作之前必须要做好备份和操作记录。这个我也遇到过一次，一个银行业务系统部分省市的网点分批上线，有个网点的移植数据搞错了，同事作删除时，忘了加where条件，好在当时上线网点还不多，采取了一些补救措施，现在想起来还后怕。以后在生产系统维护时，我自己就没再敢单独做过增删改操作，总是两个人都看过之后，再回车。收起
浏览671
在项目中用到过的高可用性有三种方式
1 双机热备
所有的交易型应用都要用的，部署两台数据库服务器作热备，使用的是Power HA（HACMP），从项目测试情况看，切换时会有秒级的数据库服务停止，总体效果还是不错的。
2 hadr
HADR曾经在IBM 的实验室做过测试，那个时候用的还是DB29.5。后来有个项目准备使用，在同城灾备中心增加一台数据库备用服务器，也做过测试，在生产系统和同城灾备之间使用光纤连接，性能还可以，切换了几次还比较顺利。最后客户觉得维护起来麻烦，没有上线。
3 磁盘复制
这个是正在做的一个项目，数据量比较大，也是实时交易系统。在同城灾备和上海异地灾备中心各部署磁盘阵列，通过磁盘复制方式实现数据同步。感觉这种方式，只是复制了数据，一旦出现问题，切换还是比较麻烦，正在做灾备切换的方案，看测试结果了。
还用过Q复制，这个对于分散数据查询压力比较方便，把实时交易生产数据库的数据通过Q复制到另一台查询服务器，用户做单纯查询功能时，连接查询服务器，分但了生产数据库的压力，这个算是变相的高可用性。收起
1 双机热备
所有的交易型应用都要用的，部署两台数据库服务器作热备，使用的是Power HA（HACMP），从项目测试情况看，切换时会有秒级的数据库服务停止，总体效果还是不错的。
2 hadr
HADR曾经在IBM 的实验室做过测试，那个时候用的还是DB29.5。后来有个项目准备使用，在同城灾备中心增加一台数据库备用服务器，也做过测试，在生产系统和同城灾备之间使用光纤连接，性能还可以，切换了几次还比较顺利。最后客户觉得维护起来麻烦，没有上线。
3 磁盘复制
这个是正在做的一个项目，数据量比较大，也是实时交易系统。在同城灾备和上海异地灾备中心各部署磁盘阵列，通过磁盘复制方式实现数据同步。感觉这种方式，只是复制了数据，一旦出现问题，切换还是比较麻烦，正在做灾备切换的方案，看测试结果了。
还用过Q复制，这个对于分散数据查询压力比较方便，把实时交易生产数据库的数据通过Q复制到另一台查询服务器，用户做单纯查询功能时，连接查询服务器，分但了生产数据库的压力，这个算是变相的高可用性。收起
浏览646