银行
44同行回答
最近参与一个双活项目比较多，说下自己的看法啊
“双活”这个词的含义需要准确定义。定义不明确的话，什么RAC啊，purescale啊，DPF啊，HADR啊，DataGuard啊，都可以称为双活，因为确实是多个节点或系统同时活着，不是active/standby。
所以得圈一个明确的范围来讨论“双活”
下面说说我经常听到的“双活”，抛砖引玉啊
我经常听到的“双活”，是数据中心或者数据站点级别上的双活。其特点归纳起来就是：
1）有两个数据中心。这两个数据中心share nothing。每个都有自己独立的系统，包括独立的DBMS节点，独立的存储，独立的数据库数据和其它数据，可以单独拿来跑业务应用的
2）距离一般还很长，有上百公里甚至上千公里的。这么长的距离主要是出于安全考虑
3）这两个数据中心的配置和数据是高度同构的同步的，能力上它们需要能够支持全部的应用。既能相互合作分担完成工作（负载均衡，至少备机侧能分担一些查询类工作）；又能在其中一个停机时独立承担全部业务（高可用）
4）因为距离长，所以只能采用异步的数据复制方式。备机端的数据要稍微旧一点。选择适合运行在备机端的应用是个难题
5）需要有高度自动化的站点切换和回切功能，并且对切换时间要求很高（RTO必须很小）。因为要求快速切换，所以备机侧的数据必须是热的，DBMS是一直正常工作的，所以数据复制在备机侧需要是逻辑式的复制
6）可定制的切换策略。因为允许两边都运行负载，必须考虑因为数据复制延迟而导致的自动切换情况，这种情况比自动故障切换更复杂，需要把数据延迟这种性能指标纳入到监控和切换策略中
7）因为是异步复制方案，所以在真的灾难情况下会有数据丢失（RPO>0）。如果想把双活兼用作容灾方案，必须有其它辅助手段
从业务上看，这种东西的好处有：
1）负载均衡，提升资源利用率
2）减少应用停顿，提高可用性
3）因为距离够大，所以也可以抗一些地区性的灾难（前提是能承担那点数据损失或者有办法补回来）
从技术实现上，倒是跟数据库关系不大了，工作主要在数据库之外。难点主要有：
1）数据复制技术。主要难点在对主站点的影响、业务高峰期的性能、极端情况下的性能（想想银行夜间运行业务批量的时候）、稳定性、本身是否支持高可用部署
2）监控系统，需要和数据库以及复制程序深度集成，除了监控健康状况（死还是活）外，还能监控性能好坏（比如复制延时高还是低）
3）高度自动化的切换和回切功能，这也是需要和复制及监控深度集成的
4）因为是站点级方案，但站点内的数据并非都在数据库内。数据库外的数据（比如某应用使用的磁盘文件）怎么办呢？
说这么多，到底有没有DB2用户可用的成熟的站点级双活方案？答案是没有。客户需要自己搞定的事情相当多。如果想搞站点级双活，需要很大的决心和勇气，当然还有和厂商的深度合作
Oracle用户有没有可用的成熟的站点级双活方案？据我了解，答案也是没有。如果谁知道有，请不吝指教
再说一下，我上面所说的，仅限于远程站点级双活，不适用于节点级双活等其它双活场景收起
“双活”这个词的含义需要准确定义。定义不明确的话，什么RAC啊，purescale啊，DPF啊，HADR啊，DataGuard啊，都可以称为双活，因为确实是多个节点或系统同时活着，不是active/standby。
所以得圈一个明确的范围来讨论“双活”
下面说说我经常听到的“双活”，抛砖引玉啊
我经常听到的“双活”，是数据中心或者数据站点级别上的双活。其特点归纳起来就是：
1）有两个数据中心。这两个数据中心share nothing。每个都有自己独立的系统，包括独立的DBMS节点，独立的存储，独立的数据库数据和其它数据，可以单独拿来跑业务应用的
2）距离一般还很长，有上百公里甚至上千公里的。这么长的距离主要是出于安全考虑
3）这两个数据中心的配置和数据是高度同构的同步的，能力上它们需要能够支持全部的应用。既能相互合作分担完成工作（负载均衡，至少备机侧能分担一些查询类工作）；又能在其中一个停机时独立承担全部业务（高可用）
4）因为距离长，所以只能采用异步的数据复制方式。备机端的数据要稍微旧一点。选择适合运行在备机端的应用是个难题
5）需要有高度自动化的站点切换和回切功能，并且对切换时间要求很高（RTO必须很小）。因为要求快速切换，所以备机侧的数据必须是热的，DBMS是一直正常工作的，所以数据复制在备机侧需要是逻辑式的复制
6）可定制的切换策略。因为允许两边都运行负载，必须考虑因为数据复制延迟而导致的自动切换情况，这种情况比自动故障切换更复杂，需要把数据延迟这种性能指标纳入到监控和切换策略中
7）因为是异步复制方案，所以在真的灾难情况下会有数据丢失（RPO>0）。如果想把双活兼用作容灾方案，必须有其它辅助手段
从业务上看，这种东西的好处有：
1）负载均衡，提升资源利用率
2）减少应用停顿，提高可用性
3）因为距离够大，所以也可以抗一些地区性的灾难（前提是能承担那点数据损失或者有办法补回来）
从技术实现上，倒是跟数据库关系不大了，工作主要在数据库之外。难点主要有：
1）数据复制技术。主要难点在对主站点的影响、业务高峰期的性能、极端情况下的性能（想想银行夜间运行业务批量的时候）、稳定性、本身是否支持高可用部署
2）监控系统，需要和数据库以及复制程序深度集成，除了监控健康状况（死还是活）外，还能监控性能好坏（比如复制延时高还是低）
3）高度自动化的切换和回切功能，这也是需要和复制及监控深度集成的
4）因为是站点级方案，但站点内的数据并非都在数据库内。数据库外的数据（比如某应用使用的磁盘文件）怎么办呢？
说这么多，到底有没有DB2用户可用的成熟的站点级双活方案？答案是没有。客户需要自己搞定的事情相当多。如果想搞站点级双活，需要很大的决心和勇气，当然还有和厂商的深度合作
Oracle用户有没有可用的成熟的站点级双活方案？据我了解，答案也是没有。如果谁知道有，请不吝指教
再说一下，我上面所说的，仅限于远程站点级双活，不适用于节点级双活等其它双活场景收起
如果已经是HADR，可以建立两个数据库，配置成彼此互为主备，感觉很不错，还省钱。类似古时候的双工。 自己画了个草图。 ：－）
这类双活只能是伪双活，用来做读写分离还差不多
可以借助ogg等双向同步工具来实现。jlandzpa 发表于 2013-11-16 21:02