基于存储容灾安全性置疑

anycall2010

如果使用基于存储层面的容灾。如果不小心误删除数据，如果不小心删除东西的话，两套存储里的数据都会被删除，如何规避？有没有什么好的解决方案？有做过的给帮忙建议一下？

anycall2010

原帖由 wolfop 于 2008-12-15 15:06 发表
10次有8次起不来，夸张了，就算异步复制，10次有一次起不来都不到。
何况很多容灾都是先做同步复制，再异步复制到更远的距离。
当然，究竟能否起来，不是那么简单，万一真是站点故障，你怎么保证生产端的CPU、内存没傻掉，把active redolog写坏了。所以一般会再弄多一份BCV/FLASHCOPY/SHADOWIMAGE之类的东西。

楼上能不能说深入点，需要你们的帮助。

vecentli

我上面有描述。

原帖由 anycall2010 于 2008-12-19 21:15 发表
如果使用基于存储层面的容灾。如果不小心误删除数据，如果不小心删除东西的话，两套存储里的数据都会被删除，如何规避？有没有什么好的解决方案？有做过的给帮忙建议一下？

ruluo

有快照嘛

allway

基于存储容灾启不来的概率和，按RESET按钮后启不来的概率一样，都应该非常小

anycall2010

原帖由 ruluo 于 2008-12-16 14:01 发表
我做过，就没有发现起不来的情况，:-)

DA1放在主站点，DA2放在备站点，每个上面都有一个大小相同的卷，主站点DA1上的卷暂时叫做在线卷，备用站点DA2上的卷成为镜像卷。数据通过光纤网络从DA1上的在线卷复制到DA2上的镜像卷，定时对镜像卷做快照，通过快照验证数据库是否能够正常打开。如果DA1坏掉，可以从DA2上的最近的可用快照就可以打开数据库。

请教前辈，需要存储什么软件？卷拷贝？卷复制？其他克隆软件？

cqubityj

原帖由 vecentli 于 2008-12-17 13:46 发表
我觉得存在起不来的可能，比如redolog放在fs上面。
有一些更改可能还在fs的cache里面，如果此时生产端发生故障，则有可能导致数据库不一致。

redo是直接写到磁盘里而不会放在操作系统的cache里吧。否则一旦down机，cache里的东西一定是丢了，而如果有些东西还没有写到磁盘上，那相当于在线日志不完整或不正确，理论上连instance recovery可能都保证不了。这和用不用存储阵列没什么关系。

vecentli

我上面说明是把redo放到fs上，fs是有cache的，这样在主机crash的时候就会丢失数据，导致redo损坏。

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

原帖由 cqubityj 于 2008-12-25 11:19 发表
redo是直接写到磁盘里而不会放在操作系统的cache里吧。否则一旦down机，cache里的东西一定是丢了，而如果有些东西还没有写到磁盘上，那相当于在线日志不完整或不正确，理论上连instance recovery可能都保证不了。这和用不用存储阵列没什么关系。

eagle3250

存储容灾是相对的,主库起不来,比如undo 或redo 坏了,
容灾端也起不来的;如果不能recover,就会丢数据了

ruluo

看#40