Informix Dynamic Server 11.50 的 HDR 环境搭建最佳实践
Informix Dynamic Server 11.50 的 HDR 环境搭建最佳实践
【前言】
Informix Dynamic Server(IDS) 的 HDR 技术就是一种成熟的内置在 IDS 数据库引擎中的容灾恢复技术,它通过两个远程结点的实时双机备份,把逻辑日志从主服务器中传输到辅助服务器,使得两台服务器的状态时刻保持一致,从而提供快速的灾难恢复能力。本文以一个 HDR 配置实例为基础,详细描述了在 IDS 11.5 环境下搭建 HDR 高可用性环境的步骤、技术细节以及需要注意的问题,相信一定会对读者有所帮助。
【概述】
随着 IDS 在电信、银行、保险等各行业应用的发展,IDS 数据库灾备系统尤其是异地灾备系统的建设显得越发重要。大家知道,HDR 技术是非常方便、高效、实用的异地容灾备份系统解决方案。因而,我们这里将针对 IDS 的使用者,详细介绍 IDS 11.5 中的 HDR 技术,从搭建 HDR 实例讲起,包括一些常见的服务器状态转移场景、典型的 HDR 灾难恢复以及 11.5 相比 9.4 的 HDR 新功能等。本文包含了我们对 IDS 11.5 HDR 相关官方文档的解读,也是我们搭建实际 HDR 环境最佳实践的总结报告。
IDS 11.5 中 HDR 的完整功能介绍
在 11.5 中 HDR 的功能已经相当完善,这里做一个简要介绍:
1.灾难发生时应用程序可以在等待一个超时时间以后,自动平滑过渡到可用的辅助服务器,不需要人工干预,大大提高了应用程序的可用性,避免的更多的经济损失。
2.辅助服务器不仅可进行读操作还可以完成写操作 (update/delete/insert),大大提高了硬件的利用率。
3.提供了新的连接管理器 (Connection Manager) 组件,用于提供服务器集群中状态的自动转换协调、静态的负载平衡、动态的负载平衡。
4.灾难发生时,通过 DRAUTO 参数或者 CM 的配置,HDR 对本身可以自动恢复。
5.完善的数据传输加密功能,多种加密算法,可以自动切换加密算法和密码。
6.方便易用的免费数据库管理员工具:OpenAdmin Tool。
服务器环境
图 1. 服务器环境
服务器 :
Informix0: 9.125.66.129 1G memory, 120G disk, 2cpu(Intel(R) Pentium(R) 4 CPU 3.20GHz), IDS 实例 beijing,辅助服务器
Informix1: 9.125.66.130 2G memory, 120G disk, 2cpu(Intel(R) Pentium(R) 4 CPU 2.80GHz), IDS 实例 shanghai ,主服务器
操作系统 :
Fedora release 10 (Cambridge)
网络 :
局域网络,两台机器在同一网段
IDS 版本 :
IBM Informix Dynamic Server Version 11.50.UC4
配置操作系统信任关系
为了满足 HDR 主辅服务器之间进行数据传输和相互操作的需要,我们在配置 HDR 之前首先要在两台服务器之间建立操作系统级别的信任关系。具体而言是要在主辅服务器之间建立 RSH 信任关系。
确认 rsh 已经安装并且启动
使用以下命令检查:
>>chkconfig | grep rsh
rsh: on
如果 rsh 没有安装或者没有启动,我们需要使用操作系统的安装程序管理软件进行安装配置,对于 fedora 可以使用:
yum install rsh-server, yum install rsh
针对 Informix 用户配置 rsh
当然这里也可以针对所有用户配置互信关系,但是只针对 Informix 用户配置互信关系就够用了。
首先,在两台机器的 /home/Informix 目录下创建 .rhosts 文件。
其次,在 Informix1 的 .rhosts 文件中添加它信任的机器名字或者 IP 也就是 : Informix0 或者 9.125.66.129,在 Informix0 的 .rhosts 文件中加它信任的机器名字或者 IP 也就是: Informix1 或者 9.125.66.130。
最后需要特别注意:两台机器上都要保证 .rhosts 的权限为 600 否则该文件将被忽略,信任关系配置将失败。也就是要执行:
chmod 600 .rshosts
验证 rsh 配置
在 Informix0 上用 Informix 用户登录执行:
>>rsh Informix1 hostname
Informix1
在 Informix1 上用 Informix 用户登录执行:
>>rsh Informix0 hostname
Informix0
HDR 配置
前提条件
两台服务器的 IDS version 必须相同 (OS 的版本可以有细微的不同 )。
在两台服务器创建 IDS 数据库实例: Informix1:shanghai, Informix0:beijing。Informix1 的 IDS 实例 shanghai 将要被配置成主服务器。
配置 SQLHOSTS
配置指向对方的服务名
在 shanghai 服务器的 SQLHOSTS 文件加入指向北京服务器的条目:
beijing onsoctcp Informix0 6666
在北京服务器的 SQLHOSTS 文件加入指向上海服务器的条目:
shanghai onsoctcp Informix1 6666
最后两台服务器的 SQLHOSTS 文件都要包含以下内容:
beijing onsoctcp Informix0 6666
shanghai onsoctcp Informix1 6666
配置服务器组
配置服务器组的目的在于方便应用使用。这一步需要在应用端的 SQLHOSTS 做,但不是必须的步骤。只需要在 SQLHOSTS 中加入黑体的部分即可:
china group - - i=1
beijing onsoctcp Informix0 6666 g=china
shanghai onsoctcp Informix1 6666 g=china
配置 ONCONFIG
两台服务器关于 Root Dbspace 的参数必须相同:
ROOTNAME
ROOTOFFSET
ROOTPATH
ROOTSIZE
实际环境中我们的配置为:
ROOTNAME rootdbs
ROOTPATH $InformixDIR/demo/hdr/hdr.rootdbs
ROOTOFFSET 0
ROOTSIZE 1000000
关于磁盘镜像,不要求两台服务器的 MIRROR 配置必须相同,但是如果在主服务器对 Root DBSpace 做了镜像设置,那么辅助服务器也必须做同样的配置,也就是说这种情况下以下参数必须相同:
MIRROR
MIRROPATH
MIRROROFFSET
实际环境中我们没有对这些参数做修改,使用了默认值。
关于物理日志配置的以下参数必须相同:
PHYSBUFF
PHYSILE
实际环境中我们没有对这些参数做修改,使用了默认值。
关于逻辑日志配置的以下参数必须相同:
LOGBUFF
LOGFILES
LOGSIZE
DYNAMIC_LOGS
实际环境中我们没有对这些参数做修改,使用了默认值。
关于 HDR 配置的以下参数必须相同:
DRAUTO
DRINTERVAL
DRTIMEOUT
实际环境中我们的配置为:
DRAUTO 0
DRINTERVAL -1
DRTIMEOUT 30
如果 HDR 对之间的数据传输需要加密的话,那么以下加密参数必须相同:
ENCRYPT_HDR
ENCRYPT_CIPHERS
ENCRYPT_MAC
ENCRYPT_SWITCH
ENCRYPT_MACFILE
实际环境中我们没有对这些参数做修改,使用了默认值。
为了使得辅助服务器可写,实际环境中我们设置了:
UPDATABLE_SECONDARY 1
两台服务器关于服务名的设置分别为:
SERVERNUM 0/1
DBSERVERNAME beijing/shanghai
建立 HDR
步骤 1:配置 UDR、UDT、DataBlade
如果数据库需要用到 UDR、UDT、DataBlade 等,需要先在主服务器进行安装和注册,然后在辅助服务器安装 UDR、UDT、DataBlade( 注意:这里只需要安装不需注册 ),如果不需要用到这些,则可以省略这一步。
步骤 2:在主服务器 (Informix1) 上设置服务器状态
执行 onmode -d primary beijing
这一步是告知 Informix1 的 shanghai 实例,它将要被赋予 HDR 主服务器的角色,与它配对的辅助服务器实例为 beijing。
步骤 3:关闭辅助服务器
如果辅助服务器的 IDS 实例是 online 状态,则需要先行关闭,即在 Informix0 上执行:
onmode – ky
步骤 4:在主服务器做 0 级全备份,在辅助服务器做全恢复
这一步可以通过任何传统的方式来完成,但是为了方便起见,这里使用 ontape 通过 STDIO 管道来完成,也就是说数据库的 0 级全备份不需要占用磁盘空间,也省去了全备份文件拷贝的步骤,主服务器在做全备的同时通过管道把数据发送给辅助服务器,辅助服务器同时做全恢复,备份数据只在内存中临时存在,节省了空间又加快了速度。所以,这一步只需要一个命令就可以完成:
在 Informix1 执行以下命令:
ontape -s -L 0 -t STDIO -F | rsh Informix0 “ontape -p – t STDIO"
这时候 Informix0 上的 beijing 实例会自动启动,状态由 not initialized 变为 Initialization,进而变为 Fast Recovery:
>> onstat -
IBM Informix Dynamic Server Version 11.50.UC4 -- Initialization
-- Up 00:00:04 -- 144144 Kbytes
>> onstat -
IBM Informix Dynamic Server Version 11.50.UC4 -- Fast Recovery
-- Up 00:00:07 -- 144144 Kbytes
步骤 5:在辅助服务器 (Informix0) 上设置服务器状态
执行 onmode -d secondary shanghai
这一步是告知 Informix0 的 beijing 实例,它是被作为 HDR 辅助服务器的角色,与它配对的主服务器实例为 shanghai。
步骤 6:状态验证
步骤 5 执行完毕后,稍等一下,可以看到辅助服务器 (Informix0) 上 beijing 实例的状态由 Fast Recovery 变化为 Updatable (Sec) ,也就是:
在辅助服务器 (Informix0):
>>onstat -
IBM Informix Dynamic Server Version 11.50.UC4 -- Updatable (Sec)
-- Up 00:07:21 -- 144144 Kbytes
>>onstat -g dri
IBM Informix Dynamic Server Version 11.50.UC4 -- Updatable (Sec)
-- Up 00:02:22 -- 144144 Kbytes
Data Replication:
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes
HDR Secondary on shanghai 50 / 1 Y
DRINTERVAL -1
DRTIMEOUT 30
DRAUTO 0
DRLOSTFOUND /home/informix/IDS1150EE/etc/dr.lostfound
DRIDXAUTO 0
ENCRYPT_HDR 0
在主服务器 (Informix1):
>>onstat -
IBM Informix Dynamic Server Version 11.50.UC4 -- On-Line (Prim)
-- Up 01:32:20 -- 160528 Kbytes
>>onstat -g dri
IBM Informix Dynamic Server Version 11.50.UC4 -- On-Line (Prim)
-- Up 00:02:41 -- 144144 Kbytes
Data Replication:
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes
primary on beijing 50 / 1 NA
DRINTERVAL -1
DRTIMEOUT 30
DRAUTO 0
DRLOSTFOUND /home/informix/IDS1150EE/etc/dr.lostfound
DRIDXAUTO 0
ENCRYPT_HDR 0
这表明我们的 HDR 环境配置成功,并且我们的辅助服务器和主服务器一样是可以执行写操作的。
HDR 相关参数介绍
这一部分力求用最简单的方式介绍 HDR 相关参数,关于详细的说明请参见 IDS 技术文档。
UPDATABLE_SECONDARY
这个参数是 11.50 才有的新功能,取值范围为:0 到 2 × (CPU VP), CPU VP 一般就是服务器上 CPU 的个数。
作用:用于控制辅助服务器是否可写,也就是说如果设置为大于 0 的数,则在辅助服务器可以执行 (delete/insert/update) 操作,相应的状态为:Updatable (Sec) ,如果设置为 0 ,则在辅助服务器只能执行 select 操作,相应的状态为:Read-Only (Sec) 。
进一步的说,实际上这个参数的直接含义是辅助服务器上进行写操作的连接个数。
DRINTERVAL
这个参数单位为秒,用于设置多久才把日志发送到辅助服务器做数据同步,如果设置为 -1 则为同步模式,也就是说任何时候只要 logical-log buffer 要写到磁盘中,就同时把日志内容发送到辅助服务器,得到辅助服务器确认后才认为写磁盘操作成功。在我们的实际设置中,设置成了 -1,这样在发生灾难情况下不会因为缓冲区的问题而丢失数据,但是性能上会受到一些影响。
DRAUTO
取值范围为:
0 Manual
1 Retain server type
2 Reverse server type
3 Connection Manager Arbitrator controls
简单来说,这个参数用于控制 HDR 中 IDS 实例重启后怎样确定自己的角色, 1 表示保持原有角色,2 表示转换为新的角色,3 表示使用连接管理器来仲裁。举个例子说:比如 HDR 主服务器重启后,DRAUTO 为 1 时,主服务器仍为主服务器;DRAUTO 为 2 时主服务器变为辅助服务器,原来的辅助服务器成为新的主服务器。
DRTIMEOUT
单位为秒,用来指定 HDR 对之间多少时间间隔没有响应被认为是超时。
DRLOSTFOUND
指定一个目录,用于存放逻辑日志,内容是主服务器已经提交但是辅助服务器没有同步的数据。用于防止数据丢失。
DRIDXAUTO
取值范围为 0、1。
是否自动进行索引修复。
关于传输加密参数
ENCRYPT_HDR 取值范围为:0、1
ENCRYPT_CIPHERS 各种支持的加密算法组合,详见文档。
ENCRYPT_MAC 取值范围:off, low, medium, high
ENCRYPT_SWITCH 两个秒为单位的时间,例如:60,60
ENCRYPT_MACFILE 取值范围:密钥文件全路径或者 BUILDIN
这一组参数用于设置 HDR 对之间数据传输的加密方式,只有 ENCRYPT_HDR 为 1 时才进行数据加密传输。
IDS11.5 支持很多加密算法:DES, des3 , desx, aes......,也可以把 ENCRYPT_CIPHERS 设置为 all, 意为使用所有支持的加密算法。
ENCRYPT_MAC 用于控制加密的级别,可以根据自己的需要设置。
ENCRYPT_SWITCH 的第一个数字表示多久进行一次加密算法的切换,第二个数字表示多久进行加密密码的切换。也就是说 HDR 在固定的时间间隔内自动切换加密算法和加密密码,大大减小了数据泄露的可能性。
ENCRYPT_MACFILE 为指向加密密钥文件的全路径,可以使用内置的加密密钥文件,也就是说可以设置为”BUILDIN”即可,如果要使用自己的密钥文件可以使用 IDS 自带的工具”GenMacKey”来生成,具体使用方式请参照 IDS 相关技术文档。要强调的是:HDR 对两台服务器的加密密钥文件的内容必须相同。
HDR 使用示例
图 2. 应用环境
创建示例数据
脚本 cteate_table.sql 用于创建示例数据,具体内容请参见附录。其中 customer.unl 和 customer_sample.unl 为数据文件。
首先创建 stores_demo 数据库,然后通过运行:
dbaccess stores_demo create_table.sql
来创建实验数据表。
应用示例
我们使用了三个简单脚本分别模拟不同的应用,
insert.bash 用来做插入操作
update.bash 用来做更新操作
query.bash 用来做查询操作
每个脚本启动以后都是隔几秒钟就自动针对 customer 表进行相应的操作,启动的方式分别为:
insert.bash stores_demo beijing
update.bash stores_demo beijing
query.bash stores_demo beijing
其中第一个参数为数据库名,第二个参数为数据连接名。为了验证 HDR 正常工作,这里我们使用了以下场景, 同时运行以下脚本:
1) insert.bash stores_demo china
2) update.bash stores_demo china
3) query.bash stores_demo china
4) query.bash stores_demo beijing
5) query.bash stores_demo shanghai
应用 3),4),5) 分别通过访问服务器组 (China)、辅助服务器 (Beijing)、主服务器 (shanghai) 的方式用来监控 customer 表的数据变化。
应用 1)、2) 通过访问服务器组 (China) 对数据进行插入和更新操作:1) 用来插入数据,2) 用来更新 customer 表中 customer_num 为 1 的一条记录。
这样我们可以看到,主、辅服务器,包括服务器组都是可以提供服务,都可以执行 select/update/insert/delete 操作,两边的数据自动同步,也就是说,在主服务器做的数据修改会自动同步到辅助服务器,反之亦然。这样在提供灾备功能的同时也大幅度提高了硬件利用率 ( 很多高可用性灾备方案中的辅助服务器不能提供任何服务,平时状态下辅助服务器的硬件投资是一种极大的浪费 ),当主服务器发生灾难事故时,辅助服务器可以自动接管连接到服务器组的应用,也就是说在一个网络超时之后,应用 1)、2)、3) 可以自动平滑过渡到辅助服务器,这一场景在后文有更详细的描述。
当然,大家也可以改变脚本运行的组合方式,模拟自己关心的运行场景,脚本具体内容参见附录。
容灾恢复实验
在上述应用脚本运行起来以后,我们可以进行人为破坏以模拟灾难场景,然后查看应用脚本是否能够在一个超时时间段内平滑过渡到可用的 HDR 结点。需要说明的是,在通过服务器组连接到 HDR 服务器对的场景下,当主服务器可用时,应用是连接到主服务器的,也就是说仅仅对辅助服务器的破坏不会直接影响应用的运行 ( 这里指的是连接到服务器组的应用 ),因而我们的人为破坏主要针对主服务器进行,破坏方式为:
正常关闭主服务器
拔掉主服务器网线
再有,在 ONCONFIG 文件中的 DRAUTO 参数配置直接关系到 HDR 服务器对的灾难恢复方式,我们的实验尝试了常用的 DRAUTO=1 和 2 的场景。
关闭重启主服务器
当 DRAUTO=1 时,主服务器恢复以后仍能保持主服务器的地位,具体如下:
关闭主服务器:onmode – ky
辅助服务器自动完成以下状态变化:Updatable (Sec) > Fast Recovery (Sec) > On-Line
对于连接到 china 服务器组的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重启主服务器,重启主服务器 IDS 实例:oninit – vy,主服务器自动完成以下状态变化:Fast Recovery (Prim) > Quiescent (Prim) > On-Line (Prim)
同时,辅助服务器自动完成以下状态变化:On-Line > Shutting Down > Updatable (Sec)
当 DRAUTO=2 时,主服务器恢复以后只能退为辅助服务器的地位,具体如下:
关闭主服务器:onmode – ky
辅助服务器自动完成以下状态变化:Updatable (Sec) > Fast Recovery (Sec) > On-Line (Prim)
对于连接到 china 服务器组的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重启主服务器,重启主服务器 IDS 实例:oninit – vy,主服务器变为新的辅助服务器,状态为:Updatable (Sec)
同时,辅助服务器状态保持:On-Line (Prim)
拔掉主服务器的网线
当 DRAUTO=1 时,主服务器恢复以后仍能保持主服务器的地位,具体如下:
拔掉主服务器网线
主服务器状态保持不变,为:On-Line (Prim)
辅助服务器自动完成以下状态变化:Updatable (Sec) > Fast Recovery (Sec) > On-Line
对于连接到 china 服务器组的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重新连接主服务器网线,主服务器自动完成以下状态变化:Fast Recovery (Prim) > Quiescent (Prim) > On-Line (Prim)
同时,辅助服务器自动完成以下状态变化:On-Line > Shutting Down > Updatable (Sec)
当 DRAUTO=2 时,主服务器恢复以后只能退为辅助服务器的地位,具体如下:
拔掉主服务器网线
辅助服务器自动完成以下状态变化:Updatable (Sec) > Fast Recovery (Sec) > On-Line (Prim)
对于连接到 china 服务器组的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重新连接主服务器网线,主服务器状态不变,为:On-Line (Prim)
同时,辅助服务器状态不变,同样是:On-Line (Prim)
注意:这种情况下 HDR 对已经遭到破坏,两个服务器都是主服务器都在试图联系自己的辅助服务器,很显然都会失败,处理方式参见:DRAUTO=2 时需要注意的一个问题。
几个常见问题
在同一台机器搭建 HDR 实验环境
如果需要在同一台机器上的两个 IDS 实例之间搭建 HDR,对于 ROOTPATH,因为 HDR 要求 IDS 主辅实例的值必须相同,而我们是在同一台机器,IDS 两个实例又不能指向同一个文件,这就产生了矛盾,这时我们需要使用一个小技巧:使用相对路径,这个对路径是相对于运行 oninit 时的当前路径 ( 注意 : 在 windows 中,因为 oninit 是作为服务运行的,没有当前路径,该路径是相对于路径 %InformixDIR%bin 的相对路径 )。比如 ROOTPATH 设置为 ./data/hdr.rootdbs,在 /home/informix 下运行 oninit,则实际上使用的数据文件是:/home/informix/data/hdr.rootdbs。
一个常见的 HDR 启动问题
有时 HDR 辅助服务器不能成功启动,并且我们会在 online.log 文件中看到:类似“DR: Start failure recovery from tape ...”的信息。一般来说,这是因为主服务器已经把某些 log 文件备份出去,辅助服务器启动以后向主服务器发送同步请求后,主服务器没有找到需要的 log 文件 ( 因为已经被 backup)。解决的办法是:
挂接 log 所在的磁带使得辅助服务器可以访问该文件
在辅助服务器运行:ontape -l
DRAUTO=2 时需要注意的一个问题
DRAUTO=2 的情况下,如果因为网络连接问题造成主辅服务器失去联系,两个服务器都会自动把自己状态转为主服务器,网络正常后,两个服务器都开始试图联系自己的辅助服务器,很显然都会失败,为了重建 HDR 对,我们需要在二者中选择新的辅助服务器 ( 最好是数据更新最少的服务器 ),然后重新建立 HDR 对。如果零级恢复的代价太大,我们可以先尝试使用 oninit – PHY 命令把选定的新辅助服务器转换到 Fast Recovery 状态,然后再通过 onmode 命令建立 HDR 对,这种方式是否成功取决于服务器在 HDR 对遭到破坏期间的是否有 checkpoint 发生。
关于对 chunks/spaces 的操作
在 HDR 对中,当需要添加 / 删除 chunks/dbspace 时,需要注意的是:
操作只能在主服务器进行
操作可以由 HDR 主服务器自动同步到辅助服务器
主辅服务器需要预先创建相应的文件或者 link
例如:创建一个新 dbspace。
1. 需要预先在主辅服务器创建相应的文件:
>> touch dbspace1
>> chmod 660 dbspace1
2. 然后在主服务器执行:
>>onspaces -c -d dbspace1
-p /home/informix/IDS1150EE/demo/hdr/dbspace1 -s 10000 -o 0
Verifying physical disk space, please wait ...
Space successfully added.
关于 BLOB 和 CLOB 数据类型
在 IDS11.5 的 HDR 环境下是可以使用 BLOB/CLOB 数据类型,也就是说对 BLOB/CLOB 数据的更新可以通过 HDR 自动同步,在辅助服务器同样可以对 BLOB/CLOB 数据进行更新操作。
关于 RAW table
在实际应用中,为了加快数据更新速度,有时候需要使用 RAW 类型的数据表,在 HDR 环境下对 RAW 类型数据表需要注意以下几点:
在主服务器上可以创建、删除、访问 RAW 类型的数据表,但是不能修改 RAW 类型为 STANDARD 类型,也不能修改 STANDARD 类型为 RAW 类型 , 否则会得到 -19845 错误。
在辅助服务器上不能对 RAW 类型数据表进行任何形式的访问,否则会得到 -19846 错误。
IDS 11.5 HDR 与 IDS 9.4 HDR 的比较
以下这张表格简要的对 HDR11.5 的功能做了总结,也就是列举了如果从 9.4 升级到 11.5 从 HDR 的角度我们能享受到的新技术成果。
表 1. IDS 11.5 HDR 与 IDS 9.4 HDR 对比表
功能 目标 IDS 9.4 IDS 11.5
1 应用的自动快速切换 快速恢复、易用性好 手工 自动
2 辅助服务器可写 提高硬件利用率 N/A YES
3 连接管理器 (CM) 提高硬件利用率、易用性 N/A YES
4 HDR 自动重建 提高易用性和硬件利用率 N/A YES
5 数据传输加密 安全性好 N/A YES
6 OAT 可视化工具 易用性好 N/A YES
【结束语】
以上是我们在 IDS 11.5 中搭建 HDR 环境的实践,总之,IDS 11.5 的 HDR 技术为我们提供了一个完整的异地数据库容灾解决方案,当灾难发生时可以使得应用快速恢复,在平时又能大幅度提高硬件利用率……,所有这些都是 IDS 11.5 的 HDR 技术给我们带来的好处,如上所述,相对于其他异地备份技术 HDR 的环境搭建又是如此容易,我们相信,使用 11.5 的 HDR 技术作为异地容灾备份机制是明智的选择。