实时嵌入式数据库系统高可用性策略研究

摘要：针对实时嵌入式数据库对高可用性的需求，分析了大型数据库的高可用性解决方案，并依据嵌入式系统的特点，确立了实时嵌入式数据库高可用性策略应遵循的基本思想和关键技术。提出了一种适用于实时嵌入式数据库的高可用性策略，该策略基于集群技术，采用主备模式，通过数据库复制的方式确保主、备数据库实例之间的数据一致性，并对数据库复制过程设置超时机制，使其具备实时性，并对主、备数据库实例的切换方式和高可用性的可移植性进行了设计。

关键词关键词：实时嵌入式数据库；集群技术；高可用性策略

中图分类号：TP391文献标识码：A文章编号文章编号：16727800（2013）011012403

0引言

实时嵌入式数据库（RealTime Embedded DataBases，以下简称RTEDB）主要用于对可靠性和性能有较高要求的嵌入式系统，如网络通讯系统、工业控制系统、机载飞控与导航系统等。与普通嵌入式数据库相比，RTEDB不仅具有体积小、可移植性好、直接与应用集成等嵌入式数据库的普遍特性，而且为了满足实时性要求，通常采用内存数据库，并且对索引、事务管理等数据处理策略进行了优化。

上述嵌入式系统中的数据库除了要满足实时性要求外，往往还需要具备高可用性（High Availability）。高可用性数据库能够不间断地运行，不因软硬件故障而停止服务或丢失数据。本文依据RTEDB的高可用性需求以及嵌入式系统环境和RTEDB本身的特点，从基本思想和策略设计两个方面对基于RTEDB的高可用性策略进行了研究。

1嵌入式数据库高可用性策略

1.1总体架构

大型数据库系统，如Oracle等，运用了多种技术来保证其高可用性，包括RAID技术、集群技术、数据库复制、硬件复制等。上述方法中，RAID、数据库复制以及硬件复制技术需要大量冗余的硬件和额外的软件服务作为支撑，对于体积和资源都受限的嵌入式系统而言难以接受。相比较而言，集群技术的思想更适合嵌入式系统。高可用性实时嵌入式系统通常由多个计算单元或模块组成，相互之间通过数据总线或网络进行连接。在多个计算单元或模块部署数据库，可以很方便地组成数据库集群，而且不需要额外的硬件和集群管理软件。在此基础上，嵌入式数据库可以自己管理数据库集群，形成多个数据库之间的主备或互为备份的关系，保证数据库服务和数据的高可用性。

1.2配置方案

基于集群的高可用性方案有主备模式、互备模式等多种配置方案。由于实时嵌入式系统通常对并行性的要求较低，为了节省资源，RTEDB可采用主备模式实现高可用性。

在该模式中，一个数据库应用同时具有多个数据库实例，每个数据库实例都拥有相同的功能和数据拷贝。主数据库实例直接为用户提供数据库服务，执行用户提交的数据库事务请求；备份数据库实例在主数据库实例正常的情况下不向用户提供服务，只作为主数据库实例的备份，一个主数据库实例可以同时对应多个备份数据库实例。

主数据库实例和各个备份数据库实例分别部署在不同的物理空间，比如部署在不同的计算单元或模块上，相互之间通过调用内部总线或者网络通信机制进行通信，保持数据一致，互为镜像。当主数据库实例所在的硬件或软件出现故障，造成主数据库实例失效，备份数据库实例可以在短时间内发现主数据库实例失效，并自动取代主数据库实例，继续为用户提供服务。通过以上配置，用户便能够不间断地使用数据库服务，保证了数据库系统的高可用性。

1.3关键技术

高可用性RTEDB的关键问题在于如何保持位于不同计算单元或模块的数据库实例完全一致，并可以相互替代。数据库实例的一致性可以通过数据库复制的方式来实现。数据库复制实际上是对事务的复制，其过程如图1所示，当用户向主数据库实例发起数据库事务T时，主数据库实例收到T后，不仅要自己执行事务T，还要将T复制到所有的备份数据库实例，让所有的备份数据库实例均执行事务T。各个备份数据库实例自己执行事务T并将提交的结果如成功、失败或者超时等反馈给主数据库实例，只有当所有备份数据库实例执行事务T均返回成功时，主数据库实例的事务T才被确认为执行成功并进行提交。这样，通过事务的复制，主数据库实例将自己的更新复制到了所有的备份数据库实例，确保了数据更新在主、备两端同时成功或失败，从而保持了数据库实例的一致性。

图1事务复制过程 在数据库复制过程中，除了要考虑如何保持数据库实例一致，还需要考虑如何保证该过程的实时性。高可用性策略的实时性保证面临的最大挑战是主、备数据库实例间通信延迟的不可预测，这样，需要用相应的超时设置来保证整个数据库复制过程的执行时间可预测，并能够将超时信息及时通知给用户。

本节通过对现有高可用性技术的分析，明确了RTEDB高可用性策略的基本思想，为RTEDB高可用性策略设计提供了指导。

2基于RTEDB的高可用性策略设计

2.1数据库复制过程

依据数据库复制的思想，数据库实例保持一致的过程实际上是主数据库实例不断地将自身的事务操作复制给备份数据库实例并共同执行的过程。该过程划分为主、备数据库实例的初次数据复制和事务复制两个子过程。完整的数据库复制过程如图2所示。其中，初次数据复制只发生在备份数据库实例创建之初，而事务复制则伴随着主、备数据库实例的整个生命周期。

在主数据库实例已创建和启动后，当有新的备份数据库实例加入时，首先要进行主、备数据库实例间的初次数据复制。在此过程中，主数据库实例将现有数据复制到备份数据库实例中，使主、备数据库实例间的数据保持一致。

初次数据复制的过程见图2。主数据库实例首先发起一个事务T1，专门用于管理数据复制。同时，备份数据库实例也发起一个事务T2用于管理该过程，并等待主数据库发送数据。T1开始后，主数据库开始读取现有的数据，并向备份数据库实例发送。备份数据库实例收到主数据库实例发来的数据，写入自己管理的数据库中。主数据库的数据发送完毕，开始等待备份数据库实例对数据复制的确认。当备份数据库实例数据库写入完毕，提交事务T2，若T2提交成功，则向主数据库实例发送对数据复制的确认。主数据库实例收到确认信息，提交事务T1，此时，数据库实例间的初次数据复制完成。

在上述过程中，主数据库实例的事务T1要等到备份数据库实例的事务T2提交成功后才进行提交，确保了数据从主数据库实例正确地复制到了备份数据库实例。

主、备数据库实例在初次数据复制过后，主数据库实例继续进行正常的事务操作。为了继续保持主、备数据库实例的一致性，还要不断地进行事务复制。事务复制有同步事务复制和异步事务复制两种方式。同步复制的过程见图2，其过程与初次数据复制基本相同：主数据库实例收到用户的事务请求T后，在执行的同时，将T通过通信的方式复制到各个备份数据库实例，然后等待所有的备份数据库实例执行T并返回执行成功，当所有的备份实例都执行T成功后，主数据库实例才向用户返回T执行成功。

同步事务复制可以完全保证主、备数据库实例间的数据一致。对用户而言，由于要进行数据传输和等待备份数据实例执行完毕，事务处理速度会受到影响，但对于影响整个系统成败的关键任务而言，仍然是十分必要的。并且，对于非关键任务而言，还可以采用异步事务复制。与同步事务复制相比，异步事务复制中主数据库实例的事务T不需要等待所有备份数据库实例执行T成功即可进行本地提交，备份数据实例也各自提交事务T。异步事务复制不能够保证主、备实例完全一致，但可以提高性能，减少资源消耗，对于非关键任务也是可以接受的。

2.2实时性

高可用性RTEDB数据库复制过程的实时性也非常关键。为了保证实时性，实时嵌入式系统中的所有关键任务都有严格的截止期限制，在高可用性RTEDB中，主数据库实例和备份数据库实例的本地事务处理的实时性由RTEDB的其它功能模块保证。对于高可用性策略而言，需要考虑的是如何在主数据库实例和备份数据库实例之间通信延迟不可预测的情况下实现两者之间数据交换和处理过程执行时间的确定性。

为此，RTEDB的高可用性策略需要加入相应的超时机制对整个数据复制过程进行控制。该超时机制包括3个基本的超时设置：

（1）初次同步超时时间INITIAL_TIMEOUT。INITIAL_TIMEOUT用于控制整个数据库实例初次数据复制过程，若初次数据复制耗时超过INITIAL_TIMEOUT，则主数据库实例认为该备份数据库实例无效，停止与该备份数据库实例进行数据复制，同时向数据库报告初次数据复制超时。

（2）事务复制超时时间REPLICA_TIMEOUT。REPLICA_TIMEOUT用于控制同步事务复制过程中主数据库实例和备份数据库实例间的事务复制。若主数据库实例发送事务T或者备份数据库实例接收T这一过程的时延超过了REPLICA_TIMEOUT的限制，对于前者，主数据库实例丢弃并回滚事务T；对于后者，备份数据库实例丢弃事务T并通知主数据库实例，主数据库实例回滚事务T。最后由主数据库实例通知用户事务T执行超时。

（3）同步等待超时时间SYNC_TIMEOUT。SYNC_TIMEOUT用于控制主数据库实例等待备份数据库实例执行从主数据库实例收到的事务T的信息反馈时间。主数据库实例不会一直等待备份数据库实例对事务T的执行，若超过了SYNC_TIMEOUT所规定的时间，即使备份数据库实例执行事务T成功，主数据库实例同样会认为事务T在备份数据库实例执行失败，回滚事务T的操作，通知用户事务T执行超时。

一旦在主数据库实例与某个备份数据库实例通信过程中触发了上述3种超时设置中的一种，主数据库实例可以做出相应的处理，既可以向用户报告，也可以认为该备份数据库实例已失效，并将其排除在整个高可用性框架之外。这样，整个数据库复制过程的各个操作都有严格的截止期限制，从而可预测其执行时间。

需要注意的是，上述超时机制只适用于同步事务复制方式，本文所设计的高可用性策略对于异步事务复制方式不提供实时性保证。

2.3主、备数据库实例切换

主、备数据库实例通过心跳机制进行定期联络，一旦备份数据库与主数据库实例的联络超时，备份数据库便认为主数据库实例已经失效。若只有一个备份数据库实例，该实例自动成为新的主数据库实例，并向主数据库实例发送一个信号，以“杀死”主数据库实例，即使主数据库实例实际上还在运行，也将被强行停止。

当有多个备份数据库实例时，则需要一种竞争机制来决定选择哪个备份实例作为新的主实例。在本文所设计的高可用性策略中，备份数据库实例的竞争通过比较各个备份数据库实例的事务序列号来进行，事务序列号是已提交的事务标识，由主数据库实例创建和记录。新提交的事务序列号一定大于之前提交的事务序列号，并由主数据库实例在事务复制时发送到各个备份数据库实例。当有多个备份数据库实例竞争成为主数据库实例时，数据库会选择当前事务序列号最大的，即数据最新的备份数据库实例为主数据库实例。若多个备份实例的事务序列号均为最大值，则在其中随机选择一个，然后“杀死”主数据库实例。

2.4可移植性

RTEDB作为嵌入式软件，应当具有较强的可移植性，以适应不同的软硬件平台。由于高可用性RTEDB需要主、备数据库实例间进行可靠的通信，因此，高可用性策略应当具有较好的针对通信方式的可移植性。

高可用性通信的移植性可通过通信抽象层实现，通信抽象层介于高可用与底层通信功能之间，屏蔽了底层通信的细节，对上层而言，其功能及相关接口固定，RTEDB调用通信抽象层即可实现数据的发送、接收等功能。对于底层通信而言，则需要依据通信抽象层的要求以及实际使用的通信方式，进行相应的移植工作。这样，对于当底层通信机制发生变化时，只需要修改底层通信功能的实现方式，而不需要对高可用本身进行开发工作。

3结语

某些嵌入式系统中某些关键的数据应用需要不间断地运行和提供服务，不允许发生停止服务和数据丢失等情况，这就要求实时嵌入式数据库具备高可用性。本文在分析了现有大型数据库的高可用性技术的基础上，提出了一种针对实时嵌入式数据库的高可用性策略。该策略基于大型数据库的集群技术，采用主备数据库实例模式，主备数据库实例间采用数据库复制的方式保持数据一致性，并通过超时机制保证整个数据库复制过程的实时性。在主数据库实例失效，切换到备份数据库实例时，采用了记录和比较事务序列号的方法，保证数据最新的备份实例成为主实例。此外，还对高可用的可移植性进行了考虑。

参考文献参考文献：

＼[1＼]万玛宁，关永.韩相军.嵌入式数据库典型技术SQLite和Berkeley DB的研究＼[J＼].微计算机信息，2006（2）.

＼[2＼]史恒亮，白光一.嵌入式数据库的现状和发展趋势＼[J＼].计算机系统应用，2010（2）.

＼[3＼]于雪平，孟丹.数据库应用的高可用性及实现技术＼[J＼].计算机应用研究，2004（5）.

＼[4＼]付社良，田斌.OracleRAC 10g系统高可用性测试及分析＼[J＼].武汉理工大学学报：信息与管理工程版，2007（2）.