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

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

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

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

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。异步事务复制不能够保证主、备实例完