楼主: lc7888

[精华] 数据库容灾、复制解决方案全分析

[复制链接]
招聘 : 售前/售后支持
论坛徽章:
5
ITPUB元老
日期:2005-04-25 13:27:42授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:00
11#
 楼主| 发表于 2004-7-9 12:00 | 只看该作者
最初由 biti_rainy 发布
[B]系统上通常不一致没关系是因为还有 logfile 的存在,而日志文件通常是被写入了磁盘的,oracle本身是顺序写的,还不需要读,应该是被重整的几率比较小

还有存储设备上,比如掉电没关系,是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘,这个如果不能保证那一掉电基本都要出问题的


但是在复制的那端,我就不清楚是怎么处理的,比如我要停掉复制,开始用起这数据来,或者说设备掉电了,这个时候是怎么处理的 [/B]

在复制的那端,我感觉是没有经过特殊处理的,因为存储设备完全是物理上的同步,在你停掉复制的时候,他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的,但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致,所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下,停止存储的复制,然后启动目标端数据库,但还是有1/3的几率无法启动,如果是在原系统发生故障或断电的情况下,估计就更不好说了。
我还是比较佩服那个客户的勇气,一个省级移动运营商的数据中心,数据库连归档都没有,一旦系统崩溃,至少要损失当天的数据,同时容灾端的数据库能不能起来还是个问题……
还好目前还没有出问题,要是出了问题,不知道他们会怎么办……

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
12#
发表于 2004-7-9 12:56 | 只看该作者
上次做存储设备的来公司,谈到这个问题的时候说:  很多客户就是这么做的

我就说: 很多人这么做的并不能说就没问题,因为很多 人没有出现事故,是因为隐藏的问题没有机会暴露出来。我需要:
1:机制上的可靠保障,这个可能只有非常理解 原理的人能回答
2:实际系统的测试,要经过在我们自己提供的数据场景下反复测试

通过这两点之后我们才敢放心使用

使用道具 举报

回复
招聘 : 售前/售后支持
论坛徽章:
5
ITPUB元老
日期:2005-04-25 13:27:42授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:00
13#
 楼主| 发表于 2004-7-9 13:07 | 只看该作者
最初由 biti_rainy 发布
[B]上次做存储设备的来公司,谈到这个问题的时候说:  很多客户就是这么做的

我就说: 很多人这么做的并不能说就没问题,因为很多 人没有出现事故,是因为隐藏的问题没有机会暴露出来。我需要:
1:机制上的可靠保障,这个可能只有非常理解 原理的人能回答
2:实际系统的测试,要经过在我们自己提供的数据场景下反复测试

通过这两点之后我们才敢放心使用 [/B]

同意,确实很多人都是这么用的,也确实都很可能出现问题,所以我一直以为基于存储的数据库容灾方案是有问题的,但在有些环境中好像还只能这么做,例如我们的一个客户,也是一个省级的移动运营商,其数据库每天的日志量达到100G以上,在这种条件下,好像只有这种解决方案比较可行,其他的都会有一些问题,至少那些使用软件实现的逻辑复制方案是不行的,我感觉oracle自己的standby好像也负担不了吧?不过他们的数据库至少还是归档的,还有一点保证。呵呵。

使用道具 举报

回复
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
14#
发表于 2004-7-12 13:54 | 只看该作者
从ORACLE的角度来衡量基于存储的容灾肯定是有问题的,不可能做到100%可用。

即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失(当前日志组的数据)。

换个思路了,使用基于应用的同步方案吧。

使用道具 举报

回复
招聘 : 售前/售后支持
论坛徽章:
5
ITPUB元老
日期:2005-04-25 13:27:42授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:00
15#
 楼主| 发表于 2004-7-13 14:35 | 只看该作者
前两天太忙,一直没时间,今天继续总结,呵呵
(3)基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件,以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……

使用道具 举报

回复
招聘 : 售前/售后支持
论坛徽章:
5
ITPUB元老
日期:2005-04-25 13:27:42授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:00
16#
 楼主| 发表于 2004-7-13 15:31 | 只看该作者
继续……
基于redolog的逻辑复制产品有很多的优势,但跟上面提到过的其他方案比较起来,也有一些缺点:
数据库的吞吐量太大时,其实据会有较大的延迟,当数据库每天的日量达到60G或更大时,这种方案的可行性交差;
实施的过程可能会有一些停机时间,来进行数据的同步和配置的激活;
复制环境建立起来以后,对数据库结构上的一些修改需要按照规定的操作流程进行,有一定的维护成本。
不过目前这类产品的发展很快,上面的这些问题,在大部分产品的最新版本中都有很大的改进。

使用道具 举报

回复
论坛徽章:
0
17#
发表于 2004-7-19 15:02 | 只看该作者

我感觉如果是给别人做软件

用到的ORACLE功能太深,后来麻烦还是自己的,
他们维护不了

使用道具 举报

回复
论坛徽章:
0
18#
发表于 2004-7-20 10:18 | 只看该作者
我们单位存储使用的是EMC的磁盘阵列,我们通过EMC公司提供的TIMEFINDER软件,为数据库使用的逻辑卷建立了BCV,每天做同步然后把BCV断开,我们试过在生产卷的BCV卷上面把数据库启动起来,并能对生产数据库的归档文件进行恢复。

使用道具 举报

回复
论坛徽章:
0
19#
发表于 2004-7-22 13:44 | 只看该作者

请教lc7888

您说的备中心1/3机会不可用,是同步复制还是异步复制的情况?

使用道具 举报

回复
招聘 : 售前/售后支持
论坛徽章:
5
ITPUB元老
日期:2005-04-25 13:27:42授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:00
20#
 楼主| 发表于 2004-7-22 13:52 | 只看该作者

Re: 请教lc7888

最初由 Lee_Bill 发布
[B]您说的备中心1/3机会不可用,是同步复制还是异步复制的情况? [/B]

是指同步复制的情况。
这个数字我不敢保证它的准确性,因为我没有做过实际的实验来验证,但从我在客户那里看到的实际情况来说,基本属实。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表