Chinaunix

标题: 基于阵列的复制，oracle之类的数据库能保证同步么 [打印本页]

作者: bluevisual 时间: 2009-05-30 23:06
标题: 基于阵列的复制，oracle之类的数据库能保证同步么
最近看了一些CDP之类的文章，里面讲到两个阵列之间采用 SRDF或TrueCopy之类的技术，可以实现数据块级别复制。我有一个疑问：oracle之类的数据库能复制么，会丢失数据么，会不会造成数据库状态不一致的情况，业务切换的时候。

作者: yoyosys 时间: 2009-05-31 10:53
数据库不建议做存储级别的复制，这会导致数据的不一致性，在复制的过程中，内存中的数据是无法复制的。硬件级的复制对于文件级的没有影响。

作者: 无牙 时间: 2009-05-31 10:59
复制肯定会丢数的，只不过是多与少的问题。

作者: bluevisual 时间: 2009-05-31 11:35
我也是这样认为的，对于数据库之类的远程复制不适宜采用基于阵列的容灾

作者: qqadmini 时间: 2009-05-31 13:28
标题: 回复 #1 bluevisual 的帖子
HDS的官方文档说...基入阵列的复制是不会丢数据的...要看你采取什么模式...比如说..你采取Universal Replicator,的话..有两种模式可以选择...
就是同步和异步..........
1"同步保证数据一致性...
2"异步保证业务正常运行...不会同步一样有"等待停顿"的..

作者: 无牙 时间: 2009-05-31 14:06
H的比E的强

作者: mike79 时间: 2009-05-31 14:25
都不知道在说些什么，一点数据库的常识都没有。
基于存储的同步复制，配合数据库的日志机制，可以保证数据库中已经commit的数据不丢失，没有commit的数据在数据库起来后被rollback。而不是什么内存中的数据都丢失。
对于数据库而言，启用灾备存储上的数据库就相当于机器掉电以后被重启。因此在数据一致性上确实存在风险，比不上数据库自身的容灾方案，例如oracle的dataguard。

作者: qqadmini 时间: 2009-05-31 21:45

原帖由 mike79 于 2009-5-31 14:25 发表
都不知道在说些什么，一点数据库的常识都没有。
基于存储的同步复制，配合数据库的日志机制，可以保证数据库中已经commit的数据不丢失，没有commit的数据在数据库起来后被rollback。而不是什么内存中的数据都丢 ...

1:这里是存储版本,不是ORACLE版本.
2:LZ的问题就是问的基于阵列的.,就是问服务器里"两块硬盘,时刻都是互相复制状态" A和B,A坏了以后,B会不会和A一样,并且能继续无缝的工作.

[ 本帖最后由 qqadmini 于 2009-5-31 21:48 编辑 ]

作者: myguangzhou 时间: 2009-05-31 22:39
ORACLE COMMIT的数据只是写入OS认为的DISK而已，因此丢数据的风险还是存在的。
为保险起见，可以在OS安装AGENT的软件，与存储交互联动，保证数据的一致性。

作者: mike79 时间: 2009-05-31 23:27

原帖由 qqadmini 于 2009-5-31 21:45 发表

1:这里是存储版本,不是ORACLE版本.
2:LZ的问题就是问的基于阵列的.,就是问服务器里"两块硬盘,时刻都是互相复制状态" A和B,A坏了以后,B会不会和A一样,并且能继续无缝的工作.

先看清楚LZ问了什么：oracle之类的数据库能复制么，会丢失数据么，会不会造成数据库状态不一致的情况，业务切换的时候。
回答是
1，数据库也可以复制
2，只要数据库中commit的数据都不会丢失，没有commit的数据会丢失，而不是什么内存中的数据都丢失
3，对于灾备存储上的数据库，在启动时候就相当于经历了一次掉电

LZ没有说要无缝的工作。做存储的一点也不懂数据库的话，那就是在瞎做。
至于说服务器里"两块硬盘,时刻都是互相复制状态"，呵呵，这个错误就搞大了。存储复制是LUN对LUN的复制，在任何时刻都是一个做source，一个做target，不是什么相互复制状态。这些基本概念只要做过存储复制就都知道了。

作者: mike79 时间: 2009-05-31 23:38

原帖由 myguangzhou 于 2009-5-31 22:39 发表
ORACLE COMMIT的数据只是写入OS认为的DISK而已，因此丢数据的风险还是存在的。
为保险起见，可以在OS安装AGENT的软件，与存储交互联动，保证数据的一致性。

哈，在为H3C做忽悠？
Oracle的commit成功返回表示数据已经成功写入本地存储和灾备存储，所以说commit的数据不会丢失。但是数据写入存储并不是说数据所在的数据块被刷新，oracle中的commit成功就是把redo log项写入到redo log中。一旦启动灾备存储上的oracle，数据库要做instance recovery。

os上根本不需要什么agent，装了agent后就新引入了一个潜在的故障点以及影响数据库性能，只有坏处没什么好处。除了H3C之外就没厂商这么做了。

作者: yangm63 时间: 2009-06-01 10:02
H3C是飞康的CDP呦

作者: yoyosys 时间: 2009-06-01 10:10
从中还是学习到不少知识

作者: 旷野的呼唤 时间: 2009-06-01 12:17

原帖由 mike79 于 2009-5-31 23:38 发表

哈，在为H3C做忽悠？
Oracle的commit成功返回表示数据已经成功写入本地存储和灾备存储，所以说commit的数据不会丢失。但是数据写入存储并不是说数据所在的数据块被刷新，oracle中的commit成功就是把redo log ...

我没做过硬件级的复制
我想问的是：
还有阵列的cache和磁盘的cache。
怎么解决这两个问题？oracle的commit成功只是表示写阵列成功，并不代表已经写入磁盘。

作者: mike79 时间: 2009-06-01 12:27

原帖由 旷野的呼唤 于 2009-6-1 12:17 发表

我没做过硬件级的复制
我想问的是：
还有阵列的cache和磁盘的cache。
怎么解决这两个问题？oracle的commit成功只是表示写阵列成功，并不代表已经写入磁盘。

概念好混乱阿。
所谓写阵列成功，都是数据写入磁盘阵列的缓存就返回。至于什么时候将数据刷新到物理磁盘上，那是磁盘阵列自己控制的，中间还有raid算法等。这些对os是透明的，更不要说数据库层面了。而存储复制对于os也是透明的，os根本不知道是否存在存储复制，它就是等待磁盘阵列写返回。而本地磁盘阵列将写入缓存的数据复制到远端阵列的缓存，在远端阵列返回写成功后才向os返回写成功。

[ 本帖最后由 mike79 于 2009-6-1 12:28 编辑 ]

作者: myguangzhou 时间: 2009-06-01 15:36

原帖由 mike79 于 2009-5-31 23:38 发表

哈，在为H3C做忽悠？
Oracle的commit成功返回表示数据已经成功写入本地存储和灾备存储，所以说commit的数据不会丢失。但是数据写入存储并不是说数据所在的数据块被刷新，oracle中的commit成功就是把redo log ...

晕倒，我从没碰过H3C的东西。
在OS层安装AGENT之类的软件与存储集成，EMC和NETAPP都有类似的解决方案，貌似只有FOR ORACLE（貌似而已）；并不是只有IBM有的，才是最好的。
这位童鞋虽然是IBMER，但是也不必把别家的产品和技术说的如此不堪撒。

“Oracle的commit成功返回表示数据已经成功写入本地存储和灾备存储”，我不知道数据写入存储的缓存算不算“已经成功写入本地存储”？
OS和ORACLE都管不了存储的缓存，因此电池、UPS等对数据的保护才显得特别重要；当然，如果有AGENT和存储打交道就更好了。
好像成了托了

[ 本帖最后由 myguangzhou 于 2009-6-1 16:16 编辑 ]

作者: bluevisual 时间: 2009-06-01 17:02
两个阵列之间采用同步复制的话，Oracle数据库commit之后，这些数据肯定是已经写入到本地和远程灾备设备中（写入阵列的cache中，emc 也会返回一个正确的信息给前端客户端的）。这个是毫无疑问的，我想问的是：基于阵列的容灾能保证数据库中cache数据的完整性，通过oracle的回滚日志可以保证么。

作者: myguangzhou 时间: 2009-06-01 17:17

原帖由 bluevisual 于 2009-6-1 17:02 发表
两个阵列之间采用同步复制的话，Oracle数据库commit之后，这些数据肯定是已经写入到本地和远程灾备设备中（写入阵列的cache中，emc 也会返回一个正确的信息给前端客户端的）。这个是毫无疑问的，我想问的是：基 ...

如果数据库写入的数据完完整整地保存在阵列的缓存或者硬盘里，那么数据库当然可以通过instance recovery保证其数据不丢失了，所谓的数据一致性更不在话下

作者: mike79 时间: 2009-06-01 17:34

原帖由 myguangzhou 于 2009-6-1 15:36 发表
在OS层安装AGENT之类的软件与存储集成，EMC和NETAPP都有类似的解决方案，貌似只有FOR ORACLE（貌似而已）；

EMC也有？是什么agent？EMC的CX的MirrorView我也做过，貌似没听说过需要agent for oracle。

作者: mike79 时间: 2009-06-01 17:36

原帖由 bluevisual 于 2009-6-1 17:02 发表
我想问的是：基于阵列的容灾能保证数据库中cache数据的完整性，通过oracle的回滚日志可以保证么。

启用灾备存储上的数据库就相当于数据库服务器掉电重启，接下来就自己理解吧。

作者: mike79 时间: 2009-06-01 17:41

原帖由 myguangzhou 于 2009-6-1 15:36 发表

“Oracle的commit成功返回表示数据已经成功写入本地存储和灾备存储”，我不知道数据写入存储的缓存算不算“已经成功写入本地存储”？

所谓写入存储，就是阵列返回给OS成功。至于是阵列是等数据写入磁盘才给OS返回成功，还是数据写入缓存就返回成功，那是磁盘阵列的事情，OS才不管。OS就认为，既然你返回了成功，那么下次我就应该读到上次写入的数据。所以磁盘阵列要有双控制器，要有非丢失缓存或者UPS，要有write through等机制来保证写入的数据不丢失。

作者: myguangzhou 时间: 2009-06-01 18:19
晕倒，我还以为你们在说快照呢

作者: wolfop 时间: 2009-06-01 20:30

原帖由 旷野的呼唤 于 2009-6-1 12:17 发表

我没做过硬件级的复制
我想问的是：
还有阵列的cache和磁盘的cache。
怎么解决这两个问题？oracle的commit成功只是表示写阵列成功，并不代表已经写入磁盘。

同步复制的情况，commit成功保证了远程存储都已经收到相应的IO写请求和数据，同时，请记住，提供与远程复制能力的磁盘阵列一般都有自带备用电池，所以是否写入磁盘不是关键问题。当然，如果发生本地灾难和远程磁盘阵列同时故障的极端情况，不借助SHADOW IMAGE/BCV/FLASHCOPY的手段，仍然可能出现远程数据不可用的情况，但这种情况，你用DG一样不保证能数据可用。

作者: 旷野的呼唤 时间: 2009-06-02 10:10
标题: 回复 #20 mike79 的帖子
mike的说话是正确的。
抛开硬件本身的问题不谈。只要保障了oracle日志文件就保障了数据的一致性。
对于oracle来说，启用灾备存储就相当于数据库服务器掉电重启。
具体的过程要请熟悉ORACLE的人回答了。大概是这个时候会扫描数据文件、控制文件和日志中的scn号，进行一致性修复。

作者: 旷野的呼唤 时间: 2009-06-02 10:19

原帖由 mike79 于 2009-6-1 17:36 发表

启用灾备存储上的数据库就相当于数据库服务器掉电重启，接下来就自己理解吧。

其实我觉得讨论偏离了方向。基于硬件的复制问题，数据库本身有它自己的保障机制。
但是这个应该对硬件复制透明的吧。
我怎么觉得这个讨论应该是关注硬件复制如何保障数据同步而不是讨论ORACLE的机制吧。

本菜鸟没做过这么高深的玩意，只是纯粹借机学习。说错了请指正

[ 本帖最后由旷野的呼唤于 2009-6-2 10:20 编辑 ]

作者: mike79 时间: 2009-06-02 12:28

原帖由 旷野的呼唤 于 2009-6-2 10:19 发表

其实我觉得讨论偏离了方向。基于硬件的复制问题，数据库本身有它自己的保障机制。
但是这个应该对硬件复制透明的吧。
我怎么觉得这个讨论应该是关注硬件复制如何保障数据同步而不是讨论ORACLE的机制 ...

呵呵，那是因为很多人告诉LZ说硬件复制不适合数据库应用。

作者: cqubityj 时间: 2009-06-02 13:35
从理论上来讲，要保证灾备存储上的Oracle数据的一致性，就要求在阵列复制时，应用在灾备存储上的IO顺序与Oracle发给主阵列的IO顺序一致。而阵列复制一般都会重整IO，因此在灾备存储上应用IO的顺序有可能与Oracle发给阵列的IO顺序不一致，在这种情况下就有可能会出现问题。例如：oracle的IO顺序可能是IO1、IO2、IO3，而在灾备阵列上应用时可能是IO1、IO3、IO2。假设oracle向主阵列发了IO1、IO2、IO3，这时主阵列损坏了，而此时可能IO1和IO3已被传到灾备存储上，而IO2完全丢失了。这样在灾备存储上的数据可能就会出现不一致的情况。　
HDS的truecopy支持按顺序应用IO的机制，从理论上来讲，truecopy是安全的。

作者: mike79 时间: 2009-06-02 13:57

原帖由 cqubityj 于 2009-6-2 13:35 发表
而阵列复制一般都会重整IO，因此在灾备存储上应用IO的顺序有可能与Oracle发给阵列的IO顺序不一致，在这种情况下就有可能会出现问题

在胡说些什么呀。
同步复制，灾备存储接受到的IO顺序和主存储完全相同。
异步复制，各家厂商（EMC/HDS/IBM）都有各自的机制来保证IO一致性。

作者: cqubityj 时间: 2009-06-02 14:10

原帖由 mike79 于 2009-6-2 13:57 发表

在胡说些什么呀。
同步复制，灾备存储接受到的IO顺序和主存储完全相同。
异步复制，各家厂商（EMC/HDS/IBM）都有各自的机制来保证IO一致性。

我说的是在复制端以与源端相同的顺序应用IO，据我所知，HDS的truecopy是明确说过支持这一特性的。至于EMC和IBM我不知道他们现在是否支持。但有一点是可以肯定的，就是在异步复制过程中，数据的传输是不能保证按IO顺序的。

作者: cqubityj 时间: 2009-06-02 14:17

原帖由 mike79 于 2009-6-2 13:57 发表

在胡说些什么呀。
同步复制，灾备存储接受到的IO顺序和主存储完全相同。
异步复制，各家厂商（EMC/HDS/IBM）都有各自的机制来保证IO一致性。

给你一下网址参考
http://www.eygle.com/archives/2009/05/hds_truecopy_dataguard.html
这里简略介绍了truecopy的实现原理，但说的很清楚。我没有详细了解过IBM和EMC的产品，不清楚他们是否支持这一特性。

作者: mike79 时间: 2009-06-02 14:50

原帖由 cqubityj 于 2009-6-2 14:10 发表

我说的是在复制端以与源端相同的顺序应用IO，据我所知，HDS的truecopy是明确说过支持这一特性的。至于EMC和IBM我不知道他们现在是否支持。但有一点是可以肯定的，就是在异步复制过程中，数据的传输是不能保 ...

顺序IO只是实现数据一致性的一种手段，不是唯一手段，甚至不是最好的手段。
异步复制通常都设置有时间间隔，假设在在时间间隔内源端密集的轮流修改两个block，block 1-->block 2-->block 1-->block 2......最后的结果就是虽然只修改了2个数据块，可能不超过1MB，但是累加的修改量很大，可能超过1GB。此时hds怎么进行异步复制？难道把这1GB的修改量都复制过去？这不是傻了嘛，纯粹在浪费带宽。还不如把这2个block打包复制过去，要求对端要么都apply，要么都不apply。这样既保证了数据一致性，又节省带宽。

作者: mike79 时间: 2009-06-02 14:55

原帖由 cqubityj 于 2009-6-2 14:17 发表

给你一下网址参考
http://www.eygle.com/archives/2009/05/hds_truecopy_dataguard.html
这里简略介绍了truecopy的实现原理，但说的很清楚。我没有详细了解过IBM和EMC的产品，不清楚他们是否支持这一特性。

truecopy以前也实施过，对它的原理还是有印象的。记得是将源端的IO顺序缓存下来，在异步复制的时候按照源端IO顺序传输到灾备端。所以需要一定数量的缓存来保存这些IO。假设因为链路中断，异步复制被迫停止了24小时。而这24小时内源端的IO量很大，超过100GB，你需要多大的缓存来保存这些IO才能保证IO顺序？遇到这种情况，还不是一样乱序传输。

作者: bbjmmj 时间: 2009-06-02 15:54
我们前几天就被自家人给刨了光缆。现在全国大搞房地产、动迁，通信线路损坏的可能性是很高的，不能不考虑。

存储复制最要命的就是通信中断，无论同步复制还是异步复制，都存在这个风险，灾备线路一旦中断，业务就要停止，虽然可以用MULTIPATH、路由之类的辅助手段加以预防，但并没有彻底解决业务中断的问题，比如灾备中心发生火灾，或者设备故障，那业务就不可避免地要中断，所以业界才搞出个“非计划内停机”的概念来糊弄大家

盘阵容灾还有两项功能需要实现，第一，只有写入操作才向远端传送数据，这样做的目的主要不是节约带宽，而是减小网络延迟；第二，线路意外中断时，应能在较短的时间内自动继续业务。

作者: mike79 时间: 2009-06-02 15:58

原帖由 bbjmmj 于 2009-6-2 15:54 发表
灾备线路一旦中断，业务就要停止

大神又来布道啦？

作者: bbjmmj 时间: 2009-06-02 16:03

原帖由 mike79 于 2009-6-2 15:58 发表

大神又来布道啦？

唉！我记得跟你说过，要你小心民工大哥刨你光缆，想不到这种事发生在我头上了，网络断了整整三天！

作者: wolfop 时间: 2009-06-02 16:31

原帖由 bbjmmj 于 2009-6-2 15:54 发表
我们前几天就被自家人给刨了光缆。现在全国大搞房地产、动迁，通信线路损坏的可能性是很高的，不能不考虑。

存储复制最要命的就是通信中断，无论同步复制还是异步复制，都存在这个风险，灾备线路一旦中断，业 ...

我就猜到大神一看到火贴就要来布道的，呵呵。

让俺来崇拜崇拜，千万别拦着。

作者: 雪凤凰 时间: 2009-06-03 10:54
大家概念都抠得很细啊
这是CU的好风气
嘿嘿

作者: bbjmmj 时间: 2009-06-03 13:21

原帖由 wolfop 于 2009-6-2 16:31 发表

我就猜到大神一看到火贴就要来布道的，呵呵。

让俺来崇拜崇拜，千万别拦着。

我就喜欢凑热闹

作者: lostgamer 时间: 2009-06-03 13:34
肯定不能保证！或多或少丢失。

作者: myguangzhou 时间: 2009-06-03 14:07
我只知道人肯定会死的，其他都不敢打包票

作者: bluevisual 时间: 2009-06-03 14:31
想不到，俺的这个帖引来这么多路神仙光顾，学到了好多技术细节。

作者: forecast777 时间: 2009-06-03 15:05
如果出现链路中断，是否基于阵列的远程复制技术，基本都无法避免一致性问题？？
印象中VVR有专门针对链路中断的考虑，不晓得实际是怎样的？

作者: 无牙 时间: 2009-06-03 15:14
都有类似的机制。

作者: laosun 时间: 2009-06-03 15:31
百密必有一疏，现代IT还做不到真正的安全！

作者: forecast777 时间: 2009-06-03 16:10
产品是一个变量；交付是一个变量；运维也是一个变量:wink:

作者: babyyellow 时间: 2009-06-03 17:50
如果可以设定复制时按照oracle 的数据块的尺寸来读的话，是没有问题的

复制完了，然后把原库的归档日志和onlineredo 也复制过去,是可以的

作者: yoyosys 时间: 2009-06-03 17:51
CDR要用这个功能就强大了

作者: forecast777 时间: 2009-06-04 11:06

原帖由无牙于 2009-6-3 15:14 发表
都有类似的机制。

阵列层面如何保障一致性呢？ bitmap是不能实现交易级的一致性的。中端阵列大多是bitmap方式吧？有类似VVR SRL或VXVM DCO之类的东西么？

印象中高端阵列好像有类似于time stamp之类的机制，这种机制和LOG机制比如何呢？

另外请教,如果VVR SRL写满，启用了DCM是否也无法保障一致性了？？

[ 本帖最后由 forecast777 于 2009-6-4 11:09 编辑 ]

作者: 无牙 时间: 2009-06-04 11:16
如果VVR SRL写满，启用了DCM，也是能保证一致性的。
数据复制后是不是能用，和数据库本身的机理有关系，这时候就要靠数据库的日志来前滚或者后滚。

作者: forecast777 时间: 2009-06-04 11:32
阵列如何能够保障复制时的一致性呢？
如果redo log都有问题了，如何前滚或者后滚

作者: forecast777 时间: 2009-06-04 11:35

原帖由无牙于 2009-6-4 11:16 发表
如果VVR SRL写满，启用了DCM，也是能保证一致性的。
数据复制后是不是能用，和数据库本身的机理有关系，这时候就要靠数据库的日志来前滚或者后滚。

谢谢！

阵列的time stamp也是一个卷么？如果写满写bitmap也不能保障一致性吧？

time stamp和veritas Log机制有优缺点的不同么？？

作者: mmmmn 时间: 2009-06-04 17:31

原帖由 bbjmmj 于 2009-6-2 15:54 发表
存储复制最要命的就是通信中断，无论同步复制还是异步复制，都存在这个风险，灾备线路一旦中断，业务就要停止，虽然可以用MULTIPATH、路由之类的辅助手段加以预防，但并没有彻底解决业务中断的问题，比如灾备中心发生火灾，或者设备故障，那业务就不可避免地要中断

不明白

作者: ffaatt 时间: 2009-06-04 17:56
标题: 我的一点看法：
我是做售前的，对技术细节没有深入了解，以下观点未必正确，请大家指正。
1.基于阵列的同步模式远程复制是能够保证数据一致性的，至于数据是在阵列Cache还是写入了Disk没有什么关系；在数据库Cache中的数据不一致是由数据库自己的log机制负责的，和阵列没有关系；
2.在异步模式下比较复杂
1).异步模式丢数据很正常，但是需要保证2个事情，a.链路中断后已传输的数据始终是一致的，b.链路恢复后续传的数据也是一致的（当链路再次中断仍然能够保持正确）
2)大多数阵列异步模式的实现方法：在Cache中建立IO队列（可能有timestamp），在多个磁盘卷之间建立一致性组（包括数据库的数据文件、日志文件等），这样基本都能满足a.的需求
3)问题是阵列Cache大小有限，当链路速度太慢或者长时间中断时，Cache队列溢出了，有些阵列只能放弃复制，等链路恢复后重新来过（所有源数据再拷贝一次），有些阵列放弃队列模式，改用Bitmap模式，在链路恢复后先按照Bitmap复制，完成后再回到正常的队列模式，这两种阵列都不能满足b.的需求。在容灾系统规划中就是“二次容灾问题”，当第一次灾难结束/链路恢复后，如果在数据没有完全同步时再来一次灾难，那么远端数据就是不一致的，容灾就白做了(仅指阵列层面)，所以在第一次链路恢复后，不能立刻同步数据，而是先把远端的数据做一个本地复制(Shadowimage之类)，然后再同步，即使再次发生灾难，至少远端还有一份老一点的数据。关键它是"一致的"，可以用来恢复应用；
  4)在高端磁盘阵列中(其实真正的高端也就HDS USP和EMC，加HP OEM的XP),USP/XP有3种复制模式：“同步”，“异步”，“日志异步”。日志异步就是在阵列中专门配置一个RAID组用于存放IO日志(带Timestamp)，这样在链路中断时可以继续记录IO队列(RAID组可以保存TB级的数据，Cache是GB级的)，因此可以满足b.的需求。还有一些其他的好处，日志异步方式是由远端主动到本地读取日志的“拉”模式，而不是本地发送到远端的“推”模式，这样本地阵列在复制中始终是被动的，负载较小，而且链路中断时也不需要操心，链路恢复后由远端来“拉”即可；另外日志模式可以容易实现1点对多点的容灾，1个本地阵列可以复制到多台远端阵列
  5)在中端阵列中(EMC CX, HP EVA, IBM/SUN/ DS, Netapp FAS)，我只知道EVA的异步复制是日志模式的，称作"WHL"(Write History Log)，因为EVA的磁盘空间是划分是自动分配的，所以阵列上没有专门的日志盘，所有空闲的磁盘空间都可以拿来做日志，无需管理员干预，所以EVA基本也可以满足二次容灾的需求。
  6)综上所述，异步有“Cache队列Timestamp+磁盘Bitmap”，“磁盘写日志”2中模式，后面一种可以始终保持数据一致性

3.顺便说句和存储无关的题外话
在容灾中要求保证一致性其实有很多层面的方法，阵列是其中一个层次，还需要其它层面的配合
1)业务流程，例如每个业务操作都留有凭证，即使数据库中丢了数据也能再输进去
2)应用软件，在写数据库之前先做一个log并传到异地
3)数据库、操作系统/文件系统层面的日志/回滚技术
4)最低层，最简单的是阵列复制层面的

[ 本帖最后由 ffaatt 于 2009-6-4 18:46 编辑 ]

作者: jadge 时间: 2009-06-04 18:29
看大家都是在讨论Oracle数据库，其他哪些数据库也可以与这个原理差不多呢？望各位赐教...不胜感谢

作者: ffaatt 时间: 2009-06-04 18:53
各种主流的数据库产品一般都有日志、回滚这一套，还有类似的应用如Exchange、Domino等也差不多。主流的阵列厂商（包括Veritas这样的存储软件商）一般都会把自己的本地复制和和异地复制和这些应用集成起来，有些做为实施服务来卖，有些免费给个脚本模板，还有一些打包成为一个产品模块来卖，

作者: wolfop 时间: 2009-06-04 20:09

原帖由 forecast777 于 2009-6-4 11:32 发表
阵列如何能够保障复制时的一致性呢？
如果redo log都有问题了，如何前滚或者后滚

你本地的redo log如果都有问题了，你如何前滚或者回滚？

作者: forecast777 时间: 2009-06-04 20:27

原帖由 wolfop 于 2009-6-4 20:09 发表

你本地的redo log如果都有问题了，你如何前滚或者回滚？

呵呵，我那个是反问句。
赞成“ffaatt“等人的观点。

作者: forecast777 时间: 2009-06-04 21:13

原帖由 ffaatt 于 2009-6-4 17:56 发表
我是做售前的，对技术细节没有深入了解，以下观点未必正确，请大家指正。
1.基于阵列的同步模式远程复制是能够保证数据一致性的，至于数据是在阵列Cache还是写入了Disk没有什么关系；在数据库Cache中的数据不一 ...

有两个疑问请您指点：
1）Time stamp各厂商都在内存实现么？有没有把它放在一个独立卷中的？是否存在一个所需cache大小和带宽、数据量/频繁度等指标的对应关系公式？

2）您说“所以在第一次链路恢复后，不能立刻同步数据，而是先把远端的数据做一个本地复制(Shadowimage之类)，然后再同步” 这个是通过脚本实现么？在push模式下，这个脚本触发问题如何把握？？
另外某客户案例是在备援站点每隔一个时间做个SI，这样实现一致性和其它数据使用用途。这个是最佳方法么？

[ 本帖最后由 forecast777 于 2009-6-4 21:15 编辑 ]

作者: xiaomao2006 时间: 2009-06-04 23:38
很好的题目,顺便问一下,oracle的数据盘或文件用snapshot做备份,不管哪个厂商的,能从snapshot恢复吗,我认为能,问题是数据会损失多少?

作者: bbjmmj 时间: 2009-06-05 12:51
感觉楼上FFAATT对存储复制的说法已经比较权威了。
说说我的看法，我不赞成使用存储复制。
一方面是存储复制太耗费带宽，比如更改表中一个记录中某个字段的值，这个操作，至少会影响到存储数据库文件的存储系统的一个数据块，同时还会影响日志文件，也就是说，即使我只是该了某个记录中一个整形字段的值，使用存储复制都要至少复制两个以上的数据块，实际数据发生更改的部分可能远远小于块的尺寸，这个时候就存在带宽严重浪费的情况。
另一方面，如果远端没有来得及“拉”块，主存储即发生了损坏，这个时候，不但要丢数据，甚至有可能破坏文件系统，这个问题比数据库本身提供的REDO LOG要严重得多，REDO LOG只是丢掉一个操作，不存在破坏文件系统的问题。

作者: wolfheader 时间: 2009-06-05 13:15

原帖由 ffaatt 于 2009-6-4 17:56 发表
我是做售前的，对技术细节没有深入了解，以下观点未必正确，请大家指正。
1.基于阵列的同步模式远程复制是能够保证数据一致性的，至于数据是在阵列Cache还是写入了Disk没有什么关系；在数据库Cache中的数据不一 ...

顶，了解了重要问题

EVA的问题

eva提供了snapclone和mirror clone两种模式，正好需要clone一个oracle 所在的datavg出来做测试用，选择snapclone的话cache使用模式必须是writetrhough。

用mirrorclone，可以允许source卷使用cache，大概原因就是你说的这样。

不过我准备把oracle down了再刮起mirror卷测试，而且只有一个主机，没法测试在orale活的时候使用mirror起数据库了：（

原来试过基于os的复制，legato的co-standby可以使用本地卷替代共享盘做cluster，还有legato的replistor，可以复制oracle所在卷到异地，不是都是在切换发生时有一系列动作，对各种数据库支持都很好。

基于阵列的mirror，从技术上怎么都比基于os要更安全，丢失数据更少。

我说的不一定对，嘿嘿

作者: mike79 时间: 2009-06-05 15:06

原帖由 bbjmmj 于 2009-6-5 12:51 发表
感觉楼上FFAATT对存储复制的说法已经比较权威了。
说说我的看法，我不赞成使用存储复制。
一方面是存储复制太耗费带宽，比如更改表中一个记录中某个字段的值，这个操作，至少会影响到存储数据库文件的存储系统 ...

大神又来布道了，大家想鼓掌的鼓掌，想跑的快跑阿。

作者: mike79 时间: 2009-06-05 15:11

原帖由 wolfheader 于 2009-6-5 13:15 发表

顶，了解了重要问题

EVA的问题

eva提供了snapclone和mirror clone两种模式，正好需要clone一个oracle 所在的datavg出来做测试用，选择snapclone的话cache使用模式必须是writetrhough。

用mirrorcl ...

基于OS的复制还需要第三方软件？不用这么麻烦吧。做个LVM Mirror，把一份拷贝放在异地不就可以了？
AIX的GLVM的最新版本还支持异步复制，不过没测试过。只测试过同步的GLVM，理论上和基于存储复制一样不丢数据，很经济实惠。

作者: wolfheader 时间: 2009-06-05 15:30

原帖由 mike79 于 2009-6-5 15:11 发表

基于OS的复制还需要第三方软件？不用这么麻烦吧。做个LVM Mirror，把一份拷贝放在异地不就可以了？
AIX的GLVM的最新版本还支持异步复制，不过没测试过。只测试过同步的GLVM，理论上和基于存储复制一样不丢数 ...

所以那个软件几乎淘汰了，整合到aam中了，还是有些不错的附加功能的

作者: wolfop 时间: 2009-06-05 17:26

原帖由 ffaatt 于 2009-6-4 17:56 发表
我是做售前的，对技术细节没有深入了解，以下观点未必正确，请大家指正。
1.基于阵列的同步模式远程复制是能够保证数据一致性的，至于数据是在阵列Cache还是写入了Disk没有什么关系；在数据库Cache中的数据不一 ...

EMC的DMX什么时候加了日志模式了？DMX-3的时代我没听说，DMX-4加的？

作者: bbjmmj 时间: 2009-06-08 14:47

原帖由 mike79 于 2009-6-5 15:11 发表

基于OS的复制还需要第三方软件？不用这么麻烦吧。做个LVM Mirror，把一份拷贝放在异地不就可以了？
AIX的GLVM的最新版本还支持异步复制，不过没测试过。只测试过同步的GLVM，理论上和基于存储复制一样不丢数 ...

不是所有LVM都支持Mirror，而且做Mirror也不一定非要用LVM，分区也可以Mirror。

作者: mike79 时间: 2009-06-08 16:37

原帖由 bbjmmj 于 2009-6-8 14:47 发表

不是所有LVM都支持Mirror，而且做Mirror也不一定非要用LVM，分区也可以Mirror。

大神来啦，大家收拾衣服快跑阿~~~~

作者: bbjmmj 时间: 2009-06-08 19:17

原帖由 mike79 于 2009-6-8 16:37 发表

大神来啦，大家收拾衣服快跑阿~~~~

不至于吓成这样吧？

其实阵列复制也好，LVM mirror 也好，都是比较蠢的法子，从安全性、可靠性、效能方面考虑，逻辑复制、GFS效果会更好些。

作者: mike79 时间: 2009-06-08 20:18

原帖由 bbjmmj 于 2009-6-8 19:17 发表

不至于吓成这样吧？
其实阵列复制也好，LVM mirror 也好，都是比较蠢的法子，从安全性、可靠性、效能方面考虑，逻辑复制、GFS效果会更好些。

呵呵，大神你说啥就是啥。

就是没人听你的。

作者: bbjmmj 时间: 2009-06-09 08:34

原帖由 mike79 于 2009-6-8 20:18 发表

呵呵，大神你说啥就是啥。
就是没人听你的。

我还记得在网易跟你掰扯REDO LOG的时候你那个不认账的样子呢，太可爱了

你前面回帖说的“存储复制是LUN对LUN的复制，在任何时刻都是一个做source，一个做target，不是什么相互复制状态。”也是错的，存储复制可以一对一、一对二甚至一对多，如果我用ISCSI做成软RAID1，那就真的可以相互复制了。

作者: mike79 时间: 2009-06-09 10:23

原帖由 bbjmmj 于 2009-6-9 08:34 发表

我还记得在网易跟你掰扯REDO LOG的时候你那个不认账的样子呢，太可爱了

你前面回帖说的“存储复制是LUN对LUN的复制，在任何时刻都是一个做source，一个做target，不是什么相互复制状态。”也是错 ...

呵呵，你说错那就错吧。要是你认为我说对了，我倒要好好反思了：难道我已经退化到大神这种地步了？

ps 我记得在网易也是没人听大神的。不过大家公认，大神最强的就是会拿大移动硬盘给领导拷贝电影会拔网线。这种事情，没有几十年的功力是做不来的。

作者: easybegin 时间: 2009-06-09 10:27
学习一下

作者: 聪明笨小孩 时间: 2009-06-09 14:27
路过了解一下

作者: 100心 时间: 2009-06-09 22:01
强帖留名，飞康CDP，我还不知道是什么东西。

作者: kimifc 时间: 2009-07-02 15:42
问题越挣越明了~~

作者: spook 时间: 2009-07-03 09:05

原帖由 wolfop 于 2009-6-4 20:09 发表

你本地的redo log如果都有问题了，你如何前滚或者回滚？

删除掉，再走一次手工好了……

作者: wolfheader 时间: 2009-07-03 11:30
前几天翻不到这个帖子了，幸好被顶起来了

测了一下，用bc 做了mirror ，在oracle open状态下，把mirror拆开，拆开的volume挂起来，oracle照样是好的。

作者: redwaves 时间: 2009-07-03 11:32
基于阵列的复制可以通过同步mirror去保证数据，异步方式不可以

作者: wolfop 时间: 2009-07-03 22:57

原帖由 spook 于 2009-7-3 09:05 发表

删除掉，再走一次手工好了……

如果是active的那个呢？

作者: desert969 时间: 2010-11-18 19:02
本帖最后由 desert969 于 2010-11-18 19:03 编辑

测了一下，用bc 做了mirror ，在oracle open状态下，把mirror拆开，拆开的volume挂起来，oracle照样是好的。

巧合吧！

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)