CN102656565A

CN102656565A - 已复制数据的故障切换和恢复

Info

Publication number: CN102656565A
Application number: CN201080056311XA
Authority: CN
Inventors: G·A·M·麦卡利斯特; S·西瓦苏布拉马尼亚
Original assignee: Amazon Technologies Inc
Current assignee: Amazon Technologies Inc
Priority date: 2009-10-26
Filing date: 2010-10-26
Publication date: 2012-09-05
Anticipated expiration: 2030-10-26
Also published as: US8595547B1; EP2494444A1; JP2018045715A; WO2011053594A1; JP5860497B2; US9817727B2; CA2778456C; US11714726B2; ES2645414T3; EP3276492B1; JP2013508883A; CN102656565B; US9298728B2; EP3276492A1; US10860439B2; US20230393953A1; US20180067822A1; JP5529972B2; EP2494444A4; US20160210205A1

Abstract

在数据库环境中的已复制实例提供自动故障切换和恢复。监控部件可对于实例与主要副本和辅助副本周期性地通信，每个副本能够存在于分开的数据区或地理位置中以提供一定水平的可靠性和可用性。在主要实例上运行的数据库可具有在块级被同步地复制到辅助副本的信息，使得主要副本和辅助副本处于同步中。在监控部件不能与副本之一通信的情况下，监控部件可试图确定那些副本是否具有相同的数据生成版本。根据状态信息，监控部件可自动执行恢复操作，例如故障切换到辅助副本或执行复制副本恢复。

Description

已复制数据的故障切换和恢复

背景

当越来越多数量的应用和服务通过网络例如互联网变得可用时，越来越多数量的内容、应用和/或服务提供商求助于诸如云计算的技术。云计算通常是通过服务例如Web服务来提供对电子资源的访问的方法，其中用于支持那些服务的硬件和/或软件动态地可升级来在任何给定的时间满足服务的需要。用户或客户一般将租借、租用或以其它方式支付通过云访问资源的费用，并因此不必购买和维持硬件和/或软件来提供对这些资源的访问。

虽然各种应用和资源的方面可在云中被调节和管理，但这些应用和资源所依赖的数据存储库并不类似地被客户或其它这样的用户调节或容易管理。一般，执行诸如供应并按比例调整数据存储的任务是冗长乏味的手工程序，其中客户必须给数据库管理员(DBA)或类似的专家用户提供配置信息和需要，使得DBA可确定配置是否是有效的。此外，不存在使客户容易动态地和/或自动地调节数据库实例的参数或管理数据存储库的其它这样的方面的方法。在很多情况下，数据实例将使备份和恢复机制在适当的地方，但这些机制常常在单个位置或区域中，使得它们在该区域中容易受到失败或出故障。此外，当数据实例失败时，一般花费几分钟来生成新的实例，将适当的卷连接到新的实例，并另外执行从故障恢复所必需的任务。

附图简述

将参考附图描述根据本公开的各种实施方案，其中：

图1示出各种实施方案可被实现的环境；

图2示出可根据各种实施方案使用的控制面和数据面的示例性分离；

图3示出利用可根据各种实施方案使用的多个监控部件的例子；

图4示出用于在可根据一个实施方案使用的多个数据区中运行的已复制数据实例的示例性实现；

图5示出根据一个实施方案的主要副本的示例性状态转变图；

图6示出根据一个实施方案的监控部件的示例性状态转变图；

图7示出可根据一个实施方案使用的用于执行故障切换操作的示例性过程；

图8示出可根据一个实施方案使用的用于恢复辅助副本的示例性过程；

图9示出可根据一个实施方案使用的用于管理事件处理器的示例性过程；

图10示出可根据一个实施方案使用的归因于出故障的事件处理器的重新分配的例子；以及

图11示出可根据一个实施方案使用的用于添加新的事件处理器作的示例性过程。

详细描述

根据本公开的各种实施方案的系统和方法可克服在常规方法中经历的前述和其它不足的一个或多个，以在电子环境中管理数据存储的方面。特别是，各种实施方案提供单独的控制环境、或可用于使用户能够管理和/或改变数据环境的各种方面的控制面、或数据面。可经由一组Web服务提供这种“自我服务”功能，使用户面和控制面能够一起充当虚拟数据库管理员(DBA)。用户或客户可通过例如多个外部可见的应用编程接口(API)之一向控制面提交请求。各种API可用于在数据环境中执行关于数据存储库例如关系数据库的特定功能。被接收到API之一的请求可被分析以确定将在数据面中执行的期望行动，例如调节数据存储器或数据存储实例的操作或配置参数的行动。部件例如工作流部件可确定对行动的适当任务，并使任务以适当的顺序执行。这些任务中的至少一个一般将在数据环境中被执行，例如以调节关系数据库的方面。

根据某些实施方案，这样的系统可在数据环境中提供已复制数据实例的供应。供应可利用主要-辅助复制方法，主要副本和辅助副本的每个在一个或多个分离的数据区、单独的地理位置等中或跨越一个或多个分离的数据区、单独的地理位置等来供应。数据库副本可在单独的数据实例上运行，每个数据实例连接到在副本中未被共享的专用块存储卷。

在各种实施方案中，可使用块级复制机制例如来自奥地利Vienna的Linbit的分布式复制块设备(DRBD

)或如华盛顿州西雅图的Amazon.com公司所提供的弹性块存储(EBS)来执行复制，块级复制机制可反映在服务器之间的块设备的内容，并在冗余系统中同步地复制数据。每个实例可运行安装成管理数据实例的所有输入和输出(I/O)操作的具有块级复制机制(BLRM)内核模块的内核。可在主要副本处执行所有读和写，块级复制机制与辅助副本同步地复制信息。

主要副本和辅助副本都可具有外部面向的DNS名称。客户可使用DNS名称例如DNS_primary来得到当前的主要副本。DNS_primary名称可又被称为或“(别名记录)“cname”为(当前)主要副本的外部DNS名称。当主要副本故障或否则不可用时，辅助副本可被提升或故障切换以变成新的主要副本，由此DNS_primary的别名记录可更新到新的主要实例的DNS名称。所有写被发送到在当前主要副本上的数据库。当主要实例接收到写时，信息被同步地写到辅助副本上。当在两个地方成功地写时，写可被认为是成功的。在各种实施方案中在主要副本处只执行所有读。

因此可使用在不同的数据区中运行的实例副本在多个数据实例中支持数据库复制。可使用在块级处的同步复制机制进行数据库写，使得没有数据丢失，除非所有副本由于涉及多个数据区的大规模故障等而不可用。复制可提供比可使用单个数据库实例实现的更高的可用性，因为单个副本故障不在延长的一段时间内引起对数据库的故障。例如，如果数据库的主要副本出故障，那么各种实施方案可执行故障切换操作，由此辅助副本接管作为新的主要副本。复制也可在很多例子中提供比未复制的数据库更高的持久性，免受数据区的故障、数据卷故障等。

图1示出用于实现根据各种实施方案的方面的环境100的例子。如将被认识到的，虽然基于Web的环境用于解释的目的，但是不同的环境可在适当时用于实现各种实施方案。所示的环境100包括测试或发展部分(或侧)和生产部分。生产部分包括电子客户端设备102，其可包括可操作来通过适当的网络104发送并接收请求、消息或信息并将信息传送回设备的用户的任何适当的设备。这样的客户端设备的例子包括个人计算机、蜂窝电话、手持式消息发送设备、膝上型计算机、机顶盒、个人数字助理、电子书阅读器等。网络可包括任何适当的网络，包括内联网、互联网、蜂窝网络、局域网或任何其它这样的网络或其组合。用于这样的系统的部件可至少部分地取决于网络的类型和/或所选择的环境。用于经由这样的网络进行通信的协议和部件是公知的，且将不在本文详细地讨论。通过网络的通信可通过有线或无线连接或其组合来实现。在本实施例中，网络包括互联网，因为环境包括用于接收请求并响应于其请求的Web服务器106，虽然对于其它网络，可使用服务于类似的目的的可选设备，如对本领域的普通技术人员明显的。

例证性环境包括至少一个应用服务器108和数据存储器110。应理解，可能有一些应用服务器、层或其它元件、过程或部件，其可被链接或以其它方式配置，其可相互作用以执行任务，例如从适当的数据存储器获得数据。如本文使用的，术语“数据存储器”指能够存储、访问和检索数据的任何设备或设备的组合，其可包括在任何标准的、分布式或群集环境中的任何组合和数量的数据服务器、数据库、数据存储设备和数据存储介质。应用服务器可包括按需要与数据存储器合并以为客户端设备执行一个或多个应用的方面、为应用处理大多数数据访问和商业逻辑的任何适当的硬件和软件。应用服务器与数据存储器协作来提供访问控制服务，并能够产生内容例如文本、图形、音频和/或视频以传输到用户，该内容在本实施例中可通过Web服务器以HTML、XML或另一适当的结构语言的形式提供给用户。所有请求和响应的处理以及在客户端设备102和应用服务器108之间的内容的传送可由Web服务器处理。应理解，Web和应用服务器是不需要的，且仅仅是示例性部件，如本文讨论的结构代码可在任何适当的设备或主机上执行，如在本文其它地方讨论的。此外，环境可被构造成使得测试自动框架可被提供为用户或应用可订阅的服务。测试自动框架可被提供为在本文讨论的各种测试模式中的任一个的实现，虽然也可使用各种其它实现，如本文讨论或建议的。

环境还包括发展和/或测试侧，其包括允许用户例如开发者、数据管理员或测试者访问系统的用户设备118。用户设备118可以是例如上面关于客户端设备102描述的任何适当的设备或机器。环境还包括发展服务器120，其类似于应用服务器108起作用，但一般在代码在生产侧上被部署并执行之前在发展和测试期间运行代码，并例如是外部用户是可访问的。在一些实施方案中，应用服务器可起发展服务器的作用，且分离的生产和测试存储可以不被使用。

输出存储器110可包括一些分离的数据表、数据库或用于存储关于特定方面的数据的其它数据存储机制和介质。例如，所示的数据存储器包括可用于为生产侧提供内容的、用于存储生产数据112和用户信息116的机制。数据存储器也被示为包括用于存储测试数据114的机制，测试数据114可与用户信息一起对测试侧使用。应理解，可能有很多其它方面，其可能需要存储在数据存储器中，例如页面图像信息和访问权限信息，其可在适当时存储在上面列出的机制的任一个中或在数据存储器110的额外机制中。数据存储器110通过与其相关的逻辑可操作来接收来自应用服务器108或发展服务器120的指令，并响应于其而获得、更新或以其它方式处理数据。在一个例子中，用户可提交对某种类型的项目的搜索请求。在这种情况下，数据存储器可访问用户信息以验证用户的身份，并可访问目录细节信息以获得关于该类型的项目的信息。该信息接着可例如在用户能够通过用户设备102上的浏览器查看的网页上列出的结果中返回给用户。可在浏览器的专用页面或窗口中查看对所关注的特定项目的信息。

每个服务器一般将包括提供对该服务器的一般管理和操作的可执行程序指令的操作系统，并一般将包括存储指令的计算机可读介质，当所述指令由服务器的处理器执行时允许服务器执行其预期的功能。对服务器的操作系统和一般功能的适当实现是已知的或在市场上可得到的，并容易由本领域普通技术人员特别根据本文的公开来实现。

在一个实施方案中的环境是利用经由通信链路使用一个或多个计算机网络或直接连接来互连的一些计算机系统和部件的分布式计算环境。然而，本领域的普通技术人员将认识到，这样的系统可同样好地在具有比图1所示的更少或更多数量的部件的系统中操作。因此，图1中的系统100的描绘应被理解为本质上是例证性的，且不限于本公开的范围。

例如图1所示的环境可能对提供商例如电子市场是有用的，其中多个主机可用于执行任务，例如服务内容、认证用户、执行支付交易、或执行很多其它这样的任务中的任一个。这些主机中的一些可配置成提供相同的功能性，而其它服务器可配置成执行至少一些不同的功能。在这样的情况下的电子环境可包括额外的部件和/或其它布置，例如在下面详细讨论的在图2的配置200中示出的那些部件。

根据一个实施方案的系统和方法提供使开发者、客户或其它经授权的用户能够容易和成本有效地获得并配置关系数据库和其它这样的数据源的关系数据库服务(“RDS”)，使得用户可执行任务，例如存储、处理和查询云中的关系数据集。虽然关于互联网、Web服务和基于互联网的技术讨论了这个例子，应理解，各种实施方案的方面可与在电子环境中通过网络可得到或提供的任何适当的服务一起使用。此外，虽然服务在本文被称为“关系数据库服务”，但应理解，这样的服务可在电子环境中与任何适当类型的数据存储库或数据存储器一起使用。在本实施例中的RDS包括至少一种Web服务，其使用户或客户能够容易管理关系数据集，而不担心部署、升级、补丁管理、备份、复制、故障切换、容量管理、按比例调整和数据管理的其它这样的方面的管理复杂性。开发者因此自由地开发复杂的云应用，而不担心管理数据库基础设施的复杂性。

在一个实施方案中的RDS提供单独的“控制面”，其包括对管理数据存储的方面有用的部件(例如，硬件和软件)。在一个实施方案中，提供允许用户或客户在RDS内进行调用以执行与数据存储有关的某些任务的一组数据管理应用编程接口(API)或其它这样的接口。然而，用户仍然可使用直接接口或API来与数据存储库进行通信，并可仅当必要时使用控制面的RDS特定的API，以管理数据存储或执行类似的任务。

图2示出可根据一个实施方案使用的RDS实现200的例子。在本实施例中，最终用户的计算设备202被示为能通过网络206在控制面208内进行调用，以执行任务，例如提供数据面210的数据存储库。用户或应用204可直接通过数据面210的接口访问所供应的存储库。虽然最终用户计算设备和应用用于解释的目的，但是应理解，任何适当的用户、应用、服务、设备、部件或资源可在各种实施方案中在适当时访问控制面和/或数据面的接口。此外，虽然部件分成控制面和数据面，但是应理解，这可指用于提供相应的功能性的至少一些资源(例如，硬件和/或软件)的实际或虚拟分离。

在本实施例中的控制面208本质上是处理控制和管理行动例如供应、按比例调整、复制等的硬件和软件部件的虚拟层。在本实施方案中的控制面包括Web服务层212或层，其可包括至少一个Web服务器，例如连同计算机可执行软件、应用服务器或其它这样的部件。Web服务层还可包括用于从访问网络206接收Web服务调用或请求的一组API 232(或其它这样的接口)。可提供每个API来接收对将关于数据环境执行的至少一个特定的行动的请求，例如供应、按比例调整、克隆关系数据库的实例或使关系数据库的实例冬眠。当接收到对API之一的请求时，Web服务层可解析或以其它方式分析该请求以确定作用于或处理调用所需的步骤或行动。例如，可接收包括对创建数据存储库的请求的Web服务调用。在本实施例中，Web服务层可解析该请求以确定待创建的数据存储库的类型、所请求的存储卷、所请求的硬件(如果有)的类型、或其它这样的方面。对请求的信息可被写到管理(“Admin”)数据存储器222或其它适当的存储位置或工作队列，用于随后的处理。

在一个实施方案中的Web服务层包括一组可升级的面向客户的服务器，其可提供各种控制面API并基于API规范返回适当的响应。Web服务层还可包括至少一个API服务层，其在一个实施方案中由处理面向外部的客户API的无国籍复制服务器组成。Web服务层可负责Web服务前端特征，例如基于证书来认证客户、授权客户、抑制对API服务器的客户请求、使用户输入生效、并将请求和响应编组或编出。API层也可负责响应于API调用而从管理数据存储器读数据库配置数据/将数据库配置数据写到管理数据存储器。在很多实施方案中，Web服务层和/或API服务层将是唯一的外部可见的部件，或对控制服务的客户可见并可由客户访问的唯一部件。Web服务层的服务器可以是无国籍的，并水平地按比例调整，如本领域中已知的。API服务器以及持久数据存储器可例如在地理区域中或地理位置附近的多个数据中心中扩展，使得服务器对单个数据中心故障是能复原的。

在本实施方案中的控制面包括在本文称为“清理器”部件214的部件。清理器部件可以是可操作来轮询控制面的各种部件或以其它方式确定将响应于未完成的请求来执行的任何任务的任何适当的部件。在本实施例中，Web服务层可将“创建数据库”请求的指令或信息放置在管理数据存储器222或类似的工作队列中，且清理器可周期性地检查用于未完成的工作的管理数据库。可使用各种其它方法，如将对本领域的普通技术人员明显的，例如向清理器发送工作存在的通知的Web服务。清理器部件可获得“创建数据库”请求，且使用该请求的信息可将请求、调用或其它这样的命令发送到可操作来例示该请求的至少一个工作流的工作流部件216。使用如在文本的其它地方讨论的工作流服务来产生和维持在一个实施方案中的工作流。通常工作流是应被执行来执行特定的工作的一系列任务。工作流不是实际工作，而是控制信息的流动和工作的执行的工作的抽象。工作流也可被认为是状态机，其可在执行期间的任何时间管理并返回过程的状态。在一个实施方案中的工作流部件(或部件的系统)可操作来为例如下列任务管理和/或执行工作流的托管和执行：存储库创建、修改和探测；恢复和备份；安全组创建、探测和修改；用户证书管理；以及密钥旋转和证书管理。这样的工作流可紧随着工作流服务实现，如在本文的其它地方讨论的。工作流部件也可管理在用于不同的数据库引擎例如MySQL的工作流步骤之间的差异，因为下层工作流服务不一定改变。

在本实施例中，可使用用于创建数据库并应用从原始请求提取的信息的工作流模板来例示工作流。例如，如果请求是针对MySQL

关系数据库管理系统(RDBMS)实例，与Oracle

RDBMS或其它这样的实例相反，则特定的任务将被添加到指向MySQL实例的工作流。工作流部件也可选择与所请求的存储的量有关的特定任务、任何特定的硬件需要或其它这样的任务。这些任务可按对总工作有用的执行顺序被添加到工作流。虽然一些任务可被并行地执行，但其它任务依赖于将被首先完成的以前任务。工作流部件或服务可在工作流中包括这个信息，且任务可按需要被执行以及信息被传递。

客户的示例性“创建数据库”工作流可包括任务，例如供应数据存储实例，分配实例外持久存储的卷，将持久存储卷连接到数据存储实例，接着分配并连接DNS地址或客户可用于访问或以其它方式连接到数据实例的其它地址、端口、接口或标识符。在本实施例中，给用户提供用于访问实例的DNS地址和端口地址。工作流也可包括下载并安装任何二进制或用于特定的数据存储技术(例如，MySQL)的其它信息的任务。工作流部件可管理这些和任何相关任务的执行、或这样的任务的任何其它适当的组合，并可响应于实际上相应于数据面210中的数据存储实例的“创建数据库”请求而产生对指示“数据库”的创建的请求的响应，并提供用于访问实例的DNS地址。用户接着可直接使用DNS地址和端口访问数据存储实例，而不必访问或经过控制面208。各种其它工作流模板可用于执行类似的工作，例如删除、创建或修改一个或多个数据存储实例，例如增加存储。在一些实施方案中，工作流信息被写到存储器，且至少一个单独的执行部件(未示出)拉或以其它方式访问或接收将基于工作流信息执行的任务。例如，可能存在执行供应任务的专用供应部件，且该部件可能不被工作流部件调用，但可监控任务队列或可接收用于以很多相关方式中的任一种供应任务的信息，如应明显的。

如所述，各种实施方案可利用可接收对过程或任务的当前状态例如供应存储库的请求或调用的工作流服务，并可返回过程的当前状态。工作流部件和/或工作流服务不进行实际调用或请求以执行每个任务，而相反管理使控制面的部件能够确定待执行的下一任务的工作流的状态和配置信息以及该任务所需的信息，接着产生包括该状态信息的在数据面内的适当调用，由此数据面的部件可进行调用以执行任务。工作流和任务可并行地被调度，以便增加吞吐量并最大化处理资源。如所讨论的，任务的实际执行将出现在数据面中，但任务将起源于控制面。例如，工作流部件可与可在数据存储器中进行调用的主机管理器通信。因此，对于给定的任务，可对穿过某些参数的工作流服务进行调用，由此工作流服务产生工作流的任务的序列，并提供当前状态，使得当前状态的任务可被执行。在任务被执行(或以其它方式被解决或终结)之后，部件例如主机管理器可答复服务，其可接着提供关于工作流中的下一状态的信息，使得下一任务可被执行。每当工作流的任务之一被执行时，服务可提供待执行的新任务，直到工作流完成。此外，可对不同的工作流并行地运行多个线程，以加速工作流的处理。

在本实施方案中的控制面208还包括至少一个监控部件218。当在数据面中创建数据实例时，可将该实例的信息写到控制面中的数据存储器例如监控数据存储器220中。应理解，监控数据存储器可以是单独的数据存储器，或可以是另一数据存储器的一部分，例如在管理数据存储器222中的一组不同的表、或另一适当的存储库。监控部件可访问在监控数据存储器中的信息，以确定在数据平面210中的有效实例234。监控部件也可执行其它任务，例如从控制面和/或数据面的多个部件例如Web服务层、工作流部件、清理器部件和各种主机管理器收集日志和/或事件信息。使用这样的事件信息，监控部件可暴露客户可见的事件，用于例如实现面向客户的API的目的。监控部件可不断地监控控制面的所有运行的存储库和/或实例的健康状态，探测这些实例中的任一个的故障，并发起适当的恢复过程。

对于提供对数据存储器的访问的机器，在数据面中的每个实例234可包括至少一个数据存储器226和主机管理器部件228。在一个实施方案中主机管理器是在实例和/或应用服务器例如Tomcat或Java应用服务器上执行的应用或软件代理，其被编程为管理任务例如软件部署和数据存储操作以及监控数据存储器和/或相应的实例的状态。在一个实施方案中主机管理器侦听只可从内部系统部件到达且客户或其它外部实体不可采用的端口。在一些实施方案中，主机管理器不能在控制面层内发起任何调用。主机管理器可负责管理和/或执行任务，例如建立对新的存储库的实例，包括建立逻辑卷和文件系统，安装数据库二进制和种子，并开始和停止存储库。主机管理器可监控数据存储器的健康状态以及针对错误条件例如I/O错误或数据存储器错误监控数据存储器，并且如果必要可重新启动数据存储器。主机管理器还执行和/或管理数据存储器和/或操作系统的软件补丁和升级的安装。主机管理器还可收集相关的度量，例如可与CPU、存储器和I/O使用有关。

监控部件可对所监控的实例234例如通过发送特定的请求或通过监控来自主机管理器的心跳来周期性地与每个主机管理器228进行通信，以确定每个主机的状态。在一个实施方案中，监控部件包括配置成向每个主机管理器发出命令的一组事件处理器(或监控服务器)，例如以获得特定的主机和/或实例的状态。如果响应在特定数量的重试之后没有被接收到，则监控部件可确定存在问题，并可将信息存储在管理数据库222或另一这样的工作队列中以执行对实例的行动，例如验证该问题且如果必要则重新供应实例。清理器可访问该信息并切断实例的恢复工作流以试图自动从故障恢复。主机管理器228可充当对控制面的监控和其它部件的代理，代表控制面部件执行实例的任务。有时候，实例之一例如相应的主机、实例或卷毁损、再引导、重新启动等将出现不能被自动解决的问题。在一个实施方案中，存在可记录这些和其它客户可见性事件的记录部件(未示出)。记录部件可包括API或其它这样的接口，使得如果实例在一段时间内是可用的，客户可调用适当的“事件”或类似的API来获得关于事件的信息。在一些情况下，当实例出故障时请求可保持未决。因为在这个实施方案中控制面与数据面分离，控制面从不接收数据请求，因此不能排队等候对随后提交的请求(虽然在一些实施方案中该信息可被转发到控制面)。因此，在本实施方案中的控制面向用户提供关于故障的信息，所以用户可在必要时处理请求。

如所讨论的，一旦供应了实例且给用户提供了DNS地址或其它地址或位置，用户就可通过网络使用Java数据库连接(JDBC)或其它这样的客户端将请求“直接”发送到数据面210以直接与该实例234交互作用。在一个实施方案中，数据面采取计算云环境(或至少包括计算机云环境或是计算云环境的部分)或一组Web服务和资源的形式，这组Web服务和资源在硬件和/或软件部件的“云”或动态网络中提供数据存储和访问。DNS地址在这样的动态云环境中是有益的，因为实例或可用性故障例如可通过将DNS地址编程地重新映射到用于使用的任何适当的置换实例而被掩蔽。从用户202或应用204接收的请求例如可指向网络地址转换(NAT)路由器224或其它适当的部件，其可将请求引导到实际实例234或相应于请求的DNS的主机。如所讨论的，这样的方法允许实例被动态地移动、更新、复制等，而不需要用户或应用改变用于访问实例的DNS或其它地址。如所讨论的，每个实例234可包括主机管理器228和数据存储器226，并可在持久存储器230中具有至少一个备份实例或副本。使用这样的方法，一旦实例通过控制面被配置，用户、应用、服务或部件就可直接通过对数据面的请求与实例交互作用，而不必访问控制面232。例如，用户可通过DNS地址直接发出结构查询语言(SQL)或与实例中的数据有关的其它这样的命令。用户将仅仅必须访问控制面，如果用户想执行任务例如扩展实例的存储容量。在至少一个实施方案中，控制面208的功能可作为至少一种服务由提供商提供，提供商可以或可以不与数据面210的提供商有关，而可仅仅是可用于提供和管理数据面中的数据实例且也可监控和确保在分离的数据面210中的那些实例的可用性的第三方服务。

如所讨论的，提供控制面的功能作为Web服务或其它这样的服务的一个优点是控制面起虚拟数据库管理员(DBA)的作用并避免人DBA执行任务例如供应数据。供应数据目前是冗长的手工程序，需要DBA来接收必要的配置信息，确定配置是否是有效的，优化和调节实例，并执行其它这样的任务，其花费相当大量的时间和努力。此外，这样的方法提供很多错误机会，其可能不被发现，直到数据被丢失之后。使用如本文描述的控制面或服务，用户或客户可替代地提交包括信息例如硬件的类型和数据库产品的版本的调用。控制面或服务可接着执行必要的任务来创建、删除、修改、扩展或以其它方式修改数据存储器或数据存储实例。控制面也可用一致的方式支持一些不同的数据库引擎，而不需要DBA在每个引擎中是专家。一旦被供应，用户就可本地访问数据实例，并可简单地将现有的应用(例如MySQL应用)指向DNS地址或特定实例的其它位置信息。没有查询模型或其它这样的功能的限制或修改，因为用户可继续使用建立在MySQL、Oracle或其它数据库技术上的应用。

图3示出根据一个实施方案的配置300的实例，配置300可用于目的例如单个或复制的RDS实例的监控和自动恢复。虽然为了简单和清楚的目的在附图之间延续参考数字，但是应理解，这些仅仅代表可用于各种实施方案的类似部件，且不应被解释为需要来自各种其它实施方案的部件或仅仅显示单个实施方案的不同视图。此外，可在各种实施方案中使用更少或额外的部件，且在给定附图中部件的存在或缺乏不应被解释为该部件在给定的实施方案中被需要或不是有用的，除非另外特别规定。在实施方案和附图之间的变化根据本公开对普通技术人员应是明显的。

如图所示，控制面的监控部件(或服务)218可包括在本文称为事件处理器的一系列处理节点302。在一个实施方案中，事件处理器包括可操作来监控数据面的方面的一群监控服务器。每个事件处理器可配置成通过相关的主机管理器228与指定的一组或系列的数据存储器226和/或数据实例234通信。如所讨论的，每个数据存储器和主机管理器可存在于数据面210或数据环境的节点或机器上。每个事件处理器可使用任何适当的通信技术与所分配的主机管理器通信，以例如通过使用安全(例如HTTPS)请求如“getStatus”请求查验(ping)每个主机管理器来从每个主机获得当前的状态。响应于该请求，每个主机管理器可发送响应，其包括信息例如主机管理器228是否有问题或主机管理器228是否探测到问题以及任何相关度量、参数值或被确定为相关的诊断信息。在某些实施方案中，由主机管理器返回的信息的量和类型可基于主机管理器的状态而变化。例如，如果没有错误被探测到，则主机管理器可发送待记录或以其它方式处理的标准的一组指定度量。如果例如探测到问题，则可包括不同的一组信息，例如指示问题类型的信息以及与该问题类型相关的诊断或其它信息。各种算法可被提供给主机管理器用于进行这样的确定。当从主机管理器接收到信息时，事件处理器可在必要时分析信息，并将该信息存储在监控数据存储器220或其它这样的位置中。如在本文的其它地方讨论的，事件处理器也可将任何日志信息存储在监控数据存储器中。如在本实施例中讨论的，监控数据存储器220可以是单个逻辑数据存储器，但可以在很多数据实例304中被划分。

可能有使用多个事件处理器302作为监控部件218的部分的很多优点。一个这样的优点是，对于数据面中的大量数据实例254，单个事件处理器可能没有足够的容量来同时监控每个实例。利用多个事件处理器允许监控工作分布在几个事件处理器中。此外，使用多个事件处理器允许现有的事件处理器在故障或其它这样的问题的情况下承担另一事件处理器的工作。如果数据实例仅由单个事件处理器管理且存在处理器使事件处理器变得不可用的问题，则该数据实例可能不使任何监控被执行，因此可能有出故障或其它这样的问题的风险。通过在一组事件处理器中扩展监控并允许通过每个事件处理器监控的范围来动态地更新，控制面可确保数据面中的每个实例在实质上任何时间被监控，甚至在一个或多个事件处理器的故障的情况下。

在一个实施方案中，通过在任何给定的时间获得待监控的多个实例(包括副本)并将多个实例分配在多个事件处理器中来确定每个事件处理器的责任。例如，如果在数据面中有25,000个待监控的实例且在控制面中有五个事件处理器运行，则可给每个事件处理器用于监控这些数据实例中的大约5,000个的责任。如果给每个实例提供例如标识符，则可给每个事件处理器一系列标识符(例如前5,000个标识符，第二组5,000个标识符等)，以使调节每个事件处理器的责任更容易，而不是必须管理这25,000个实例的每个的映射信息。在附图中的实例示出在这样的实施例中的每个事件处理器的责任的范围。

以适当的间隔例如一分钟一次，每个事件处理器302可将正由该事件处理器监控的请求发送到每个主机管理器228。在一个实施方案中事件处理器是在控制面的Tomcat容器内运行的Java应用，其对数据面中的数据实例有规律地轮询主机管理器。事件处理器在一个实施方案中可通过使用DNS名称或主机管理器端口进行getStatus()或类似的调用(例如，在SSL上)来轮询主机管理器。在一些实施方案中，正被监控的数据实例由客户数据存储器标识符、数据存储器标识符和实例标识符的组合来唯一地识别。使用这样的方法，当将数据实例移动到云中的另一实例时，可区分开旧和新的实例的状态。事件处理器可基于来自主机管理器的响应来确定数据实例的状态。在一个实施方案中数据实例可以处于至少下面的示例性状态之一中：“OK”(数据实例正在正确地运行)、“不得与外界接触的”(数据实例在可疑的故障状态中)、或“无效的”(数据实例不可达到且不对状态的请求做出响应)。

在大多数情况下，主机管理器将返回指示主机管理器、相关实例等正如预期地运行的响应，且事件处理器可更新监控数据存储器220中的信息。在一个实施方案中当主机管理器返回适当的响应例如HTTP响应代码“200”(对成功的HTTP请求的标准响应代码)时，事件处理器可认为数据实例在“OK”或类似状态中。如果响应没有从主机管理器被接收到，或如果响应是超时响应(例如HTTP代码“500”或任何其它“5xx”错误响应代码)，则事件处理器可重新发送getStatus请求，并可将数据实例置于“不得与外界接触”或类似状态中。如果主机对于多于预定数量的状态查验或其它这样的请求处于“不得与外界接触”状态中，则数据实例可被宣告为处于“无效”或类似状态中。如果主机在预定数量的状态查验中以“200”响应(或类似)代码回来在线，则主机或实例可移动到“OK”状态。在将主机状态从“不得与外界接触”移动到“无效”或所使用的“OK”之前的预定数量的检查至少部分地是避免归因于间歇的网络错误、暂时过载的事件处理器、暂时过载的主机管理器或其它这样的临时错误的假阳性，其实际上不导致数据实例是不可用的，否则需要恢复。在一个实施方案中，“不得与外界接触”的状态不持久，因为该状态可容易由另一事件处理器确定。

如果在预定数量的状态请求之后没有接收到答复，或状态以其它方式移动到“无效”或类似状态，如在本文其它地方讨论的，则事件处理器将关于问题状态的信息输入管理数据存储器222(或如上所述的其它工作队列)中，该信息指示不存在关于无响应的主机管理器的可疑状态。如上所述，控制面的清理器214的部件可周期性地检查管理数据存储器以得到信息，且当清理器针对问题状态的怀疑探测信息时，可启动适当的恢复工作流。例如，清理器可将信息传递到工作流部件216，其使适当的工作流产生，例如处理不可用的数据实例的工作流、处理由主机管理器报告的错误的工作流、或很多其它这样的情况中的任一个。工作流管理器可产生适当的工作流，传递状态信息，并处理如在本文其它地方讨论的各种其它方面。

将恢复信息存储在管理数据存储器中的一个优点是，这样的方法允许甚至在监控系统出故障的情况下也恢复。独立于监控数据存储器的可用性实现恢复行动可能是合乎需要的。使用管理数据存储器可能是可接受的，因为在本实施方案中，任何类型的恢复(包括产生工作流等)需要管理数据存储器(或其它这样的工作队列)是有效和可用的。因此，避免对恢复的另一依赖性并替代地安排一次可用性可能是合乎需要的。

根据各种实施方案的系统和方法使客户能够利用Web服务或类似的这样的方法，以在云计算或类似的环境中创建一个或多个已复制的数据库实例，提供高度持久和高度可靠的数据解决方案。当客户在各种实施方案中创建已复制的数据库实例时，客户数据使用主要-辅助复制模型被同步复制。在一些实施方案中，副本可位于不同的物理位置上，例如在不同的数据区中。每个数据“区”可以指例如位于特定的地理区域内的一个或多个数据中心或数据服务器的组，不同的区位于不同的地理位置处或周围。RDS实例接着可容忍数据区之一的故障，因为在不同的地理位置处的另一数据区可能避免故障，除了在大的灾难性事件的情况下。在一些情况下，数据中心可跨越多个数据区，但在给定数据中心内的数据副本可在不同的区中被例示。很多其它变形是可能的，例如重叠区、在多个地理位置处的区等。如果主要副本故障或以其它方式变得不可用，则RDS系统可快速并自动故障切换到辅助副本，导致非常少的停机时间或数据不可用性。

在一个实施方案中，客户能够通过调用控制面的Web服务层的指定接口来创建已复制的数据库实例，例如关于图2讨论的。例如，客户可调用指定诸如实例类、所分配的存储器、数据库引擎等方面的“CreateDBInstance”API，因为客户将创建未复制的数据实例。当创建已复制实例时，客户可包括至少一个额外的参数，例如“已复制”或类似的参数，一个值被设置为“真”或任何其它适当的值指示所创建的实例应被复制。在一些实施方案中，值默认被设置为“假”，使得未复制的实例被创建，除非另外由客户指定。在一些实施方案中，只有某些客户具有创建已复制实例的能力，例如负担某些水平的服务的费用的客户等。

在一些实施方案中，客户也可选择辅助副本是否在与主要副本不同的数据区中创建。在一些实施方案中客户也可被允许选择对实例的一个或多个特定的数据区、或例如有序列表，而在其它实施方案中客户不能选择对至少辅助副本的数据区。如果客户指定两个数据区且例如数据区之一例如在延长的时间段内变得不可用，在一些实施方案中持久性需求将使另一副本在第三数据区中产生，依此类推。这可能需要多个客户的数据区列表的顺序的管理和更新，这可复杂化用户体验，而不提供任何明显的益处。此外，应用遍及数据区扩展相关的应用舰队可能更容易，使得可能有位于与辅助副本相同的数据区中的一些应用舰队。

在一些实施方案中，客户可为已复制的数据实例调用“DescribeDBInstance”或类似的API，由此RDS可列出信息，例如主要副本的端点DNS名称和主要副本当前所位于的数据区。客户仍可使用将用于单个数据区的常规方法与RDS实例进行通信，因为例如RDS实例的状态一旦是“可用的”，客户就可接收数据存储器的端点DNS名称，并使用端点DNS名称连接到实例。在复本故障的情况下，RDS可使数据库故障切换到相应的辅助副本，且端点DNS名称又可被称为新的主要副本。数据库端点DNS名称在很多实施方案中保持不变，在已复制实例的寿命期间不变。

在一些实施方案中，可例如通过调用已复制参数被设置为“真”的“ModifyDBInstance”或类似的API来给客户提供将未复制的实例转换成已复制实例的能力。这可使数据库能够在适当的时间例如在下一维护窗期间或紧接在请求之后转换到已复制实例，因为可依赖于API调用参数等。

各种实施方案利用块极复制机制，例如实现什么也不共享的内核模块、反映服务器之间的块设备的内容的已复制存储解决方案。BLRM可紧接着块设备(即，硬盘或逻辑卷)工作。它使用主要-从属复制结构，其中主要副本将所有更新指向下层块设备。对块设备的所有输入和输出(I/O)请求由BLRM内核模块拦截，所有写操作被自动和同步地复制。BLRM提供对等设备的内在故障探测，并在对等节点不可到达时调用适当的恢复处理程序。BLRM也可在背景中将暂时不可用的节点自动重新同步化到数据的最近版本，而不干扰在主要副本处的数据访问。BLRM使用生成标识符(“GI”)来识别已复制数据的生成，由此BLRM可确定方面，例如两个节点是否是同一副本对的成员、背景重新再同步(如果必要)的方向、以及部分或完全的重新同步是否需要。BLRM驱动器可在任何适当的时间例如在副本对的初始化期间、当断开的备用副本切换到主要副本时、或起主要作用的资源与辅助副本断开时开始新的生成。虽然为了解释的目的，块级复制机制在本文用作实例，应理解，可在各种实施方案的范围内使用任何其它适当的块级技术或机制。

如所讨论的，在各种实施方案中的RDS数据实例可建立在一个或多个系统或平台上。例如，实例可建立在虚拟计算环境上，虚拟计算环境使客户能够利用Web服务或另一适当的方法来使用各种操作系统发起实例并管理那些实例。提供这样的虚拟计算环境的Web服务的实例是由Amazon.com公司提供的弹性计算云(EC2)服务。数据实例也可建立在块级存储机制上，块级存储机制可提供独立于实例的寿命持久的实例外存储器。块存储机制可提供存储卷，其可连接到实例并被暴露为实例内的设备。块存储平台的实例在2008年8月8日提交的题目为“Managing Access of Multiple Executing Programs to aNon-Local Block Data Storage”的共同未决的美国专利申请号12/188,949被提供，该专利由此通过引用被并入本文。逻辑卷(例如LVM层)可建立在块存储卷和适当的文件系统的顶部上，使得客户数据库可在LVM/文件系统层的顶部上运行。在一个实施方案中对于已复制数据库，BLRM可在LVM层的顶部上运行。在这样的实施方案中BLRM将拦截所有I/O请求并将那些请求发送到逻辑卷，其又可在多个块存储卷中分离请求。逻辑卷的使用可提供处理多个块存储E卷的能力以及容易扩展存储的能力等。在LVM的顶部上的分层BLRM也可允许写操作在副本中被复制。

图4示出用于实现主要-辅助复制模型以提供已复制RDS实例的机制400的实例。在本实施例中，主要副本410和辅助副本412位于数据平面408或数据库环境的不同的数据区(1和2)中。每个副本建立在块存储机制的顶部上，块存储机制在这里被示为BLRM层418、422，用于管理对每个副本的块存储器的I/O的块存储器420、422。控制面406的部件例如可类似于关于图2讨论的那些部件，能够通过将配置命令发到例如可执行必要的建立操作的本地主机管理器414、416来创建已复制RDS实例。如在附图中看到的，块级机制例如BLRM 418、422定位成拦截在块设备级处的所有I/O请求，并将对请求的信息写到本地磁盘和远程磁盘420、424。在本实施例中，数据库426(例如SQL)只在主要副本410上运行，且所有客户端402在主要副本410上运行其数据库事务(经由适当的网络404)。数据库426不在辅助副本412上运行，且文件系统也可不安装在辅助副本上，因为数据库将通常不知道在下层设备中的更新。

每个数据库客户端402可使用又可称为主要副本410的主机名称的RDS数据库DNS端点名称来自动发现当前的主要副本。通过使用DNS来发现当前的主要副本，可例如维持与现有的数据库客户端例如本地MySQL客户端、JDBC、PHP、C#和Haskell的兼容性。虽然DNS缓存可潜在地使客户端试图连接到旧的主要副本，客户端将不能通过连接到辅助副本来与数据库交谈，因为没有数据库在辅助副本中运行。客户于是可知道获得适当的DNS信息。

如所讨论的，可在相同或不同的数据区中运行的多个基础数据实例中支持数据库复制。一旦使用同步方法进行了写操作，数据就将被丢失，除了在所有副本由于多个数据区的故障而都不可用的非常罕见情况下，等等。这样的方法可比单个数据库实例提供更高的可用性，因为单个副本故障不在延长的一段时间内引起数据库的运转中断。例如，如果数据库的主要副本出故障，系统可在很多情况下对辅助副本执行故障切换操作。此外，这样的方法可提供比未复制的数据库更高的持久性，并可防止免受故障，例如数据区的故障或单个块存储卷故障。

如以前提到的，RDS可利用块级机制例如BLRM来反映服务器之间的块设备的内容。主要-从属复制结构使主要副本能够接受并写对块设备的所有更新。对块设备的所有I/O请求由BLRM内核模块拦截，使得写被同步地复制。BLRM利用生成标识符(“GI”)来识别已复制数据的生成。BLRM使用这个机制来确定两个节点是否实际上是同一副本对的成员，与被偶然连接的两个节点相反。GI也可用于在必要的情况下确定背景重新同步的方向，并确定部分或全部重新同步是否被需要。在至少一个实施方案中，GI是一般唯一标识符(UUID)，且不单调地增加序列成员。BLRM驱动器可当断开的辅助副本切换到新的主要副本时、或当起主要角色的资源从辅助副本断开时，在副本对的初始化期间开始新的生成。

在副本对(例如主要副本P和辅助副本S)被初始化并第一次被连接的实例中，主要副本P可产生新的GI，例如GI₁。如果主要副本P与S断开并移动到降级的模式中，其中P执行所有I/O而没有同步复制，P可产生新的GI，例如GI₂。然而甚至在P和S由于网络分区而断开的情况下，S将不产生新的GI。在本实例中，主要副本P在其元数据中保持新的和以前的GI(分别是GI₁和GI₂)。用于存储以前的GI的一个原因是优化辅助副本恢复。例如，可能有使S暂时断开的临时网络分区。因此，当分区修复时且当S重新连接到P时，P可看到S的当前GI是P的以前的GI，使得P可只运送在两个数据生成之间改变的那些块。

在存在主要副本的故障的实例中，当P被探测到不可用时，S可被提升到新的主要副本。当发出将辅助副本提升到新的主要副本的命令时，BLRM可在新的主要副本(以前的S)处生成新的GI。因此，当P(原始主要副本)重新加入簇并与S进行通信时，P可确定数据生成已改变且P必须使来自S的数据同步。

如所讨论的，主要副本P可接受所有写和读，且DNS_primary名称可又被称为或“别名记录”为主要实例的DNS名称。辅助实例S可通过来自主要副本的DRDB复制(或类似的块级复制)协议接收所有更新。没有设备被安装或数据库在辅助副本中被启动。当实现故障切换时，可被利用的另一部件是监控部件M。监控部件可监控主要和/或辅助副本的健康状态，并当故障出现时发起适当的故障切换行动。监控部件在一个实施方案中周期性地查验主要副本和辅助副本或以其它方式与主要副本和辅助副本通信。该通信可包括例如以有规律的间隔由T_heartbeat或类似参数指定的几秒钟发生的心跳通信。每当监控部件查验P和S时，在一个实施方案中监控部件向在每个副本中运行的主机管理器发出HTTP getStatus()命令。当P和S每个接收调用时，副本可执行BLRM或类似的状态调用以确定每个副本的当前状态。例如，主要副本P可运行BLRM工具命令以确定状态，例如IN_SYNC、STALLED、DEGRADED、DEAD等。

除了报告状态以外，每个副本也可向监控部件报告其相应的GI，监控部件可将生成数存储在存储器中。每当新的监控部件自引导时，新的部件可从明显一致的数据存储器(即，监控数据库)读取副本对的列表以及端点，并将该信息存储在存储器中。在每个状态查验期间，监控部件可确定数量是否是相同的。如果由于某种原因，数量是不同的，则GI值可在存储器中被更新。

主要副本或辅助副本可以处于至少两种被监控的状态的一个中。图5示出根据一个实施方案的主要副本的状态转变图500的实例。当副本连接到监控部件时，副本可具有MONITORED状态。当副本未连接到监控部件时，副本可以处于NOT_MONITORED或类似状态中。主要实例也可处于多个数据同步状态之一中。例如，当P和S都运行并可彼此通信时，P可以在IN_SYNC状态中，其中所有写在P和S之间被同步地写。观看状态图，在主要副本处于IN_SYNC/被监控状态中的504处，主要副本可与辅助副本通信，所有写成功，BLRM正心跳，且主要副本正被监控。如果主要副本从监控部件断开但仍然与辅助副本同步，则状态可转变到状态502。在状态502，主要副本可与辅助副本通信，且这两个副本都被连接并且是最新的，但主要副本从监控部件断开且因而未被监控。辅助副本也可在辅助副本是健康的并与主要副本联系的CONNECTED状态中，并当辅助副本是健康的但与主要副本脱离联系时可以在DISCONNECTED状态中。因此，在状态502和504，辅助副本将是CONNECTED，但在其它状态将是DISCONNECTED。

当P被监控但与S断开或否则脱离联系且不能进行任何I/O操作时，主要副本可具有STALLED或类似的状态508，因为所有写被冻结。当P与S断开并切换到未复制模式时，主要副本可具有DEGRADED或类似状态406。这允许当S出故障或否则不可到达时P继续服务于读和写。P可从状态502或508中的任一个达到DEGRADED模式。在很多实施方案中P可以不保持在DEGRADED模式中很长时间，因为RDS将一般产生新的备用副本。一旦新的辅助副本被例示，与主要副本完全同步，并被监控部件监控，状态就可转变回状态504，其中副本处于IN_SYNC中并被监控。

当P与S断开并且处于或以其它方式进入NOT_OBSERVED状态中时，主要副本可以在SUICIDAL或类似状态510中。在这种情况下，在一段时期例如T-failover秒之后，P的状态可改变到SUICIDAL。这个状态510在一些实施方案中可从STALLED状态达到，并在P与监控部件脱离联系时出现。在这个状态下，主要副本通过关闭本身或再引导其数据实例来“杀死”自己。

作为用于实现这样的过程的监控和故障切换结构的部分，每个已复制的数据库(即，副本对)由监控部件监控。在RDS中，单个监控部件可监控多个副本对。此外，系统可利用多个或“一群”监控节点。如所讨论的，监控部件可通过以适当的时间间隔例如每T-heartbeat秒连续地查验副本对来确定所监控的数据库的状态。从相应的监控部件M的观点看，图6示出已复制的数据库的状态转变图600的实例。当主要副本在IN_SYNC状态中且辅助副本被连接时，M可将数据库视为在IN_SYNC或类似状态604中。当监控部件例如由于网络分区而不能与副本之一通信时，M也可将数据库视为在状态604中，但其它副本向监控部件指示副本被连接且在同步中，使得没有执行故障切换事件的需要。

如果由于某种原因M不再与主要副本和辅助副本通信，则监控部件被划分掉或两个副本在同一时间是不可用的。在任一情况下，M可将数据库的状态视为移动到已划分或类似的状态602中。这可将主要的辅助副本都置于未监控状态中。当监控器划分结束时或当新的监控部件被分配给数据库时，状态可返回到IN_SYNC状态604中。

如果M不再与主要副本通信且辅助副本不能与主要副本通信使得它在断开状态中，则监控部件可将数据库视为在S_ONLY状态606中。如果在一段时间例如T_failover秒内监控部件能够重新建立与主要副本的通信，则状态可返回到IN_SYNC状态604。如果监控器在至少T_failover秒内不能与主要副本通信，监控部件可决定将辅助副本提升到新的主要副本。如果辅助副本确认当前的GI与主要副本的最后一个已知的GI相同，且辅助副本确认提升请求，则状态可转变到P_ONLY状态608，直到新的辅助副本被例示并完全与新的主要副本同步，此时状态可转变回IN_SYNC 604。

然而，如果监控部件决定将辅助副本提升到新的主要副本，但辅助请求拒绝提升请求，则状态可转变到灾难或类似状态610。辅助副本可拒绝该请求，因为辅助副本的当前GI不同于主要副本的最后一个已知的GI。在其它情况下，可否则不从辅助副本接收响应。这可发生在存在大的不可用性时，或在GI或成员资格信息被破坏的高度不可能的情况下。

在状态是IN_SYNC 604的另一情况下，监控部件可能失去与辅助副本通信的能力，且主要副本也可能失去与辅助副本通信的能力，使得主要副本在STALLED状态中。在这种情况下，状态监控部件可请求主要副本移动到DEGRADED状态，且由监控部件观看的状态可转变到P_ONLY或类似状态608。由于监控部件和主要副本不能与辅助副本通信，且主要副本在DEGRADED模式中，新的辅助副本可被例示并完全与主要副本同步，由此由M观看的状态可转变回IN_SYNC状态604。

如可通过状态转变图看到的，在至少一个实施方案中，对于在某些情况下的实例，由监控部件实现的故障切换算法可使监控部件将辅助副本提升为新的主要副本。如应理解的，这个例子仅仅表示穿过图6的状态图的一个路径。图7示出可根据一个实施方案使用的用于故障切换到辅助副本的示例性过程700。在本实例中，主要副本和辅助副本被提供、连接和同步(702)。生成标识符(GI)对每个副本产生以识别已复制数据的当前生成(704)。监控部件被分配给副本并周期性地查验副本(706)。被分配给副本对的监控部件可获得或被提供对该对的“租用”，其可在一段时间之后到期。租用一般将从主要副本的主机管理器接收到，且事件处理器标识符和租用时间可存储在这两个副本中，使得事件处理器租用方案能够经受得住主要副本的崩溃。以这种方式，监控部件可周期性地从副本释放，因此可为了负载分布或划分的目的而移动到其它对，或由于很多其它这样的原因中的任一个以其它方式被操纵。在租用期结束接近结束时，监控部件可试图重新开始租用，可做出不重新开始租用的决定，等等，如在本文其它地方讨论的。如果监控部件失去与主要副本的联系(708)，监控部件可试图在一段时间内重试(710)。如果监控部件在任何时间恢复与主要副本的联系，监控部件可继续。如果监控部件在一段时间例如T_failover秒内失去与主要副本的联系，则做出关于辅助副本是否能够与主要副本通信(712)或辅助副本是否在DISCONNECTED状态中的决定。也可做出关于在联系失去时主要副本的状态是否被已知与辅助副本在IN_SYNC中的确定。在各种实施方案中，该确定可单独地或实质上同时做出。如果辅助副本不能与主要副本通信且副本被同步(例如，具有相同的GI值)，则监控部件可发出将辅助副本提升到新的主要副本的命令(716)。如果P的最后状态不能被确定，则没有故障切换出现。如果该过程或机器被再引导，或如果新的监控部件接管，监控部件可能不知道P的状态。在这种情况下，状态可被处理为DEGRADED。

当将辅助副本提升到新的主要副本时，监控部件可向辅助副本的主机管理器发出命令，例如promoteTopPrimary(oldGI)。在本实施例中，“oldGI”是主要副本的主机管理器的最后一个已知的GI。当接收到该请求时，辅助副本可最后一次试图与主要副本通信。如果副本仍然不能通信，则辅助副本证实当前GI与(主要副本的)oldGI相同(718)。辅助副本也可验证租用信息，由此发出请求或发送状态请求的监控部件是该副本的有效监控部件，或副本的当前“租约持有者”。如果是这样，辅助副本确认它可提升自身，并通过发出适当的BLRM命令变成新的主要副本(720)。辅助副本将新的GI返回到监控部件作为对promoteToPrimary()请求的响应。随后，新的(提升的)主要副本的主机管理器安装文件系统并启动数据库(例如，MySQL)(722)。当监控部件成功地提升了辅助副本时，DNS_primary别名记录(cname)可指向新的主要副本(724)，如可由监控部件或控制面的其它部件执行的。随后，实例状态可被标记为需要辅助副本恢复(726)。

然而，如果辅助副本的当前GI与oldGI不相同，则将辅助副本提升为新的主要副本可能不安全。在这种情况下，可异常中断提升过程，并对操作员干预产生警报(或另一适当的补救行动)。如果操作员不能解决这个问题，则可通过将数据库恢复到最后公知的点来执行时间点恢复。

查看附图，可确定很多不同的故障情况。例如，在第一种故障情况中，主要副本和辅助副本正运行，并与操作监控部件通信。从监控部件的观点看，只要部件能够周期性地例如在最多T-monitoringcomponent秒内与每个实例通信，每件事物就按预期的运行。主要副本的状态在这种情况下将是“IN_SYNC/OBSERVED”。

然而在监控部件和辅助副本之间的网络链路被划分掉的故障情况下，主要副本能够与辅助副本和监控部件通信，但监控部件将不能与辅助副本通信。从主要副本的观点看，所有写仍然是成功的，使得主要副本仍然在IN_SYNC/OBSERVED状态中，以便没有辅助副本恢复被发起。从这个观点看，如果监控部件探测到辅助副本故障，但主要副本仍然与辅助副本同步，所以监控部件不必执行任何操作，并可继续试图与副本通信。

如果相反监控部件不能例如响应于网络分区与主要部件通信，则辅助副本将能够与主要副本和监控部件通信，但主要副本将从监控部件不可到达。从主要副本的观点看，在n*T_heartbeat秒之后，主要副本将移动到NOT_OBSERVED状态，因为主要副本不与监控部件联系。在一些实施方案中，n的值可以被设定为n≥2。主要副本的状态因此可以是IN_SYNC/OBSERVED。从监控部件的观点看，只有辅助副本是可到达的，但辅助副本仍然与主要副本联系，使得监控部件不发起任何故障切换。

在一个示例性故障情况中，辅助副本可能由于诸如节点故障或网络分区的因素而出故障。图8示出可根据至少一个实施方案使用的用于执行辅助副本恢复的过程800的实施例。该实施例假设副本已经被供应、传递和同步，且副本正被监控部件监控(802)。如果监控部件失去与辅助副本的联系(804)，监控部件可试图在一段时间内重试(806)。如果监控部件在任何时间重新获得与辅助副本的联系，该过程可继续。如果监控部件在一段时间内脱离与辅助副本的联系，则做出关于主要副本是否能够与辅助副本通信的确定(808)。如果主要副本不能与辅助副本通信，则主要副本可在T_sync秒之后进入STALLED状态(810)。在进入STALLED状态之后，主要副本可等待n*T_heartbeat秒以接到监控部件的消息。如果主要副本在这个时间单位内接到监控部件的消息(即，主要副本在MONITORED状态中)，则主要副本转到DEGRADED状态并在下一信号交换中通知监控部件(812)。从监控部件的观点看，状态转到P_ONLY，其中监控部件发现辅助副本是不可到达的。当确定此时，监控部件将数据实例的状态标记为诸如NEED_SECONDARY_RECOVERY的状态，并发起辅助副本恢复工作流(814)，例如在本文其它地方讨论的。

在另一故障情况中，所有主机可运转并在运行中，但主要副本可远离监控部件和辅助副本被划分，例如可能由于数据区分区或坏的机架上行链路。因此，监控部件能够与辅助副本通信，但监控部件和辅助副本都不能到达主要副本。从主要副本的观点看，在T_sync秒之后，主要副本转到STALLED状态。在进入STALLED状态之后，主要副本等待n*T_heartbeat秒以接到监控部件的消息。在这种情况下，主要副本没有接到监控部件的消息并从辅助副本断开，使得它移动到SUICIDAL状态，且当它作为辅助副本回来时通过再引导其实例来“杀死”自己。从监控部件的观点看，监控部件达到S_ONLY状态，其中它发现主要副本是不可到达的。监控部件在下一信号交换中检查辅助副本以确定辅助副本是否可与主要副本通信。在这种情况下，辅助副本将宣称它在DISCONNECTED状态中。监控部件等待T_failover秒并接着确认主要副本仍然是不可用的。如果是这样，监控部件使辅助副本提升为新的主要副本，如果数据库的以前状态在IN_SYNC中且如果辅助副本的当前GI与主要副本的最后已知的GI相同。T_failover的时间值可被设定为n*T_heartbeat+T_buffer，其中n是与以前在早些时候的情况中所述的相同的参数，被设定为n≥2。T_buffer是预期主要副本“杀死”自己的最坏情况时间。

在主要副本出故障且没有其它问题的类似情况下，也存在故障切换。然而在这种情况下，主要副本没有任何转变状态，因为主要副本出故障且将不进入SUICIDAL或其它这样的状态。

在另一故障情况中，主要副本和辅助副本可按预期的运行和通信，而没有网络问题，但监控部件可能出故障或否则变得不可用。从主要副本的观点看，每件事情仍然在IN_SYNC数据同步状态中，但主要副本记下它在NOT_OBSERVED状态中。

如所讨论的，控制面包括分布的一组事件处理器或事件处理器群，其配置成监控RDS实例并在必要时发出适当的恢复行动。可例如通过使用简单的基于散列的划分算法来给每个事件处理器分配RDS实例的一部分的监控工作负荷的一部分，在该算法中，基于实例标识符或类似的标识值来完成散列法。为了监控已复制实例，事件处理器可起监控部件的作用。事件处理器可通过查验与该实例相关的所有副本或以其它方式与这些副本通信来确定RDS实例的健康状态。如果实例未被复制，则事件处理器只需要与该实例的单个主机管理器通信。

当存在已复制实例时，可能有在事件处理器群当中划分实例监控工作负荷的特殊考虑。在一些实施方案中，当实例的数量增加时，监控系统应实质上线性地按比例调整。可通过添加额外的事件处理器(例如，主机)在各种实例中完成这个按比例调整。也可能有对事件处理器的放置的约束，因为事件处理器位于与正被该事件处理器监控的数据库的每个副本的不同数据区中可能是合乎需要的。通过将事件处理器放置在不同的数据区中，数据中心的故障不导致两个同时的故障(例如，监控部件和至少一个副本的故障)同时发生，使数据库潜在地达到不能恢复的状态。确保每个数据实例(包括所有副本)被连续监控也可能是合乎需要的。这可在各种实施方案中通过划分数据库实例并将每个分区的监控所有权分配给事件处理器之一来完成。如果事件处理器由于任何原因而出故障，则出故障的事件处理器所拥有和监控的分区应均匀地重新分配给其它可用的事件处理器。

为了确保监控系统的线性可量测性并仍然满足对事件处理器的放置的约束，事件处理器群在至少一个实施方案中基于每群存在于的数据区被分割成不同的组。每个组可配置成使得在一组内的事件处理器与RDS实例相关，所述RDS实例的副本与相应的事件处理器不在相同的数据区中。

作为例子，可能有覆盖四个相应的数据区(DZ1、DZ2、DZ3和DZ4)中的实例的四个事件处理器组(G1、G2、G3和G4)。对于每个副本对，监控工作负荷可被分配在不在与副本对相同的数据区中的组之间。在本实施例中，副本对在DZ2和DZ3中的RDS实例的监控工作负荷可在G1和G4中的事件处理器当中被分割。对于在DZ3和DZ4中的副本对，工作负荷可在组G1和G2之间分割。

对于位于给定数据区中的所有已复制数据库，每个事件处理器可计算独立地覆盖数据区对的事件处理器的列表。随后，对于给定的数据区对，覆盖该数据区对的事件处理器标识符可按词典顺序被分类。数据库标识符也可被分类并在数据区对中均匀地被分割。例如，可能在区DZ2和DZ3中存在具有副本的数据库。这些数据库可由组G1和G4中的事件处理器一起监控。为了简单起见，在这个数据区对中的数据库的数据库标识符可被设置为(DB1，...，DB1000)，且分别在组G1中有两个事件处理器(EP1和EP2)而在组G4中有两个事件处理器(EP3和EP4)。在本实施例中，当EP1自引导时，EP1可确定有在数据区对(DZ2、DZ3)中的待监控的1000个数据库和覆盖它们的四个事件处理器。通过按词典顺序对事件处理器标识符进行分类，EP1可确定它占用DB1到DB250，EP2可占用DB251到DB500，EP3可占用DB501到DB750，以及EP4可占用DB751到DB1000。EP1可重复相同的步骤以确定EP1负责监控它有资格监控的每个副本对的数据库。

为了探测事件处理器的故障，每个事件处理器可配置成周期性地例如每10秒钟将HEARTBEAT消息(例如，通过HTTP)发送到每个其它事件处理器。事件处理器也可维持事件处理器的列表和其状态(例如，AVAILABLE或DEAD)连同每个事件处理器的最后登记时间。当第一事件处理器在大于heartbeat_failover_time(其一般是心跳时间间隔的几倍，例如心跳时间间隔的六倍)的一段时间内没有接到另一事件处理器的消息时，第一事件处理器可宣布无响应的事件处理器为DEAD或在类似状态中，并可调节其监控工作负荷。当无响应的事件处理器主机启动或恢复时，事件处理器可本身在类似于heartbeat_failover_time的一段时间内在BOOTSTRAP或类似模式中启动，以从其对等事件处理器接收心跳并可启动其心跳代理。在这个时间之后，事件处理器可本身移动到OPERATIONAL模式，其中它基于被分配给其划分的事件处理器的状态来确定其监控工作负荷的当前片。在一段时间内将事件处理器留在BOOTSTRAP模式中的一个原因是确保加入事件处理器集体的新的事件处理器和剩余的事件处理器有足够的时间来聚集在活动中的事件处理器的当前状态上。

在数据区的故障的情况下，确保在出故障的数据区中的事件处理器所监控的实例由剩余的组接管是合乎需要的。在一个实施例中，四个事件处理器组(G1、G2、G3和G4)分别覆盖在四个数据区(DZ1、DZ2、DZ3和DZ4)中的事件处理器。如果DZ1停止运转，则由DZ1中的事件处理器监控的实例可自动由其它数据区中的事件处理器接管。

然而，可能在一个区域中可以只有三个数据区，三个事件处理器组(G1、G2和G3)监控数据区对(DZ2、DZ3)，(DZ3、DZ1)和(DZ1、DZ2)。在DZ1出故障的情况下，G2和G3需要被重新部署，使得每个组监控辅助副本在与本身相同的数据区中的实例，以便容忍包含主要副本的数据区的故障。在各种实施方案中，当数据区在三-DZ区域中出故障时，标志例如“辅助-dz-协同定位-覆盖”标志可被开启。如果这个标志被关掉，则组分割监控工作负荷，工作负荷具有事件处理器不能存在于与副本对相同的数据区中的约束。如果标志开启，则组可覆盖该约束并重新排列自身以选择辅助副本在与本身相同的数据区中的RDS实例。该标志可继续存在于控制面中的监控数据库或类似的数据存储器中。

确保只有一个事件处理器监控特定的RDS实例也可能是合乎需要的。在某些实施方案中，故障切换算法要求单个监控部件(即，事件处理器)在任何给定的时间监控副本对。这个约束可以被利用，因为在网络分区的任一侧上有两个事件处理器可能是不合乎需要的，一个事件处理器试图故障切换RDS实例，而另一事件处理器假设主要副本仍然是继续有效的，导致“分脑”情况。

为了确保只有单个事件处理器监控RDS实例，在一些实施方案中可能需要事件处理器明确地从RDS实例的主要副本获取租约。在其它实施方案中，监控部件可从控制环境的另一部件获取租约，该另一部件管理租约并在数据环境中与各种部件相互作用。只有当获取租约时，来自RDS实例的主要副本的租约才是有资格对给定的RDS实例并且只在租用期例如T_lease内发起故障切换的事件处理器。事件处理器在一个实施方案中可通过查验数据库副本(例如，通过发出HTTP状态ping())从RDS实例主要副本获取租约，由此数据库副本的主机管理器除了其通常的响应以外还可交出租约。在一些实施方案中，只有当副本是BLRM主要副本、主要副本和辅助副本同步时，且如果仍然有被提供给另一事件处理器的有效租约，租约才被交出。当主要副本将租约交给事件处理器时，主要副本可将租用时间和事件处理器标识符写到其BLRM驱动器。通过当它在同步中时写到BLRM磁盘，主要副本固有地向辅助副本通知租约。因此，只有在租用时间和事件处理器标识符被成功地写(即，在这两个副本中被复制)之后，主要副本才将新的租约交给事件处理器。此外，通过在这两个副本中写事件处理器标识符和租用时间，事件处理器租借方案能够幸免于主要副本的崩溃。在至少一些实施方案中，RDS实例的辅助副本从不在任何时间交出任何租约。辅助副本可接受promoteToPrimary()或类似的请求，只有当该请求来自标识符与在其BLRM驱动器中的标识符相同的事件处理器时。

当事件处理器再引导且新的主机接管时，事件处理器假设RDS实例的状态(它以前没有监控)为P_ONLY-主要副本在DEGRADED模式中的状态。事件处理器查验主要副本和辅助副本，以确定数据库的当前状态并相应地改变其状态。如早些时候提到的，如果主要副本被假设在DEGRADED状态中，则事件处理器不发起任何故障切换。通过采取“悲观”方法，当新的事件处理器接管时，将存在较少的错误。当事件处理器再引导或新的事件处理器接管时，事件处理器查验与给定主机相关的两个副本以确定哪个副本是当前的BLRM主要副本。一旦这个信息被收集，事件处理器就可检查适当的pDNS API以确保DNS_主要别名记录指向当前的主要副本。如果否，事件处理器可立刻进行故障切换。这种情况可发生在事件处理器在故障切换的中间停止运转时。因为DNS信息可能由于DNS缓存和其它效应而是不正确的，所以pDNS API可被查询，而不解决DNS名称，因为pDNSAPI读权威数据库。然而，在主要副本和辅助副本都认为它们是正确的主要副本的不可能的情况下，操作员或负责的技术员可被寻呼，等等。

在控制面中的监控数据库可存储待监控的当前有效的数据库实例的列表、每个实例(例如，已复制的)的类型、以及事件处理器对不同的客户相关的事件收集的任何事件。当数据库的数量增加时，在一些实施方案中可能必须在单个监控数据库之外按比例调整。为此目的，在监控数据库中的所有表可被划分。为了实现监控DB划分，“db划分地图”可连同事件处理器一起被使用。当事件处理器必须使与数据库实例有关的事件持久时，事件处理器可与“db划分地图”商议以确定将事件的信息写到的适当数据库。

图9示出用于根据一个实施方案监控在存储桶中的事件处理器的健康状态并处理事件处理器之一的故障的示例性过程900。在本实施例中，对数据面确定至少一个工作负荷分区(902)。至少部分地根据数据存储器、实例、主机管理器和待监控的其它这样的部件的数量，总工作负荷可被划分成多个单独的分区中的任一个。可将一组事件处理器分配给每个工作负荷分区(904)，且可对所分配的分区给在该组中的每个事件处理器分派工作的一个相应的部分(906)。以适当的时间间隔，每个事件处理器将“心跳”消息(例如，通过HTTP)发送到在覆盖同一工作负荷分区的同一组或存储桶中的事件处理器(908)。心跳可按任何适当的时间间隔例如每10秒钟被发送。在一个实施方案中，“心跳”指简单的多播消息，其被发送到存储桶中的每个事件处理器以向其它事件处理器通知发送心跳的事件处理器的状态。事件处理器可维持事件处理器的列表及其状态(例如，“可用”或“无效”)连用每个事件处理器的最后登记时间。如果确定心跳从存储桶中的每个事件处理器接收到(910)，该过程可继续。

然而，如果确定在同一存储桶中的事件处理器不与心跳响应，则进行关于事件处理器是否未能在等于或大于规定的心跳故障时间的一段时间(例如，是心跳时间间隔的六倍)内发送心跳的确定(912)。如果规定的心跳故障时间没有达到，则该过程可继续。如果心跳故障时间至少在没有来自事件处理器的心跳的情况下达到，则在存储桶中的每个在活动中的事件处理器可宣布无响应事件处理器为“无效的”或在类似状态中，并可重新分配责任范围并接管监控工作负荷的一部分(914)。因为存储桶中的每个在活动中的事件处理器未能从有故障的事件处理器接收到心跳消息，所以事件处理器可每个将所分配的工作负荷扩展适当的量以继续“缺少的”事件处理器的工作。

如果有四个事件处理器和60,000个实例被监控，如图10的实施例1000中所示的，则每个事件处理器处理15,000个实例(其可按标识符的词典顺序或另一适当的顺序排序，等等)。如果事件处理器之一出故障，则其它三个事件处理器可重新分配其各自的责任范围，使得每个事件处理器现在处理所述实例中的20,000个(仍然根据标识符被连续地排序，等等)。因此，因为实例使用排序方案来排序，所以每个事件处理器可调节待监控的排序方案的范围，且不必映射或以其它方式跟踪哪些“新的”实例要监控。被监控的范围可存储在例如监控数据存储器中。这样的方法在实例被添加或移除的情况下也是有益的，因为工作负荷可自动(实质上)均匀地分布在事件处理器中。仅在特定的存储桶内的心跳也可能比全局心跳机制维持起来更有效和容易。

图11示出用于在事件处理器被添加到存储桶时将工作范围重新分配在存储桶中的示例性过程1100，例如可以是添加额外的处理能力的结果或有故障的事件处理恢复并再次能够处理工作负荷的一部分的结果。事件处理器可例如通过事件处理器主机重新启动或恢复或主机仅仅被启动或添加到存储桶而变成活动的(1102)。事件处理器也可被添加到存储桶(1104)，虽然在恢复的情况下，事件处理器可能已经被分配给该存储桶。当在活动中的事件处理器被添加到存储桶时，事件管理器可在一段时间(例如，心跳故障时间)内进入诸如“自引导”模式的模式中以从存储桶中的对等事件处理器接收心跳(1106)，以获得关于存储桶中活动的其它事件处理器的信息并确定例如用于发送心跳的时间。事件处理器可参与心跳代理以也开始将心跳发送到存储桶中的其它事件处理器(1108)。在这个时间之后，主机可将自身移动到“操作”模式，其中每个事件处理器可重新分配工作范围并基于分配给其划分的事件处理器的状态来确定其监控工作负荷的当前片1110。在一段时间内在“自引导”模式中离开事件处理器的一个原因是确保加入(或重新加入)事件处理器集体的新的事件处理器，以及剩余的事件处理器有足够的时间来聚集在活动中的事件处理器的当前状态上。

根据一个实施方案的方法也例如通过以50-60％的容量运行每个事件处理器来过度划分事件处理器。这样的方法使至少一个或两个事件处理器能够在每个存储桶中出故障，而没有对性能的明显消极的影响。出故障的事件处理器将最终再次变得可用，例如其中相应的主机自引导。该事件处理器接着可再次开始交换心跳，由此在存储桶中的其它事件处理器可自动探测事件处理器的存在。所分配的工作可如上所述自动重新分布，使得工作相对均匀地分布在存储桶中的较大的一组可用事件处理器中。

除了上面讨论的故障情况以外，还可能有可根据各种实施方案处理的各种其它故障模式。例如，主要副本实例可再引导，使得当主要副本的主机管理器回来在线时，它首先将发现BLRM状态从“主要/辅助”改变到“辅助/辅助”，因为主要副本回来在线作为辅助副本，如果监控部件没有已经故障切换到辅助副本。接着可能归事件处理器(例如，监控部件)负责来确定在这两个副本当中谁将是主要副本，并进行适当的promoteToPrimary()调用。如果辅助副本实例再引导，监控部件将通知辅助副本出故障并可标记该实例用于恢复。然而，同时，如果辅助副本回来在线(在再引导之后)，辅助副本恢复工作流可通知此并请求辅助副本的主机管理器试图重新连接。这可避免对简单的实例再引导情况创建新的辅助副本的费用。如果未复制的实例再引导，则主机管理器可自动将其状态从辅助副本转换到主要副本，而不需要监控部件提升实例。这可减小用于未复制实例的实例再引导的恢复时间。

当主要副本出故障且不回来在线时，监控部件可探测主要副本故障并将辅助副本提升到新的主要副本。随后，监控部件可将管理数据存储器中的RDS实例状态标记为处于诸如“PENDING/DEGRADED_NEED_SECONDARY_RECOVERY”的状态中。这个状态可使恢复清理器反弹以启动适当的恢复工作流。恢复工作流可试图确定这两个副本是否是继续有效的。如果旧的主要副本回来在线作为辅助副本，例如其中再引导花费足够量的时间使得监控部件将副本标记为无效的，则工作流可将旧的主要副本连接到新的主要副本，并且一旦副本被完全同步就例如以OK的数据库状态标记已完成的恢复。然而，如果旧的主要副本根本没有回来，工作流可终止旧的实例，并使用关于创建已复制实例描述的相同步骤来摆脱辅助副本。如果辅助副本出故障，那么监控部件可探测故障并将管理数据存储器中的实例状态标记为处于恢复工作流开始生效的状态中，例如通过使用“PENDING/DEGRADED_NEED_SECONDARY_RECOVERY”或类似的状态。当数据库由于某种原因崩溃时，主要副本的主机管理器可充当保姆过程并自动重新启动数据库。

如所讨论的，监控工作负荷的每个分区可由一组事件处理器覆盖。在事件处理器之一出故障或经历各种其它这样的问题中的任一个的情况下，使用一组事件处理器覆盖工作负荷的单个分区实现监控负荷在剩余的事件处理器中的重新分布。在一个实施方案中，每组事件处理器包含在存储桶或其它这样的分区中。存储桶中的每个事件处理器负责处理在单个数据面中的实例的范围或在该平面中的实例的分组。故障探测过程可用于确保故障是否出现，在该存储桶中的其它事件处理器接管由出故障的事件处理器处理的实例的责任。在至少一个实施方案中，监控数据存储器保存由存储桶中的这组事件处理器监控的当前在活动中的数据实例的列表，以及事件处理器对各种客户相关的事件收集的信息。当所监控的实例的数量增加时，可能必须在单个监控数据存储器之外按比例调节。因此，在监控数据存储器中的每个表可被划分，包括db_轮询_列表。

在一个实施方案中，事件处理器部署有下面示例性格式的分区表：

划分Id	散列范围
		P0	0-10000
P1	10000-20000

这个分区配置可用作对事件处理器主机的配置文件。

如果给定的工作负荷分区产生将负责的这组事件处理器保持在恒定的追上模式(即，不能在某个时间段内完成所指定的健康状态检查)的相当数量的事件，额外的事件处理器可被添加到负责该工作划分的这组而不必重新划分数据存储器。使用这样的技术，可将性能可量测性与数据可量测性问题区分开。例如，可将产生事件处理器不能追上的那么多事件的单次划分与单次划分产生单个数据存储器不提供足够的存储空间的单个数据存储器的那么多事件的情况区分开。

事件处理器的成员资格和事件处理器被分配到的分区可存储在诸如事件处理器成员资格配置文件的位置上。成员资格配置信息可用于一组(例如，在同一分区或存储桶中)中的事件处理器，并可具有下面的示例性格式：

<EP标识符><EP主机名称><端点_端口><划分Id>

当单次划分被多个事件处理器覆盖时，每个事件处理器通过对事件处理器标识符分类例如通过使用按词典顺序或基于散列的分类例程并统一地划分存储桶范围来划分存储桶范围。每个事件处理器可独立地确定待监控的适当范围。

在这样的系统中，确保待监控的数据存储器和/或实例的列表或组自动被填充并随着时间更新也可能很重要的。一种方法是创建例如数据库列表的表，该表是可按需要被传播的实例的快照副本。然而这样的方法可能难以维持，并确保每个适当的部件具有最近的拷贝。另一方法是使事件处理器查询数据面部件，并接着将信息在本地存储在控制面中。这样的方法可创建很多消息发送业务，并可能难以维持和更新。根据一个实施方案的方法相反使每个事件处理器能够暴露接口，例如“setStatus”或类似的API。作为例如“创建”或“删除”工作流的部分，任务可被添加到指示适当的主机管理器调用事件处理器的工作流的末尾，该事件处理器负责或曾经负责管理实例。主机管理器可因此调用事件处理器的“setStatus”API以在存在状态的变化作为工作流的结果(或其它这样的行动)的任何时间设置主机的状态。每当事件处理器通过“setStatus”API接收到调用时，信息可被放置在本地数据存储器中以将新的主机添加到其分区组，移除主机，等等。主机的信息也可被写到监控数据存储器或另一适当的持久性位置。

在一个实施方案中，当前在活动中的数据实例的权威性列表存在于管理数据存储器中。待监控的数据实例的活动列表存在于表例如“db_轮询_列表”表中的监控数据存储器中。为了添加、移除或更新在监控数据存储器中的实例的状态，事件处理器暴露“updateHost”API，其接受参数例如数据存储器标识符、数据实例相关的参数(例如，实例标识符和DNS地址)以及实例状态(例如，“添加”、“移除”或“更新)。当事件处理器接收到这个调用时，事件处理器对db_轮询_列表表进行适当的变化(例如，添加、移除或更新输入项)。例如，如果客户提交请求以创建具有数据存储器id“id1”的数据存储器，则用于创建数据存储器的工作流将在供应必要的资源并配置数据存储器时在管理数据存储器中将id1的状态标记为“可用的”。作为在创建数据库工作流任务中的最后的步骤，updateHost API可例如通过经由内部虚拟IP到达来在事件处理器之一处被调用，以将数据存储器(以及其实例)添加到监控工作流。通过在供应工作流中进行更新监控状态的最后(或至少接近最后)步骤，RDS数据存储器的创建、删除或修改的可用性从监控数据存储器的可用性去耦。

一旦主机管理器设置了待监控的活动中的实例的状态，负责的事件处理器就可周期性地查验实例的主机管理器，如在本文其它地方讨论的。如果实例是不可用的，例如可能由于主机管理器崩溃或再引导，则事件处理器将不得到对实例的响应，并将潜在问题的信息写到管理数据存储器。清理器将探测该信息，并将使适当的恢复工作流产生并被执行。在一个实施方案中，恢复工作流首先检查数据存储器或数据实例的度量的历史，例如详述实例的I/O错误的历史的信息。工作流接着试图自动确定实例是否出故障，例如其中存在连接错误，或是否没有连接问题而有增加数量的I/O错误，以支持实例的特定容积指示潜在问题。工作流的任务可试图自动确定和/或隔离问题，其中存在可能对很多不同的部件出现的很多不同的问题。这样的确定以及从这样的问题的恢复不是平凡的问题。

然而，可能存在从故障自动恢复可能不是合乎需要的情况。例如，整个数据中心可能出故障，其中数千数据存储器变得不可用。试图实质上同时恢复所有这些数据存储器可能是不合乎需要的。在一个实施方案中，清理器(或控制面的另一部件)可配置有最大数量的错误或并行地执行特定类型的工作流。如果工作量的数量超过例如指定的数量或阈值，可对操作员或DBA发送或以其它方式产生消息或其它这样的通知，由此有经验的用户可确定解决这种情况的最佳方法。在一个实施方案中，清理器将在任何给定的时间运行至多相同类型的指定数量的工作流，例如给定类型的10个工作流，但将不产生警报，直到相同类型的第二数量例如25个工作流被请求。根据一个实施方案的系统提供操作服务仪表板，其中DBA或其它经授权的操作员可评估监控过程的状态，并可人工执行恢复行动。使用这样的接口，DBA可如本文讨论的选择使启动工作流能够执行特定的恢复行动的选项。接口可以与控制面一起使用来与多个相异的数据库引擎和系统一起工作，即使控制面不在数据面的数据路径中。控制面可监控例如每个引擎的错误消息和日志。这样的方法也可允许每个数据存储器作为整体被监控，同时监控数据存储器的任何副本。接着可基于副本的状态等来执行不同的恢复。

应认识到，可能有可导致数据存储器或数据实例的不可用性或不可靠性的多种类型的故障。例如，主机设备可能出故障或再引导，或可能有主机管理器应用管理实例的问题。也可能有数据存储器的问题，例如核心转储或分段违规(SegV)例外。也可能有I/O操作或通信链路的问题，或托管数据存储器的实例的故障。也可能由各种其它类型的故障，例如逻辑卷的故障、网络运转中断或数据区故障。不同的工作流可用于试图确定不同的故障类型并从不同的故障类型恢复。在一个实施例中，主机管理器在一个实施方案中是对相应的数据实例的网关，且这个主机管理器的故障本质上允许没有对该实例的控制。为了处理故障例如在存储器之外运行的Tomcat过程，控制面的监控部件可在必要时确保Tomcat重新启动。监控系统可协调重新启动以避免不必要的错误或错误探测。

此外，如所讨论的，仅仅探测故障并从故障恢复是不够的，因为必须考虑其它因素，例如故障的尺寸或规模。例如，对托管数据存储器的单个云实例的故障的恢复行动可实质上不同于处理整个数据区的故障的恢复行动。对于较大的问题，多个故障可能需要被关联并分析，使得恢复行动不通过试图同时单独地恢复各种实例来混合现有的问题。在一些情况下，执行分段恢复可能是合乎需要的，其中不仅并行过程的数量是有限的，而且过程的排序可被控制，使得没有数据被丢失且没有恢复行动被采取，这些恢复行动由于随后的恢复行动而需要稍后被校正。在一些情况下尽可能多地局部化恢复过程可能也是合乎需要的。在至少一些实施方案中，当可能时以安全的方式局部地处理故障可能是有益的。例如，对简单故障例如主机管理器或数据过程的故障的局部恢复行动对于总RDS系统的管理堆栈所执行的行动可能是优先的。

也可能有数据实例、数据存储器或I/O过程出故障的各种原因，其中每个原因可能需要不同的恢复行动。例如，数据存储器错误可使数据存储器出故障，或至少产生相当数量的读/写错误。数据存储器或实例也可能由于过载、坏的块或其它这样的情况而出故障。也可能有用户引起的错误，例如导致数据存储器崩溃的不正确的查询。在其它情况下，数据存储器日志卷可被填充或破坏。为了处理这些和其它类型的故障，数据过程可不变地由主机管理器监控。如所讨论的，每个主机管理器可具有状态监控部件，其例如通过运行获得状态命令(例如，对于MySQL，这可采取/仓/mysql_admin状态的形式)来检查数据存储器或实例的状态。状态监控部件可周期性地检查状态，且如果实例是不可用的，则实例可被重新启动或以其它方式被处理。如果实例重复地变得不可用，或经历其它这样的错误，则状态监控部件可停止试图校正错误，并使信息被写到控制面中的监控或管理数据存储器。

为了探测数据存储器错误和I/O崩溃，可在一些实施方案中监控数据存储器错误日志和/或内核日志。每个主机管理器可运行另一模块，其连续地扫描这两个(或其它)错误日志中的某些错误类型，并产生有关的度量。对于每种错误类型，可设定预定的阈值，在该阈值之外错误将被发送到操作员用于分析和可能的恢复。

根据一个实施方案的故障探测机制具有多个被施加的约束。例如，可配置监控部件线性地按比例调节，使得当数据实例的数量超过主机的数量时，事件处理器的存储桶被设置为轮询，例如额外的监控部件可简单地按需要被添加。此外，可确定，将例如通过划分数据实例并将每个划分的监控所有权分配给事件处理器之一来不变地监控所有数据实例。如所讨论的，如果事件处理器由于任何原因而出故障，出故障的事件处理器所拥有并监控的划分可均匀地重新分布到其它可用的事件处理器，例如在同一存储桶中的处理器。此外，当RDS客户创建并删除数据存储器和/或实例时，数据库实例的列表可通过将任何添加到工作流来保持最新。

数据存储器划分

如在可高度按比例调整的分布式系统中公知的，在数据存储器内的分区只被按比例调整到数据存储器系统存在于的物理系统的限制。由于这个限制，预先构造系统使得系统可在单个数据存储内以及在很多数据存储系统中按比例调整。在不同的数据存储系统中的数据的水平划分可有助于可高度按比例调整的系统，其可处理对事件存储的重要的要求。

根据一个实施方案的系统利用客户_id作为分区密钥来划分数据表，包括数据实例的列表(db_轮询_列表)、有关的事件(db_事件表)或安全组事件表。在数据存储器标识符上使用客户标识符可能是有利的，因为一些事件不限于单个数据存储器并可甚至不涉及特定的数据存储器。例如，在安全组中的变化不直接应用于任何数据存储器，而可能需要被存储为客户可见的事件(即，使用DescribeEvents API可重新获得)。此外，单个客户的事件可能不发展而超过单个数据存储器的存储空间，因为在一些实施方案中，事件数据仅保留有限的一段时间，例如14天。

存在通过使用存储桶分区来处理在水平数据存储器分区中的数据集的分区的很多方式。存储桶划分提供在被划分的数据和数据被存储的分区之间的抽象层。这个抽象层允许分区的更容易的操作管理，例如数据随着时间的过去而迁移的新分区的添加，同时仍然允许应用使用用于确定被划分的数据的放置的散列机制。如本文所述的存储桶划分系统的实现包括某些实施方案特有的部件，但总的概念可应用于很多不同的使用情况，如应明显的。

为了实现存储桶划分，可确定应用可以采用的固定数量的存储桶。存储桶的数量可在应用的寿命内保持固定，使得选择大的足够数量在某些实施方案中可能很重要。存储桶的数量可反映将负荷均匀地分布在所有存储桶中的能力，这些存储桶可被单独的分配到较少数量的物理划分。如果有被分配给同一存储桶的太多单独的实例，则将多个存储桶有效地存储在单个划分中可能变得成问题。固定数量的存储桶可充当在待划分的数据和分区本身之间的中间层。在分层中的第一步骤是弄清楚不同的数据片如何映射到各种存储桶。如上所述，数据的分区密钥可以是客户标识符。有效和一致的散列算法可用于提供可被直接分配给单独的存储桶的值。每当客户标识符散列成分配给存储桶的值时，该标识符在数据的寿命中在存储桶中可以是有效的。

在本实施例中，存储桶被分配给单独的工作负荷分区。可能总是有比分区更多的存储桶，所以映射可用于将很多不同的存储桶分配给单独的分区。为了使分配配置简洁，存储桶数量的范围可用于将存储桶分配给单独的分区。下面的实例是示出划分分配可如何工作的例子：

分区1＝{1-25000}

分区2＝{25001-50000}

在本实施例中，从1到25,000的存储桶号被分配给“分区1”，而从25,001到50,000的存储桶号被分配给“分区2”。每个数据需要被添加到系统且客户标识符的散列将工作流映射到存储桶100时，例如与该客户(包括数据存储器和安全组)有关的任何数据可插入在“分区1”中物理地有效的表中。这样的方法也可用于读取关于客户的数据库或安全组的任何信息，其中对给定客户的事件的请求将从“分区1”读取，该客户的标识符散列到存储桶100。

上面的实施例处理相对简单的情况，存储桶到分区的初始分配未改变。然而，有时新的分区需要添加到系统以减轻对其它分区的负担。使用上面的这个实施例，新的划分“分区3”可被添加以从其它两个分区拿掉负荷：

分区1＝{1-16666}

分区2＝{33333-50000}

分区3＝{16667-33333}

如可看到的，8334个存储桶(16667到25000的号码)从“分区1”取下并重新分配给“分区3”。此外，8333个额外的存储桶(25001到33333的号码)从“分区2”取下并重新分配给“分区3”。这个重新分配可基于最忙或最慢的存储桶，但在本实施例中存在存储桶在分区中的相对均匀的重新分布。

当存储桶分配改变时，存在于物理分区中的数据可能被影响。在上面的实施例中，存储桶100用于存储客户的信息，客户的标识符被散列到100。然而在存储桶11000中可能有数据，且在重新划分之前写的任何数据在“分区1”中是有效的，但在重新划分之后写的任何数据将存储于“分区3”中。为了使用存在于一个分区中的以前数据和存在于另一分区中的当前数据解决这个问题，系统可允许多于一个的分区被分配给存储桶。给定的存储桶可具有至少两个分区：当前分区和以前的分区。在本实施例中，重新划分将导致具有两个被分配的分区的存储桶10001到15000，“分区3”作为当前分区，而“分区1”作为以前的分区。如所提到的，存储桶11000的任何新的数据将在当前分区中，而在重新划分之前写的任何数据将在以前的分区中。当对事件的查询或任何信息映射到存储桶11000时，检查该数据的当前分区以及检查以前的分区可能很重要，因为记录也可存在于那里。对在存储桶中的多个分区查找的主要的支持可引起遗漏那些实例的潜在成本，那些实例将在给定存储桶的以前分区中结束。然而，因为任何最新创建的事件被写到当前的分区，将只对当重新划分发生时运行的工作流实例或关闭的工作流引起遗漏的成本。协助最新创建的事件可提高性能，同时仍然允许有效地完成重新划分的灵活性。

如上所讨论的，可在各种操作环境中实现各种实施方案，操作环境在一些情况下可包括一个或多个用户计算机、计算设备或可用于操作多个应用中的任一个的处理设备。用户或客户端设备可包括多个通用个人计算机例如运行标准操作系统的桌上型或膝上型计算机以及蜂窝无线和手持设备中的任一个，手持设备运行移动软件并能够支持很多联网和消息发送协议。这样的系统也可包括运行各种市场上可买到的操作系统和其它已知应用的任一个的多个工作站，用于诸如发展和数据库管理的目的。这些设备还可包括其它电子设备，例如哑终端、瘦客户端、游戏系统和能够经由网络通信的其它设备。

各种方面也可被实现为至少一种服务或Web服务的部分，例如可以是面对服务的结构的部分。服务例如Web服务可使用任何适当类型的消息发送例如通过使用以可扩展标记语言(XML)格式并使用适当的协议例如SOAP(从“简单对象访问协议”得到)交换的消息来进行通信。由这样的服务提供或执行的过程可用任何适当的语言例如Web服务描述语言(WSDL)来编写。使用语言例如WSDL允许功能，例如在各种SOAP框架中的客户端侧代码的自动产生。

大多数实施方案利用本领域技术人员熟悉的用于使用多种市场上可买到的协议例如TCP/IP、OSI、FTP、UpnP、CIFS和AppleTalk中的任一个支持通信的至少一个网络。网络可以是例如局域网、广域网、虚拟专用网络、互联网、内联网、外联网、公共交换电话网络、红外网络、无线网络和其任何组合。

在利用Web服务器的实施方案中，Web服务器可运行多种服务器或中间层应用中的任一个，包括HTTP服务器、FTP服务器、CGI服务器、数据服务器、Java服务器和商业应用服务器。服务器也可以能够例如通过执行一个或多个Web应用来执行在来自用户设备的响应请求中的程序或脚本，这些Web应用可被实现为以任何编程语言例如Java

C、C#或C++或任何脚本语言例如Perl、Python或TCL以及其组合编写的一个或多个脚本或程序。服务器也可包括数据库服务器，没有限制地包括可从Oracle

MicrosoftSybase

和IBM

商业地得到的那些服务器。

环境可包括如上所述的各种数据存储器和其它存储器或存储介质。这些可存在于多种位置上，例如在(和/或存在于)一个或多个计算机本地的或远离在网络中的任何或所有计算机的存储介质上。在特定的一组实施方案中，信息可存在于本领域技术人员熟悉的存储区域网络(“SAN”)中。类似地，用于执行属于计算机、服务器或其它网络设备的功能的任何必要的文件可在适当时在本地和/或远程地存储。在系统包括计算机化设备的场合，每个这样的设备可包括可经由总线电耦合的硬件元件，元件包括例如至少一个中央处理单元(CPU)、至少一个输入设备(例如，鼠标、键盘、控制器、触摸屏或小键盘)和至少一个输出设备(例如显示设备、打印机或扬声器)。这样的系统也可包括一个或多个存储设备，例如磁盘驱动器、光学存储设备和固态存储设备例如随机存取存储器(“RAM”)或只读存储器(“ROM”)以及可移动介质设备、存储卡、闪存卡等。

这样的设备也可包括如上所述的计算机可读存储介质阅读器、通信设备(例如调制解调器、网卡(无线或有线)、红外通信设备等)和工作存储器。计算机可读存储介质阅读器可连接于或配置成接收计算机可读存储介质，其代表远程、本地、固定和/或可移动存储设备以及用于暂时和/或更永久地包含、存储、传输并检索计算机可读信息的存储介质。系统和各种设备一般还包括很多软件应用、模块、服务或位于至少一个工作存储设备内的其它元件，包括操作系统和应用程序例如客户端应用或Web浏览器。应认识到，从上面的描述中，可选的实施方案可具有很多变化。例如，定制的硬件也可被使用和/或特定的元件可在硬件、软件(包括便携式软件例如小应用程序)或两者中实现。此外，到其它计算设备例如网络输入/输出设备的连接可被使用。

用于包含代码或代码的部分的存储介质和计算机可读介质可包括在本领域中已知或使用的任何适当的介质，包括存储介质和通信介质，例如但不限于在用于存储和/或传输信息例如计算机可读指令、数据结构、程序模块或其它数据的任何方法或技术中实现的易失性和非易失性、移动和不可移动介质，包括RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字通用盘(DVD)或其它光学存储器、盒式磁带、磁带、磁盘存储器或其它磁性存储设备或可用于存储期望信息并可由系统设备访问的任何其它介质。基于本文提供的公开和教导，本领域普通技术人员将认识到实现各种实施方案的其它方式和/或方法。

说明书和附图因此在例证性而不是描述性的意义上看待。然而，将明显，可对其进行各种修改和改变，而不偏离如权利要求中阐述的发明的较宽的精神和范围。

条款1.一种管理来自控制环境的关系数据库实例的已复制实例的恢复的计算机实现的方法，包括：

在配置有可执行指令的一个或多个计算机系统的控制下，

使用单独的控制环境的监控部件周期性地与数据库环境中的主要实例副本和辅助实例副本进行通信，由至少一个监控部件接收的每个响应包括第一实例副本和第二实例副本中的相应一个的状态信息和数据生成信息，对于单次数据生成，对主要实例副本的数据更新被同步地复制到辅助实例副本；

响应于至少一个监控部件不能与第一实例副本和第二实例副本中的一个通信，确定第一实例副本和第二实例副本是否能够彼此通信以及第一实例副本和第二实例副本是否具有公共的数据生成信息；

当监控部件在最小的时间段内不能与主要副本通信、辅助实例副本不能与主要副本通信、且第二实例副本具有与主要副本的最后已知状态相同的数据生成信息时，使辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本；

当监控部件在最小的时间段内不能与辅助副本通信且主要实例副本不能与辅助副本通信时，使产生关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行；以及

当监控部件在最小的时间段内不能与主要副本和辅助副本中的任一个通信、主要实例副本和辅助实例副本能够彼此通信、且主要实例副本和辅助实例副本具有相同的数据生成信息时，对主要实例副本和辅助实例副本不执行故障切换或恢复操作。

条款2.条款1的计算机实现的方法，还包括：

当监控部件在最小的时间段内不能与主要副本通信、辅助实例副本不能与主要副本通信、且辅助实例副本具有与主要副本的最后已知状态不同的数据生成信息时，使时间点恢复操作对主要实例副本执行。

条款3.条款1的计算机实现的方法，还包括：

当监控部件在最小的时间段内不能与主要副本通信且辅助实例副本不能与主要副本通信时，使主要实例副本本身终止。

条款4.条款1的计算机实现的方法，其中给用户提供使用户能够与当前主要实例副本通信的别名，包括当故障切换操作使辅助实例副本变成新的当前主要实例副本时。

条款5.一种使用单独的控制环境管理数据库环境中的已复制数据库实例的计算机实现的方法，包括：

在配置有可执行指令的一个或多个计算机系统的控制下，

使用单独的控制环境的监控部件监控在数据库环境中的主要实例副本和辅助实例副本中的每个的状态信息；以及

响应于监控部件不能与第一实例副本和第二实例副本中的一个通信：

确定故障信息，包括第一实例副本和第二实例副本是否能够彼此通信以及第一实例副本和第二实例副本是否具有公共数据生成标识符；

至少部分地基于故障信息，确定将在控制环境中执行的工作流，工作流包括响应于监控部件不能与第一实例副本和第二实例副本中的一个通信而在数据库环境中执行的一个或多个任务；以及

在控制环境中执行工作流。

条款6.条款5的计算机实现的方法，其中工作流包括当监控部件在最小的时间段内不能与主要副本通信、辅助实例副本不能与主要副本通信、且第二实例副本具有与主要副本的最后已知状态的公共数据生成标识符时使辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本的任务。

条款7.条款6的计算机实现的方法，其中执行故障切换操作还包括安装文件系统并对新的主要副本启动数据库。

条款8.条款5的计算机实现的方法，其中工作流包括当监控部件在最小的时间段内不能与辅助副本通信且主要实例副本不能与辅助副本通信时使产生关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行的任务。

条款9.条款5的计算机实现的方法，其中工作流包括当监控部件在最小的时间段内不能与主要副本和辅助副本中的任一个通信、主要实例副本和辅助实例副本能够彼此通信、且主要实例副本和辅助实例副本具有公共数据生成标识符时在控制环境中将信息存储到数据存储器而不执行故障切换或恢复操作的任务。

条款10.条款5的计算机实现的方法，其中在单个数据区中、在分开的地理位置处的分开的数据区中、在越过多个地理位置的单个数据区中或越过在单个地理区域中的多个数据区供应第一实例副本和第二实例副本。

条款11.条款10的计算机实现的方法，其中至少一个监控部件位于第三数据区或地理位置中，或在第一数据区或第二数据区或地理位置中。

条款12.条款5的计算机实现的方法，其中给用户提供使用户能够与当前主要实例副本通信的别名，包括当故障切换操作使辅助实例副本变成新的当前主要实例副本时。

条款13.条款5的计算机实现的方法，还包括：

在控制环境中存储第一实例副本和第二实例副本的状态信息和数据生成标识符。

条款14.条款5的计算机实现的方法，其中第一实例副本和第二实例副本中的每个在数据库环境中的分开的数据实例上运行，每个数据实例连接到一个或多个专用块存储卷。

条款15.条款14的计算机实现的方法，还包括：

使用块级复制机制同步地将数据从主要实例副本复制到辅助实例副本，块级复制机制可操作来在第一实例副本和第二实例副本的一个或多个专用块存储卷之间同步地复制数据。

条款16.条款5的计算机实现的方法，其中主要实例副本为客户执行关系数据库。

条款17.一种使用单独的控制环境管理数据库环境中的已复制数据库实例的计算机实现的系统，包括：

处理器；以及

包括指令的存储设备，当所述指令由处理器执行时使处理器：

使用单独的控制环境的至少一个监控部件监控数据库环境中的主要实例副本和辅助实例副本中的每个的状态信息；以及

响应于至少一个监控部件不能与第一实例副本和第二实例副本中的一个通信：

在控制环境中执行工作流。

条款18.条款17的系统，其中工作流包括当监控部件在最小的时间段内不能与主要副本通信、辅助实例副本不能与主要副本通信、且辅助实例副本具有与主要副本的最后已知状态的公共数据生成标识符时使辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本的任务。

条款19.条款17的系统，其中工作流包括当监控部件在最小的时间段内不能与辅助副本通信且主要实例副本不能与辅助副本通信时使产生关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行的任务。

条款20.条款17的系统，其中工作流包括当监控部件在最小的时间段内不能与主要副本和辅助副本中的任一个通信、主要实例副本和辅助实例副本能够彼此通信、且主要实例副本和辅助实例副本具有公共数据生成标识符时在控制环境中将信息存储到数据存储器而不执行故障切换或恢复操作的任务。

条款21.条款17的系统，其中在单个数据区中、在分开的地理位置处的分开的数据区中、在越过多个地理位置的单个数据区中或越过在单个地理区域中的多个数据区供应第一实例副本和第二实例副本。

条款22.条款17的系统，其中给用户提供使用户能够与当前主要实例副本通信的别名，包括当故障切换操作使辅助实例副本变成新的当前主要实例副本时。

条款23.一种存储指令的计算机可读存储介质，所述指令用于使用单独的控制环境管理数据库环境中的已复制数据库实例，所述指令在被执行时使处理器：

在控制环境中执行工作流。

条款24.条款23的计算机可读存储介质，其中工作流包括当监控部件在最小的时间段内不能与主要副本通信、辅助实例副本不能与主要副本通信、且辅助实例副本具有与主要副本的最后已知状态的公共数据生成标识符时使辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本的任务。

条款25.条款23的计算机可读存储介质，其中工作流包括当监控部件在最小的时间段内不能与辅助副本通信且主要实例副本不能与辅助副本通信时使产生关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行的任务。

条款26.条款23的计算机可读存储介质，其中工作流包括当监控部件在最小的时间段内不能与主要副本和辅助副本中的任一个通信、主要实例副本和辅助实例副本能够彼此通信、且主要实例副本和辅助实例副本具有公共数据生成标识符时在控制环境中将信息存储到数据存储器而不执行故障切换或恢复操作的任务。

条款27.条款23的计算机可读存储介质，其中在单个数据区中、在分开的地理位置处的分开的数据区中、在越过多个地理位置的单个数据区中或越过在单个地理区域中的多个数据区供应第一实例副本和第二实例副本。

Claims

1.一种使用单独的控制环境管理数据库环境中的已复制数据库实例的计算机实现的方法，包括：

在配置有可执行指令的一个或多个计算机系统的控制下，

响应于所述监控部件不能与第一实例副本和第二实例副本中的一个通信：

确定故障信息，包括所述第一实例副本和第二实例副本是否能够彼此通信以及所述第一实例副本和第二实例副本是否具有公共数据生成标识符；

至少部分地基于所述故障信息，确定将在所述控制环境中执行的工作流，所述工作流包括响应于所述监控部件不能与所述第一实例副本和第二实例副本中的一个通信而在所述数据库环境中执行的一个或多个任务；以及

在所述控制环境中执行所述工作流。

2.如权利要求1所述的计算机实现的方法，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述主要副本通信、所述辅助实例副本不能与所述主要副本通信、且所述第二实例副本具有与所述主要副本的最后已知状态的公共数据生成标识符时使所述辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本的任务。

3.如权利要求1所述的计算机实现的方法，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述辅助副本通信且所述主要实例副本不能与所述辅助副本通信时使产生所述关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行的任务。

4.如权利要求1所述的计算机实现的方法，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述主要副本和辅助副本中的任一个通信、所述主要实例副本和辅助实例副本能够彼此通信、且所述主要实例副本和辅助实例副本具有公共数据生成标识符时在所述控制环境中将信息存储到数据存储器而不执行故障切换或恢复操作的任务。

5.如权利要求1所述的计算机实现的方法，其中在单个数据区中、在分开的地理位置处的分开的数据区中、在越过多个地理位置的单个数据区中或越过在单个地理区域中的多个数据区供应所述第一实例副本和第二实例副本。

6.如权利要求5所述的计算机实现的方法，其中所述至少一个监控部件位于第三数据区或地理位置中，或在第一数据区或第二数据区或地理位置中。

7.如权利要求1所述的计算机实现的方法，其中给用户提供使所述用户能够与当前主要实例副本通信的别名，包括当故障切换操作使所述辅助实例副本变成新的当前主要实例副本时。

8.如权利要求1所述的计算机实现的方法，其中所述第一实例副本和第二实例副本中的每个在所述数据库环境中的分开的数据实例上运行，每个数据实例连接到一个或多个专用块存储卷。

9.如权利要求8所述的计算机实现的方法，还包括：

使用块级复制机制同步地将数据从所述主要实例副本复制到所述辅助实例副本，所述块级复制机制可操作来在所述第一实例副本和第二实例副本的所述一个或多个专用块存储卷之间同步地复制数据。

10.一种使用单独的控制环境管理数据库环境中的已复制数据库实例的计算机实现的系统，包括：

处理器；以及

包括指令的存储设备，当所述指令由所述处理器执行时使所述处理器：

响应于所述至少一个监控部件不能与第一实例副本和第二实例副本中的一个通信：

在所述控制环境中执行所述工作流。

11.如权利要求10所述的系统，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述主要副本通信、所述辅助实例副本不能与所述主要副本通信、且所述第一实例副本和第二实例副本具有与所述主要副本的最后已知状态的公共数据生成标识符时使所述辅助实例副本执行故障切换操作以变成关系数据库实例的新的主要副本的任务。

12.如权利要求10所述的系统，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述辅助副本通信且所述主要实例副本不能与所述辅助副本通信时使产生所述关系数据库实例的新的辅助实例副本的辅助实例副本恢复过程被执行的任务。

13.如权利要求10所述的系统，其中所述工作流包括当所述监控部件在最小的时间段内不能与所述主要副本和辅助副本中的任一个通信、所述主要实例副本和辅助实例副本能够彼此通信、且所述主要实例副本和辅助实例副本具有公共数据生成标识符时在所述控制环境中将信息存储到数据存储器而不执行故障切换或恢复操作的任务。

14.如权利要求10所述的系统，其中在单个数据区中、在分开的地理位置处的分开的数据区中、在越过多个地理位置的单个数据区中或越过在单个地理区域中的多个数据区供应第一实例副本和第二实例副本。

15.如权利要求10所述的系统，其中给用户提供使所述用户能够与当前主要实例副本通信的别名，包括当故障切换操作使所述辅助实例副本变成新的当前主要实例副本时。