跳至主要內容

高可用性（HA）

概述

SmartEDB 高可用性是为网络和电信设备等需要最高可靠性的应用提供的内存和磁盘嵌入式数据库解决方案。本简介将简要介绍 SmartEDB 高可用性的特点，接下来的各部分会详细说明其功能和实现方式。

SmartEDB 高可用性通过在独立的地址空间内维护多个相同的数据库实例来确保数据的高可靠性。典型的硬件配置包括：

  • 机箱内通过高速总线进行通信的两块或多块电路板
  • 局域网上的两台或多台计算机
  • 通过控制器局域网络（CAN）连接的两个或多个控制器
  • 同一硬件实例内的多个进程或线程

下图展示了多个应用程序如何访问网络节点 A 上的主数据库，同时所有数据库更新会自动在网络中复制到节点 B、C 和 D 上的副本数据库，确保数据的一致性和高可用性。

一种具有时间感知能力的两阶段提交协议可确保数据库主实例和备用实例中的更改要么同时成功，要么同时失败，从而实现同步（积极复制，见图 1）。或者，SmartEDB 高可用性可以配置为实现更快的延迟复制。


由 SmartEDB 高可用性运行时提供的高可用性控制接口（HA API）为应用程序提供了配置、建立、维护和终止高可用性连接的简便方法。通过积极复制，一种时间感知型传输协议不仅确保了可靠的通信，还能检测超时情况。

当主应用程序（即高可用性应用程序的主要实例）所在的系统发生硬件或软件故障时，高可用性协议会检测到超时，并通知副本（应用程序的备用实例）选举一个备用数据库实例来接管主数据库的角色。同样，SmartEDB 高可用性协议能够识别副本应用程序中的故障，自动终止该副本与主数据库的任何连接，并向主应用程序发送通知，以便及时采取纠正措施。

工作原理

配置为提供近乎全天候可用性的计算环境被称为高可用性系统。这些系统通常具备冗余的硬件和软件，确保没有单点故障，即不会因为某个硬件或软件组件的故障而导致整个系统失效。当故障发生时，故障转移过程会将故障组件的任务转移到备份组件上继续执行。这要求高可用性系统具备准确的实例监控或心跳机制，并且能够在故障转移期间快速、准确地同步资源。作为高可用性系统的一部分，数据库也必须具备高可用性，以确保数据的连续性和可靠性。

让我们来看看几个具备高可用性并配备数据库的系统，它们能够提供完全无停机时间的服务：

  • 工业控制器：内置内存数据库，用于存储工厂内各台机器上所连接传感器采集到的测量数据。
  • 互联网 IP 路由器：使用内存数据库来维护其内部存储子系统——路由表，确保网络流量的高效管理。
  • 飞机控制与导航系统：飞机拥有多个数据源，如天线、皮托管、陀螺仪等。它不仅需要从这些设备收集数据，还要监控自身的电力、遥测等基础设施。
  • 手术室、器官运输及其他医疗设备：这些关键设备依赖高可用性系统，确保在紧急情况下也能正常运行。

所有这些系统都需要可靠的故障转移流程和高可用性数据存储。为了实现高可用性，数据存储通常会提供一种维护数据副本的方法。实现高可用性数据库应用程序的传统机制称为数据库复制（如下图所示）。在这种解决方案中，故障转移程序允许系统继续使用数据库，确保服务不中断。

复制数据库是指在不同的故障独立节点上复制事务的数据库。发起事务的节点被称为主节点或主节点，而事务被复制到的节点则被称为副本节点或从节点。数据库的更改从主节点传播到次要节点，确保所有节点的数据保持一致。

在主节点配置的副本控制机制有助于主站点与数据库副本之间的数据传播。这些机制可以根据更新（由事务引入的更改）传播到所有数据库副本的时间进行分类。

更新传播可以在事务边界内或边界外进行。在第一种情况下，复制称为“急切”或“同步”。如果在事务边界之外发生，则复制称为“延迟”或“异步”。无论传播何时发生，传播的单位都是事务（即事务内的所有插入/更新/删除操作一起应用，并且一起成功或失败）。

急切复制

急切（同步）复制（如下图所示）以一种直接的方式提供数据一致性，并且在出现故障时能实现最快的应用程序恢复时间。在急切复制方案中，绝不会丢失任何事务，在故障转移期间不存在节点同步相关的开销，并且副本数据库可立即使用。同时，同步复制具有更高的处理成本和更高的通信开销，这可能会在正常使用期间增加响应时间。

惰性复制

与急切复制相反，惰性复制方案在主节点上提交事务之后异步地将更新传播到副本节点（如下图所示）。这些更新作为单独的事务应用到副本节点。与急切传播相比，惰性更新传播可以通过减少事务内的消息往返来提高事务响应能力。然而，由于更新是异步地应用到副本节点的，因此副本事务存在使用过时数据或错误地报告某些数据可用的风险，如果发生一系列更新和查找操作的话。例如，如果读取操作发生在主节点事务传播到副本节点之前，那么副本应用程序可能会读取已被主节点事务删除的数据元素。

时间感知型积极复制

为了在面对不可预测的网络延迟时实现可预测的故障转移和其他响应时间，可以使用时间感知型积极复制协议（如下图所示）。由于嵌入式和其他实时系统经常施加严格的处理期限，时间感知型方法确保了从主站点到副本站点的事务数据按时交付。与任何同步复制方案一样，故障转移过程非常短。

术语

  • 主数据库：这是系统中的主要数据库实例，负责存储和管理核心数据。
  • 主应用程序（或简称为“主程序”）：这是创建并维护主数据库的进程。在某些情况下（例如共享内存应用程序），可能会有多个应用程序共同担任主程序的角色。其中，一个应用程序将作为“主主程序”，而其他应用程序则被称为“次主程序”。
  • 备用数据库或副本数据库：这是一个保存主数据库副本的数据库，用于在主数据库发生故障时提供冗余支持。
  • 副本应用程序（或简称为“副本”）：这是与副本数据库交互的进程。可能有多个进程同时充当副本。副本应用程序与主应用程序功能相同，只是在特定时刻所扮演的角色不同。
  • 同步：当一个新的副本加入系统时，通过向其发送主数据库的完整副本以初始化该副本的过程。
  • 复制：这是将主程序中已提交的事务传输到一个或多个副本的过程，确保所有副本的数据保持一致。

实现

在同步复制中，SmartEDB 高可用性使用时间感知的两阶段提交协议，确保一个或多个备用数据库与主数据库保持同步。一旦同步完成且连接保持，备用数据库始终是主数据库的精确副本。

SmartEDB 高可用性运行时是一个无上下文库，不创建任务或进程，而是提供 API 供应用程序实现高可用性，支持同步和异步复制。同步复制通过两阶段提交协议实现，主应用在事务提交时会阻塞，直到事务被所有副本确认。

简化的时间感知同步复制流程如下：

  1. 主节点启动事务 T 并分配时间戳。
  2. 副本节点等待主节点的复制通知。
  3. 主节点本地执行读写操作并调用 mco_trans_commit()，生成“写集”消息。
  4. 主节点发送“事务可用性”消息和数据给所有副本。
  5. 副本节点收到消息后开启事务并分配时间戳。
  6. 若超时未收到完整写集，副本认为通信失败并向主节点报告。
  7. 收到完整写集后，副本执行更新并测试冲突，然后将结果返回主节点。
  8. 主节点等待指定时间内所有副本的确认，超时未响应的副本将被排除。

异步复制则不会在事务提交时阻塞主应用，因此处理速度更快，但可能导致副本读取过时数据。

在同一进程中可以同时运行主节点和副本节点。启用副本模式后，不允许修改数据库。例如，“级联复制”场景包括：

  1. 主节点：仅作为主节点，可修改数据库。
  2. rplmst：作为一级副本和二级副本的主节点。
  3. 副本：连接到 rplmst 的二级副本。

注意：关闭 HA 系统时，可以通过 mco_db_save() 或 SaveSnapshot() 方法保存内存数据库，并通过 mco_db_load() 或 Database.Open() 方法加载。如果事务序列器相同，则跳过同步步骤，显著加快重启过程。

通信通道

在设计高效的高可用性嵌入式数据库管理系统时，主要挑战是使 HA 接口能够集成到各种嵌入式实时应用中。这些应用对吞吐量、延迟、错误容忍度和资源调整有不同的要求。嵌入式系统使用多种媒体访问协议和传输方式，从高端系统的 VME 后台总线到多 CPU 系统的局域网通信。

SmartEDB 高可用性复制协议采用应用程序的通信协议，通过称为“通信通道”的网络级抽象来支持实时和嵌入式应用的需求。通信通道代表主节点与副本之间的端到端通信，配置参数包括性能和其他特定参数。其主要属性是按时可靠性，以超时时间指定。

通信通道使 SmartEDB 高可用性独立于底层介质和操作系统，但需要应用程序实现通信层。发行版包含 TCP、UDP、命名管道和 QNX 消息传递的通信通道实现。

HA 性能

SmartEDB 事务针对提交进行了优化。事务期间保留“前映像”页面，若事务中止则恢复原状；若提交，则丢弃前映像页，提高提交效率。

应用程序修改数据库（添加、删除、更新）时，数据在事务进行中逐步提交。提交时更新索引，若无错误（如唯一性冲突），前映像页返回空闲内存池，事务完成。因此，事务提交主要涉及索引更新。

在急切复制模式下，提交时主节点发送写集给副本，并同时更新索引。当索引更新完毕且副本返回提交结果代码后，主节点完成提交调用。

注意：更新索引可能导致唯一性冲突，但由于事务已转发至副本，主节点和副本上的提交都会失败。这可以接受，因为唯一性冲突和事务中止都是罕见情况，而并行更新索引带来的好处超过了偶尔传输失败的低效。

同步事务提交时间为 T + C(d) + C(i) + R + C(d)，其中：

T = 提交数据传输到副本的时间
C(d) = 主副本数据库提交数据的时间
C(i) = 主副本数据库提交索引的时间
R = 副本返回结果代码的时间

与非 HA 模式相比，HA 同步复制模式下的提交时间增加 T+C(d)+R。由于索引更新并行执行，增量主要是 T+R，因此高速通信（如高速总线）至关重要。

显式的事务回滚由主运行时本地处理，不会影响副本，因此不影响已中止事务的性能。

只读事务与负载均衡

SmartEDB 副本数据库支持并发只读访问，便于开发人员实现负载均衡，将读请求分配到主实例和备用实例之间。MCO_READ_ONLY 事务在主实例上执行时不会向副本发送写集。

使用 MURSIW 事务管理器时，副本提交会等待所有只读事务完成，可能延长两阶段提交时间。为缓解此问题，副本提交优先级高于读取请求，最长等待时间为当前最长只读事务的完成时间。因此，建议保持读取事务简短。

SmartEDB 高可用性支持持久型与临时型数据库、不同架构布局（利用二进制架构演变）、不同操作系统间的复制，甚至小端序和大端序机器间的复制（如 x86 到 PowerPC），只要硬件架构相同或二进制兼容（如 Linux/x86 和 VxWorks/x86）。不支持不同整数大小架构（如 x32 到 x64）间的复制。

OpenSSL 与高可用性的集成

为便于安全通信、授权和验证，SmartEDB 高可用性传输层安全机制采用安全套接层（TLS/SSL）来实现。OpenSSL 被选为最普及且广受认可的 TLS 协议实现方式之一。

要在应用程序中使用 OpenSSL 网络功能，用户系统必须安装有本地的 OpenSSL。编译器必须能够访问 OpenSSL 的头文件和库文件。

有关实现 OpenSSL 安全的详细信息，请参阅“网络通信”页面。

SDK 示例

请使用以下链接查看感兴趣的高可用性 API 编程示例。

开发语言说明
C高可用性 C 语言示例
C++高可用性 C++ 语言示例
Java高可用性 Java 语言示例
C#高可用性 C# 语言示例
Python高可用性 Python 语言示例