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

lc7888

最初由 biti_rainy 发布
[B]系统上通常不一致没关系是因为还有 logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小

还有存储设备上，比如掉电没关系，是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的


但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的 [/B]

在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下，停止存储的复制，然后启动目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。
我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题……
还好目前还没有出问题，要是出了问题，不知道他们会怎么办……

biti_rainy

上次做存储设备的来公司，谈到这个问题的时候说：  很多客户就是这么做的

我就说： 很多人这么做的并不能说就没问题，因为很多 人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：
1：机制上的可靠保障，这个可能只有非常理解 原理的人能回答
2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试

通过这两点之后我们才敢放心使用

lc7888

最初由 biti_rainy 发布
[B]上次做存储设备的来公司，谈到这个问题的时候说：  很多客户就是这么做的

我就说： 很多人这么做的并不能说就没问题，因为很多 人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：
1：机制上的可靠保障，这个可能只有非常理解 原理的人能回答
2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试

通过这两点之后我们才敢放心使用 [/B]

同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。呵呵。

abcd

从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。

即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失（当前日志组的数据）。

换个思路了，使用基于应用的同步方案吧。

lc7888

前两天太忙，一直没时间，今天继续总结，呵呵
（3）基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……

lc7888

目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
这类产品的原理基本相同，其工作过程可以分为以下几个流程：
使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制（主要在oracle9i环境中）。
这种技术的技术特点和优势主要有以下几点：
目标端数据库一直是一个可以访问的数据库；
能保证两端数据库的事务一致性；
因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；
基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；
因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。
这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。
由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。

lc7888

继续……
基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：
数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；
实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；
复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。
不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。

tgliu

用到的ORACLE功能太深，后来麻烦还是自己的，
他们维护不了

happy_py

我们单位存储使用的是EMC的磁盘阵列，我们通过EMC公司提供的TIMEFINDER软件，为数据库使用的逻辑卷建立了BCV,每天做同步然后把BCV断开，我们试过在生产卷的BCV卷上面把数据库启动起来，并能对生产数据库的归档文件进行恢复。

Lee_Bill

您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？