FusionCube V100R002C02 数据库基础设施容灾方案
文档版本V1.0
发布日期2014-02-20
版权所有? 华为技术有限公司2013。保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
商标声明
和其他华为商标均为华为技术有限公司的商标。
本文档提及的其他所有商标或注册商标，由各自的所有人拥有。
注意
您购买的产品、服务或特性等应受华为公司商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。除非合同另有约定，华为公司对本文档内容不做任何明示或暗示的声明或保证。
由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。
华为技术有限公司
地址：深圳市龙岗区坂田华为总部办公楼邮编：518129
网址：https://www.doczj.com/doc/b94437218.html,
前言
概述
本文档介绍FusionCube产品的容灾方案信息。
读者对象
本文档主要适用于以下工程师：
公司MKT、行销、渠道商在项目拓展中使用
符号约定
在本文中可能出现下列标志，它们所代表的含义如下。
表示有高度潜在危险，如果不能避免，会导致人员死亡或严重伤害。
表示有中度或低度潜在危险，如果不能避免，可能导致人员轻微或中等伤害。
表示有潜在风险，
数据丢失、设备性能降低或不可预知的结果。
表示能帮助您解决某个问题或节省您的时间。
表示是正文的附加信息，是对正文的强调和补充。
修改记录
修改记录累积了每次文档更新的说明。最新版本的文档包含以前所有文档版本的更新内
容。
文档版本01 (2014-02-20)
第一次正式发布。
目录
前言 (ii)
1 容灾简介 (1)
1.1 数据库容灾概述 (1)
1.2 容灾系统的评价指标 (1)
1.3 容灾方案的模式介绍 (1)
2 FusionCube数据库容灾方案概述 (3)
3 FusionCube数据库容灾方案介绍 (4)
3.1 DataGuard容灾方案 (4)
3.1.1 方案概述 (4)
3.1.2 适用场景 (4)
3.1.3 方案组网 (5)
3.2 Goldengate容灾方案 (9)
3.2.1 方案概述 (9)
3.2.2 适用场景 (10)
3.2.3 方案组网 (10)
3.3 方案比较 (11)
4 术语 (14)
1 容灾简介
1.1 数据库容灾概述
容灾系统是指在相隔较远的异地，建立两套或多套功能相同的系统，系统之间可以相互
进行健康状态监视和功能切换，当一处系统因意外(如火灾、洪水、地震、人为蓄意破
坏等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工
作。
容灾系统需要具备较为完善的数据保护与灾难恢复功能，保证生产中心不能正常工作时
数据的完整性及业务的连续性，并在最短时间内由灾备中心接替，恢复业务系统的正常
运行，将损失降到最小。
1.2 容灾系统的评价指标
现在工业界都以数据丢失量和系统恢复时间作为标准，对某个容灾备份系统进行评价，
公认的评价标准是RPO和RTO。
RPO（Recovery Point Objective）：即数据恢复点目标，以时间为单位，即在灾难发生时，
系统和数据必须恢复到的时间点要求。RPO标志系统能够容忍的最大数据丢失量。系统
容忍丢失的数据量越小，RPO的值越小。
RTO（Recovery Time Objective）：即恢复时间目标，以时间为单位，即在灾难发生后，
信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止
的最长时间。系统服务的紧迫性要求越高，RTO的值越小。
RPO针对的是数据丢失，而RTO针对的是服务丢失,RTO和RPO的确定必须在进行风
险分析和业务影响分析后根据不同的业务需求确定。
1.3 容灾方案的模式介绍
根据不同容灾方案的部署,恢复方式, 可大致分为一下几种方式:
异地双中心双活模式:
Active + Active 负载均衡模式, 即本地生产中心和异地容灾中心同时提供业务支撑能力和容灾能力。
当任意数据中心出现异常,重大灾难事故, 另一中心均可自动提供全部或部分的, 高RTO 要求的业务支撑能力,保证业务的持续性。
●异地双中心主备模式:
Active + Standby, 即本地生产中心提供业务支撑能力, 异地中心仅提供容灾能力。
正常情况下,容灾中心不提供业务支撑的能力, 一旦发生重大灾难事故,则人工干预后提供部分或全部的业务能力,保证生产业务的持续性。
●两地三中心主备模式:
本地生产中心提供业务支撑能力, 本地容灾中心提供关键/核心业务的容灾能力,异地容灾中心提供非核心/关键业务的容灾能力。
为更好的保护IT投资, 本地容灾中心仅针对高RTO要求的关键/核心业务提供容灾能力, 异地容灾中心仅提供低RTO要求的业务容灾能力。
●异地多生产中心负载均衡+ 集中容灾中心模式:
异地多生产中心提供业务支持和负载均衡能力, 共用独立的容灾中心进行统一的容灾/备份；
当任一生产中心发生重大灾难事故, 即可由其他生产中心提供动态的业务保证能力, 亦可由集中的容灾中心提供业务能力, 确保高RPO, 低RTO要求的业务持续性要求。
2 FusionCube数据库容灾方案概述
FusionCube提供以下容灾解决方案，可满足各种容灾模式需求:
●基于DataGuard的数据库容灾方案，满足以下需求场景
1.主、备库数据库版本一致，硬件平台一致
2.备库基本不对外提供服务，或者只承担部件报表查询等任务
3.多种保护模式，根据应用需要灵活选择
4.主、备站点间有充足的带宽
●基于Goldengate的数据库容灾方案，满足以下需求场景：
1.支持多种数据库
2.低延迟（亚秒级RPO）、低带宽要求，适合远程容灾
3.灾备端Active，实现快速接管（最小化RTO），消除切换风险
4.灾备端可灵活选择硬件、OS、数据库版本，支持利旧
5.支持部分核心数据应急、误删除保护
3 FusionCube数据库容灾方案介绍
3.1 DataGuard容灾方案
3.1.1 方案概述
Oracle Data Guard 是当今保护企业核心资产（数据）的最有效解决方案之一，它能够使
数据在24x7 的基础上可用，而无论是否发生灾难或其它中断。
Oracle Data Guard 是管理、监控和自动化软件的基础架构，它创建、维护和监控一个或
多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。
Data Guard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可
能位于距生产数据中心数千公里的远程灾难恢复站点，或者可能位于同一城市、同一校
园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时，Data
Guard 可以将任意备用数据库切换到生产角色，从而使与中断相关的停机时间减到最少，
并防止任何数据丢失。主要特点如下：
●节约投资
Oracle Data Guard是Oracle原厂自带的容灾产品。该产品完全免费。在容灾软件上用户
无需支付额外费用，这可以大大节约用户的资金投入。
●技术成熟、稳定
早在Oracle 7版本就已经推出该功能（当时名称为Standby数据库）。其核心采用了Oracle
成熟的归档、备份、恢复技术。经过多年不断的发展，已经成为一项技术成熟、稳定，
有广泛成功案例的技术。
●对系统运行性能影响小
Data Guard在主数据库服务器端不存在对日志解析等工作，仅需要主数据库服务器端将
归档日志文件传输到容灾节点。因此对生产系统性能影响极小。
●能够满足用户基本业务需求
Data Guard能够满足用户基本的数据容灾、RTO、RPO、带宽等相关基本业务需求。3.1.2 适用场景
基于DataGuard的容灾方案主要应用于主、备站点部署数据库版本一致、硬件平台一样，
平时备用站点不对外提供业务的场景。
3.1.3 方案组网
图3-1 DataGuard 容灾方案
DataGuard Broker
客户端
FusionCube
容灾方案
1. 检查主站为的是否运行于归档模式，如果不是则把主站点设备成归档模式
2. 在容灾端建立实例需要的目录
3. 网络配置
a) Sqlnet.ora 配置
b) 监听配置
c) 网络服务别名配置
4. 参数文件配置
5. 容灾端创建standby redo log
6. 对容灾端做基线
7. 打开容灾端的DataGuard
8. 打开ADG
9. 重建temp 文件
容灾切换
Dataguard中的容灾切换（role transition）有两类：switchover和failover。区别在于：
switchover将一个physical 库平稳成为primary，将primary切换为standby角色，这个
过程可以保证无数据丢失，在完成后原生产端变成容灾端，原容灾端变成新的生产端。Failover是当主库无法正常工作时，强制将容灾端failover成primary角色，如果在primary
库在出故障之前不是处于最大保护模式的话，将会有一些数据丢失，因为当前在写的
redo或者已存在的gap不能再传送到standby库。如果primary库都打开了flashback的话，可以将原来的主库重新设为新primary role数据库的standby库。
在进行role transition要检查：primary,standby是否处于archvielog模式，归档的相关参
数以及原生产端是否配置standby redo log文件；Standby库的临时文件（临时表空间的数据文件）要和primary匹配；是rac的话：在容灾端只有一个实例mount,其它都要关闭。
SWITCHOVER
切换步骤：
1. 将主节点A切换为standby模式：
在A上执行select switchover_status from v$database，如果返回为SESSIONS ACTIVE，说明有进程在进行，可以通过如下命令将其停止:
SQL> alter database commit to switchover to physical standby with session shutdown;
如果返回值为to standby，则执行：
SQL> alter database commit to switchover to physical standby;
此时，会将数据库从primary转换为standby角色，同时在转换动作执行前，oracle会先将控制文件backup到相应的trace文件中。
2. 原主节点A的DB启动到mount状态：
3. 将原备节点B切换为primary模式：
此时，在B上执行：
SQL> select switchover_status from v$database;
如果返回值为to primary，那么执行：
SQL> alter database commit to switchover to primary;
如果返回为session active，那么在执行：
SQL> alter database commit to switchover to primary with session shutdown;
注意，开始切换前，正常情况下，生产端的switchover_status为to primay和session active。容灾端的状态为not allowed，只有当生产端做切换动作后，容灾端的状态才会变成to standby。
4. 启动节点B到open状态
5. 设置A为Recover Managed Standby：
此时A上的switchover_status变成RECOVERY NEEDED。在A上打开real time apply 功能：
SQL> alter database recover managed standby database using current logfile disconnect from session;
切换失败的回退方法：
在做switchover过程中，如果碰到错误而无法正常完成切换，那么此时可以回退到切换前的状态。方法如下：
1.将原生产端A回退为新的生产端：
SQL> alter database commit to switchover to primary with session shutdown;
如果这个语句执行成功，那么关闭并重启数据库，使DB运行在read write的primary模式下。以后的步骤就不需要执行了。
这个语句执行时会在trace文件中记录重建原生产端控制文件的sql语句。
2.在B上创建一个新的standby控制文件。在A上执行以下语句并将生产的文件拷贝
到B并在B的nomount状态下执行：
SQL> alter database create standby controlfile as ‘/…/std.ctl’
3.启动B的数据库，打开redo apply功能。
如果需要，可以重新做switchover。
FAILOVER
当主节点全部当机后，手工启动B，并且在B作为主节点运行期间，A一直未能修复，此时需要将B转换为primary角色。一段时间后，当A修复并且要重新做为主节点，那么可以先将A配置为新的standby，然后再做switchover。
一、无gap的FAILOVER
1. 检查日志gap：
在B上看看是否有归档日志文件的gap：
SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;
这个视图在11.1.0.7中并不准确，可以比对生产端和容灾端各自的v$managed_standby 的LNS和RFS进程各自的log sequence，也可以直接去检查生产端和容灾端各自的归档目录下已有的归档文件。
如果有gap，则必须从相应的节点(thread)中拷贝相应的归档日志文件到B的相应目录下，并注册他们：
SQL> alter database register physical logfile 'filespec1';
如果可以确保生产端的所有归档日志及redo日志都已经传送或拷贝注册到容灾端，那么容灾端做failover后不会有数据丢失。如果有些归档日志无法获得或者最后的redo 数据没有传送到容灾端，那么会有部分数据丢失。
2. 关闭A的数据库实例
3. 在B上取消recover managed状态：
执行如下语句：
SQL> alter database recover managed standby database cancel;
SQL> alter database recover managed standby database finish;
4. 转换B作为Primary：
SQL> alter database commit to switchover to primary [with session shutdown];
5. 重新启动B数据库：
SQL> alter database open;
6. 后续处理：
如果A的数据库无法再启动，在B做生产端期间A无法承担容灾端的角色，那么当A 修复好以后，将备份的tnsnames.ora、listener.ora、sqlnet.ora文件从备份文件中恢复出来，然后从B对A做基线，然后打开redo apply功能，使A与B同步。然后再做一次switchover 将A恢复为生产环境。
二、有gap的FAILOVER
如果容灾端存在日志的gap，那么用正常的切换方法做findish时会报错：
Media Recovery Waiting for thread 1 sequence 20
Fetching gap sequence in thread 1, gap sequence 20-20
这样的场景下，做failover切换的方法是在容灾端执行以下命令，忽略gap，丢失部分数据，打开数据库：
SQL> alter database recover managed standby database cancel;
SQL> alter database activate physical standby database;
SQL> alter database open;
站点重建:
在新的生产端全库备份，然后将备份集传输到容灾端，进行恢复。具体步骤如下：
在新生产端做备份，然后将备份集传输到容灾端
将容灾DB使用自己的参数文件启动到nomount状态
使用传输来的备份集中的控制文件为容灾端做恢复：
RMAN> restore standby controlfile from ‘/备份集路径/包含控制文件的名称’;
RMAN> alter database mount;
RMAN> restore database;
确保生产端和容灾端的容灾复制监听都已开启，并且可tnsping通双方的容灾复制网络
别名，生产端的log_archive_dest_state_2必须是ENABLE
在容灾端执行以下命令打开real time apply，并且处理备份集到当前时间之间新产生的日
志：
RMAN> alter database recover managed standby database using current logfile disconnect
from session;
缺点描述：
操作麻烦。并且需要为备份集准备一个磁盘空间。
优点描述：
仅对使用了的块进行备份，例如数据库表空间共1000G，但仅有1G的块上有数据，那
么备份集仅1G左右，而且还可以采用压缩备份，备份集做多可降到十分之一，大大减
少了数据传输量，加快了速度。适用于大数据库场景。
容灾切回处理：
当源站点恢复后，可以通过switchover实现容灾切回。
3.2 Goldengate容灾方案
3.2.1 方案概述
Goldengate是一种基于日志的结构化数据复制软件，它通过解析源数据库在线日志或归
档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标
数据库同步、双活。
采用Goldengate的数据复制技术，实现数据实时备份，确保核心数据的安全，同时避免
引入过多种类的软硬件产品，降低了运营维护的复杂度和投入，有利于灾备系统的恢复
和切换。
其主要特点有：
1.实时性随着一个新事务在数据源端产生，数据马上被捕获，转换（如果有必要），
并且在极短时间内被传送给目标端系统
2. 持续可用性 Goldengate 工作不需要专门的时间窗口或者系统中断，它的架构可以
保证即使遇到计划或非计划断电也不会影响可用性。
3. 异构支持 只要源和目标端都是主流数据库，主流平台，即使在在异构环境下，也
可以使用TDM 进行系统间数据复制，这就确保了IT 部门的灵活性。
4. 高性能，低影响 Goldengate 能够支持每秒数千的事务交易，同时对源系统和目标
系统仅仅有极小的性能影响。
5. 事务一致性 尽管事务是在源和目的两个不同的系统之间传递的，Goldengate 依然
可以确保其参照完整性和事务一致性。
3.2.2 适用场景
需要提供数据库容灾的数据库一体机场景，两个站点可以是主、备或者双活；另外，两
个站点可以是异构平台。
3.2.3 方案组网
这里提供Goldengate 双活时的容灾组网。
该方案网络拓扑如下图所示。
图3-2 Goldengate 容灾方案（双活模式）
RAC 节点RAC
节点RAC
节点IB 网络
Fusion Storage Golden Gate RAC 节点RAC 节点RAC 节点
IB 网络Fusion Storage
Golden Gate 中心A 应用
数据库容灾方案如下：
（1） 修改主数据库为归档模式，并打开强制日志
（2） 在源库上部署捕获进程负责从在线日志和归档抽取事务信息并把这些信息写入
trail 文件。可以根据日志生产的数据配置多个抽取进程
（3）在源库上部署1个或多个投递进程，负责把抽取进程生成的trail文件投递到对
端
（4）在目标库上部署1个或多个交付进程，负责解析源库投递过来的trail文件并在
目标库上重做对应的事务
（5）在目标库上冲击1个或多个抽取进程，当源库故障目标库升主后负责抽取中线
日志和归档日志并生成trail文件
（6）在目标库上部署1个或多个投递进程，负责把抽取进程生成的trail文件投递到
源库
（7）在源库部署1个或多个交付进程，负责解析目标库投递过来的trail文件并在源
库上重做对应的事务
（8）应用能同时连接源库和目标库，通过应用层控制当前具体连接的是源或者目标
库
灾难恢复方案如下：
（1）当源库故障时，把应用的连接地址修改为目标库就可以完成数据库的切换，保证业
务尽快恢复；
（2）管理人员可以在任何时间进行灾备演练、容灾数据查询、打印或测试，对生产中心
没有任何影响，不影响数据继续复制。
容灾切换：
Goldengate的容灾切换是自动的，当应用连接到目标库后，部署在目标库上的抽取进程
会抽取目标库的在线日志或归档日志并由投递进程投递到源库，再由源库上的交付进程
完成事务的重做。
站点重建:
原生产中心重建后（如数据库故障排除），系统管理员使用Goldengate使源库和目标库
达到同步
容灾切回处理：
1、源库故障恢复后，通Goldengate可以实现目标库和源库数据的一致
2、当两个库的数据一致时，把应用的数据库连接地址修改为源库，即可完成整个容灾
的切回
3.3 方案比较
DataGuard作为Oracle数据库自带的一种容灾软件，可以在不增加客户投资的情况为客
户提供容灾功能。
Goldengate支持异构平台，可以为用户提供更灵活的选择。
FusionCube V100R002C02 数据库基础设施容灾方案 4 术语
4 术语
数据中心容灾备份方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于 30 年。
2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。 备份介质层（内置虚拟带库）：主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等，一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质，用于近期的备份数据存放，将物理磁带库或者光盘库作为二级备份介质，用于长期的备份数据存放。
数据保护系统 医院备份、容灾及归档数据容灾 解决方案
1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化HIS、LIS 和PACS 等系统是目前各个医院的核心业务系统，承担了 病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于30 年。
2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 2.1 数据备份解决方案 针对于医院的HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的LAN 或LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。
i 版权所有? 华为技术有限公司
前言 区块链成为近两年热点话题，因其通过分布式数据存储、点对点传输、共识机制、加密算法等技术的集成，可有效解决传统交易模式中数据在系统内流转过程中的造假行为，从而构建可信交易环境，打造可信社会。近年来各国政府机构，国际货币基金组织以及标准、开源组织和产业联盟等在纷纷投入区块链产业的拉通和应用。随着区块链的产业价值的逐渐确定，区块链迅速地成为一场全球参与竞逐的“军备”大赛，中国也开始从国家层面设计区块链的发展道路（发改委委托信通院组织国内主要区块链公司进行区块链的顶层设计的研讨，工信部的信软司也在积极确定区块链的顶层设计机构）。2018年，区块链及相关行业加速发展，中国将领跑全球进入“区块链可信数字经济社会”，我们正面临区块链重大的产业机遇。 区块链的应用已由开始的金融延伸到物联网、智能制造、供应链管理、数据存证及交易等多个领域，将为云计算、大数据、承载网络等新一代信息技术的发展带来新的机遇，其构建的可信机制，将改变当前社会商业模式，从而引发新一轮的技术创新和产业变革。 编委会成员 顾问：张文林、龚体、肖然、廖振钦、万汉阳、楚庆、张辉、潘秋菱、祁峰、伊志权、ZHU PEIYING、刘培、王伟、王小渭、LIAO HENG 研究撰写：张小军、曹朝、胡瑞丰、刘再耀、张亮亮、周瑛达、郭兴民、吴义镇、杜伟、甘嘉栋、WU SHUANG、姜耀国、William Michael Genovese、朱朝晖 排版设计：杨少青 审稿：潘秋菱、张小军、胡瑞丰、刘再耀、周瑛达
目录 前言 (ii) 1 区块链的兴起 (1) 1.1 区块链的起源 (1) 1.2 区块链的发展路径 (2) 1.3 当前区块链认识上的两大误区 (3) 2 区块链核心技术及原理机制 (5) 2.1 区块链的概念和特征 (5) 2.2 区块链的核心技术 (6) 2.2.1 分布式账本 (6) 2.2.2 共识机制 (7) 2.2.3 智能合约 (8) 2.2.4 密码学 (11) 2.3 华为在区块链发展中进行的技术创新 (12) 2.3.1 共识算法创新 (12) 2.3.2 安全隐私保护 (13) 2.3.3 离链通道 (14) 3 区块链国内外产业发展现状 (16) 3.1 区块链相关产业政策现状 (16) 3.2 区块链在开源领域的发展现状 (17) 3.3 区块链在标准领域的发展现状 (18) 3.4 区块链产业联盟发展现状 (19) 4 区块链的典型应用场景 (22) 4.1 数据交易：实现数据交易的过程透明、可审计，重塑社会公信力 (23) 4.2 身份认证：验证身份的合法性，加速数字化社会发展 (24) 4.3 新能源：打造清洁能源交易信任基石 (25) 4.4 车联网：用区块链实现信息准确共享，构建新经济模式 (27) 4.5 供应链溯源：树立公信力，构建真实交易 (28) 4.6 运营商云网协同：解决运营商网络碎片化，构建新商业模式 (29) 4.7 供应链金融：有效减少金融风险，拓展金融业务发展 (30)
Oracle数据库异地容灾方案介绍 2008年11月
目录 第一章需求分析 (4) 1.1 序言 (4) 1.2 用户现状 (4) 1.2.1 系统平台 (4) 1.2.2 数据库平台 (6) 1.3 用户需求 (7) 1.3.1 日常功能 (7) 1.3.2 故障切换 (7) 1.3.3 基本要求 (7) 1.3.4 性能要求 (8) 1.3.5 数据一致性 (9) 1.3.6 系统兼容性 (9) 1.3.7 高可用性 (10) 1.3.8 健壮性要求 (10) 1.3.9 设备无关性 (10) 1.3.10 管理监控功能 (11) 第二章Oracle Data Guard介绍 (12) 2.1 Data Guard实现原理 (12) 2.2 Oracle Data Guard 优势 (15) 2.3 Data Guard提供的保护模式 (16) 2.4 Data Guard实现方式以及对系统的限制要求 (17) 2.5 切换方式 (17) 第三章系统建议方案 (19) 3.1 Data Guard优势 (19) 3.2 Data Guard运行模式 (19) 3.3 Data Guard保护模式 (20)
3.4 Data Guard初始安装步骤 (20) 3.5 用户需求点对点应答 (21) 3.5.1 日常功能 (21) 3.5.2 故障切换 (22) 3.5.3 基本要求 (23) 3.5.4 性能要求 (23) 3.5.5 数据一致性 (25) 3.5.6 系统兼容性 (26) 3.5.7 高可用性 (26) 3.5.8 健壮性要求 (27) 3.5.9 设备无关性 (27) 3.5.10 管理监控功能 (28)
现阶段，由核心技术、扩展技术和配套技术三者组成的区块链技术体系已逐步成形，未来将继续在数据流通、网络规模、技术运维、平台安全等方面创新演进。 （一）区块链技术图谱 区块链作为一种综合性技术，其技术组成按重要程度可分为核心技术、扩展技术、配套技术三类。核心技术指一个完整的区块链系统必须要包含的技术，包括密码算法、对等式网络、共识机制、智能合约、数据存储；扩展技术指进一步扩展区块链服务能力的相关技术，包括可扩展性、互操作性、协同治理、安全隐私；配套技术指提升区块链系统安全性、优化使用体验等相关技术，包括系统安全、运维部署、基础设施。 1.核心技术现状 2014年以太坊的诞生，奠定了区块链系统的五大核心技术，包括密码算法、对等式网络、共识机制、智能合约、数据存储。 （1）密码算法 国密支持成为多数联盟链标准配置。2020年1月1日起实施的《中华人民共和国密码法》，加速了国内联盟链对国密算法的支持进度，国密支持占比逐步提升，逐渐成为联盟链的标准配置。据2020年可信区块链评测结果显示，受测厂商目前国密支持占比已达82%，其中，SM2、SM3、SM4支持率分别占比79%、75%、68%。 （2）对等网络 兼顾通信效率与去中心程度的混合型网络成为主流。对等网络按网络结构可分为无结构网络、结构化网络、混合型网络。无结构网络鲁棒性好，去中心化程度高，但通信冗余严重，容易形成网络风暴，如经典Gossip网络；有结构网络牺牲了去中心化程度，按照一定策略维护网络拓扑结构，提升通信效率，如类DHT （(Distributed Hash区块链白皮书（2020年）23Table，分布式哈希表）网络；混合型网络作为一种折中方案，兼顾了通信效率与去中心化程度。随着区块链网络规模的扩大，出于对高效通信策以及网络治理的需要，混合型网络逐渐成为行业主流方案。 （3）共识机制
六种数据库容灾方案 1、经典方案，即双机ha，单盘阵的环境。 简单的说，双机热备就是用两台机器，一台处于工作状态，一台处于备用状态，但备用状态下，也是开机状态，只是开机后没有进行其他的操作。打个比方来说，在网关处架上两台频宽管理设备，将两台的配置设定为一致，只是以一台的状态为主，一台为次。主状态下的频宽管理设备工作，处理事件，次状态下的频宽管理设备处于休眠，一旦主机出现故障，备用频宽管理设备将自动转为工作状态，代替原来的主机。这就是“双机热备”。 2、单机双盘阵（os层镜像）。针对某些用户的双盘阵冗余的需求，我提出了在os层安装卷管理软件，用软件对两台盘阵做镜像的方案，但只有单机工作，一台盘阵挂了，因为os层的软raid的作用，系统仍然可以工作。 3、双机双柜（os层镜像）方案，这个方案，仍然是用os层做镜像，但是用了双机ha，这种方式有个尚未确认的风险，非纯软方式的ha要求主机有共享的存储系统。一台机器对盘阵lun做的镜像虚拟卷，是否也适用另一台主机，也就是说，a主机做的镜像，b主机接管后，是否会透明的认出a机做镜像之后的逻辑虚拟卷，如果ab两主机互相都能认，那么就是成功的方案！！ 4、双机双柜（底层镜像）。这种方案，虽然共享的lun不是在一台物理盘阵上，但是被底层存储远程镜像到另一台盘阵上，能保持数据的一致性
5、双机双柜纯软方式HA。这种方案，主机装纯软HA软件，虽然纯软不需要外接盘阵，但是接了盘阵，照样可行。 6、双机双柜（hacmp geo），其实geo大体上就是个类似于纯软HA的软件。
数据库安全 （一）数据库安全的定义 数据库安全包含两层含义：第一层是指系统运行安全,系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动；第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。 编辑本段 （二）数据库安全的特征 数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。下面分别对其进行介绍 1．数据独立性 数据独立性包括物理独立性和逻辑独立性两个方面。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的；逻辑独立性是指用户的应用程序与数据库的逻辑结构是相互独立的。 2．数据安全性 操作系统中的对象一般情况下是文件，而数据库支持的应用要求更为精细。通常比较完整的数据库对数据安全性采取以下措施： （1）将数据库中需要保护的部分与其他部分相隔。 （2）采用授权规则，如账户、口令和权限控制等访问控制方法。 （3）对数据进行加密后存储于数据库。 3．数据完整性 数据完整性包括数据的正确性、有效性和一致性。正确性是指数据的输入值与数据表对应域的类型一样；有效性是指数据库中的理论数值满足现实应用中对该数值段的约束；一致性是指不同用户使用的同一数据应该是一样的。保证数据的完整性，需要防止合法用户使用数据库时向数据库中加入不合语义的数据 4．并发控制 如果数据库应用要实现多用户共享数据，就可能在同一时刻多个用户要存取数据，这种事件叫做并发事件。当一个用户取出数据进行修改，在修改存入数据库之前如有其它用户再取此数据，那么读出的数据就是不正确的。这时就需要对这种并发操作施行控制，排除和避免这种错误的发生，保证数据的正确性。 5．故障恢复 由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。 SQL server数据库安全策略 SQL Server2000[1]的安全配置在进行SQL Server2000数据库的安全配置之前，首先必须对操作系统进行安全配置，保证操作系统处于安全状态。然后对要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的Web应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似“,;@/”等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上最新SQL补丁SP3。 SQL Server的安全配置 1．使用安全的密码策略 我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库账号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa账号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步，建议密码含有多种数字字母组合并9位以上。SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非您确认必须使用空密码，这比以前的版本有所改进。同时养成定期修改密码的好习惯，数据库管理员应该定期查看是否有不符合密码要求的账号。 2．使用安全的账号策略 由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个账号进行最强的保
２０１８年华为区块链白皮书
前言 区块链成为近两年热点话题，因其通过分布式数据存储、点对点传输、共识机制、加密算法等技术的集成，可有效解决传统交易模式中数据在系统内流转过程中的造假行为，从而构建可信交易环境，打造可信社会。近年来各国政府机构，国际货币基金组织以及标准、开源组织和产业联盟等在纷纷投入区块链产业的拉通和应用。随着区块链的产业价值的逐渐确定，区块链迅速地成为一场全球参与竞逐的“军备”大赛，中国也开始从国家层面设计区块链的发展道路（发改委委托信通院组织国内主要区块链公司进行区块链的顶层设计的研讨，工信部的信软司也在积极确定区块链的顶层设计机构）。2018年，区块链及相关行业加速发展，中国将领跑全球进入“区块链可信数字经济社会”，我们正面临区块链重大的产业机遇。 区块链的应用已由开始的金融延伸到物联网、智能制造、供应链管理、数据存证及交易等多个领域，将为云计算、大数据、承载网络等新一代信息技术的发展带来新的机遇，其构建的可信机制，将改变当前社会商业模式，从而引发新一轮的技术创新和产业变革。 编委会成员 顾问：张文林、龚体、肖然、廖振钦、万汉阳、楚庆、张辉、潘秋菱、祁峰、伊志权、ZHU PEIYING、刘培、王伟、王小渭、LIAO HENG 研究撰写：张小军、曹朝、胡瑞丰、刘再耀、张亮亮、周瑛达、郭兴民、吴义镇、杜伟、甘嘉栋、WU SHUANG、姜耀国、William Michael Genovese、朱朝晖 排版设计：杨少青 审稿：潘秋菱、张小军、胡瑞丰、刘再耀、周瑛达
目录 前言 (ii) 1 区块链的兴起 (1) 1.1 区块链的起源 (1) 1.2 区块链的发展路径 (2) 1.3 当前区块链认识上的两大误区 (3) 2 区块链核心技术及原理机制 (5) 2.1 区块链的概念和特征 (5) 2.2 区块链的核心技术 (6) 2.2.1 分布式账本 (6) 2.2.2 共识机制 (7) 2.2.3 智能合约 (8) 2.2.4 密码学 (11) 2.3 华为在区块链发展中进行的技术创新 (12) 2.3.1 共识算法创新 (12) 2.3.2 安全隐私保护 (13) 2.3.3 离链通道 (14) 3 区块链国内外产业发展现状 (16) 3.1 区块链相关产业政策现状 (16) 3.2 区块链在开源领域的发展现状 (17) 3.3 区块链在标准领域的发展现状 (18) 3.4 区块链产业联盟发展现状 (19) 4 区块链的典型应用场景 (22) 4.1 数据交易：实现数据交易的过程透明、可审计，重塑社会公信力 (23) 4.2 身份认证：验证身份的合法性，加速数字化社会发展 (24) 4.3 新能源：打造清洁能源交易信任基石 (25) 4.4 车联网：用区块链实现信息准确共享，构建新经济模式 (27) 4.5 供应链溯源：树立公信力，构建真实交易 (28) 4.6 运营商云网协同：解决运营商网络碎片化，构建新商业模式 (29) 4.7 供应链金融：有效减少金融风险，拓展金融业务发展 (30)
数据容灾备份设计方案 1.1数据备份的主要方式 目前比较实用的的数据备份方式可分为本地备份异地保存、远程磁带库与光盘库、远程关键数据+定期备份、远程数据库复制、网络数据镜像、远程镜像磁盘等六种。 （1）本地备份异地保存 是指按一定的时间间隔（如一天）将系统某一时刻的数据备份到磁带、磁盘、光盘等介质上，然后及时地传递到远离运行中心的、安全的地方保存起来。 （2）远程磁带库、光盘库 是指通过网络将数据传送到远离生产中心的磁带库或光盘库系统。本方式要求在生产系统与磁带库或光盘库系统之间建立通信线路。 — （3）远程关键数据+定期备份 本方式定期备份全部数据，同时生产系统实时向备份系统传送数据库日志或应用系统交易流水等关键数据。 （4）远程数据库复制 生产系统相分离的备份系统上建立生产系统上重要数据库的一个镜像拷贝，通过通信线路将生产系统的数据库日志传送到备份系统，使备份系统的数据库与生产系统的数据库数据变化保持同步。 （5）网络数据镜像 是指对生产系统的数据库数据和重要的数据与目标文件进行监控与跟踪，并将对这些数据及目标文件的操作日志通过网络实时传送到备份系统，备份系统则根据操作日志对磁盘中数据进行更新，以保证生产系统与备份系统数据同步。 （6）远程镜像磁盘 利用高速光纤通信线路和特殊的磁盘控制技术将镜像磁盘安放到远 …
离生产系统的地方，镜像磁盘的数据与主磁盘数据以实时同步或实时异步方式保持一致。磁盘镜像可备份所有类型的数据。备份拓扑网络结构1.2（即东风东路院区中心机广州市第八人民医院具有两个不同地点的中心机房房和嘉禾院区中心机房），在这基础上是可以构建一个异地容灾的数据备份系统，以确保本单位的系统正常运营及对关键业务数据进行有效地保护，以下设计方案仅提供参考。嘉禾院区数据中心东风东院区数据中心 本方案中，我们采用EMC的CDP保护技术来实现数据的连续保护和容灾系统。 1.在东风东院区数据中心部署一台EMC 480统一存储平台，配置一个大容量光纤磁盘存储设备，作为整个系统数据集中存储平台。 2.在嘉禾院区数据中心部署一台EMC 480统一存储系统，配置一个大容量光纤磁盘存储设备，作为整个平台的灾备存储平台。 ） 3.两地各部署两台EMC RecoverPoint/SE RPA，采用CLR技术，即CDP（持续数据保护）+CRR（持续远程复制），实现并发的本地和远程数据保护。 4.在东风东院区数据中心本地采用EMC RecoverPoint/SE CDP（持续数据保护）技术实现本地的数据保护。． 5.两地采用EMC RecoverPoint/SE CRR（持续远程复制）技术，实现远程的数据保护。由于两地之间专线的带宽有限，可以采用EMC Recoverpoint/SE异步复制技术，将东风东院区数据中心EMC480上的数据定时复制到嘉禾院区数据中心。根据带宽的大小，如果后期专线带宽有所增加，RecoverPoint会自动切换同步、异步、快照时间点三种复制方式，尽最大可能保证数据的零丢失。 1.3本地数据数据保护（CDP）设计
XXXX公司Oracle数据库异地容灾方案 2011年08月29日
1、公司简介 XXXX公司。 2、项目背景 ●XXXX有两个数据中心。 ●两个基地之间使用TCP/IP网络进行连接。 ●生产业务系统的后台数据库为Oracle。 ●数据库服务器操作系统为Windows。 ●数据库目前总体数据量约为2.4T。 ●生产系统为双机容错架构。 ●希望远程数据中心成为容灾中心。 3、解决方案 3.1方案原理 这是一个很典型的应用场景，用户对RPO、RTO的要求比较高，用户希望数据丢失尽可能少，恢复尽可能快。可是，要实现这一愿望，传统的容灾方案都是采用昂贵的存储设备或卷管理软件来实现，投入相当惊人，用户很难接受！CommVault的CDR连续数据复制是一个性价比很高的解决方案，工作原理如下图所示：
这个Oracle远程容灾方案的设计思想是：在容灾系统初始化时或备份系统被破坏时，利用备份和恢复来传送数据库的DBF文件；在数据库日常工作时，利用CDR来时复制数据库日志文件，并将日志回滚到备份数据中（对于双机架构来说，原理相同，所需模块相同， 如图生产主机可为双机或集群架构）。系统的数据流如下图所示：
3.2实施过程 在这个方案中，我们采用了CommVault的备份技术和CDR技术，数据共有4份冗余，除了生产数据外，还有容灾数据，本地备份和异地备份数据；这里需要注意的是，在两个数据中心的数据库都是使用本地数据为业务系统提供服务，并且将数据在两个数据中心之间相互复制，以便达到两个数据中心互为容灾中心的目的。整个容灾系统的建立共分4个阶段： ●初始化阶段：通过备份＋恢复方式，在容灾站点生成初始化数据 ●容灾复制阶段： 1.通过CDR复制交易日志 2.自动回滚日志实现数据库容灾 3.每天做异地数据库的冷备份 4.每天做本地数据库的热备份 ●灾难重建阶段： 如果数据崩溃，由于本地和异地都有灾备数据，通过本地的直接恢复实现本地网络 的灾难数据重建，避免在远程网络上传送大量的初始化数据 ●容灾演练阶段： 将容灾站点的数据库打开，就可以使用了。恢复正常工作方式，只要将灾备的数据 恢复，然后回滚以前的日志数据，就能恢复容灾复制阶段。 4、技术要点 在这4个阶段中，充分利用了CommVault的独特技术： ●CDR复制：连续数据复制，复制数据库交易日志。 ●断点续传：支持从中断点继续传送。 ●GridStor：支持多个介质服务器使用不同地区的数据源，这样就不需要通过网络来 回传送大量的数据。 ●自动恢复和回滚：支持以时间或者自动的方式，恢复和回滚日志或其它数据，而不 需要手工执行。 ●辅助拷贝：支持将本地的备份数据复制到异地，实现异地的灾备。
浪擎为您解析各种容灾方案
容灾分为两大类： 一、数据级容灾 也就是异地容灾系统有本地数据的一个副本，数据可以是本地生产数据的实时复制，也可以比本地数据略微落后，一般使用复制或备份的方法实现。目前实现数据级容灾的手段多种多样，技术成熟，更重要的是数据级容灾需要的软硬件投入较小，有着广泛应用。 二、应用级容灾 在数据级容灾基础上，在异地建立一套与本地生产系统相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当本地系统发生灾难时，异地系统可以提供完全可用的生产环境。大部分情况下应用级容灾要求容灾中心和生产中心之间有1:1的软硬件配置，相关的容灾软件价格也比较昂贵。 目前比较流行的集中容灾解决方案有： 一对一灾备 这是最简单也是最低成本的灾备方式，部署方式灵活，针对不同的距离和链路状况都有诸多适合的技术实现，从管理上来说也是最简单方便的，总体上这是性价比最高的一种灾备方式。 一对一灾备 两地三中心
两地三中心 同城灾备中心是一个同步数据镜像站点的，同样两地三中心可以有多种模式。与其他灾备方式不同，这种方式同时使同城灾备中心具有应用接管能力，在异地有数据的完整备份。在容灾能力上，两地三中心是当前最好的容灾模式，可以最大程度的保护数据和业务连续性，应对重大区域性灾难，多个中心之间可以在平时进行业务分担，也可以实现相互完全业务互备，而后端实现数据同步。 多对一统一灾备 多对一的统一灾备模式适合于有分支机构的企业和政府单位，地方或者分支机构统一向上级或总部进行备份，宏杉科技的灾备技术可以支持64:1，各个分支节点的复制互相独立，互不干扰。
多对一统一灾备 现代灾备方式 前面的讲到的几种灾备方式一般都仅针对数据型容灾，也就是灾难发生时可以保证一份可用的数据副本存在。随着用户对业务安全性和连续性要求越来越高，基于存储双活的应用级容灾已经被越来越多的用户采纳，我们称为现代的灾备方式。目前业界主流的双活实现方式有两大类，一类是以EMC、IBM、华为等为代表的采用虚拟化网关的实现方式，另一类采用存储自身实现双活，代表性品牌有Netapp、HDS以及国内的宏杉等，两种方式各有优缺点，用户需要按照自己的实际情况选择适合自己的容灾方式，适合的才是最好的。
华为GPON OLT 单业务配置手册 登陆OLT ﹥﹥User name ：root ﹥﹥User password ：admin Huawei Integrated Access Software. Copyright(C) Huawei Technologies Co., Ltd. 2002-2009. All rights reserved. ----------------------------------------------------------------------------- User last login information: ----------------------------------------------------------------------------- Access Type: Serial IP-Address : -- Time : 2013-02-02 10:34:51 ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- User fail login information: ----------------------------------------------------------------------------- Access Type IP-Address Time Login Times ----------------------------------------------------------------------------- Serial -- 2013-02-02 10:39:18 11 ----------------------------------------------------------------------------- 进入特权模式 Huawei﹥enable 进入全局配置模式 Huawei# config Huawei(config)# 创建DBA模板（模板id为120，模板名称为hisense，模板类型为type4最大带宽）Huawei(config)# dba-profile add profile-id 120 profile-name hisense type4 max 102400 Huawei(config)#display dba-profile all ---------------------------------------------------------------------------- Profile-ID type Bandwidth Fix Assure Max Bind compensation (kbps) (kbps) (kbps) times ---------------------------------------------------------------------------- 1 1 No 5120 0 0 0 2 1 No 1024 0 0 0 3 4 No 0 0 32768 0 4 1 No 1024000 0 0 0 5 1 No 32768 0 0 0 6 1 No 102400 0 0 0 7 2 No 0 32768 0 0
数据库容灾、复制解决方案全分析（绝对精品） 目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案： （1）基于存储层的容灾复制方案 这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。 目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。 （2）基于逻辑卷的容灾复制方案 这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。 我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？ 也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？ 上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案 我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧…… 我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。 所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。
1.用户现状与需求 1.1.用户IT系统现状 用户现有系统包括数据库、应用、WEB、邮件等系统，虽然是双机架构，但是其稳定性和可靠性都没有达到核心系统应该具备的标准，而且直连的存储架构对于性能和管理型都有一定的局限性。 业务数据是企业业务的生命线，如何保护好计算机系统里存储的数据，保证系统稳定可靠地运行，并为业务系统提供快捷可靠的访问，是系统建设中最重要的问题之一。为了保护业务系统的关键业务数据，我们必须对这些数据进行有效的备份，并支持快速恢复。 通过备份的方式将文件、数据库等重要数据做一个副本，只能在本地建立数据保护。但因意外(如火灾、地震等)停止工作时，随之而来的损失更是不可估量，为避免类似风险的存在，就需要建立异地容灾系统，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作，保证业务稳定运行。 1.2.用户需求 1.2.1.建设目标 从容灾的级别来说，可以规划数据级容灾和应用级容灾，根据业务种类多，业务方式多样化的特点，仅建设一个数据级容灾是不够，容灾发生时，业务快速的恢复是容灾系统的一大需求。应用级容灾是建立在数据级容灾的基础上，在容灾切换时，除了切换核心的数据库数据外，还包含了IP地址切换（按客户需要选择），中间件服务，用户级业务。应用级容灾从流程上实现了全业务的连续性需求。 从我们的灾难系统建设经验出发，xxx有限公司可以考虑以下业务连续性计划目标：RPO（最大允许数据丢失时间）：零数据丢失 RTO（最大允许宕机时间）：30分钟
应用级容灾需求 1.2.2.需求分析 用户需要保障数据的长期安全可靠的，数据对于灾难的安全性和可恢复性：灾难切换时间要求灾难系统切换时间不超过30分钟，最好在10分钟内实现。 多种灾难切换方式提供自动灾难系统切换和手动灾难切换方式 计划内维护要求提供计划内维护支持能力，计划内维护切换时间不多于10分钟 数据丢失性要求原则上要求零数据丢失，可以依据情况进行调整 数据同步方式提供同步和异步两种方式 备份和灾难备份方式采用物理备份方式实现 物理部件失败要求支持部分磁盘，文件系统，主机，磁盘柜等各种物理部件失败导致的失败保护。 站点失败要求支持由于火灾，电力以及其他因素导致站点失败的数据保护。 逻辑失败要求支持由于数据块腐败导致的数据库无法启动，数据丢失等逻辑失败保护 人类错误失败要求支持由于人类误操作以及入侵等导致人类错误失败导致的数据保护或者恢复。 生产系统的性能影响要求生产系统性能影响不超过5% 生产系统可用性要求容灾系统不会降低生产系统可用性 网络链路分钟级别短暂故障要求不会对生产系统产生影响 网络链路小时级别长期故障要求不会对生产系统产生影响 网络链路密集的秒级别短暂故障要求不会对生产系统产生影响 网络链路容错支持网络链路的容错，可以利用网络的备份链路，比如多路网卡等灾难系统的硬件故障由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响，比如网卡，磁盘以及控制卡等 灾难系统的软件故障由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响，比如灾难系统管理软件部件等 网络协议采用IP网络实现
信息系统容灾咨询服务项目 信息系统容灾演练 实施方案
目录 1演练背景 (4) 2演练目标与原则 (5) 2.1演练目标 (5) 2.2演练原则 (5) 3演练组织 (7) 3.1演练组织结构 (7) 3.2演练岗位人员安排 (8) 4演练方案设计 (10) 4.1灾难恢复演练场景 (10) 4.2演练假设条件 (10) 4.3演练系统范围 (10) 4.4演练方式 (10) 4.5演练方案技术要点说明 (11) 4.6灾备系统技术方案概述 (13) 5演练计划 (15) 5.1演练时间 (15) 5.2演练地点 (15) 5.3演练总体流程 (15) 5.4灾备演练流程大纲 (16) 5.5灾备演练流程控制图 (16) 5.6演练信息沟通方式 (16) 6演练准备工作 (18) 6.1灾备演练总体工作计划 (18) 6.2人员准备 (18) 6.3人员培训 (18) 6.4业务验证准备 (18) 6.5场地资源准备 (18) 6.6演练风险分析 (19) 7演练相关附件 (20) 7.1附件1演练方案模板 (20)
7.2附件2灾难恢复演练签到表 (20) 7.3附件3灾难恢复演练切换记录表 (21) 7.4附件4灾难恢复演练业务测试记录表 (22) 7.5附件5灾难恢复演练业务部门问题与建议表 (22)
1演练背景 信息系统及服务在xx公司生产经营和业务创新中越来越重要，信息系统灾难直接威胁公司战略目标实现，为提高xx公司信息系统的风险抵御能力，减少灾难打击和重大事故发生时造成的损失，保障业务持续稳定运行，2017年8月xx公司启动了灾备体系建设专项工作，2017年12月完成灾备咨询规划，2018年5月完成灾备系统实施方案设计和软硬件资源采购，2018年12月中旬实施并完成同城灾备系统集成建设与系统联调测试，初步完成重要信息系统的应用级灾备体系建设。灾备建设是xx公司信息系统安全运行保障体系的基础性工作，是保障信息服务业务连续性的必要手段，是适应当前IT建设和未来业务发展趋势的重大战略部署，是xx公司信息安全保障体系的重要组成部分。 灾难恢复演练是IT服务业务连续性建设的重要工作内容。通过演练可检验应急响应和灾难恢复体系的完整有效性，使相关人员了解信息系统应急响应及灾难恢复目标和流程；全面验证技术及业务管理指挥、流程操作、协调配合等方面的综合能力；完成灾难恢复相关人员意识和知识技能培训；验证应急响应及灾难恢复能力。 本文档为灾备咨询服务商H3C在本项目中的文档交付物，为xx公司信息系统灾难恢复演练提供规划和指导。本恢复演练规划方案对本项目中的灾难恢复演练的演练范围、演练方式、演练方案设计和演练计划进行了说明。灾难恢复演练是一项持续性的、常态化的体系建设和维护工作，本规划方案做为演练范例，指导近期项目中的灾难恢复演练；后续演练需结合具体演练目标和内容不断修订和完善。
山西新景矿煤业有限责任公司数据灾备解决方案 2017年10月
目录 第1章需求分析 (3) 1.1用户简介 (3) 1.2需求描述 (3) 1.3方案目标 (5) 第2章技术方案 (7) 2.1全局拓扑 (7) 2.2（人员定位、产量监控、自动化平台）应用级双活容灾设计——镜像系统 (7) 2.3（网站、OA、虹膜系统等）数据级容灾设计——实时备份 (8) 2.4功能展示 (8) 2.4.1全自动化追逐式全量 (8) 2.4.2实时增量复制 (9) 2.4.3切换 (9) 2.4.4回切 (9) 2.4.5日常维护 (9) 2.5镜像系统．在线式应用级容灾系统产品优势 (10) 2.5.1所见即所得的容灾 (10) 2.5.2应用级的复制技术 (10) 2.5.3实施无需停顿业务系统 (10) 2.5.4主备系统硬件规格无需一致 (10) 2.5.5对网络带宽消耗非常小 (10) 2.5.6其他 (11) 2.6实时备份．数据级备份系统产品优势 (11) 2.6.1全功能全平台 (11) 2.6.2实时、定时备份 (11) 2.6.3任意时间点还原 (12) 2.6.4其他 (12) 2.7Y系MCenter平台.可持续运维平台 (13) 2.8方案配置 (14) 2.8.1软件模块 (14) 2.8.2硬件模块 (14) 第3章项目预算清单 (16)
第1章需求分析 1.1用户简介 新景矿是国家"八五"、"九五"重点能源建设项目之一，前身为阳煤集团三矿改扩建区。1997年8月试生产，井口定名三矿新井，隶属三矿管理。1998年10月阳煤集团为建立高产、高效矿井，以"阳煤党发【1998】398号"文《关于成立新景矿及新井党委的通知》将三矿新井从三矿分离出来，成立新景矿。 随着企业社会信息化的发展，众多业务系统的运行，必然会产生大量的数据，而这些数据作为各行各业最重要的资源，越来越受到人们重视。同样，由于数据量的增加和新业务的不断涌现，如何确保数据的安全性、可用和可靠性；如何确保业务系统的可持续性运行；如何实现数据的集中管理，建立便捷维护的平台也是目前所面临的一个重要问题。 1.2需求描述 ?简述 根据与用户的沟通，我们初步了解到客户的实际环境业务系统众多，其中人员定位系统、产量监控系统、生产自动化平台均采用集群方式，也是本企业的核心应用系统，其他诸如网站、OA、虹膜等系统均为单机运行。具体环境见下方调研表： ?容灾环境调研表
容灾备份系统简介 2010-8-11 项目背景
随着计算机技术的快速发展，每个企业都在大量的使用计算机处理自己的核心数据, 这些数据往往是企业生产经营必不可少的部分。依赖这些数据的计算机系统的停机往往会造 成企业生产经营活动的停顿，给企业造成巨大的损失。所以，可以说，这些数据是企业的生 命核心。企业的IT管理员为了保证生产经营活动的持续运行，不断的加强对系统和数据的保护，如使用基于双机的高可用技术，磁盘阵列系统的RAID技术等。然而，人们依然无法 回避由于磁盘故障，人为失误，应用程序的逻辑错误，自然灾害等原因带来的系统停机或者数据丢失。所以，数据备份作为数据保护的最后一道屏障，必不可少。 、功能介绍 ■实时保护：连续捕获、实时备份数据变化，全过程保护数据安全。实现真正的持续性数据保护（CDP,无需设置任何备份时间点，居国内外同类产品领先地位。 ' 完善备份：同一软件可实现“数据库双机热备+接管”、“本地实时灾备”、“异地实时灾备”，全方位保证数据库安全。 E 任意回退：可按任意操作步数或时间点进行数据回退。主数据库遭到破坏时，备份数据库可将主数 据库回退到损坏前最后时刻的状态，且能保证事件的完整性。 ■ 快速恢复：主数据库或表损坏，从站自动检测，提示回退的步数。恢复1个G数据库在3 -5分钟。 ' 增量备份：只备份变化部分，在保障备份数据安全的同时减少备份的工作量。 ' 错峰机制：在系统负荷极大时暂停备份以免系统瘫痪，当系统负荷下降时备份暂停期间的数据，并重新开始实时备份。 ' 低耗资源：对主数据库压力小，系统采用消息机制，只有灾数据库发生变化时才触发，只传数据库的变化部分，不同于文件拷贝，和数据表的轮询。 ' 操作简单：自主开发设计，着重考虑国内用户使用习惯，安装、设置非常简单。 丄维护方便：启动或连接中断后重连时，自动校验主从站数据，保证数据准确。 ' 加密传输：底层通讯采用自主研发的通讯平台，所有数据都是用加密数据包进行数据交换，充分保证数据安全。 ' 高性价比：在各项性能领先的同时，价格远远优于国外软件。当选择不接管的热容灾备份方式时，从站可采用低档Server或高稳定性的PC （有足够的存储空间即 可），从而实现极低的总体成本。 ' 通用性好：不对数据库中的应用做任何修改。与数据库中表的结构无关，且无任 何限制。对数据库备份完整：如TABLES（表）、DIAGRAMS关系图）、VIEWS（视图）、 USERS（用户）、ROLES RULE等。