摘 要：企业信息化实现所必须依赖的关系型数据库是基于共享存储或者热备的方式来实现高可用的。在高可用的实现过程中存在用户需求不明确和硬件投资成本太高的问题，企业对高可用方案的可管理性与系统复杂性之间的矛盾。基于SLA的数据库高可用方案将SLA与数据库可靠性有机的结合在一起，有效的解决了数据库高可用在实施过程中的投资和收益矛盾。

关键词：SLA；数据库；高可用性；服务质量

中图分类号：TP311.131 文献标识码：A

Abstract：The relational database，which enterprise informatization depends on，achieves high availability based on shared storage or hot standby.Many problems are encountered in the implementation process of database high availability，such as ambiguous user requirements，high hardware investment cost，and the contradiction between the manageability of the high availability scheme and the complexity of the system.According to the SLA-based database high availability scheme，the paper organically combines SLA with the database reliability，which effectively solves the contradiction between investment and profit during the implementation process of database high-availability.

Keywords：SLA；database；high availability；service quality

1 引言（Introduction）

數据库已经成为企业信息化和数字化不可或缺的核心数据管理系统。数据是企业最为核心的无形资产，提供高可用的数据库服务是数据库管理系统的核心目标。为了实现数据库高可用的目标往往需要付出昂贵的服务和设备费用，但是在出现数据库相关故障时仍旧难以应付，在相应的时间内完成数据库的恢复，继而继续提供生产服务[1，2]。服务等级协议（SLA）被广泛应用与描述服务所需要达到的性能目标，能够将企业对数据库高可用的需求与高可用实现的目标有机的关联起来。SLA可以帮助用户梳理对数据库可用性的等级需求，对应等级需求实现的可用性方案，并且通过SLA也可以明确用户对数据损失和恢复生产时间的需求，进一步理解数据库可靠性的含义。

2 数据库高可用方案（High availability scheme of

database）

近年来，互联网通过云计算的方式将高昂的设备费用转化给计算能力提供给用户，以MySQL、OceanBase、Mango等分布式数据库，通过软件实现自动容错，使得自身故障对外部使用者不可见，能够将数据库部署在廉价的不可靠低端服务器上，且能够同时满足高可用与强一致性[3]。但是数据作为企业的核心资产，尤其对部分企业来说出于对安全保密的考虑，难以将企业的数据部署到公有云数据库中。

本文以Oracle DB作为企业主流数据库来研究数据库高可用方案，Oracle DB实现高可用的方案主要有RAC高可用集群、DataGuard热备和MAA最大可用性架构三种模式[4]，其中MAA包含了前两者的实现。限于篇幅，笔者不再对数据库的常规备份、恢复机制做研究描述，但是备份、恢复手段亦数据库高可用的基础。

2.1 RAC高可用集群

Oracle实现高可用的主流方式是通过Oracle自身提供的Cluster集群中间件来搭建集群，在Cluster集群的基础上构建多台Oracle主机和实例，并将数据存储在多个实例可以共享访问的共享存储中。在每台服务器中运行着各自的Oracle实例（Node1，Node2，Node3）管理自身的进程和内存、集群ASM实例管理逻辑卷和文件系统、Cluster和Oracle DBMS自身的日志。所有实例都通过HBA卡连接高端的光纤存储区域网FC-SAN（Fabre Channel-Storage Area Network）实现共享存储。共享存储中需要存储集群的配置文件、选举文件、数据库的数据文件、在线日志文件、归档日志文件和备份文件等。RAC高可用集群的实现方案如图1所示。

如图1所示，由于共享在线日志，多服务器组件集群中的任一服务器或者实例出现故障，其他的实例可以迅速接管其故障之前读写操作，因此可以继续提供服务。相比于单点部署的单实例数据库，RAC集群规避了单点服务器、实例的故障风险，提高了可靠性[5]。从图中也可以看出，RAC还提供了横向扩展能力，能够为用户在性能问题上提供解决方案。

虽然RAC集群中ASM卷组考虑了存储磁盘坏块的可能性而采用了多路磁盘镜像提高了存储磁盘的可用性，但是RAC的整体可用性仍旧受限于共享存储的可用性。为了保证服务器与存储之间的可用性，数据库实例和共享存储之间一般采用光纤存储交换机或者更高配置的InfiniBand交换机，可以使传输速度达到16GB/s—40GB/s，从而保证了实例数据的快速读写；另外，如果不能采用高端存储来提供共享存储，一般需要两套存储以同步或者异步的模式完成主备，以规避因存储控制器损坏而带来的存储单点风险。endprint

2.2 DataGuard热备

Oracle提供的另一种高可用方案通过DataGuard将主节点的在线日志复制到热备节点实现Master/Slaver，并在热备节点应用在线日志的方式实现主备同步。在Master节点出现故障无法继续提供服务的情况下，可以通过自动Failover或者是Switchover手动切换的方式实现快速启用Slaver节点（Standby）接手主节点的服务。DataGuard热备的实现方案如图2所示。

DataGuard热备实现对数据库生产环境整体备份的高可用机制，按照在线日志在热备节点的应用情况可将高可用的保护模式分为最大可用性、最大性能和最大保护三种[6]。

最大可用性模式：Master节点产生的redo log需要同步至Slaver节点之后才提交应用。在出现网络故障时，redo log无法同步至Slaver节点，最大可用性模式将转换为最大性能模式。这种模式确保在Master节点出现故障的时Slaver节点不会丢失太多数据，最多丢失Master节点出现故障时无法传递给Slaver的那个redo log。

最大性能模式：Master节点无需等待redo log同步至Slaver节点，所以可以保证Master节点始终能够保证自身的性能，而不会因为redo log同步的问题导致写入缓慢。因此，无法保证在Master节点出现故障时与Slaver节点的数据一致性。

最大保护模式：Master节点产生的redo log需要同步至Slaver节点之后才提交应用。出现网络故障时，Master无法同步redo log至Slaver节点，而导致Master停止数据库服务，完全保证Master节点与Slaver节点的数据一致性。因此，因网络因素、Slaver服务器因素等难以确保架构的高可用。

2.3 MAA架构

MAA（Maximum Availability Architecture）最大可用性架构是通过结合RAC与DataGuard实现的高可用方案，按照图3的方式MAA架构由两套三节点RAC集群通过Data Guard实现。在RAC1中可容忍服务器、操作系统和数据库实例级别的单节点故障，对于MAA整体架构来说可以继续容忍RAC1存储、区域网络级别的故障，通过Failover或者手动Switchover将生产服务转移至RAC2继续提供。

总之，在用户了解其数据核心价值之后，需要慎重选择数据库高可用的方案。因為，每一种方案都对应了能够为用户的带来的不同等级的高可用实现能力、每一种方案的背后都是企业软硬件固定资产的投资、每一种方案都需要不同等级的DBA来综合管理。为了能够清晰的梳理用户需求，让用户切实的认识高可用方案的投资与价值，笔者研究了服务等级协议在数据库高可用方案中的应用。

3 基于SLA数据库高可用需求（High availability for

the database based on SLA）

服务等级协议（Service Level Agreement，SLA）是由ITTF提出，用于约定服务质量指标和服务双方责任的正式协议，SLA是服务提供商和用户之间为了保证服务质量而签署的一份关于服务内容、双方的责任和义务、质量等级与价格的服务细节的协议[7]。通过将SLA应用于数据库高可用实现，能够明确企业需求与高可用服务质量的定义，将有差异的个性化服务与不同的实际需求相结合。笔者研究了数据库高可用在不同企业需求影响因素下的实现与企业需要付出的投资价值，另外还针对不同的高可用方案给出了具体的服务质量目标。

3.1 用户需求与投资

影响用户投资于数据库高可用方案和灾难恢复解决方案的主要因素是应对不在计划内数据库停机时间RTO（Recovery Time Objectives or recovery time）和数据丢失RPO（Recovery Point Objectives or data loss tolerance）、过度管理（Management Overhead），并考虑高可用系统的总体投资（Total Cost of Ownership）与回报收益（Return on Investment）。

表1概要统计了单实例数据库、数据库RAC集群、数据库DataGuard和最大可用性架构MAA等四种高可用架构的相关参数，单实例数据库在出现故障时需要做介质恢复，因此无法估计RPO和RTO；RAC集群对于单实例故障可以做到无数据丢失和无停止服务时间；DataGuard因为Redo log应用的模式不同而会不丢失数据或者丢失部分数据，因为Slaver备机是通过自动Failover或者手动Switchover的方式进行切换，根据环境可以在五分钟内完成切换；由于Oracle MAA是结合了RAC和DataGuard两种技术，如果是RAC能够解决的故障，则不会丢失数据也不会停止服务，反之，则如同DataGuard。对于管理成本来说，由于单实例数据库出现故障之后需要停止并恢复服务，再次过程中需要针对可用性的管理成本升高；而RAC由于自身多节点的集群管理，在高可用的管理成本一般；DataGuard作为专业性热备，高可用管理成本最低；MAA由于自身结合了RAC和DataGuard两种技术，高可用管理中必然需要掌握RAC的管理技术，所以高可用管理成本一般。

所以综合各种高可用方案来看，单实例的投资和汇报较低，RAC和DataGuard的投资成本一般，但是都能提供不同的高可用回报，MAA最大可用性架构投资成本较高，能够获得最高的可用性。本文后续将继续分数据库高可用的投资。

对比单实例的Oracle Database，按照不同的节点数目需要购置相应数量的授权。endprint

由于服务器对于任何数据库服务都是必须的，而高可用所需要解决的重点也是软硬件单点故障而造成的服务不可继续，所以服务器的投资需要依据自身的性能要求进行购置，以Oracle MAA为例，MAA既可以RAC环境同步RAC环境，也可以实现RAC环境同步单点环境；因为共享存储需要通过光纤交换机连接存储，所以光纤交换机是否需要实现主备模式而提高光纖网络的高可用需要企业依据自身对网络的要求进行配置；因为共享存储是RAC实现高可用的单点受限因素，所以企业需要在存储采购过程中清楚存储的可靠性，并考虑实现存储级别的高可用。

在软硬件的配置之外，企业还需要依据需求配置数据库管理人员，表2中体现了数据库管理的最低配置而非绝对配置。

3.2 服务质量目标

在企业明确对数据库高可用的需求之后，不同的高可用方案可实现不同的质量目标，而对于数据库高可用来说关键的指标是RPO和RTO，笔者分别针对不同故障予以说明[6]。

在生产环境中出现数据库故障之后，因为数据库高可用的架构不同，可能会丢失部分数据，本文主要列举了单实例故障、服务器故障、存储故障、用户错误和数据损坏等数据丢失情况，配合常规数据库RMAN备份手段，Oracle MAA只有在存储整体损坏不可用（不是磁盘级损坏）会因为DataGuard应用日志为选择最大保护模式而会丢失部分数据（文中所提到“部分数据”都指因网络等因素导致Master所产生的redo log 未能同步至Slaver节点而导致丢失部分数据）。DataGuard最为专业的热备，与MAA能够提供同样级别的数据损失保护能力。RAC由于存在存储单点故障的风险，因此可能会丢失备份后的归档日志。

在生产环境中可能存在多种DBA需要应对的数据库故障，笔者主要针对由于硬件服务器故障、网络故障、操作系统升级和数据库升级等场景，研究高可用架构的大约停机时间（具体的停机时间跟DBA管理能力、故障的复杂程度、规章制度的明细等正相关，本文不详细阐述）。在表4中列举的故障情况也存在多样性，以单点网络故障为例，表中研究的是数据库对外提供服务的网络出现了故障中断，而不是RAC自身心跳通讯故障中断或者DataGuard同步网络中断。具体的情况需要在SA中详细分裂描述，而不能以一概全。

由于MAA具备RAC和DataGuard的技术，只有在多点网络故障、多节点服务器故障和存储故障影响了RAC不可用的情况下需要通过Failover或者Switchover的切换至备机，整个过程可以控制在两分钟内，其他情况下可以通过轮询的方式进行处理，几乎不影响生产服务。DataGuard在多节点服务器故障时将无法提供继续服务，其他的情况均需要将Slaver切换至Master，可以将时间控制在2分钟以下。RAC因为存在多节点服务器，因为在单点网络故障、服务器故障时不影响生产服务，在操作系统升级、数据库补丁升级等时可采用轮询的方式，同样不需要停止服务，但是其他情况下需要分钟至小时的停机服务用于恢复生产。

4 结论（Conclusion）

本文以Oracle database三种不同的数据库高可用实现机制（RAC、DataGuard和MAA）为研究样例，说明了数据库高可用实现机制和理论收益的不同。通过将SLA引入数据库高可用方案实现中，本文概要研究了企业需求、投资、RTO和RPO。研究表明，SLA可以让企业更加明确自身对数据库高可用的需求、全面而深入的了解数据库高可用实现的不同机制、不同数据库高可用方案能够达到的效果，以及需要实现数据库高可用而付出的不同投资。有效的解决了企业在数据库高可用实施过程中需求、投资、期望和收益等环节的各项问题。

参考文献（References）

[1] 何花.高可用技术在数据库领域中的应用[A].2016智能城市与信息化建设国际学术交流研讨会论文集IV，2016.

[2] 周春华.系统数据库可靠性分析[J].电子产品可靠性与环境试验，2016，34（01）：48-51.

[3] 杨传辉.OceanBase高可用方案[J].华东师范大学学报：自然科学版2014，9（5）：173-179.

[4] Oracle.MAA[EB/OL].http：//www.oracle.com/goto/maa.

[5] Oracle.RAC[EB/OL].http：//docs.oracle.com/cd/E11882_01/rac.112/e41960/toc.htm.

[6] Oracle.DataGuard[EB/OL].http：//docs.oracle.com/cd/E11882_01/server.112/e41134/toc.htm.

[7] 赵又霖.基于服务等级协议的云服务成本计算模型研究[D].武汉：武汉大学，2014.

作者简介：

张庆民（1969-），男，硕士，研究员.研究领域：系统集成，信息安全.endprint