基于Oracle数据库的复制解决方案对比分析
作者：王荔
前文对主流数据复制、保护技术进行了简单介绍，本文以Oracle数据库为例，以RPO=0为业务场景，从不同视角，针对部署方案进行分析比较；技术原理是相通的，该分析过程同样适用于其他数据库。
通过对目前主流数据保护技术的分析，基于各个层次的数据保护技术在不同角度的优劣各有不同，越底层的复制技术，部署实现较为简单，对基础设施的依赖度强，日常维护复杂度高；越靠近应用的复制技术，部署实现相对复杂，对基础设施依赖小，技术自主可控度高；企业需要基于业务连续性要求，结合自身的技术能力和业务模型，找到其中的耦合点，寻求基础设施成本和应用改造，运维成本的平衡。下图作为一个表示。
下面以Oracle数据库为例，针对RPO=0的数据库复制解决方案进行分析比较：
| 应用同步复制 | 数据库同步复制 | 存储层同步复制+数据库集群 | 数据库准实时复制+应用补偿 | |
|---|---|---|---|---|
| 实现方式 | 应用同步双写 | Oracle Active Dataguard | Oracle RAC（3节点）+ASM（双存储） | Oracle Active Dataguard+应用补偿 |
| 基本部署描述 | 主副本系统位于不同机房，数据更新通过应用层面来完成 | 2套数据库位于不同机房，通过ADG最大可用模式实现同步复制 | 一套数据库的3个节点，2个节点部署在A机房，1节点部署在B机房，共享一份数据，底层通过Oracle ASM实现不同机房的存储复制 | 2套数据库位于不同机房，通过ADG最大性能模式实现准实时复制；结合应用层面的数据补偿功能，满足RPO要求 |
| 站点级耦合性 | 紧 | 紧 | 紧 | 松 |
| 应用架构复杂度 | 高 | 低 | 低 | 中 |
| 技术架构复杂度 | 低 | 高 | 低 | 低 |
| 站点级扩展性 | 受距离限制，站点级扩展性差 | 受距离限制，站点级扩展性差 | 受距离限制，站点级扩展性差 | 与距离无关，站点级扩展性好 |
| 站点间距离 | 依赖 | 依赖 | 依赖 | 无依赖 |
| 副本对主本的性能影响 | 受网络距离、延时、带宽、副本数据写性能的影响 | 受网络距离、延时、带宽、副本数据写性能的影响 | 受网络距离、延时、带宽影响 | 无影响 |
| 软、硬件投入 | 中 | 高 | 低 | 中 |
| 自主可控 | 完全自主可控 | 基本可控 | 基本可控 | 部分自主可控 |
| 器件级单点故障（中低危高频） | 支持 | 支持 | 支持 | 支持 |
| 人为操作失误（高危低频） | 有限影响，如果是应用程序中或者脚本自动双库操作，需配合Flashback或应急库或存储级快照或者同城（异地灾备）技术来实现快速恢复；如果是人工连接到单数据库上的操作，另外一个库不受影响 | 全局影响，需配合Flashback或存储级快照或同城（异地灾备）技术来实现快速恢复 | 全局影响，需配合Flashback或应急库或存储级快照或同城（异地灾备）技术来实现快速恢复 | 根据需求场景选择；如果需要备库提供准实时查询功能，则需配合Flashback或者应急库或存储级快照或同城（异地灾备）技术；如果提供非实时查询，本技术方案支持人为操作失误情况下的快速数据恢复 |
| 数据库坏块（逻辑故障）（高危低频） | 有限影响 | 有限影响：支持物理坏块的自动检测和恢复 | 全局影响，需配合应急库或存储级快照或同城（异地灾备）技术来实现快速恢复 | 有限影响：支持物理坏块的自动检测和恢复 |
| 机房整体故障（高危低频） | 支持 | 支持 | 支持 | 支持，数据库不一致部分需要应用补偿 |
| 双活、读写分离 | 支持 | 支持 | 支持 | 支持 |
| 日常维护停机时间 | 相比单站点，可大幅缩短停机维护时间 | 相比单站点，可大幅缩短停机维护时间 | 与单站点相同，不变 | 相比单站点，可大幅缩短停机维护时间 |
| 维护复杂度 | 中 | 高 | 中 | 中 |
| 自动化切换 | 应用或者中间件层实现 | 配合data guard broker工具实现自动切换 | 无 | 配合data guard broker工具实现自动切换 |
| 维护风险 | 中 | 高 | 中 | 低 |
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞0Ctrl+Enter 发表
本文隶属于专栏
作者其他文章
评论 2 · 赞 9
评论 2 · 赞 9
评论 0 · 赞 2
评论 0 · 赞 1
评论 1 · 赞 0
添加新评论0 条评论