Database High Availability Using SHADOW Systems

作者
摘要
1 介绍
2 DBMS的高可用性
- 2.1 无共享技术
- 2.2 共享存储技术
3 SHADOW 概览
4 系统操作
- 4.1 保护
- 4.2 故障转移
- 4.3 脱保护
- 4.4 讨论
5 原型系统的实现
- 5.1 使用EBS作为SHADOW
- 5.2 PostgreSQL详细信息
6 评估
- 6.1 实验方法论
- 6.2 大内存场景
- - 6.2.1 数据库I/O
- 6.3 小内存方案
- 6.4 直连存储方案
- 6.5 故障转移操作
7 结论
致谢
参考文献

作者

Jaemyung Kim∗ Kenneth Salem∗ Khuzaima Daudjee∗ Ashraf Aboulnaga† Xin Pan∗
∗University of Waterloo, †Qatar Computing Research Institute
{jaemyung.kim, ken.salem, kdaudjee}@uwaterloo.ca, aaboulnaga@qf.org.qa

摘要

热备用技术被广泛用于实现高可用性的数据库系统。这些技术使用两个独立的数据库副本、一个活动副本和一个由备用数据库管理的备用。这两个数据库副本独立存储，并由管理它们的数据库系统进行同步。然而，部署在计算云中的数据库系统通常可以访问可由多个服务器共享的可靠持久存储。在本文中，我们考虑如何在这种设置下改进热备用技术。

我们提出了一种新的热备用高可用性方法——SHADOW系统。与其他使用共享存储的数据库系统一样，SHADOW系统将管理数据库复制的任务从数据库系统推送到底层存储服务中，从而简化数据库系统。与其他系统不同，SHADOW系统还提供写操作转移（write offloading），从而使活动数据库系统不需要更新持久数据库。相反，这一责任由备用系统承担。我们在Amazon的云上展示了使用SHADOW原型进行性能评估的结果，表明写操作转移使SHADOW能够优于传统的热备用复制，甚至是不提供高可用性的独立DBMS（Database Management System，数据库管理系统）。

Categories and Subject Descriptors H.2.2 [DATABASE MANAGEMENT]: Physical Design; H.2.4 [DATABASE MANAGEMENT]: Systems

关键词：设计、性能、可用性

1 介绍

为了提高数据库管理系统（DBMS，Database Management System）的可用性，热备用系统得到了广泛的应用。一个热备用系统管理数据库的一个单独备用副本。如果活动的或主要的DBMS发生故障，则活动系统的工作负载将转移到备用系统，以便很少或没有停机时间。在正常运行期间，活动系统将更新日志发送到备用系统。备用数据库根据其数据库副本重新执行这些更新，以便与活动数据库保持密切同步（图1）。

图1. 热备用系统

这种热备用方法非常适合于无共享环境，因为有两个独立的数据库副本可以由单独的服务器管理。然而，部署在计算云中的数据库系统通常可以访问可由多个服务器共享的可靠持久存储。例如，亚马逊的弹性计算云（EC2，Elastic Compute Cloud）包括弹性块存储（EBS，Elastic Block Store），它为运行在EC2中的服务器实例提供网络连接的可靠持久存储卷。OpenStack和其他系统在私有云中提供可靠的共享存储。在某些设置中，例如EC2，网络连接持久存储可能是持久存储的唯一选项。服务器连接的辅助存储是短暂的，这意味着在服务器发生故障时它是不可恢复的。

在具有共享持久存储的云环境中，可以使用现有DBMS热备用技术。比如简单地忽略存储系统的数据共享功能，将数据库的活动副本和备用副本独立存储在共享存储中。例如这种方法在Amazon的RDS管理关系数据库服务[3]中使用。在本文中，我们再次访问DBMS热备用技术，了解在共享持久存储可用的环境中部署活动服务器和备用服务器的设置。我们解决了以下问题：如何利用共享持久存储构建更好的高可用性数据库系统？

我们提出了SHADOW，这是一种DBMS热备用技术，用于计算云和其他具有共享持久存储的环境。与其他热备用技术一样，SHADOW系统包括活动和备用数据库系统。然而，在SHADOW系统中，系统组件之间的职责划分与传统的热备用技术有很大的不同。在高层：

活动DBMS与客户机交互，并对其内存中缓存的数据库副本执行数据库更新。活动将更新记录写入事务日志，但不负责更新数据库。
备用DBMS负责更新数据库。备用服务器读取活动服务器写入的日志记录，利用日志在共享存储中这一事实，并使用这些记录更新数据库。
存储系统复制数据库和日志，以确保即使发生故障也能持久地存储它们。存储系统还确保活动和备用DBMS可以共享对数据库和日志的访问。

图2说明了SHADOW结构。稍后将介绍更多详细信息（例如需要一个辅助数据库）。

图2. SHADOW系统结构

与传统的高可用性热备用方法相比，SHADOW提供了几个优势。首先，通过将数据持久性的责任推到存储系统中，消除了与数据库复制相关的DBMS复杂性。DBMS热备用技术通常使用日志传送协议来同步活动和备用之间的数据库更新。这种协议可能很复杂，特别是在考虑各种故障和恢复场景时。相反，对于活动DBMS来说，在SHADOW系统中提交事务与在没有高可用性的独立设置中提交事务一样容易。

其次，通过将更新数据库的责任分配给备用数据库，SHADOW系统节省了活动DBMS向数据库写入数据的所有（或大部分）需求。关系数据库系统定期检查点数据库，包括将数据库更新从DBMS的内存缓冲区缓存写入数据库的底层持久副本。检查点需要绑定从失败中恢复所需的工作量，因为恢复从最新的检查点开始。检查点还需要绑定事务日志中需要保留的历史记录量，因为只在将数据库检查到日志记录中表示的更新之后，才能回收日志记录所占用的空间。因此，即使数据库完全可以放在内存中，由于检查点的存在，仍然会有对数据库的写I/O活动。在以DBMS高可用性为目标的现代在线事务处理（OLTP，On-Line Transaction Processing）系统中，数据库装入内存是非常常见的，因此几乎不需要或根本不需要数据库读I/O，而对数据库的大部分或全部写I/O都是由检查点引起的。SHADOW系统消除了在活动DBMS上进行检查点的需要，从而消除了活动DBMS执行的I/O的很大一部分。SHADOW系统中的活动DBMS只写日志记录，数据库写入的责任转移到备用DBMS。我们称之为写操作转移。我们对亚马逊EC2云的性能评估表明，与PostgreSQL的本地同步热备用复制相比，基于PostgreSQL的SHADOW原型具有更好的整体性能和更稳定的性能。事实上，在许多设置中，高可用性的SHADOW系统由于写操作转移甚至可以胜过独立的PostgreSQL实例，后者不提供高可用性。

第三，SHADOW系统将数据库服务器（DBMS）的复制与底层数据库和日志的复制分离。在SHADOW中，复制DBMS以确保DBMS提供的服务高度可用。为实现高可用性和持久性，数据库和日志的复制是底层存储系统的责任。这为在部署数据库服务时管理成本、可用性和持久性之间的权衡提供了灵活性。特别是，DBMS的复制程度不需要与数据库的复制程度相同，就像传统的热备用系统一样。例如，在SHADOW系统中，可以确保提交的数据库更新是3-安全的（即至少复制三次），而只部署（并交付）两个数据库系统。

最后，与传统的热备用系统相比，SHADOW系统在DBMS和持久存储之间需要的I/O带宽更小，因为数据复制发生在存储系统中。在存储系统I/O计量的环境中，例如Amazon的EC2，这可以降低热备用系统的操作成本。

本文的研究成果如下。

我们提出了SHADOW系统的体系结构，并给出了SHADOW系统中系统管理操作的算法，如启动备用DBMS或故障转移到备用DBMS。
我们提出了一个基于PostgreSQL的SHADOW原型，它设计用于在云环境中运行，其中有一个持久的块存储服务，如Amazon的弹性块存储（Elastic Block Store，EBS）。
我们提出了一个性能评估，在这个评估中，将SHADOW与OLTP工作负载下的各种基线系统进行比较。我们的评估表明，当共享存储可用时，DBMS可以高度可用（使用SHADOW的热备用方法），而不会损失总体系统性能。 相反，使用PostgreSQL的本地热备用复制使DBMS高度可用会导致性能显著下降。

论文的其余部分结构如下。第2节简要介绍了构建高可用性数据库管理系统的现有技术。第3节提供了SHADOW方法的高级概述，并将其与现有技术进行了对比。第4节更详细地描述了SHADOW系统的操作，并解释了系统操作，例如建立备用系统，以及从活动系统到备用系统的故障转移。第5节描述了我们的SHADOW原型实现，它基于PostgreSQL，使用Amazon的EBS进行持久存储。第6节给出了性能评估的结果，将原型与几个不同的基线进行比较。

2 DBMS的高可用性

在介绍SHADOW方法之前，我们首先概述了构建高可用性数据库系统的现有技术。

2.1 无共享技术

许多数据库的高可用性技术是无共享的[17]。这意味着高可用性是通过使用两个或多个DBMS实例来实现的，每个实例都在一个单独的服务器上运行，并具有自己的本地存储（假定没有共享的网络可访问存储）。DBMS实例通过网络交换消息进行通信。

第1节中描述的热备用技术是一种无共享技术。它被广泛地实现和使用，例如，在PostgreSQL复制、MySQL复制、DB2[6]、Microsoft SQL Server Always On[19]和Oracle Data Guard[12]中，它被称为数据库镜像[13]。如图1所示，每个DBMS实例管理自己的数据库副本和事务日志。客户机连接到活动DBMS并在活动DBMS上执行事务。活动DBMS将数据库更新发送到备用DBMS（例如，使用日志传送），后者根据自己的数据库应用更新。一些热备用系统还允许客户机在备用系统上运行查询（但不更新）。PNUTS[8]使用了这种方法的更通用版本，其中不同站点中的服务器集群管理数据库的多个副本，每个站点一个副本。每个更新首先发生在一个站点，然后将更新发送到其他站点。

在热备用系统中，从活动DBMS到备用DBMS的更新传播可能是同步的或异步的。通常，同步传播确保活动DBMS不会确认向客户机提交请求，直到活动DBMS和备用DBMS持续记录该事务，确保该事务的效果在系统故障后仍然存在。但是，同步复制可能会损害活动DBMS的性能，因为它必须在每个事务提交的关键执行路径上与备用数据库同步。通过延迟地传播更新，异步热备用系统避免了这个问题，但接受了由于活动的失败而导致提交但未分页的事务丢失的风险。

虽然热备用方法可以使用多达两个DBMS，但其他无共享系统使用基于仲裁的复制协议（例如，paxos[14]）在三个或更多单独的DBMS实例之间同步复制更新。例如，Microsoft的云SQL Server[7]使用自定义复制协议在三个或多个DBMS实例之间同步更新，并且只有在大多数实例确认更新后才会提交事务。此类系统的其他示例包括Granola[10]、Spanner[9]和Megastore[5]，其中最后两个系统设计用于支持地理上分离的数据库实例。

由于这些系统在DBMS实例之间就每个事务的承诺达成共识，因此提交的更新不会由于单个DBMS的失败而丢失。此外，由于它们可以在副本达到法定数量时运行，因此单个DBMS实例的丢失会导致很少或根本没有停机时间。因此，这些系统提供了非常高的可用性。但是，由于至少需要三个副本，因此它们的操作成本相对较高[7]。此外，DBMS实现的复制协议在正常操作期间引入了性能开销和延迟，与热备用系统中的同步传播类似。

2.2 共享存储技术

与无共享方法相比，另一种方法是让多个数据库系统共享对单个、可靠存储的数据库共享副本的访问。此共享副本可以存储在云共享存储服务（如Amazon的EBS）、群集文件系统（如VMFS[20]）或在可靠NAS系统中使用冗余存储设备（RAID[16]）和复制服务器。

共享存储系统的例子包括Tandem的Non-Stop SQL[18]、IBM DB2 ICE、IBM DB2 pureScale[1]和OracleRAC[2]。这些系统都采用主动/主动体系结构，其中多个DBMS实例针对同一共享数据库处理客户机事务。这种方法的一个缺点是需要分布式并发控制机制和（DBMS）缓存一致性来协调不同数据库系统进行的数据库访问，这些机制可能位于每个事务的关键路径上。与SHADOW一样，这些系统依赖共享数据库的可用性来维护整个系统的可用性。为了在数据库丢失的情况下保持可用性，可以使用热备用技术镜像整个共享存储群集（例如，Oracle RAC+Data Guard）。

另一类共享存储系统是冷备用系统，它不具有活动/活动系统的复杂性。单个活动DBMS管理共享的、网络可访问的存储数据库。如果活动DBMS失败，则会在其他服务器上启动备用DBMS，并访问活动DBMS使用的相同数据库和日志。在恢复可用性之前，备用DBMS必须使共享数据库处于一致状态（例如，通过使用基于日志的恢复协议，如ARIES[15]）。由于冷备用方法在任何时候都只需要一个活动的DBMS实例，因此备用DBMS在待机期间使用很少或没有资源（如CPU和内存）。但是，由于系统在启动备用系统并恢复数据库时关闭，因此冷备用技术不能提供真正的高可用性。相反，它通过节省等待修复活动系统的需要来减少停机时间。冷备用技术类似于SHADOW，一次只有一个DBMS实例可以更新活动数据库和共享数据库日志。但是，SHADOW备用系统是热的，以最小化由于活动系统的故障而导致的停机时间。

由于每个系统都有其自身的优点（在成本、性能、持久性或可用性方面），所有这些都在实际环境中使用，并根据应用要求进行选择。我们在第3节中介绍的SHADOW系统与热备用系统属于这个设计空间的同一部分。然而，在共享、网络可访问、持久存储可用的云环境中，SHADOW是热备用方法的一个更好的替代方案。

3 SHADOW 概览

图2说明了处于正常、受保护操作状态的SHADOW系统。客户机连接到活动DBMS，后者处理所有客户机事务。活动和备用DBMS实例都可以访问共享的可靠持久存储系统。我们假设共享持久存储系统本身是高度可用的。在本节中，我们不关心共享存储系统的具体实现。第5节介绍了SHADOW-EBS原型，它使用亚马逊的弹性块存储（EBS）进行持久存储。

图2所示的SHADOW体系结构显示了存储在共享存储中的两个数据库：一个由备用DBMS管理的主数据库，一个由活动DBMS管理的辅助数据库。当SHADOW系统启动操作时，只有（未保护的）活动DBMS在运行，并且只有一个数据库。通过获取活动数据库的快照来创建备用DBMS，该快照成为由备用数据库管理的主数据库。活动DBMS保留其数据库，该数据库现在成为辅助数据库。在整个SHADOW系统的操作过程中，有一个事务日志副本由活动DBMS和备用DBMS共享。

活动DBMS对其数据库的本地缓存副本执行事务更新，并使用提前写入日志将更新和事务提交记录推送到共享持久日志。一旦事务的日志记录在持久性存储系统中是安全的，就提交事务。备用DBMS从共享存储中读取活动实例生成的日志记录，并根据数据库的本地缓存副本重演日志更新。另外，备用数据库定期执行数据库检查点，将数据库更改从本地数据库缓存推送到持久存储中的主数据库。备用的检查点还允许从共享持久日志中清除较旧的日志记录。在SHADOW系统中，只有备用DBMS读取和更新主数据库。备用数据库的检查点操作始终确保持久主数据库和日志一起包括所有已提交事务的影响。

活动DBMS不检查点，只有在其数据库缓存的有限容量迫使它“溢出”更改的页时，才会写入辅助数据库。我们将检查点职责从活动DBMS转移到备用DBMS称为转移写操作。如果需要将数据库页放入缓存中，那么活动DBMS将从辅助数据库读取数据。在整个数据库可以容纳在活动DBMS缓存中的特殊情况下（这是现代OLTP系统中的常见情况），活动DBMS不需要写入数据库页，也不需要读取数据库页，除非首次接触此页。如果数据库大于活动的缓存，那么可能存在一些对辅助数据库的读写I/O。但是，我们期望写入I/O的数量比正常的热备用系统少很多，因为在活动DBMS上没有检查点。

SHADOW系统类似于热备用系统（图1），这种相似性允许我们通过调整现有的同步热备用系统来构建SHADOW原型（第5节），而不会有太大的困难。尽管如此，在更详细地介绍SHADOW系统的操作之前，我们在这里总结一下SHADOW系统和其他热备用系统之间的几个关键区别。

首先，SHADOW系统需要一个单一持久日志，可以由活动和备用DBMS共享。
其次，在SHADOW系统中，只有两个数据库中的一个（主数据库）和日志一起被保证包括所有提交事务的影响。
第三，在SHADOW系统中，由于转移写操作，活动DBMS很少或没有数据库I/O。
第四，在SHADOW系统中，*一旦事务的提交记录出现在持久日志中，事务就被提交。*事务提交期间，不需要在活动实例和备用实例之间进行协调。

4 系统操作

图3显示了SHADOW系统的操作状态，以及这些状态之间的转换。用虚线显示的转换是失败转换，当活动实例或备用实例失败时会发生这种转换。实线显示的转换是SHADOW系统操作，它将系统从一种操作状态移动到另一种操作状态。其他活动/备用数据库系统将有一个类似于图3所示的状态图。但是，由于SHADOW系统在活动和备用DBMS实例之间划分了更新持久存储的责任，所以SHADOW系统在不同状态下的行为与其他系统的行为不同。类似地，SHADOW系统操作，如PROTECT，不同于其他活动/备用系统中的操作。

图3. SHADOW系统的运行状态

如第5节所述，我们已经使用PostgreSQL实现了SHADOW原型。然而，SHADOW架构也应该可以使用其他数据库系统来实现。因此，在本节中，我们用更通用的DBMS来描述SHADOW操作，我们将对PostgreSQL细节的讨论推迟到第5节。在介绍SHADOW操作之前，我们首先描述我们对通用DBMS行为的假设。

我们假设DBMS使用物理逻辑的[11]或物理的写操作前记录日志（Write-ahead logging，Wal）来确保提交事务及其更新的持久性。因此，每个日志记录描述对单个页面的更新，该页面在日志记录中标识。我们假设重演记录的更新将导致对数据库页的更改，该更改等同于初始更新所导致的更改。在物理日志记录的情况下，日志重演导致的物理页面状态可能与原始更新导致的物理页面状态不同。然而，从DBMS的角度来看，这两种状态在逻辑上是等价的。我们还假设每个日志记录都有一个相关的日志序列号（Log Sequence Number，LSN），并且每个数据库页都包含应用于该页的最新更新的LSN的记录。这些技术被著名的日志记录算法所使用，例如ARIES[15]，以确保每个数据库页面只应用一次更新。

最后，我们假设DBMS可以执行定期检查点操作，并且作为检查点操作的一部分，DBMS将标识一个新的日志恢复点，即LSN，在检查点之后DBMS发生故障时，从该LSN开始日志重演。作为检查点操作的一部分，假定DBMS将新的日志恢复点记录在与日志本身相同的持久存储卷中的恢复文件中。我们假设DBMS可以随时丢弃LSN早于当前日志恢复点的日志记录，因为在发生故障时，不需要这些日志记录来恢复数据库。我们将这个过程称为日志截断。

在下面，我们将更详细地描述图3中所示的状态和操作。

4.1 保护

独立活动系统状态表示正常的未保护状态，其中单个活动DBMS处理客户机请求，并且没有备用系统状态。此状态下活动DBMS的故障会导致可用性丢失。保护操作用于创建备用DBMS，将系统移动到活动系统+备用系统状态。活动系统+备用系统状态是SHADOW系统的正常保护操作状态。

创建备用系统实例的典型方法是创建独立数据库的快照，然后部署备用系统实例。快照用作备用系统实例管理的数据库的初始状态。作为创建快照过程的一部分，活动DBMS识别一个重演首项LSN，备用系统数据库将从该LSN开始重演日志。重演首项LSN只是活动系统最近完成的检查点的日志恢复点。这将确保从日志中重演快照数据库中任何可能不存在的数据库更新。

图4说明了如何在SHADOW系统中执行保护操作。它在几个方面不同于这个典型的过程。首先，活动DBMS在创建数据库快照之前禁用日志截断，以确保共享日志将包含快照中可能不存在的所有提交的数据库更新。其次，活动系统将其数据库副本的角色从主数据库切换到辅助数据库，因为新的备用系统将管理主数据库。我们假设SHADOW系统使用存储在与日志相同的持久卷中的文件记录哪个数据库是主数据库。

图4. 保护操作的时间线

与其他日志传送热备用系统一样，新的备用DBMS以日志重演模式运行。这意味着备用系统会不断读取活动系统实例写入的日志条目（从重演首项LSN开始），并针对其数据库副本重新执行记录的更新。当备用DBMS执行检查点时，它将更新的数据库页从其数据库缓存推送到持久性存储，并在数据库的持久性副本中已知更新后从共享日志中截断旧记录。

4.2 故障转移

如果活动系统实例在受保护操作期间出现故障，则备用系统实例将变为活动系统实例，并接管客户端请求的处理。SHADOW系统中的故障转移操作（图5(a)）与其他活动/备用系统中的故障转移非常相似。备用系统实例在失败之前完成对活动系统实例生成的所有日志记录的重演，中止活动事务，然后从日志重演模式切换到正常执行模式，在该模式下，它可以接受来自客户端的新事务请求。

图5. 故障转移和脱保护操作

4.3 脱保护

当备用DBMS发生故障时，使用脱保护操作将活动DBMS恢复为单独活动系统状态。如图5(b)所示，此操作涉及到将活动系统数据库的角色从辅助数据库更改为主数据库。为此，脱保护操作将重新启用活动系统中的检查点，并强制检查点操作，以确保持久辅助数据库中存在检查点之前提交的所有更新。然后，活动系统DBMS将其数据库副本标记为主副本，并作为单独系统继续进行。从此，如果需要，可以使用一个保护操作来创建一个新的备用DBMS。

4.4 讨论

在本节中，我们将介绍一组在SHADOW系统操作期间保留的不变属性。对于每一个属性，我们都提出了一个非正式的论点来解释为什么要保留属性。

属性1. 一次最多有一个DBMS实例负责更新主数据库和截断日志。

属性1紧随保护操作，该操作在将主数据库切换到备用数据库并在其中重新启用日志截断之前禁用活动DBMS中的日志截断。在所有其他状态下，只有一个DBMS。

属性2. 所有客户机事务都可以看到数据库的当前状态，包括所有已提交事务的影响。

在独立活动系统操作期间，活动DBMS的正常操作可确保这一点。在保护操作期间，活动系统承担对辅助数据库而不是主数据库的管理。但是，保护操作不会影响活动DBMS缓存的内容，辅助数据库的初始状态与新主数据库的初始状态相同。属性2在故障转移操作后保留，因为备用DBMS在切换到正常操作并承担活动数据库的角色之前重演所有未完成的日志记录。此故障转移机制由其他基于日志传送的热备用系统使用。

属性3. 所有提交的更新都存在于主数据库的持久存储中、日志中或同时存在。

在SHADOW系统中，活动DBMS的写操作前记录日志确保提交事务的更新在提交事务之前位于持久日志中。但是，对属性3的一个威胁是日志截断可能会在将持久日志更新应用到数据库的主副本之前删除它们。属性1确保一次只有一个DBMS负责更新主数据库和日志截断，因此，如果DBMS最初负责主数据库时，正确操作该DBMS的检查点和日志截断机制将保留属性3。在SHADOW系统中，备用DBMS在保护操作期间负责主数据库。由于活动DBMS在将主数据库的控制切换到备用系统之前禁用日志截断（图4），因此当备用DBMS承担主数据库的责任时，属性3将保持不变。对SHADOW系统中的属性3的另一个威胁发生在活动系统的辅助数据库在脱保护操作期间成为主数据库时。通过在启用日志截断之前对辅助数据库执行检查点，活动DBMS确保在辅助数据库承担主数据库的角色之前，属性3将保留在辅助数据库中。

属性3的一个结果是，如果活动和备用数据库系统都失败，那么使用主数据库和日志的基于DBMS日志的正常恢复将正确地恢复数据库，不会丢失提交的事务。

5 原型系统的实现

我们已经实现了一个SHADOW原型，我们称之为SHADOW-EBS，使用PostgreSQL（9.3版）作为DBMS，使用Amazon的弹性块存储（Elastic Block Store，EBS）实现可靠的持久存储。EBS提供原始的持久存储卷，可以连接到运行在亚马逊弹性计算云（Elastic Compute Cloud，EC2）中的虚拟机中。EBS卷被复制以提供耐久性和高可用性。目前，亚马逊的EBS卷服务水平协议承诺最低可用性水平为99.95%。EBS卷可以配置各种性能特性以适合应用程序。EBS还提供快照和现代存储系统中常见的其他卷级操作。

SHADOW-EBS原型如图6所示。它由PostgreSQL的活动和备用实例组成，每个实例在EC2虚拟机中运行，加上三个EBS卷，每个卷用于日志、主数据库和辅助数据库。接下来，我们将详细介绍SHADOW-EBS使用EBS卷（第5.1节）和PostgreSQL（第5.2节）。

图6. SHADOW-EBS原型

5.1 使用EBS作为SHADOW

尽管EBS卷可以在其生命周期内连接到不同的EC2虚拟机，但在任何特定时间，一个EBS卷最多可以连接到一个虚拟机。对于SHADOW系统来说，这是一个挑战，它期望活动和备用系统共享对日志卷的访问。为了解决这个问题，SHADOW-EBS使用PostgreSQL的本地日志传送功能将日志记录从活动DBMS直接发送到备用数据库。在正常操作期间，EBS日志卷连接到活动的PostgreSQL实例。活动系统实例通过将其提交记录写入EBS日志卷来提交事务，并通过网络连接将所有日志记录的副本异步流式传输到备用服务器。这会给活动DBMS增加少量开销。但是，提交事务不需要DBMS级别的同步。一旦活动DBMS将事务的提交记录写入日志，它就可以立即确认提交到客户机应用程序，而无需等待任何形式的确认，即从备用系统接收日志记录。

如果活动DBMS失败，则可能某些日志记录已写入日志卷，但未发送到备用卷。作为故障转移操作的一部分，在使用所有流日志记录后，备用DBMS将自身连接到EBS日志卷（这是由于活动系统发生故障而可能发生的），并读取和应用任何由活动系统写入但未发送的日志记录。这样可以确保在故障转移操作期间不会丢失提交的更新。

与日志卷相关的最后一个挑战是，在正常操作期间，SHADOW备用系统负责日志截断，这需要访问日志卷。在SHADOW-EBS中，备用DBMS通过将日志截断请求发送到与活动DBMS在同一虚拟机上运行的SHADOW-EBS日志截断服务来间接执行此操作。截断服务只是作为备用DBMS的代理，在备用DBMS指定的LSN处截断日志。

SHADOW-EBS对日志流和日志截断代理的需求直接来自EBS的限制，即只有单个虚拟机可以连接到卷。如果在支持同时访问日志的存储服务（例如，可靠的网络连接文件系统或群集文件系统）上实现了SHADOW，则无需执行此操作。

EBS的一个积极特点是，在保护操作期间，SHADOW-EBS可以直接利用EBS卷的快照机制。在单独活动系统状态下，只有一个数据库卷与活动DBMS连接。在保护操作期间，SHADOW-EBS使用EBS的本机快照功能创建数据库卷的快照。此快照作为图4所示的“生成数据库快照”步骤的一部分出现。此快照用于初始化附加到新创建的备用DBMS服务器的第二个数据库EBS卷。新卷保存数据库的主副本，存储在最初连接到活动DBMS的卷中的数据库成为辅助副本。在活动DBMS发生故障的情况下，在事务处理故障转移到备用DBMS之后，可以简单地删除与活动DBMS相连的辅助数据库卷。

5.2 PostgreSQL详细信息

SHADOW-EBS使用一对PostgreSQL实例，备用系统实例以连续恢复模式运行。这意味着它连续地重演活动系统实例流到它的日志记录。

在SHADOW系统中，备用DBMS通过执行检查点操作将更新推送到持久主数据库，而活动系统根本不检查点。但是，在连续恢复模式下运行的PostgreSQL实例不能独立于活动系统实例进行检查。这是因为检查点需要在日志中创建检查点记录。由于PostgreSQL备用系统重演日志记录但不生成自己的日志记录，因此备用系统实质上重新使用活动系统的检查点记录来实现自己的检查点。

为了解决这个问题，我们修改了活动的PostgreSQL服务器，以便它执行周期性的伪检查点操作。在伪检查点期间，活动DBMS将一个正常的检查点记录写入日志，但不会将任何脏页刷新到辅助数据库，也不会更新其日志恢复点。使用活动的伪检查点生成的检查点日志记录，备用服务器可以像往常一样检查其数据库。在活动系统中，伪检查点的频率必须至少与备用系统中的真正检查点的频率相同。但是，在活动系统中，伪检查点的开销非常低。

在检查点之后，备用DBMS可以截断不再需要恢复的日志记录。如5.1节所述，我们修改了PostgreSQL，以便备用系统实例使用active的日志截断服务来完成这一任务，因为它不能直接访问日志卷。

最后，我们对PostgreSQL做了一些修改，通过确保活动DBMS在受保护操作期间尽可能少地对辅助数据库执行写操作来实现转移写操作。PostgreSQL的缓冲区管理器将脏数据库页从缓冲区缓存刷新到持久存储，原因有三个。

首先，在执行检查点时刷新所有脏缓冲区。
第二，当缓冲池中有许多脏页时，可以通过PostgreSQL的后台编写器线程将它们刷新到持久存储中。
最后，如果替换牺牲页是脏的，或者在第一次分配新页时，脏页可能会在替换页期间刷新到磁盘。

我们在PostgreSQL中添加了两个新参数来控制这些写入。

第一个可以用于启用或禁用由检查点引起的写入。
第二个可以用于启用或禁用PostgreSQL的后台编写器线程。

在保护操作期间，这些标志用于禁用活动系统实例中的两种类型的写入（在图4的“禁用检查点”步骤中），这意味着只有在页面替换期间需要时，PostgreSQL才会写入持久数据库。当活动的缓冲区缓存很大时，这种情况很少发生。在脱保护操作期间，这些参数用于重新启用数据库写入。

6 评估

在本节中，我们将评估我们的SHADOW-EBS原型，将其与其他热备用DBMS配置以及不高度可用的独立DBMS配置进行比较。我们评估了这些系统在正常受保护操作期间的事务处理性能，以及活动DBMS发生故障后故障转移所需的时间。

6.1 实验方法论

我们已经使用版本9.3PostgreSQL实现了第5节中描述的SHADOW-EBS原型系统。我们对比较SHADOW-EBS的独立和热备用基线系统使用相同版本的PostgreSQL。

对于独立基线，DBMS启动检查点的频率控制着正常操作期间的性能和恢复时间之间的权衡。检查点更频繁地减少恢复时间，但在正常操作期间会增加开销，因为检查点会消耗I/O并可能导致缓冲区缓存争用。因此，在我们的评估中，我们使用几种不同的独立配置和不同的检查点频率：

SAD：这是默认的PostgreSQL配置，每五分钟检查一次，或者当三个1GB日志段填满时（以较早发生的为准）。此配置表示性能的一个极端折衷，有利于快速恢复时间。
SA：不管日志段的总数是多少，这个配置检查点最少（每30分钟一次）。它代表了独立系统性能与恢复时间权衡的相反极端。
SA10：此配置每10分钟检查一次。因此，它代表了SA和SAD两个极端之间的平衡。

除了这些独立配置之外，我们还使用PostgreSQL的本地热备用机制来提供两个高可用基线（表1）：

系统	描述	检查点间隔	高可用性？	事务丢失？
SAD	单独PostgreSQL	5分钟	否	不适用
SA10	单独PostgreSQL	10分钟	否	不适用
SA	单独PostgreSQL	30分钟	否	不适用
ASR	PostgreSQL本地异步热备用系统	30分钟	是	可能
SR	PostgreSQL本地异步热备用系统	30分钟	是	否
SH	SHADOW-EBS	30分钟	是	否

表1. 测试系统。“事务丢失”列表明在故障转移期间提交的事务是否可能丢失。

SR：这个基线包括两个数据库系统，一个活动系统的和一个热备用系统，配置为使用同步复制。每个DBMS管理自己的数据库持久副本及其日志。活动系统使用PostgreSQL的日志传送机制将记录的更新流式传输到备用系统，备用系统根据数据库的副本重演更新。对于同步复制，在备用服务器收到并持续存储事务的提交记录之前，活动系统不会确认向客户机提交事务。在我们的SR配置中，活动和备用配置都是最低限度地检查点，就像SA基线一样。
ASR：这个基线与SR相同，只是活动系统和热备用系统被配置为使用异步复制。这意味着活动系统可以在本地提交事务后立即确认向客户机提交的事务，而无需等待备用服务器的确认[4]。由于活动系统不需要协调事务提交与备用系统，因此在故障转移期间，一些最近提交的事务可能会丢失。在SR基线中，活动和备用系统都被配置为最小检查点。

我们所有的实验都是在Amazon的EC2云上运行的，使用的是c3.4x1大型实例，它有16个虚拟CPU和30 GB的内存，用于我们所有的基线和SHADOW-EBS原型。Linux内核3.2.0-56-virtual用于所有EC2实例。

每个独立基线使用两个EBS卷，一个用于日志，一个用于数据库。SR和ASR高可用基线使用四个卷、一个数据库卷和一个活动实例的日志卷，以及一对备用卷。如图6所示，shadowebs总共使用了三个卷，一个用于日志，一个用于辅助数据库和主数据库。除非另有说明，否则所有EBS卷都使用Amazon提供的I/O功能来保证每秒600个I/O（I/Os per
secondI，OPS）的最低性能。

我们的实验使用了TPC-C基准工作负载，其中客户机（终端）配置为在没有思考时间的情况下提交事务。我们使用30个TPC-C客户机进行所有实验，足以确保测试系统以峰值吞吐量运行或接近峰值吞吐量运行。每个实验都是使用100个仓库的TPC-C数据库运行的，它的初始大小大约为11GB。在每次新运行之前，还原原始数据库并重新启动DBMS。每次实验运行持续100分钟，在此期间，数据库大小根据系统性能增长到24GB。我们忽略了每次运行的前30分钟和最后10分钟，因此我们报告的测量值代表稳态执行。我们为测试的每个配置执行了三次独立的运行。

在所有DBMS服务器上，我们每10秒刷新一次操作系统的页面缓存（包括缓存的文件数据），以最小化文件系统缓存对结果的影响。我们还对所有测试的默认PostgreSQL配置进行了两次调整。首先，我们禁用了整页日志记录（PostgreSQL参数整页写入），因为它导致了非常高的日志量，严重影响了性能并妨碍了测量。其次，我们将PostgreSQL配置为在大多数检查点间隔（参数检查点完成目标=0.9）内扩展与检查点相关的I/O，以减少检查点I/O的突发性。这些配置调整应用于SHADOW-EBS和基线配置。

6.2 大内存场景

我们的第一组实验考虑了正常运行期间的系统性能，在这种情况下，有足够的内存在每个DBMS缓冲池中本地保存整个数据库。具体来说，PostgreSQL数据库缓冲区缓存大小设置为26GB，即使在事务处理后增长，也足以容纳整个数据库。对于支持事务性工作负载的数据库系统来说，配置足够的内存以容纳整个数据库或至少是数据库的热部分是很常见的。但是，在第6.3节中，我们还考虑了具有较小缓冲池的配置。

图7将独立基线（SA、SA10、SAD）和热备用基线的平均TPC-C吞吐量与图中用sh表示的SHADOW-EBS原型的平均TPC-C吞吐量进行了比较。我们以每分钟TPC-C新订单事务报告吞吐量（TPC-C New Order transactions per minute，tpmC），这是TPC-C基准的吞吐量标准度量。我们做了几个观察：

图7. TPC-C吞吐量，大内存. 条形图高度显示三次独立运行的平均吞吐量，而误差条形图显示最快和最慢运行之间的范围

首先，SHADOW的吞吐量比独立SA基线略高，后者很少检查点，并且明显高于其他两个独立配置的吞吐量，后者检查点更具攻击性。SHADOW和SA以相同的方式提交事务——将提交记录写入日志。由于写卸载，SHADOW的平均吞吐量略高于SA，这消除了活动DBMS上的检查点。因此，可以使用SHADOW将独立DBMS配置转换为高可用性配置，而不会对性能产生负面影响。事实上，如图所示，写卸载实际上可以提高性能。

其次，SHADOW的性能也略高于ASR，后者提供了高可用性，但与SHADOW不同，后者在故障转移期间可能会丢失提交的事务。ASR的性能与SA差不多，这并不奇怪，因为两者的工作方式相同，只是ASR活动异步地将日志记录发送到备用服务器。这对性能影响不大。

最后，SHADOW的吞吐量比SR高近70%，SR是唯一一个提供可用性和持久性保证的基线，就像SHADOW的一样。

为了解释SHADOW和基线的性能，我们首先更仔细地研究事务吞吐量。在每次运行期间，我们测量了每10秒间隔内的事务吞吐量。图8显示了一个方框和盒形-虚线图，显示了每个系统在所有三次运行中这些吞吐量测量的分布。如图所示，SHADOW通常具有与ASR和SA相当的性能。然而，ASR和SA都会偶尔出现性能严重下降的时期，包括吞吐量下降到1000tpmC以下的短暂时期。我们观察到这些周期与检查点相关。相比之下，由于转移写操作，SHADOW的性能更加稳定，这消除了活动系统中的检查点I/O。SHADOW的吞吐量始终保持在45000tpmC或以上。SR基线的性能不仅比SHADOW和ASR的性能低，而且变化更大（图中的方框更大）。

图8. TPC-C吞吐量的变率，大内存情况。晶须末端显示在任何10秒间隔期间观察到的最小和最大吞吐量，框中显示两个中间四分位数，每个框中的线表示平均吞吐量。

在我们的实验中，我们还测量了事务响应时间（由于缺少空间而忽略了细节）。SHADOW-EBS和两个高可用性基线的平均响应时间相似，接近10毫秒。但是，SHADOW-EBS的平均响应时间为14.2毫秒，ASR的平均响应时间为16.5毫秒，SR的平均响应时间为22.9毫秒。ASR和SR的平均响应时间高于SHADOW-EBS，因为它们的事务中有较大的一部分具有较高的响应时间（即它们的响应时间）。ME分布的尾部比SHADOW的尾部重）。

6.2.1 数据库I/O

除了降低性能可变性之外，SHADOW还减少了数据库系统执行的I/O量。图9显示了SHADOW和基线对数据库卷的I/O总量。对于具有两个数据库卷的系统（SHADOW、SR和ASR），图9显示了每个卷的I/O总量。在所有情况下，写I/O都占主导地位，因为所有数据库系统都有足够的内存来缓存整个数据库。

从图9可以看出两件事。

首先，与ASR和SR系统相比，SHADOW活动系统执行的I/O要少得多，尽管它的吞吐量更高。与任何备用系统相比，SHADOW活动系统执行的I/O也更少。几乎所有由SHADOW活动系统执行的数据库写入都是由于数据库在每次实验运行期间的增长，因为PostgreSQL将每个新创建的数据库页面推送到持久存储（PostgreSQL的实现细节）。如果没有数据库增长，具有足够内存以容纳整个数据库的SHADOW活动系统将在数据库加载到内存后完全不执行数据库I/O。
第二，所有备用数据库系统执行的I/O量都差不多（SR执行的量稍小，但只是因为它的吞吐量较低）。基线系统（SR和ASR）在活动和备用时执行相同的I/O量，而SHADOW的I/O模式是不对称的，大多数I/O发生在备用状态。

图9. 数据库I/O总量

6.3 小内存方案

在本节中，我们给出了一个与第6.2节中给出的实验结果相同的结果，只是DBMS缓冲区缓存的大小从26GB减少到8GB。如第6.1节所述，TPC-C数据库的大小从11GB开始，并在实验过程中显著增大。因为DBMS缓冲区缓存不能容纳整个数据库，所以我们希望所有系统都必须对数据库卷执行更多的I/O操作。我们的目标是了解这种变化如何影响SHADOW相对于基线系统的性能。

图10显示了小内存配置中SHADOW和基线的平均吞吐量。毫不奇怪，所有配置在小内存配置中的吞吐量都低于大内存配置（图7）。然而，这种变化对SHADOW-EBS的影响最小。因此，shadow-ebs的吞吐量比最佳独立基线（sa）的吞吐量高20%。由于转移写操作，SHADOW在活动DBMS的数据库卷上放置的I/O负载比基线少。例如，SA基线使用的大约75%的数据库I/O带宽用于写入，只剩下25%用于读取。相比之下，SHADOW可以将其40%的I/O带宽用于读取。如果忽略由数据库增长引起的写入，这个数字将增长到50%以上。因此，除了避免检查点引起的性能波动之外，SHADOW的转移写操作还释放了更多可用的I/O带宽，用于在整个数据库不适合内存的情况下读取数据库。

图10. TPC-C吞吐量，小内存情况

6.4 直连存储方案

基线系统利用EBS卷保存数据库和日志。这在云设置中很常见，尤其是在亚马逊的EC2环境中，因为直接连接到EC2虚拟机实例（称为实例存储）的存储设备是短暂的。这意味着如果实例失败或关闭，则实例存储的内容将永久丢失。尽管如此，还有其他一些设置可以让高可用数据库系统使用直接连接的持久存储，例如本地连接的磁盘或SSD，用于数据库和日志卷。相反，SHADOW必须为其日志和数据库卷使用可靠的网络连接共享存储。

由于直接连接存储可能比网络连接存储具有更好的性能，因此SHADOW对网络连接存储的要求可能会使其处于性能劣势。在这一部分中，我们提出了一个额外的实验，探索这种效果有多重要。对于这个实验，我们将SR和ASR基线系统配置为对数据库和日志都使用实例存储，而不是EBS卷。我们将这些新配置称为ASR-EP和SR-EP。在EC2环境中，这些新配置没有数据库或日志的持久副本，因为实例存储是短暂的。尽管如此，我们还是测试了这些配置作为非云环境的代表，其中直接连接的存储是持久的，而不是短暂的。

ASR-EP和SR-EP使用的实例存储以及SHADOW和原始基线使用的EBS卷都是基于SSD的。但是，实例存储比我们使用的网络连接的EBS卷提供更好的I/O性能。例如，对于单线程顺序写入工作负载，我们的基准测试测量超过1200IOPS，例如存储（每个请求约0.8 ms），而对于EBS卷，大约750IOPS（每个请求约1.3ms）。

我们使用新的SR-EP和ASR-EP基线运行TPC-C工作负载，所有数据库服务器都配置为我们的大内存场景。图11显示了这两个基线所实现的吞吐量。为了进行比较，图7还显示了SR、ASR和具有大内存的SHADOW所实现的吞吐量。

图11. TPC-C吞吐量、短暂卷

从ASR到ASR-EP的转换消除了SHADOW和ASR之间存在的较小性能差距。这一差距主要是由于检查点的干扰，这损害了ASR。通过将数据库移动到实例存储，这比我们提供的EBS卷提供更大的I/O吞吐量，检查点对性能的影响会大大降低。不幸的是，在故障转移期间，ASR可能会丢失提交的事务。

比较SHADOW与SR和SR-EP，我们发现SR-EP优于SR，但仍优于SHADOW。SR-EP和SHADOW之间的性能差距很有趣，这可以归因于这两个系统提交事务的方式。乍一看，人们可能会期望在SHADOW中提交事务比在SR-EP中慢，因为SHADOW的网络连接EBS日志卷比SR-EP的直接连接日志卷具有更高的延迟。但是，对于SR和SR-EP，提交事务涉及两个日志写入，一个在活动状态，一个在备用状态，以及两个系统之间的网络往返。此外，这两个日志写入是按顺序进行的，即事务首先在活动状态下提交，然后通过在备用状态下再次写入提交记录来加强。对于SHADOW，提交事务只涉及单个EBS写入。尽管EBS写入比写入实例存储慢，但它们仍然比按顺序执行两个实例写入快，即使我们忽略了活动和备用系统之间的网络延迟。因此，事务在SR-EP中的提交延迟比在SHADOW中高，这意味着我们的闭环测试环境中的吞吐量更低。

6.5 故障转移操作

我们还将SHADOW-EBS系统中的故障转移所需的时间与PostgreSQL的本机同步复制（Synchronous Replication,SR）下的故障转移时间进行了比较。在这个实验中，我们首先在负载下以活动系统+备用系统状态运行系统10分钟，然后终止活动DBMS进程（活动故障）并启动到备用状态的立即故障转移。10分钟的预热时间被选择为足够大，以允许DBMS缓存在两个系统中预热。

SR系统中的故障转移操作大约需要3秒钟。SHADOW系统中的故障转移需要大约16秒。在这两种情况下，在待机状态下重放剩余的日志需要大约2秒。但是，SHADOW系统需要额外的时间将日志卷与活动实例分离（约9秒），并将其连接到备用实例（约4秒）。如果故障转移是由活动虚拟机（而不仅仅是DBMS）的故障导致的，那么将日志重新连接到备用服务器将更快（总共大约5秒，而不是13秒），因此故障转移操作将更快。总之，SR和SHADOW-EBS的故障转移时间都很短，但SHADOW-EBS的速度稍慢，因为需要重新连接SHADOW日志卷。我们注意到这个额外的延迟是EBS限制的结果，一个卷一次最多可以连接到一个服务器实例。对于没有这个限制的持久存储层，我们希望这种差异消失。

7 结论

我们已经介绍了SHADOW，这是一种新的热备用架构，它利用共享的持久存储，而共享持久存储通常在云设置中可用。在SHADOW中，活动和备用数据库系统共享对数据库和日志的单个副本访问。活动DBMS写入日志以提交事务，但不更新数据库。相反，数据库更新是备用DBMS的责任。

SHADOW是在云环境中构建高可用数据库服务的一种新颖有效的方法。SHADOW通过将复制责任从DBMS推到底层存储层来降低DBMS级别的复杂性。SHADOW还将数据库复制与DBMS复制分离。我们对TPC-C工作负载的实验表明，这些优势不会以牺牲性能为代价。我们的SHADOW-EBS原型显著优于PostgreSQL的本地同步复制。由于写负载的减少，SHADOW-EBS甚至可以比独立（不高可用）DBMS更好，甚至是一个积极调整以在恢复时间内提高性能的DBMS。、

致谢

This work was supported by a NetApp Faculty Fellowship, and by the Natural Sciences and Engineering Research Council of Canada (NSERC).

参考文献

[1] Transparent application scaling with IBM DB2 pureScale. IBM white paper, 2009.

[2] Oracle Real Application Clusters 11g release 2. Oracle white paper, 2010.

[3] Amazon Relational Database Service User Guide, 2013.

[4] PostgreSQL 9.3 Documentation, 2014. URL http://www. postgresql.org/docs/9.3/.

[5] J. Baker et al. Megastore: Providing scalable, highly available storage for interactive services. In Proc. CIDR, 2011.

[6] S. Bartkowski et al. High availability and disaster recovery options for DB2 for Linux, UNIX, and Windows. IBM Redbook, 2012.

[7] P. A. Bernstein, I. Cseri, N. Dani, N. Ellis, A. Kallan, G. Kakivaya, D. B. Lomet, R. Manne, L. Novik, and T. Talius. Adapting Microsoft SQL Server for cloud computing. In Proc. ICDE, 2011.

[8] B. F. Cooper, R. Ramakrishnan, et al. Pnuts: Yahoo!’s hosted data serving platform. In Proc. VLDB, 2008.

[9] J. C. Corbett, et al. Spanner: Google’s globally-distributed database. In Proc. USENIX OSDI, 2012.

[10] J. Cowling and B. Liskov. Granola: Low-overhead distributed transaction coordination. In Proc. USENIX ATC, 2012.

[11] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.

[12] M. Hart and S. Jesse. Oracle Database 10g High Availability with RAC, Flashback, and Data Guard. McGraw-Hill, 2004.

[13] D. Komo. Microsoft SQL Server 2008 R2 high availability technologies. Microsoft white paper, 2010.

[14] L. Lamport. The part-time parliament. ACM TODS, 16(2): 133–169, 1998.

[15] C. Mohan, D. J. Haderle, B. G. Lindsay, H. Pirahesh, and P. M. Schwarz. ARIES: A transaction recovery method supporting fine-granularity locking and partial rollbacks using writeahead logging. ACM TODS, 17(1):94–162, 1992.

[16] D. A. Patterson, G. A. Gibson, and R. H. Katz. A case for redundant arrays of inexpensive disks (RAID). In Proc. SIGMOD, 1988.

[17] M. Stonebraker. The case for shared nothing. IEEE Database Eng. Bull., 9(1):4–9, 1986.

[18] The Tandem Database Group. NonStop SQL, a distributed high performance, high availability implementation of SQL. In Proc. HPTS, 1989.

[19] L. Tuttle, Jr. Microsoft SQL Server AlwaysOn solutions guide for high availability and disaster recovery. Microsoft white paper, 2012.

[20] S. B. Vaghani. Virtual machine file system. ACM SIGOPS OSR, 44(4):57–70, 2010.

数据库使用SHADOW系统实现高可用性相关推荐

oracle数据库集群采用的是形式,铁道部采用Oracle集群数据库进行TMIS系统“三级建库”...
综述铁道部利用Oracle9i集群数据库系统(Oracle9i RAC),顺利开展铁道部运输管理信息系统(TMIS)的"三级建库"工程--在各铁路局和铁路分局利用Oracle9i ...
SQL数据库无法附加系统表损坏修复数据库中病毒解密恢复
SQL数据库无法附加系统表损坏修复数据库中病毒解密恢复开发此工具是为了让手工恢复数据库物理故障时更加简单便捷直观, 本工具用于物理修复独立处理大部分问题以及与DBCC配合完成修复各种数据库错 ...
收银系统服务器数据库,收银系统服务器数据库
收银系统服务器数据库内容精选换一换计费项包括存储费和流量费,存储费根据存储库的不同进行收取.详细的计费项目如下所示:存储费:云硬盘备份存储库:备份云硬盘时购买.云服务器备份存储库:备份普通云服务 ...
客户端实时获取Oracle数据库服务器端的系统时间
最近参与了一个基于Oracle10g数据库的C/S项目,抽空整理了一些技术相关的资料,发上来供大家一起参考学习. 项目中用到这样一个功能:客户端实时获取Oracle数据库服务器端的系统时间. 该功能的 ...
mysql水果销售系统数据库_mysql数据库水果销售系统
mysql数据库水果销售系统云服务器(Elastic Compute Service,简称ECS)是阿里云提供的性能卓越.稳定可靠.弹性扩展的IaaS(Infrastructure as a Ser ...
2013春季巡讲讲稿—基于传统数据库的大型系统构建—赵振平—中国人民公安大学CSDN高校俱乐部
巡讲主题:基于传统数据库的大型系统构建巡讲讲师:赵振平推荐阅读对象:对创业感兴趣,对编程感兴趣的学生主要内容:基于传统数据库的大型系统构建,从数据库的角度去诠释.主要介绍了数据库的历史,从古到今 ...
中国中药专利数据库及其检索系统
http://218.240.13.195/tcm_patent/chineseversion/help/help.html  "中国中药专利数据库及其检索系统"(CTCMPD) ...
Oracle数据库时区、系统时间的检查与修改
Oracle数据库时区.时间的问题 Oracle数据库时区.时间的问题,会导致使用了系统时间的存储过程出现问题. 如下图所示: 这是一个定时任务,每天定时凌晨2点执行.但是日志记录的时间与真实时间不一 ...
金算盘oracle语句,金算盘软件8e oracle数据库自动备份系统
<金算盘软件8e oracle数据库自动备份系统>由会员分享,可在线阅读,更多相关<金算盘软件8e oracle数据库自动备份系统(20页珍藏版)>请在技术文库上搜索. 1.金 ...
服务器2012系统如何备份数据库,服务器2012系统如何备份数据库备份
服务器2012系统如何备份数据库备份内容精选换一换华为云帮助中心,为用户提供产品简介.价格说明.购买指南.用户指南.API参考.最佳实践.常见问题.视频帮助等技术文档,帮助您快速上手使用华为云服 ...

数据库使用SHADOW系统实现高可用性