什么样才算真正的数据库高可用灾备

--HVR Software作为世界领先的实时数据集成技术方案提供商，其产品HVR被广泛应用于数据库高可用/容灾、实时BI、实时大数据数据库迁移和混合云数据实时集成等场景。

数据库高可用/容灾是个老话题了，但其对企业信息安全和业务连续性保障的重要性是不言而喻的。同时在行业内也存在着一些误区，这样导致了容灾方案并不总是那么有效。

首先备份不等于容灾

数据库备份是对数据的最基本保护，但无论你备份的多么频繁，备份集多么安全，当灾难发生时最多只能确保你的数据不丢失(RPO=0)，但由于生产系统的恢复需要经过备份数据集读取、数据库恢复、打开灯一系列复杂的过程，业务连续性（RTO）往往得不到有效的保障。尤其是在业务繁忙时间，数据库的不正常宕机，即使数据文件并没有损坏，数据库重启过程的事务前滚/回滚工作也往往需要花费半个小时甚至更长时间才能完成。如果数据文件本身发生损坏，一些基于存储复制或文件系统卷复制技术往往会将这些错误也一并复制到灾备端，从而使得备份失效。所以为了避免这种情况发生，此类解决方案往往还需要提供“任意时间点回退”的能力（CDP）来确保数据可以被真正有效的恢复到最近一个时间点，而代价就是依然会有至少秒级的数据丢失。

容灾也不等价与高可用

有人说容灾所说的“灾难”指的的大范围，高烈度的故障，例如火灾、地震、洪水、大范围的停电，所以往往还会有个限定词叫异地容灾。而高可用只要做到硬件冗余，实现单点故障时的业务接管就行了。这个观点只对了一半。

现如今，企业真正关心的“灾难”可以泛指非正常情况下的故障停机，而高可用则还应当应对由于IT运维工作等原因带来的计划内停机，因为无论是计划内还是计划外的停机都会对企业业务连续性造成损失。并且灾难故障往往是十年一遇甚至百年一遇，而维护停机工作才是无可避免经常会对业务连续性造成威胁的停机事件。

所以高可用容灾方案不但要应对异常故障损失， 运维工作可能会带来的计划内的系统停机更加是关键。 会造成数据库计划内停机的运维工作，常见的有：

硬件扩容，升级，改造；

软件的尤其是数据库和操作系统升级打补丁等；

应用的升级改造。

a)应用程序代码升级

b)对表的存储改造，例如将表从旧的表空间转移到新的表空间；或者最初设计不当，表增长太快，需要把普通表改造成分区表

如果能够在运维工作进行过程中让灾备系统接管生产业务，等维护工作结束后再将系统切回生产端，这就能最大化地保障业务连续性。所以真正的高可用/容灾方案不但能够容忍软硬件环境上的异构（存储设备、操作系统版本、数据库版本等），还要能够实现对接管期间业务数据的逻辑回写。

作为真正的数据库逻辑复制技术，HVR可以实现最广泛意义上的异构系统复制。其在数据库高可用/灾备场景有很多优势：

数据复制实时性高，确保数据安全性

HVR基于日志的连续变化数据捕获技术可以实现秒级延迟复制， 有效保障了异地容灾场景下， 当灾难发生时数据的安全性， RPO接近于0；

2.非侵入式数据捕获， 对源数据库无影响

HVR通过直接读取数据库的事务日志来捕获数据变化信息， 不占用生产数据库资源， 属于非侵入式的数据捕获技术。

此外， HVR还支持无代理的部署方式， 避免在生产服务器上安装部署软件产品。

3. 数据加密和压缩

数据传输过程可以实现SSL加密，同时平均20倍左右的压缩率保证了即使通过公网传输也可以保障数据不被窃取，提高网络带宽使用效率，降低网络使用成本；

HVR的成功案例，数据库复制距离超过5000公里（法兰克福到新加坡），成功的支撑了航空业的核心系统安全运营了超过10年时间；

4. 目标系统实时可用

HVR复制过程，目标数据库是出于open状态，这带来了至少2个好处：

A）随时可以验证灾备系统的可用性，确保灾难发生时可以立刻接管，不必等待数据库重新启动，RTO最小化；

B）平时目标端可以作为报表查询系统分担生产的压力，也进一步降低了故障发生的概率，提高灾备系统的利用率，保护投资；

5. 数据库之外的文件复制

很多时候，企业要实现应用灾备，数据库是核心，但往往还有很多必要的数据是放在数据库之外的，例如应用代码、脚本程序；仅仅存放了路径指针在数据库内，实际数据以文件形式保存在文件系统上的数据等。

而HVR可以支持文件的实时复制，这也完善了企业高可用/容灾方案。

6. 监控

HVR自带实时监控功能:

A）HVR的图形界面可以直观的提供当前系统复制的相关信息；

B）后台无人值守的监控会在异常发生时自动发送告警信息以email的形式发送给管理员，或以SNMP消息的方式发送到第三方企业监控平台上；

7. 报表

HVR提供丰富的报表，帮助管理人员了解和分析过去一段时间复制的延迟时间、数据量、热点表等精确信息。为调整和优化复制策略提供可靠的依据。

HVR虽然不支持一些物理操作的复制，如前所述，这恰恰是非常适合在高可用性/容灾场景的特性。

当发生存储设备更换、扩容时，基于存储的复制方案往往需要对灾备中心做同样的改造，而HVR不需要；

当数据库打补丁升级的时候，如果希望用灾备端临时接管业务，物理备份方案是没办法支持回切的；同时， 数据库升级等操作有时也会带来一些未知的风险， 例如触发新的bug问题， SQL执行计划发生改变导致性能问题等等。 HVR的方案不但可以减少升级过程带来的业务停机时间， 也可以当这些不可预料的问题发生时回退到旧版本的数据库；

当数据库需要执行一些不能在线操作的工作时， 例如将普通表改造为分区表， 或者将表从一个表空间移动到另外一个表空间。 目标数据库可以临时接管业务， 待改造完成后再将业务回切到原系统。

HVR可以支持表上的DDL复制（createtable/alter table/drop table/truncate）,所以仅仅当数据库内发生存储过程/函数/用户/权限等变化时，需要额外的工作去保证应用可以正常切换。而这些变化对于应用系统来说属于低频且受管制的操作，通常不会随意在线进行。所以完全可以在执行相关变更工作完成后，对数据库做个逻辑导出，然后传输到灾备端做导入即可。

目前HVR已经发布了5.3版本，可以将数据多种不同类型的平台之间进行复制，快看看有没有你感兴趣的?