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

liguang668 · 发表于 2004-12-13 16:55

先顶一下再说！

yl1998 · 发表于 2004-12-14 16:58

高人.
我也一直在自己摸索这些原理的东西. 进展不大. 都怪老板让我干活太多,没时间上网学习. 呵呵.

yl1998 · 发表于 2004-12-15 01:11

最初由 biti_rainy 发布
[B]我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？

也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？

上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案 [/B]

这个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.

但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.

biti_rainy · 发表于 2004-12-15 08:56

最初由 yl1998 发布
[B]

这个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.

但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质. [/B]

同步如果是从主机下来的IO直接复制，这样频繁的小IO将造成网络的大量问题，这对网络的要求太高了。以前都是听人说同步是从存储的cache 来的，拷贝的时候封锁cache不允许写……

samchj · 发表于 2004-12-16 11:37

我觉得这个和同步I/O和异步I/O没有关系，对于存储级的复制，他们都有一个队列来保证I/O的次序，这是类似于ca/emc等厂商的这些存储级（varitas文件系统级）复制的一个共同点。至少我知道veritas声称的原理是这样的。

如果不能保证I/O的次序，存储级复制没有任何意义。而且像ca这样的软件，他并不是实时改变多少就穿多少，我觉得他记录在磁盘头的tab应该隔多少时间加一次锁，然后新的插入写cache，所以如果这个时间源端off的话，cache中的数据应该是丢失的（磁盘坏）。
软件级的复制也一样，你总有一个队列来处理ops/rac的事务顺序，这个队列有放在磁盘上用文件来排队的，也有直接在内存中排队的，这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补，如果磁盘没有坏的话。

alonemo · 发表于 2004-12-20 10:26

希望斑竹作成CHM版本

wolfop · 发表于 2004-12-21 15:12

同步绝对就是那样，每个在SOURCE端写入的东西必须被远端的存储设备写入成功（不一定是写入磁盘）才返回主机写入成功，基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心，但是带宽要求等等都是很高的。
异步的方法，在之前很多是不能保证一致的，呵呵。最近据说多了很多能保证一致的方法，就知道HDS会吧所有写记录到本地一个日志卷，EMC和IBM的方法还没有弄的很清楚。

herycom · 发表于 2004-12-31 11:24

现在介绍我们数据库同步的成功案例，你们提到的问题都可以解决。
现在我们的数据同步已经投入了实际运行，采用逐步增加表的方式。目前已经同步了149个表，其中包括详单表，统计基表等。最大的6000多万记录，有16个超过1000万记录，采用10分钟异步复制。主要有以下特点：
1、关键业务数据（排出了很多垃圾数据），数据量最小
2、对生产机影响较小，目前一般只用到300M 空间
3、目标端数据不可以修改，完全保证数据一致
4、初始同步快捷、方便，不需要停止生产系统应用。影响小，只相当如一个select。
5、管理方便、灵活：能够看到各表上次同步时间；上次同步后又有多少条新数据；上次各表同步耗费多长时间等。
目前每天进行一次count(*) 检查，没有发现有问题。
如果想知道具体的实现方法和更具体的信息可以给我留email:
herycom@hotmail.com .

herycom · 发表于 2004-12-31 12:05

我们一前也试用过dsj和shareplex的产品，从名气上来说，应该还不错。具体不是我亲自试用的，但最后没有能够成功，我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。
1、这是一个24小时运行的系统，停止应用程序来进行初始同步比较麻烦。
2、需要在每天早晨从同步的数据中产生关键的数据和报表，要求不能耽误。
3、要求管理维护简单、灵活：要求运行稳定，同步中断后能够简单快速处理完。

现在我们用的oracle机制，加上第三方数据同步管理软件，只用了1个晚上就将主体数据同步好，一周就正式投入使用。然后逐步完善增加同步的表，目前已经同步了149张表，还对同步数据进行了分区处理等优化，从目前的近一个月的情况来看效果理想。
经过一年半还多的时间试用了2家产品没有能够成功，用一周时间就解决了问题（主要报表实际上第二天就正式使用了），心里是多么的欣慰、兴奋和富有成就感。
所以写了这么多东西。

herycom · 发表于 2004-12-31 13:00

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

看看我们的实际应用

补充说明

更全面的文档