数据库容灾、复制解决方案全分析

mandrake

我看这个帖子是一年以前开的，不敢确信各位老大是否还有兴趣和时间来讨论容灾技术问题？


    我最近遇到案例需要用到存储级的容灾方案，但听到这里很多大侠说这种方案不可用，想在这里再次请教各位。

环境：
1.        主中心和备份中心使用光纤线路连接，两端加载密集波分设备，带宽不是问题（当然得考虑光纤线路中断）。由于种种原因，两个中心距离限制在几十公里以内。
2.        主中心和备份中心使用同构的存储设备，以准同步的方式复制数据。
3.        数据库系统均为Oracle

    很多大侠说这种方式可能在灾难发生时备份中心的Oracle无法打开，原因是传输到备份中心的数据块可能失序，但据我了解的技术情况来说，似乎这种可能性极小：理由如下：

    一、目前很多基于存储级的复制技术，都提供了基于全局镜像这样一种实现机制。根据IBM的技术白皮书来说，是这样描述的：

    来自主机的数据被写往本地连接的磁盘系统，该系统立即向主机返回一个I/O完成指示。数据在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程磁盘系统。异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。
单纯的异步拷贝由于线路距离较远等原因，本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。这种方式也叫做“全局拷贝(Global Copy)”

    在全局拷贝(Global Copy)的情况下，比如本地磁盘系统提供给主机5个逻辑卷，某一时刻主机对这些逻辑卷发起了A，B，C，D，E，5个写盘请求，本地的磁盘系统的写顺序是A，B，C，D，E。但是由于线路等原因，远地的磁盘系统在接收写请求时，收到的顺序可能是A，C，B，D，E。写盘的顺序也是A，C，B，D，E。我们假设灾难发生在这5个写操作D，B的中间部分，那么这时远地的数据C很有可能是没有意义的，甚至是无理的。

    为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异，有的磁盘系统提供带有一致性组的异步远程数据拷贝。在这种方式下，远地的磁盘系统会将先收到的写请求缓存起来(比如上面的数据C)，等到它前面的数据(A,B)到达后，再按照顺序写盘。这种方式也叫做“全局镜像(Global Mirror)”。

  无论是IBM还是HP的存储产品，都采用了上述原理来实现其产品(HP的CA采用了类似时间戳的机制，确保一批数据写的一致性，类似提交，要么都成功，要么都不成功)，从此可以看出，在备份中心出现数据写的顺序不一致情况几乎是不可能发生的。备份中心数据写延时造成的数据丢失另当别论。这里想要得到的结论只是：数据写的顺序不一致理论上是不存在的。

    二、Oracle的工作原理是：当提交事务时，先写联机日志文件，成功以后再写数据文件。也就是说，数据文件的内容滞后于联机日志文件，凡是写到数据文件中的内容，首先经过了联机日志文件。如果灾难发生在写数据文件的时候，可能出现备份中心的数据文件内容紊乱。但是这可以出通过备份中心镜像的联机日志文件来恢复。

    由于联机日志文件长期处于写状态，那么如果灾发生在写联机日志文件机的时刻，这时，镜像的备份中心的存储系统写入联机日志文件的，就只是提交的事务的一部分，非完整的。这种情况下，Oracle数据库在启动时会检查联机日志文件做Recover操作，当Oracle顺序检查(存储也是循序写的)联机日志文件有错误的时候，就会停止恢复。这时数据库是可以打开的。这样损失的内容只是灾难发生时刻写到联机日志文件的少部分数据。


    以上是我对存储级复制技术实现容灾的理解。不对之处请大家指正。

zhxx_ora

做个记号,认真研读一下

biti_rainy

最初由 lijietz 发布
[B]没时间,就看了前面2页..发表一下自己的看法.hehe
                                                               
我觉得异地容灾的可靠性是可以得到保证的,就emc mirrorview来说把.
一次i/o不是写到本地存储就可以上报给主机表示i/o完成了的.
                                             
假如深圳(主机和存储a)和上海(存储b)异地容灾,一次i/o完成
应该是写到存储a上,a通过san,写到存储b上,当b也写入了..b通知a,此时a再通知主机.
一次i/o才算完成..而不是写入到a就算一次i/o完成了.
这样一来,对上层oracle来说,跟写到本地存储是没有区别的.
只是emc这样做.i/o的原子性大小不一样.效率多少会受到影响.
                       
而存储一般都有ups,即使没有,好点的存储都能保证在断电前把
cache中的内容写入到硬盘. [/B]

存储级别的容灾，如果是同步的，受限于距离问题，一般在几十公里以内，实施成本比较高。


所以你说的深圳和上海之间，几乎是不大可能做同步的，那系统会拖死掉的。

lijietz

最初由 biti_rainy 发布
[B]


存储级别的容灾，如果是同步的，受限于距离问题，一般在几十公里以内，实施成本比较高。


所以你说的深圳和上海之间，几乎是不大可能做同步的，那系统会拖死掉的。 [/B]

恩，是这样的。

不过平安保险的ERP系统好像就在上海和深圳做了容灾，并发用户有1000多，对ERP这种高消耗资源的系统来说是很恐怖了，好像他们用的是emc cx700..

biti_rainy

最初由 lijietz 发布
[B]

恩，是这样的。

不过平安保险的ERP系统好像就在上海和深圳做了容灾，并发用户有1000多，对ERP这种高消耗资源的系统来说是很恐怖了，好像他们用的是emc cx700.. [/B]

那估计是异步

Fenng

最初由 Kamus 发布
[B]

在推广一个好产品之前，通常需要先作一个好的主页

你提到的这个站点的美工和样式实在让我不敢恭维。。。 [/B]

哈哈哈哈

Telamon

高级复制应该有一定的局限性

charles_gao

高级复制的局限性主要在哪些方面呢？

alexzeng

很长见识,    也说点个人想法

1. 对于archive log小于100G/day 的系统, 用两级standby db来做异地容灾, 第一级与生产库在同一机房, 可以做到同步, 第二级在远程, 通过第一级的standby 来传递arch log, 可以异步.
优点: 投入相对低(不需要硬件备份设备和高速远程网络), 技术可持续性好(Oracle在持续发展的技术), 管理简单(出错的处理比较简单, 可以配合script等监控)
缺点: 初始化需要down机时间(因为第一级在本地, 以现在的存储设备, down机时间在大多数情况下应该是可以接受的)

2.对于archive log大于100G/day 的系统, 两种方法,
a. 存储设备备份.  投入比较大, 管理简单, 可靠性可以通过多次测试来保证.
b. 针对应用选择其他容灾方法.  用应用的特性去找最合适的方法, 通常是多种的方法结合

另外, 好的马要有好的骑士, 合适的骑士. 管理很重要.

byfree

向各位大师学习。。。