容灾分类
从其对系统的保护程度来分,可以将容灾系统分为:数据容灾和应用容灾描述如下:
数据容灾就是指建立一个异地的数据系统,该系统是本地关键应用数据的一个实时复制。
应用容灾是在数据容灾的基础上,在异地建立一套完整的与本地生产系统相当的备份应用系统(可以是互为备份),在灾难情况下,远程系统迅速接管业务运行。数据容灾是抗御灾难的保障,而应用容灾则是容灾系统建设的目标。
灾备的几种方式:
1、主备镜像
两个数据中心服务器部署完全一样,每次网站发布都要在两个数据中心同时发布,保证运行系统版本一致。两个数据中心有主备之分,数据通过准实时的同步系统从主站不断同步到备站。主站发生灾害性故障导致完全不可用,则将域名解析切换到备站。这种方案纯粹是为了容灾。
2、业务互补,数据同步
如某网站美国机房和国内机房部署的服务在业务上互补,美国机房部署买家服务,国内机房部署卖家服务,海外用户(主要是买家)访问美国机房,国内用户(主要是卖家)访问国内机房。主要业务数据互相实时同步,因为数据在两个机房同时写入,可能会发生冲突。
3、主主镜像
部署和发布模式与主备一样,但是多个数据中心是同时启用的,根据用户地域将域名解析到不同的机房,数据实时同步。如新浪微博。
4、一写多读
数据写入只发生在一个数据中心,但是为了加快地区用户访问,会将数据同步到其他数据中心供只读访问。这种方案适用于读多写少的网站。比如wikipedia。
引用链接:https://www.zhihu.com/question/21861839/answer/19548321
简单的说几句吧。其实这个解决方案呢,主要是要先考虑成本问题,其他的,技术问题其实都很容易解决,但是企业应用上,最大的限制就是成本。下面以ORACLE数据库为例,简单说说。希望对你有所帮助。(数据库类型并不重要,解决方案都是大同小异。)1、基于存储层的容灾复制方案
这种技术的复制机制是通过基于SAN的存储局域网进行复制,复制针对每个IO进行,复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制。对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、 *** 作系统、数据库版本等要求一致,且对络环境的要求比较高。
2、基于逻辑卷的容灾复制方案
这种技术的机制是通过基于TCP/IP的网络环境进行复制,由 *** 作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容灾复制。
3、基于oracle redo log的逻辑复制方式
使用这种方式的主要有一些第三方的软件,以及oracle自己的DATAGUARD 中的logical Standby。目前,国外已经有了很多比较成熟的产品及成功案例,国内也有类似的产品, 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
使用oracle以外的独立进程,捕捉redo log file 的信息,将其翻译成sql语句,再通过网络传输到目标端数据库,在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换,也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位,当一个事务完成后,再把它传输到目标端。所有的产品一般都是以表为单位进行复制,同时也支持大部分DDL的复制(主要在oracle9i环境中)。
数据库的吞吐量太大时,其实据会有较大的延迟,当数据库每天的日量达到60G或更大时,这种方案的可行性交差;实施的过程可能会有一些停机时间,来进行数据的同步和配置的激活;复制环境建立起来以后,对数据库结构上的一些修改需要按照规定的 *** 作流程进行,有一定的维护成本。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)