数据库容灾的几种方式

时间:2019-05-24 栏目:


数据库容灾对于大小企业来说,已经不是一个新鲜的事物了。因此,目前企业考虑数据库容灾的解决方案时,其实主要是要先考虑成本问题。相比之下,基数方面的问题反而并不是大的问题。因此,企业应用上,最大的限制就是成本。下面以ORACLE数据库为例,简单分析一下几种数据库容灾的方式。

 

1、基于存储层的容灾复制方案

基于存储层的容灾技术的复制机制是通过基于SAN的存储局域网进行复制,复制针对每个IO进行,复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制。对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致,且对络环境的要求比较高。

 

2、基于逻辑卷的容灾复制方案

基于逻辑卷的容灾技术的机制是通过基于TCP/IP的网络环境进行复制,由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容灾复制。

 

3、基于oracle redo log的逻辑复制方式

基于oracel redo log的逻辑复制主要有一些第三方的软件,以及oracle自己的DATAGUARD 中的logical Standby。目前,国外已经有了很多比较成熟的产品及成功案例,国内也有类似的产品, 但在产品的成熟程度和成功案例上跟国外还有一定的差距。

使用oracle以外的独立进程,捕捉redo log file 的信息,将其翻译成sql语句,再通过网络传输到目标端数据库,在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换,也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位,当一个事务完成后,再把它传输到目标端。所有的产品一般都是以表为单位进行复制,同时也支持大部分DDL的复制(主要在oracle9i环境中)

数据库的吞吐量太大时,其实据会有较大的延迟,当数据库每天的日量达到60G或更大时,这种方案的可行性交差;实施的过程可能会有一些停机时间,来进行数据的同步和配置的激活;复制环境建立起来以后,对数据库结构上的一些修改需要按照规定的操作流程进行,有一定的维护成本。

及时响应,快速服务,为您保驾续航

立即注册

请先完成图形验证

验  证  码:

请先完成图形验证

验  证  码:

隐私声明
当您在本网站进行合作伙伴注册登记,本网站将收集您的相关信息,并保存记录。本网站收集的个人信息包括但不限于:姓名、地址、公司、所在地区、电话号码以及电子邮件地址等。您主动提供的信息越多及越准确,我们就能够更好地为您提供有关服务。
咨询·购买