Hyper-V
使用SnapMirror活动同步进行Oracle数据库故障转移
建议更改
PDF
在SnapMirror活动同步上托管Oracle数据库的主要原因是、在计划内和计划外存储事件期间提供透明的故障转移。
SnapMirror主动同步支持两种类型的存储故障转移操作：计划内和计划外、其工作方式略有不同。管理员手动启动计划内故障转移、以便快速切换到远程站点、而计划外故障转移则由第三个站点上的调解器自动启动。计划内故障转移的主要目的是执行增量修补和升级、执行灾难恢复测试或采用一种正式策略、全年在站点之间切换操作、以证明完全的活动同步功能。
这些图显示了在正常操作、故障转移和故障恢复操作期间发生的情况。为便于说明、它们显示了一个复制的LUN。在实际的SnapMirror活动同步配置中、复制基于卷、其中每个卷包含一个或多个LUN、但为了简化情况、卷层已被删除。
正常运行
在正常操作下、可以从本地副本或远程副本访问LUN。红线表示ALOA公布的优化路径、结果应该是会优先沿着此路径发送IO。
绿线是活动路径、但可能会产生较长的延迟、因为该路径上的IO需要通过SnapMirror活动同步路径传递。额外的延迟取决于用于SnapMirror活动同步的站点之间的互连速度。
失败
如果活动镜像副本因计划内或计划外故障转移而变得不可用、则很明显、它将不再可用。但是、远程系统具有同步副本、并且指向远程站点的SAN路径已存在。远程系统能够为该LUN提供IO服务。
故障转移
故障转移会导致远程副本成为活动副本。这些路径将从"Active/Optimized"(活动/优化)更改为"Active/Optimized"(活动/优化)、并且IO将继续提供服务、而不会丢失数据
修复
源系统恢复使用后、SnapMirror活动同步可以重新同步复制、但运行的方向相反。现在、配置与起始点基本相同、只是已翻转主动镜像站点。
故障恢复
如果需要、管理员可以执行故障恢复、并将LUN的活动副本移回原始控制器。