基于存储容灾安全性置疑

cqubityj

原帖由 vecentli 于 2008-12-25 13:58 发表
我上面说明是把redo放到fs上，fs是有cache的，这样在主机crash的时候就会丢失数据，导致redo损坏。

这个cache是指fs的cache，不是storage的cache。

我说的也是文件系统的cache。具体我也不太确定Redo的写操作是否是不做cache的。但我个人认为如果Redo文件写操作做cache的话，风险比较大。Oracle的写操作是调用操作系统的write()操作完成的，而在调用write()操作时应该是可以设置参数来保证不做cache的。这样就类似于存储的write through.

shahand

原帖由 vecentli 于 2008-12-25 13:58 发表
我上面说明是把redo放到fs上，fs是有cache的，这样在主机crash的时候就会丢失数据，导致redo损坏。

这个cache是指fs的cache，不是storage的cache。

oracle  default是bytpass fs cache的。

http://download.oracle.com/docs/ ... p_unix.htm#CEGEFGCF


On both UNIX and Windows platforms, bypassing the file system buffer cache ensures data is written to disk.

On UNIX, Oracle uses the O_SYNC flag to bypass the file system buffer cache. The flag name depends on the UNIX port.

On Windows, Oracle bypasses the file system buffer cache completely.

wolfop

原帖由 shahand 于 2008-12-31 12:09 发表


oracle  default是bytpass fs cache的。

http://download.oracle.com/docs/ ... p_unix.htm#CEGEFGCF


On both UNIX and Windows platforms, bypassing the file system buffer cache ensures data is written to disk.

On UNIX, Oracle uses the O_SYNC flag to bypass the file system buffer cache. The flag name depends on the UNIX port.

On Windows, Oracle bypasses the file system buffer cache completely.

其实没那么简单，文件系统的元数据那部分，可不是受ORACLE控制。有可能fsck或者replaylog之后，文件找不到的情况。

anycall2010

原帖由 eagle3250 于 2008-12-25 17:49 发表
存储容灾是相对的,主库起不来,比如undo 或redo 坏了,
容灾端也起不来的;如果不能recover,就会丢数据了

如果镜像卷做了快照呢？

anycall2010

感谢ruluo ；我明白你的意思了。我客户目前有这样一个需求：在镜像卷的存储上放置一台服务器，让该服务器能够查询镜像卷的数据，我是否在镜像卷存储上加一个快照就能实现？

youngcow

基于存储级的容灾我做过几次测试。如果存储级别做的比较好，可以认为两边硬盘上的数据是完全一致的。但是仅仅是硬盘数据是一致的不一定数据库能正常启动。从原理上说如果源端没有把数据库的文件写坏掉，容灾端就相当于是数据库异常掉电的状态。在异常掉电的情况下，丢失的是内存中被更改的数据缓冲区中的数据，commit后的redolog会写入到硬盘中（默认是不带cache的）。当然，如果源端的业务量太大，而且没有commit的时候就挂了，容灾端启动可能需要很长时间（做rollback）。我做测试的时候发起一个事务写入10G的数据，在没有完成的情况下掉电，容灾端我们等了3个小时都没有rollback完成，这种情况就郁闷了。

ruluo

对的

anycall2010

原帖由 youngcow 于 2009-1-7 21:46 发表
基于存储级的容灾我做过几次测试。如果存储级别做的比较好，可以认为两边硬盘上的数据是完全一致的。但是仅仅是硬盘数据是一致的不一定数据库能正常启动。从原理上说如果源端没有把数据库的文件写坏掉，容灾端就相当于是数据库异常掉电的状态。在异常掉电的情况下，丢失的是内存中被更改的数据缓冲区中的数据，commit后的redolog会写入到硬盘中（默认是不带cache的）。当然，如果源端的业务量太大，而且没有commit的时候就挂了，容灾端启动可能需要很长时间（做rollback）。我做测试的时候发起一个事务写入10G的数据，在没有完成的情况下掉电，容灾端我们等了3个小时都没有rollback完成，这种情况就郁闷了。

1、楼上说的“但是仅仅是硬盘数据是一致的不一定数据库能正常启动”是指数据库的交易顺序问题，也是我主题所说的问题。这个概率有多少？楼上做过测试吗？要是有，给讲一讲。

2、楼上说的这种情况，肯定会出现这样的问题，非常感谢您能提供出来。但是有没有什么解决办法？请指教。

anycall2010

原帖由 ruluo 于 2009-1-9 00:27 发表
对的

快照分克隆和SNAPSHOT，如何灵活应用这两个武器，保证数据库容灾的安全性，请前辈指教。

funnyok

原帖由 anycall2010 于 2009-1-12 12:21 发表


快照分克隆和SNAPSHOT，如何灵活应用这两个武器，保证数据库容灾的安全性，请前辈指教。

clone是复制，snapshot只是提供一个journal，所以snapshot不适于大量更新，而且相对而言对于sp的负荷也比较大，由于副本和原本的许多block是在一起的，所以副本的io操作会影响到原本的性能。