在多部署数据库中转移连接

相关申请的交叉引用

本申请要求2019年3月19日提交的序列号为16/357,822的美国专利申请的优先权，其内容据此通过引用以其整体并入本文。

技术领域

本公开涉及数据库，并且更具体地涉及具有多个部署的数据库系统中的数据库连接。

背景

数据库是数据的有组织的集合，其使数据能够易于被访问、操纵和更新。数据库用作以有效方式储存、管理和检索信息的方法。传统的数据库管理要求公司提供基础结构和资源来管理数据中心中的数据库。传统数据库的管理可能非常昂贵，并且需要由拥有广泛技术技能组合的多个人员进行监督。

传统的关系数据库管理系统(RDMS)需要大量的计算和储存资源并且具有有限的可扩展性。大量数据可能跨多个计算设备储存。服务器可以管理数据，使得客户可以通过内部操作对其进行访问。对于希望拥有内部数据库服务器的实体，该实体必须在用于数据库的硬件和基础结构连同用于储存数据库基础结构的大量物理空间的资本投资上花费大量资源。此外，在断电或其它灾难情况期间，数据库可能极易丢失数据。这样的传统数据库系统具有重大缺陷，这些重大缺陷可以通过基于云的数据库系统来减轻。

云数据库系统可以通过云平台进行部署和传送，云平台允许组织和终端用户储存、管理和检索来自云的数据。一些云数据库系统包括通过在计算云的顶部安装数据库软件来实现的传统的数据库架构。数据库可以通过Web浏览器或应用程序编程接口(API)进行访问以用于应用程序和服务集成。一些云数据库系统由供应商操作，该供应商代表客户端直接管理数据库安装、部署和资源分配任务的后端过程。客户端可以具有通过Web浏览器和/或API的方式访问数据库的多个终端用户。云数据库可以通过降低丢失数据库数据的风险并允许跨多个地理区域的多个用户访问数据来给一些客户端提供显著的益处。

对于传统数据库系统和云数据库系统，存在多种架构。一种示例架构是共享磁盘系统。在共享磁盘系统中，所有数据都储存在可从数据集群中的所有处理节点进行访问的共享储存设备上。在这种类型的系统中，所有数据更改都被写入共享储存设备以确保数据集群中的所有处理节点访问一致版本的数据。随着共享磁盘系统中处理节点数量的增加，共享储存设备(以及在处理节点与共享储存设备之间的通信链接)成为减慢数据读取和写入操作的瓶颈。随着更多的处理节点的增加进一步加剧此瓶颈。因此，由于这个瓶颈问题，现有的共享磁盘系统具有有限的可扩展性。

另一种现有的数据储存和检索系统被称为“无共享架构”。在这个架构中，数据分布在多个处理节点上，使得每个节点储存整个数据库中的数据的子集。当新的处理节点被添加或移除时，无共享架构必须跨多个处理节点重新安排数据。数据的这种重新安排可能是耗时的，并且在数据重新安排期间破坏被执行的数据读取和写入操作。并且，特定节点与数据的相关性可以在数据集群上为流行数据创建“热点”。此外，由于每个处理节点还执行储存功能，因此该架构需要至少一个处理节点来储存数据。因此，如果移除所有处理节点，则无共享架构将无法储存数据。此外，由于数据跨许多不同的处理节点分布，因此对无共享架构中的数据管理是复杂的。

在一些情况下，跨多个地理位置、跨多个数据库供应商或提供商和/或跨可能位于同一物理位置或位于两个或更多个不同位置的多个计算设备复制数据库数据可能是有益的。这些多个位置、供应商、提供商和/或计算设备在本文可以被称为“部署”。这可以为数据库客户端提供显著的益处，因为数据是在多于一个位置被备份的。如果一个部署由于例如断电、系统错误、计划的维护停机时间等而不可用，则不同的部署可以接管对数据库的管理和操作。这可以使客户端安心，这样他们知道始终可以访问数据库数据和/或这样他们知道数据库数据是跨多个部署复制和保护的。但是，提供相同数据库的多个部署带来许多重大挑战。

一个挑战是每个部署必须有数据库数据的最新副本。一些数据库可能随着新内容、更新的内容和/或内容删除而不断被更改。这些更改可以在数据库的单个部署中被执行。一些更改(尤其是更新、删除和合并)需要大量的时间和计算资源。难点可能在于：将数据库更改传播到多个部署使得在任何给定时间都可以依赖每个部署的内容。此外，难点还在于：以具有成本效益的方式传播数据库更改使得在每个数据库部署处时间和计算资源被有效地使用。

复制数据库数据的另一个挑战是如何将对数据库的操作从一个部署到不同的部署进行更改。一个数据库可以具有主要部署和多个次要或备份部署。由于计划的转换或由于主要部署发生故障，从主要部署无缝转换到次要部署可能带来挑战。存在与以下项相关联的许多挑战：确保数据库数据是最新的并在主要部署和次要部署之间正确地复制。此外，在主要部署发生故障并且数据库操作转换到次要部署的情况下，当原始主要部署在故障后再次可用时，存在与更新原始主要部署相关联的许多挑战。必须更新原始主要部署使得在故障期间执行的所有更新都无错误地被传播并且不消耗大量时间或计算资源。

本文描述的系统、方法和设备提供了数据库复制、数据库故障转移(failover)和数据库部署之间的无缝转换的改进方法。

附图简述

参考以下附图描述了本公开的非限制性和非穷举性实现方式。参考下面的描述和附图，本公开的优点将变得更好理解，附图中：

图1是根据本公开的教导和原理的用于利用域名系统实现方式将客户端连接从第一部署转换到第二部署的系统的示意图；

图2是根据本公开的教导和原理的用于利用表现层状态转化(REST)请求实现方式将客户端连接从第一部署转换到第二部署的系统的示意图；

图3是根据本公开的教导和原理的用于利用表现层状态转化(REST)请求实现方式将客户端连接从第一部署转换到第二部署的系统的示意图；

图4是根据本公开的教导和原理的检索和数据储存系统的部件的框图；

图5是根据本公开的教导和原理的资源管理器的实施例的框图；

图6是根据本公开的教导和原理的用于生成数据库快照的过程流程的示意图；

图7是根据本公开的教导和原理的用于生成关于复制数据库的事务日志(transaction log)的过程流程的示意图；

图8是根据本公开的教导和原理的示出刷新请求的生成和传输的框图；

图9是根据本公开的教导和原理的示出快照响应的生成和传输的框图；

图10是根据本公开的教导和原理的示出快照响应的导入的框图；

图11是根据本公开的教导和原理的部署架构的示意图；

图12是根据本公开的教导和原理的全局部署组的示意图；

图13是根据本公开的教导和原理的用于在多部署数据库系统中转换客户端连接的方法的示意性流程图；和

图14是根据本公开的教导和原理的示例计算设备。

详细描述

本公开扩展到用于在多部署数据库中转移连接的系统、方法和设备。数据库系统可以具有跨多个部署储存和/或在多个部署中复制的数据。数据库部署可以包括数据库储存资源和/或数据库管理资源(例如数据湖或数据仓库)。单个数据库可以将数据储存在多个不同部署中，其中不同的部署可以位于不同的地理区域，可以由不同的提供商提供服务，可以储存数据库数据的不同部分，可以具有架构或结构差异，可以是彼此的复制等。对数据库数据的更新(例如插入、删除、合并等)可以在主要部署上执行，并被传播到一个或更多个次要部署。对数据库数据的查询可以在主要部署上执行。在实现方式中，可能有益的是：由于系统中断、客户端偏好、计划的维护而更改主要部署以满足客户端性能阈值等。本文公开的系统、方法和设备提供用于在多部署数据库中转换连接的改进手段，使得在客户端和数据库之间的数据库流量(traffic)从第一主要部署移动到新的主要部署。

公开了用于在多部署数据库系统中转换客户端连接的方法。方法包括维护在客户端和第一部署之间的客户端连接，使得数据库流量在第一部署处发生。方法包括生成引用第一部署的第一连接对象和第二部署的第二连接对象的唯一标识。方法包括接收第一部署不可用的通知。方法包括由客户端向第二部署提供外部连接组唯一标识以用于第二部署确定客户端是否应该连接到第二部署。外部连接组UUID可以基于唯一标识，并向客户端提供客户端与哪个连接组相关联的指示。方法包括如果客户端应该被连接到第二部署，则从第二部署接收统一资源定位符。

数据库连接可以从当前主要部署转换到新的主要部署。可能不希望在不确保新的主要部署已经被更新且相对于当前主要部署不陈旧(stale)的情况下转换数据库连接。例如，数据库连接(即，提供用于发起对数据库的更新或查询的手段的连接)可以连接到当前主要部署，使得对数据库的所有更新和查询是在当前主要部署处被执行的。当前主要部署可能变得不可用，并且可能需要将数据库连接转换到新的主要部署(其以前用作相对于当前主要部署的次要部署)。如果新的主要部署是陈旧的，则当连接从当前主要部署转换到新的主要部署后在数据库上执行更新和/或查询时，新的主要部署不能用作数据库数据的准确来源。例如，如果在新的主要部署用作次要部署时，对当前主要部署所做的更新没有被传播到新的主要部署，则新的主要部署将是陈旧的，并且在数据库连接转换后不能返回准确的查询结果。在特定实现方式中，次要部署中可以容忍一定程度的陈旧。但是，希望的是确保所有次要部署是数据库数据的准确表示。因此，希望的是跨所有次要部署复制主要部署，并将对主要部署所做的任何更新传播到每个次要部署。本文公开了用于在主要部署和一个或更多个次要部署之间复制数据库数据和数据库元数据的系统、方法和设备。

用于在多部署数据库系统中转换连接的系统、方法和设备可以用基于云的数据库技术来实现。数据库数据可以储存在跨地理区域可访问的基于云的储存中。这种基于云的储存是指储存在场外(off-site)储存系统中的数据库数据，在一些实现方式中，场外储存系统可以由第三方维护。例如，客户端可以选择以云储存提供商储存数据，而不是将数据储存在本地计算机硬盘驱动器或客户端拥有的其它本地储存设备上。客户端可以通过在客户端的计算资源和储存客户端数据的场外储存资源之间的互联网连接来访问数据。

数据库数据的云储存可以提供优于传统现场本地储存的几个优点。当数据库数据被储存在云储存中时，信息可以在具有互联网连接的任何位置处进行访问。因此，数据库客户端不需要移动物理储存设备或使用同一台计算机来保存、更新或检索数据库信息。此外，数据库信息可以被在不同地理位置处的多个用户同时访问、更新和保存。客户端可以通过互联网将文件的副本发送到与云储存提供商相关联的数据服务器，该数据服务器记录文件。客户端可以通过经由基于Web的界面或其他用户界面访问与云储存提供商相关联的数据服务器来检索数据。与云储存提供商相关联的数据服务器然后可以将文件发送回客户端，或者允许客户端访问和操纵在数据服务器本身上的文件。

云储存系统通常包括可以服务多个客户端的数百个或数千个数据服务器。因为计算机偶尔需要维护或修理，并且因为计算机偶尔会发生故障，所以在多台机器上储存相同信息是重要的。这种冗余可以确保即使在服务器发生故障的情况下客户端也可以在任何给定的时间访问它们的数据。

基于云的数据库储存系统可以包括多个部署。在本公开中，部署可以包括用于储存和/或管理数据库数据的一个或更多个计算和/或储存资源。部署可以包括用于储存数据库数据的资源集合，并且部署可以经由网络连接(诸如互联网连接)与其它系统和设备进行通信。在各种实施例中，部署可以位于不同的地理位置，可以在不同的储存资源上操作，可以在不同的计算资源上操作，可以由不同的基于云的提供商管理，等等。在示例中，基于云的数据库系统跨四个部署储存数据库数据。一个部署位于东部地理区域并且由第一基于云的储存提供商管理。另一个部署位于西部地理区域并且也由第一基于云的储存提供商管理。另一个部署在东部地理区域运行并且由第二基于云的储存提供商管理。另一个部署在西部地理区域运行并且由第二基于云的储存提供商管理。在该示例中，四个部署中的每个部署包括与网络连接(例如互联网连接)进行通信的计算资源的集合。四个示例部署中的每个部署可以储存数据库数据的一部分，或者可以储存数据库的整个副本。对于使用基于云的数据库系统的每个数据库客户端，跨四个示例部署储存的数据库数据可以是不同的。例如，第一客户端可以将其主要部署选择为由第二基于云的储存提供商管理的位于东部区域的部署。第一客户端可以选择剩余示例部署中的每个部署来用作次要部署并维护第一客户端的数据库数据的副本。基于云的数据库系统可以使用任意数量的部署和/或与任意数量的部署进行通信。

在一个实施例中，不同的部署位于相同地理区域，并且由相同基于云的储存提供商管理。在一个实施例中，不同的部署位于不同的地理区域，并且由相同基于云的储存提供商管理。在一个实施例中，不同的部署位于相同地理区域，并且由不同的基于云的储存提供商管理。

在本公开的实施例中，数据库数据跨多个云储存部署进行储存。这样的云储存部署可以位于不同的地理位置，并且数据库数据可以跨每个部署中的多个机器和/或服务器进行储存。云储存部署可以位于单个地理位置，但是可以连接到不同的电源和/或使用不同的计算机器来储存数据。云储存部署可以由不同的云储存提供商操作。在这样的实施例中，数据库数据跨多个部署进行复制，使得在一个部署变得不可用或发生故障的情况下，数据库数据可以继续被访问、更新和保存。在实施例中，数据库数据被储存在主要部署中，并且还被储存在一个或更多个次要部署中。当主要部署可用时，主要部署可始终被用于访问、查询和更新数据。如果主要部署变得不可用且在主要部署变得不可用时，则一个或更多个次要部署可以承担操作。当主要部署变得再次可用时，主要部署可以使用在主要部署不可用时在一个或更多个次要部署上发生的任何更改进行更新。更新后的主要部署然后可以恢复操作(包括访问、查询和更新数据)。

当数据跨多个部署被储存时，确保跨每个部署的数据是一致的是重要的。当数据被更新、修改或添加到主要部署时，可以跨一个或更多个次要部署传播更新，以确保所有部署具有一致且最新的数据版本。如果主要部署变得不可用，则每个最新的次要部署可以承担对数据的操作，其中没有数据是陈旧的或不正确的。此外，当多个部署中的任何一个部署变得不可用时，可以稍后使用在该部署不可用时的期间进行的所有更改来更新该部署。当部署在“离线”或不可用之后进行更新时，确保仅使用在该部署不可用时的期间所做的那些更改来更新该部署可能是有益的。

数据库表可以响应于诸如插入命令、删除命令、合并命令等数据操纵(DML)语句而改变。这样的修改可以被称为发生在数据库表上的事务(修改在本文可以替代性地被称为“更新”)。在实施例中，每个事务包括时间戳，该时间戳指示事务何时被接收和/或事务何时被完全执行。在实施例中，事务包括对表进行的多个改变，并且这样的改变可能影响表中的一个或更多个微分区。

在实施例中，表中的所有数据被自动划分为称为微分区的不可变储存设备。微分区可以被认为是批处理单元，其中每个微分区具有连续的储存单元。举例来说，每个微分区可以包含介于50MB和500MB之间的未压缩数据(注意，储存装置的实际大小可以更小，因为数据可以被压缩储存)。表中的行组可以映射到以柱状方式组织的各个微分区。这种大小和结构允许对非常大的表进行极细的修剪，这些非常大的表可以由数百万甚至数亿个微分区组成。可以自动收集关于储存在微分区中的所有行的元数据，包括：微分区中每个列的值范围；不同值的数量；和/或用于优化和高效查询处理的附加属性。在一个实施例中，可以在所有表上自动执行微分区。例如，可以使用插入/加载数据时发生的排序透明地对表进行分区。

在一个实施例中，元数据可以被储存在不可变储存装置中的元数据微分区中。在一个实施例中，系统可以针对数据库表的每个修改将元数据微分区写入云储存。在一个实施例中，系统可以下载和读取元数据微分区来计算扫描集。元数据微分区可以并行下载并在它们被接收时读取以改善扫描集计算。在一个实施例中，系统可以在后台周期性地合并元数据微分区。在一个实施例中，可以包括性能改善(包括预取、缓存、列布局等)。此外，利用具有柱状布局的元数据文件来进行安全改善(包括加密和完整性检查)也是可能的。

在本公开的以下描述中，参考形成本公开的一部分的附图，并且在附图中通过图示的方式示出了可以在其中实践本公开的特定实现方式。应当理解，可以利用其他实现方式，并且可以进行结构上的更改而不脱离本公开的范围。

在描述和要求保护本公开时，将根据下面陈述的定义使用以下术语。

必须注意的是，如在本说明书和所附权利要求书中所使用的单数形式“一(a)”，“一个(an)”和“该(the)”包括复数引用，除非上下文另外明确指出。

在整个说明书中对“一个实施例”、“实施例”、“一个实现方式”、“实现方式”、“一个示例”或“示例”的引用是指结合该实施例、实现方式或示例描述的特定特征、结构或特性包括在本公开的至少一个实施例中。因此，在整个本说明书中各个地方出现的以上确认的短语不一定全部指的是同一实施例、实现方式或示例。此外，应当理解，本文提供的附图是为了向本领域普通技术人员解释的目的。

如本文所使用的，术语“包括(comprising)”、“包括(including)”、“包含(containing)”及其语法上的等同形式是包括性或开放性的术语，其不排除附加的、未叙述的元素或方法步骤。

如本文所使用的，“表”被定义为记录(行)的集合。每条记录包含表属性值(列)的集合。表通常物理储存在多个较小(不同大小或固定大小)的储存单元(例如，文件或块)中。

如本文所使用的，“分区”被定义为将具有不同数据的记录物理地分离为分离的数据分区。例如，表可以基于国家属性对数据进行分区，从而导致按国家进行分区。

如本文所使用的，“部署”被定义为用于提供数据库数据的数据仓储的计算和储存资源的集合。部署可以包括网络流量路由部件、资源管理部件、元数据储存部件、微分区元数据部件、微分区组织部件以及所需的其它部件。部署可以包括云提供商接口，该云提供商接口用于供应用于资源管理的附加的计算资源、用于供应用于一个或更多个执行平台的附加的计算资源、用于管理安全部件、用于供应储存部件以及用于生成和管理云提供商用户、角色、策略等。部署可以通过写入储存装置的文件或微分区或通过直接访问元数据储存与其它部署、服务、设备和系统进行通信。部署包括用于提供数据仓储服务所必需的部件。

根据本公开的实施例可以被体现为装置、方法或计算机程序产品。因此，本公开可采用完全包括硬件的实施例、完全包括软件的实施例(包括固件、驻留软件、微代码等)或组合软件和硬件方面的实施例的形式，这些实施例可在本文中都通常被称为“电路”、“模块”或“系统”。此外，本公开的实施例可采用被体现在任何有形的表达介质中的计算机程序产品的形式，该计算机程序产品具有在介质中体现的计算机可用程序代码。

可使用一个或更多个计算机可用或计算机可读介质的任何组合。例如，计算机可读介质可包括在下列各项中的一项或更多项：便携式计算机磁盘、硬盘、随机存取存储器(RAM)设备、只读存储器(ROM)设备、可擦除可编程只读存储器(EPROM或闪存)设备、便携式光盘只读存储器(CDROM)、光学储存设备和磁储存设备。可以用一种或更多种编程语言的任何组合来编写用于执行本公开的操作的计算机程序代码。这种代码可以从源代码编译成适用于将在其上执行代码的设备或计算机的计算机可读的汇编语言或机器代码。

实施例还可在云计算环境中被实现。在本描述和所附权利要求中，“云计算”可以被定义为用于实现对可配置计算资源(例如，网络、服务器、储存装置、应用、和服务)的共享池的普遍、方便、按需网络访问的模型，其中可配置计算资源可经由虚拟化迅速地被供应并以最小管理努力或服务提供商交互而被释放，并然后被相应地扩缩。云模块可包括多种特征(例如按需自助式服务、广阔的网络访问、资源池、快速弹性、和可计量的服务)、服务模型(例如软件即服务(“SaaS”)、平台即服务(“PaaS”)、和基础设施即服务(“IaaS”))、和部署模型(例如私有云、社区云、公共云、和混合云等)。

附图中的流程图和框图示出了根据本公开的各个实施例的系统、方法和计算机程序产品的可能的实现方式的架构、功能和操作。就这点而言，在流程图或框图中的每个框可代表代码的模块、段或部分，其包括用于实现指定的逻辑功能的一个或更多个可执行指令。还将注意，框图和/或流程图中的每个框以及在框图和/或流程图中的框的组合可由执行指定功能或动作的基于专用硬件的系统或专用硬件和计算机指令的组合实现。这些计算机程序指令也可储存在可指示计算机或其它可编程数据处理装置以特定方式起作用的计算机可读介质中，使得储存在计算机可读介质中的指令产生包括实现在流程图和/或框图的一个或多个框中所指定的功能/动作的指令装置(means)的制造品。

本文描述的系统和方法可以在使用新的数据处理平台的灵活且可扩展的数据仓库上操作。在一些实施例中，所描述的系统和方法利用支持基于云的储存资源、计算资源等的云基础设施。示例的基于云的储存资源以低成本提供了按需可用的大量储存容量。此外，这些基于云的储存资源可以是容错和高度可扩展的，这在私有数据储存统中实现起来可能是昂贵的。示例的基于云的计算资源是按需可用的，并且可以基于资源的实际使用水平来定价。通常，以快速方式动态部署、重新配置和停止使用云基础设施。

在所描述的系统和方法中，数据储存系统利用基于SQL(结构化查询语言)的关系数据库。然而，这些系统和方法适用于任何类型的数据库以及任何类型的数据储存和检索平台、使用任何数据储存架构和使用任何语言以在数据储存和检索平台内储存和检索数据。本文描述的系统和方法还提供了一种多租户系统，该多租户系统支持隔离在不同客户/客户端之间以及在同一客户/客户端内的不同用户之间的计算资源和数据。

现在参考附图，图1是用于使用DNS(域名系统)实现方式将客户端数据库连接从第一部署转换到第二部署的系统100的示意图。系统100可以被实现为从主要部署故障转移到次要部署。系统100包括可以与一个或更多个部署进行通信的客户端102。如图1所示，客户端102可以与部署D1和部署D2中的一者或两者进行通信。系统102包括维护DNS(域名系统)记录106的DNS(域名系统)解析器104。部署D1维护连接对象C1，并且部署D2维护连接对象C2。

DNS解析器104将流量从第一部署路由到第二部署。在实施例中，DNS解析器104可以在没有来自客户端102的明显的指令的情况下将客户端102连接从第一部署转换到第二部署。DNS解析器104可以将记录更新为不再指向第一部署并且开始指向第二部署。在实施例中，DNS解析器104由第三方提供，该第三方与以下项分离及独立：一个或更多个部署、储存数据库数据的储存设备、储存数据库数据的储存设备、数据库管理资源、执行平台等。在实施例中，DNS记录106驻留在第三方DNS解析器104中。DNS解析器104可以被配置为将客户端102连接从第一部署转换到第二部署，其中这两个部署由不同的基于云的数据库提供商提供，或者位于不同的地理区域，或者通过任何其它方式分开或者用于任何其它目的。

通过图1所示的系统100转换客户端102连接的方法可以包括以下步骤。连接对象C1在部署D1中生成，并且连接对象C2在部署D2中生成。连接对象C1和连接对象C2用唯一标识112(uID)绑定在一起。使用引用绑定的连接对象C1和C2的唯一标识112为DNS解析器104生成全局URL(统一资源定位符)108。连接对象C1和C2包括存在于系统100中的一段元数据。在示例中，数据库客户端可以使用诸如“create connection my_conn”的语法来生成连接对象，并且唯一标识112可以由系统100生成。为了将连接对象C1和C2绑定在一起，例如，可以使用诸如“createconnectionmy_conn2”、复制组“

在图1所示的系统100中，DNS解析器104先前指向部署D1作为主要部署。为了将客户端102连接从部署D1转换到部署D2，记录更改请求110由部署D2(先前是次要部署，并将成为新的主要部署)提交到DNS解析器104。记录更改请求110包括以下指示：部署D2现在希望DNS解析器104不再指向部署D1，而是相反指向部署D2。记录更改请求110必须被传播到任何地方，即传播到新的主要部署和所有次要部署。当记录更改请求110已经由DNS解析器104传播时，客户端102所使用的全局URL108然后将指向部署D2并且将不再指向部署D1。

在实现方式中，部署D1和部署D2由不同的基于云的数据库提供商托管。在实现方式中，部署D1和部署D2由相同提供商托管，并且位于不同的地理区域。在实现方式中，部署D1和部署D2由相同提供商托管，并且位于相同地理区域。在实现方式中，部署D1和部署D2与两个不同的账户或数据库相关联，这些账户或数据库由相同提供商托管并位于相同或不同的地理区域。本文公开的系统100可以实现从第一部署到第二部署的跨云故障转移，其中两个部署由不同的提供商托管和/或可以托管在不同的地理区域中。

图2是使用REST(表现层状态转化)实现方式将客户端连接从第一部署转换到第二部署的系统200的示意图。系统200可以被实现为从主要部署故障转移到次要部署。在特定实现方式中，与图1中公开的DNS实现方式相比，图2中公开的REST实现方式可以提供更好的性能和/或可以更可靠。此外，在一些实现方式中，图2中公开的REST实现方式可以绕过让第三方DNS解析器104更新DNS记录106以执行从第一部署到第二部署的转换的需要。图2中公开的REST实现方式可以避免更改DNS记录106的需要，并且因此在特定实现方式中可以更快和/或更可靠。在一些实现方式中，对客户端可能有益的是：使用图1所示的DNS实现方式和图2所示的REST实现方式中的每一个来实现混合方法。

在REST实现方式中，用于部署故障转移的大部分逻辑可以被客户端202拥有和/或储存，并且不被推送到DNS解析器。在系统200中，存在与部署D1相关联的连接对象C1，并且存在与部署D2相关联的连接对象C2。连接对象C2和连接对象C2由唯一标识(uID)212绑定。在图2所示的示例中，部署D1是新的主要部署，并且部署D2是先前的主要部署(可以可替代地分别称为第二部署和第一部署)。与唯一标识212分离但是可以基于唯一标识212的外部连接组唯一标识216(“外部连接组UUID”)被提供给客户端202。外部连接组UUID 216指示客户端202属于哪个连接组。在实施例中，外部连接组UUID 216引用唯一标识212。外部连接组UUID 216可以被称为“conn_uuid”。外部连接组UUID 216包括与客户端202相关联的一系列部署。该一系列部署可以包括一个主要部署和任意数量的次要部署。通过分离外部连接组UUID 216和唯一标识212，实现了许多好处。一个好处是拥有单独的标识提供安全好处。在示例中，如果第三方访问外部连接组UUID 216(其可能存在于全局URL中)，则第三方仍无法计算出将连接对象C1和连接对象C2绑定在一起的唯一标识212。

在图2所示的示例中，部署D1是次要部署，并变成主要部署。部署D1是主要部署，并变成次要部署。部署D1是新的主要部署(可以替代性地称为“第二部署”)，并且部署D1是先前的主要部署(可以替代性地称为“第一部署”)。当部署D2从主要部署转换到次要部署时，到部署D2的所有连接都将关闭并标记为无效。

客户端202希望与当前为主要部署的任何部署相连接。客户端202发送REST(表现层状态转化)请求以联系部署。在多个实施例中，REST请求可以由与客户端202账户相关联的用户或系统管理员手动发送，和/或REST请求可以由与客户端202账户相关联的处理器或其它计算资源自动发送而无需用户干预。因为外部连接组UUID 216，所以部署D1内的账户知道部署D1是主要部署；部署D1执行查找以查询部署D1中是否存在任何连接组。如果查找结果为真，则查询将返回哪个部署是主要的。如果基于外部连接组UUID 216的查找无效，则查找将返回指示外部连接组UUID216无效的响应。如果部署D1是基于外部连接组UUID 216的主要部署，则部署D1向客户端202返回包括用于客户端202连接到主要部署的URL(统一资源定位符)的响应。

基于用于部署D1的连接对象C1和用于部署D2的连接对象C2来确定唯一标识212。外部连接组UUID 216可以基于唯一标识212，并且外部连接组UUID 216可以被称为“conn_uuid”)。唯一标识212指示具有与客户端202相关联的数据库数据的区域或部署。外部连接组UUID 216(即“conn_uuid”)是可以基于唯一标识212的单独标识。外部连接组UUID 216被提供给客户端202，并且客户端202将外部连接组UUID 216发送到主要部署以发起连接。

在图2所示的示例中，客户端202最初通过部署D2输送连接流量(见204)。客户端202继续通过部署D2输送连接流量(见204)，直到部署D2在210返回无效连接的通知为止。当部署D2利用外部连接组UUID 216执行查找并确定部署D2不是主要部署时，部署D2在210返回无效连接的通知。部署D2返回指示部署D2不是主要部署的无效响应。响应于从部署D2接收到无效连接的通知，客户端202在206向部署D1提供外部连接组UUID(conn_uuid)。在实施例中，客户端202在206向所有次要部署提供外部连接组UUID以确定哪个次要部署现在是主要部署。在图2所示的示例中，只有两个可能的部署(即，一个主要部署和一个次要部署)，但是应当理解，可以有主要部署和任意数量的次要部署。一旦从客户端202接收到外部连接组UUID，则部署D1使用外部连接组UUID 216执行查找以确定部署D1现在是否是主要部署。响应于查找为真，部署D1在208向客户端202提供URL以使客户端202连接到部署D1作为新的主要部署。然后，新的连接流量在客户端202和部署D1之间行进(见216)。

唯一标识212可以由连接改变部件214确定。在实施例中，为了给客户端202提供增强的安全性，唯一标识212是随机生成的，并且不包括任何标识信息(例如姓名或账号)。

客户端202可以包括数据库客户端，该数据库客户端具有在一个或更多个部署中跨储存设备储存的数据库数据。客户端202可以包括向用户或系统管理员提供访问以更新和/或查询数据库数据的账户。客户端202可以包括如本文公开的资源管理器和执行平台。

图2中公开的系统200可以被实现为从第一部署(即，图2中所示的示例中的部署D2)到第二部署(即，图2中所示的示例中的部署D1)的“优雅的(graceful)”故障转移。由于系统更新或其它计划的原因，可以基于第一部署的计划的停机时间来执行优雅的故障转移。优雅的故障转移可以由与客户端202相关联的用户或系统管理员手动发起。用户可以手动指示客户端202应该将所有连接流量从当前主要部署转换到新的主要部署。这可以基于可以特定于客户端202的需求的任何合适的原因。例如，当前主要部署和新的主要部署可以由不同的基于云的数据库提供商提供服务，并且客户端202可能希望测试新的主要部署，可能更喜欢用新的主要部署进行服务或定价，或者可能需要在当前主要部署离线时临时使用新的主要部署。多个部署的另一个示例性使用是用于灾难恢复演练。在示例实现方式中，因为中断很少，所以多个部署可以用于演练或练习以确保在主要部署实际中断的情况下数据库将根据需要继续运行。另外，例如，当前主要部署和新的主要部署可能位于不同的地理区域，并且客户端202可能更喜欢新的主要部署的地理区域，或者可能希望在该地理区域临时使用新的主要部署。应当理解，用于将客户端连接从当前主要部署转换到新的主要部署的原因可以特定于客户端202的需求和/或基于当前主要部署的计划的或意外的停机时间。在多个实现方式中，可能希望的是客户端202具有主要部署和多个次要部署，这些次要部署总是准备在根据需要的基础上接管作为主要部署。此外，可能希望的是客户端202具有跨多个地理区域和/或跨多个基于云的数据库提供商的多个部署，其中多个部署可以是彼此的复制和/或可以为客户端202的数据库数据的管理提供不同的好处。

图3是使用REST(表现层状态转化)实现方式将客户端连接从第一部署转换到第二部署的系统300的示意图。图3所示的系统300可以在基于当前主要部署的意外故障的“非优雅的”连接转换中实现。例如，在当前主要部署由于系统错误、断电或其他故障而意外不可用或离线的情况下，系统300可以执行从发生故障的当前主要部署到可以用来接管的新的主要部署的客户端连接转换。

类似于图1-2中所示的实现方式，存在基于用于部署D1的连接对象C1并且还基于用于部署D2的312连接对象C2的唯一标识312。外部连接组UUID 316可以基于唯一标识312，并且被提供给客户端302，使得客户端可以使用外部连接组UUID 316来确定其是哪些连接组的一部分。在图3所示的示例中，部署D1是先前的主要部署，并且部署D2是新的主要部署，使得客户端连接将从部署D1转换到部署D2。客户端302最初通过部署D1操作所有连接流量(见304)。部署D1可能意外地变得不可用，并且客户端302将从部署D1接收错误代码308。客户端302发起重试请求306以确定部署D1是否是不可用的。响应于客户端302确定部署D1是不可用的(例如，基于接收到错误代码308)，客户端302将尝试确定哪个部署现在是主要部署。客户端302向每个可能的部署发送外部连接组UUID316，以确定主要部署是否已经从部署D1更改为任何其它部署(在图3的示例中，主要部署已经从部署D1变换到部署D2)。如果客户端302确定连接已经更改并且存在新的主要部署，则客户端302将向新的主要部署(在图3的示例中，新的主要部署是部署D2)发送连接请求310。应当理解，客户端302可以向多个可能的次要部署发送连接请求310。主要确定部件314确定部署D2现在是否是主要部署。

现在参考图4，其示出了用于运行本文公开的方法的计算机系统。如图4所示，资源管理器402可以耦合到多个用户404、406和408。在特定的实现方式中，资源管理器402可以支持希望访问数据处理平台400的任何数量的用户。用户404、406、408可以包括例如提供数据储存和检索请求的终端用户、管理本文所述系统和方法的系统管理员以及与资源管理器402交互的其它部件/设备。用户404、406和408在本文中可以被称为“客户端”，并且可以具有到如本文所公开的一个或更多个部署的直接连接。用户404、406和408中的每一个可以连接到主要部署，并且具有将连接从主要部署转换到次要部署的能力。

资源管理器402提供支持在数据处理平台400内所有系统和部件的操作的各种服务和功能。资源管理器402可以耦合到元数据410，元数据410与储存在整个数据处理平台400中的全部数据相关联。在一些实施例中，元数据410可以包括储存在远程数据储存系统中的数据以及可从本地高速缓存获得的数据的概要。另外，元数据410可以包括关于在远程数据储存系统和本地高速缓存中如何组织数据的信息。元数据410可以允许系统和服务确定是否需要处理一条数据，而不从储存设备加载或访问实际数据。

资源管理器402还可以耦合到执行平台412，执行平台412提供执行各种数据储存和数据检索任务的多个计算资源(如下面更详细地讨论的)。执行平台412可以耦合到作为储存平台414的一部分的多个数据储存设备416、418和420。尽管在图4中示出了三个数据储存设备416、418和420，但是执行平台412能够与任何数量的数据储存设备进行通信。在一些实施例中，数据存储设备416、418和420是位于一个或更多个地理位置的基于云的储存设备。例如，数据储存设备416、418和420可以是公共云基础设施或私有云基础设施的一部分。数据储存设备416、418和420可以是硬盘驱动器(HDD)、固态驱动器(SSD)、储存集群或任何其它数据储存技术。另外，储存平台414可以包括分布式文件系统(诸如Hadoop分布式文件系统(HDFS))、对象储存系统等。

在特定的实施例中，资源管理器402与用户404、406和408、元数据410和执行平台412之间的通信链接是经由一个或更多个数据通信网络来实现的。类似地，执行平台412与储存平台414中的数据储存设备416、418和420之间的通信链接是经由一个或更多个数据通信网络来实现的。这些数据通信网络可以利用任何通信协议和任何类型的通信介质。在一些实施例中，数据通信网络是彼此耦合的两个或更多个数据通信网络(或子网)的组合。在可替代实施例中，这些通信链接是使用任何类型的通信介质和任何通信协议来实现的。

如图4中所示，数据存储设备416、418和420从与执行平台412相关联的计算资源解耦。在一个实施例中，多个数据库部署中的每个部署可以包括具有多个数据储存设备416、418和420的储存平台414。跨多个部署的储存平台414中的每个部署可以储存数据库数据的副本，使得多个部署中的每个部署能够用作在其中对数据库数据执行更新和查询的主要部署。该架构支持基于不断更改的数据储存/检索需求以及访问数据处理平台400的用户和系统的不断更改的需求对数据处理平台400进行动态更改。对动态更改的支持允许数据处理平台400响应于对数据处理平台400内的系统和部件的不断更改的需求而快速缩放(scale)。计算资源与数据储存设备的解耦支持大量数据的储存而无需相对应的大量计算资源。类似地，资源的这种解耦支持在特定时间使用的计算资源的显着增加而无需可用数据储存资源的相对应的增加。

资源管理器402、元数据410、执行平台412和储存平台414在图4中作为单独的部件被示出。然而，资源管理器402、元数据410、执行平台412和储存平台414中的每一者可以被实现为分布式系统(例如，跨多个地理位置处的多个系统/平台分布)。另外，资源管理器402、元数据410、执行平台412和储存平台414中的每一个可以根据从用户404、406和408接收的请求的更改和数据处理平台400的不断更改的需求而被放大或缩小(彼此独立)。因此，数据处理平台400是动态的并且支持定期更改以满足当前数据处理需求。

图5是描绘资源管理器402的实施例的框图。如图4所示，资源管理器402包括耦合到数据储存设备506的访问管理器502和密钥管理器504。访问管理器502可以处理本文描述的系统的认证和授权任务。密钥管理器504可以管理在认证和授权任务期间使用的密钥的储存和认证。请求处理服务508管理接收的数据存储请求和数据检索请求。管理控制台服务510支持管理员和其他系统管理人员对各种系统和过程的访问。

资源管理器402还可以包括SQL编译器512、SQL优化器514和SQL执行器210。SQL编译器512分析SQL查询并为查询生成执行代码。SQL优化器514基于需要被处理的数据确定执行查询的最佳方法。SQL执行器516针对资源管理器402接收的查询执行查询代码。查询调度器和协调器518可以将接收的查询发送到适当的服务或系统以进行编译、优化并分派到执行平台412。虚拟仓库管理器520管理在执行平台中实现的多个虚拟仓库的操作。

另外，资源管理器402包括配置和元数据管理器522，配置和元数据管理器522管理与储存在远程数据储存设备和本地高速缓存中的数据有关的信息。监视器和工作负载分析器524监督由资源管理器402执行的过程并管理跨执行平台中的虚拟仓库和执行节点的任务(例如，工作负载)的分配。配置和元数据管理器522以及监视器和工作负载分析器524耦合到数据存储设备526。

资源管理器402还包括复制和故障转移管理器528，复制和故障转移管理器528管理数据复制请求、数据库故障转移、数据库故障恢复(fail back)以及客户端连接从第一部署到第二部署的转移。例如，复制和故障转移管理器528管理和计划在多个数据库储存资源和数据库部署之间的批处理数据复制。在一个实施例中，复制和故障转移管理器528可以管理储存在主要部署中的数据的复制以在一个或更多个次要或备份部署中进行复制。此外，当主要部署发生故障时，复制和故障转移管理器528可以管理数据库操作从主要部署到次要部署的变换，和/或当主要部署再次变得可用时，可以管理数据库操作从次要部署回到主要部署的变换。复制和故障转移管理器528可以确保多个部署之间的一致的数据复制，并且还可以确保当第二部署不可用时对第一部署做出的任何更新在第二部署再次变得可用时被传播到第二部署。

图6是示出用于生成数据库快照的过程流程600的示意图。过程流程600可被执行以将主要部署中的数据库数据复制到一个或更多个次要部署中。在次要部署被认为是最新的并准备好接管作为主要部署之前，可以生成快照并且可以执行复制。过程流程600可以用于确保一个或更多个次要部署具有准确和最新的数据库数据记录，使得在系统或故障或主要部署的计划的停机时间的情况下一个或更多个次要部署准备接管作为主要部署。数据库快照使得能够在不同位置实例化源数据库的副本，例如，将储存在主要部署中的数据库数据复制到次要部署中。快照捕获数据库的一个或更多个对象，例如数据库的结构(例如，模式、表、视图等)和/或数据库的内容(即，行)。在特定实施例中，概念上最干净的方法发生在快照反映特定时间点的数据库的事务一致视图的情况下。在一个实施例中，事务一致时间点的快照不是严格的要求，并且生成能够通过应用一组事务日志记录而被带到事务一致状态的快照就足够了。

过程流程600示出了描绘在时间t

根据如何生成单独的对象快照的语义，图6中所示的过程流程600可以或不可以产生对象X和Y的事务一致时间点的表示。如果对象的快照表示是基于快照发起时对象的状态生成的，则快照本身将是快照开始时数据库的事务一致的表示。例如，在图6的上下文中，语义将对应于基于在时间t

在实施例中，不管快照是如何生成的，可能的是：通过以快照开始然后按日志记录的序列化顺序应用在快照时间帧期间生成的任何日志记录在快照时间结束时将目标置于事务一致状态。在这样的实施例中，前面的陈述假设了应用日志记录是幂等(idempotent)运算(其中目标数据库已经反映由特定日志记录进行的更新)，并且应用日志记录是无操作的。在这样的示例的上下文中，将与时间t

在数据库复制的实施例中，快照为目标数据库提供了初始状态，基于此所有后续更改将被应用。在一个实施例中，针对被储存在主要部署中的数据库数据生成快照，使得可以在一个或更多个次要部署中复制数据库数据。在另外的实施例中，当主要部署或一个或更多个其它次要部署不可用时，针对次要部署生成快照以捕获对储存在次要部署中的数据库数据进行的任何更新。如果快照与源数据库不一致，则目标数据库也将与源数据库不一致。对不一致的起点应用进一步的更改通常将不纠正不一致。例如，如果客户端账户从源数据库(在实施例中，源数据库是主要部署)故障转移到已经偏离源数据库(在这种情况下，是主要部署)的副本次要部署，则最终影响是数据损坏和/或数据丢失。因为故障转移可以在任何时候发生，所以确保源数据库(例如，主要部署)和目标数据库(例如，次要部署)之间的事务一致性对于数据库复制的价值主张可能至关重要。在一个实施例中，确保从快照构造的数据库的一致性是用于始终建立和维护源数据库和目标数据库之间一致性的构建块。

在实施例中，构成(comprise)数据库的各条信息包括元数据文件、表达属性文件(EP文件)和微分区。元数据文件包括描述数据库结构的信息，并且可以包括数据库中任何模式的列表和属性、每个模式中的表和视图的列表和属性、每个表或视图中存在的列的列表和属性等。单独的表内容可以由EP文件和元数据文件的组合来定义。单独的表内容的单独的元组值可以储存在微分区中。在实施例中，在事务时间的特定点包括特定表的内容的微分区的精确集合被包括在EP文件的集合的内容中。在实施例中，EP文件可以被认为包括微分区的列表。微分区和EP文件两者都是不可变的，并且可以在储存装置中被储存和加密。在实施例中，在特定事务时间点与表相关联的EP文件的列表是在元数据文件中被维护的。

在实施例中，事务日志记录确保日志记录本身包括足够的信息以正确和明确地在目标上再现事务更改。这是可以满足的，因为事务日志应用的更改在提交时是已知的，并且该方法可以包括捕获和序列化由事务做出的元数据更改。在实施例中，无论部署、区域或基础(underlying)云提供商如何，事务日志记录对于所有目标数据库都是可访问的。事务日志记录可以被写入远程储存装置。

在实施例中，主要部署变得不可用，并且所有数据库操作被变换到次要部署。在主要部署不可用的时间期间，对数据库数据的所有更新都可以在次要部署上执行。可以为在次要部署上执行的所有更新生成事务日志记录，并且当主要部署不再不可用时，事务日志记录可以用于将那些更新传播到主要部署。在这样的实施例中，事务日志记录的使用可以确保只有(对次要部署做出的)那些新的更新在主要部署上执行，并且没有陈旧数据或先前摄取的数据被传播到主要部署。

在实施例中，就何时生成事务日志记录而言，如本文公开的系统、方法和设备被配置为确保事务日志记录的写入实际上是事务本身的一部分。只有当事务提交时，事务日志记录才可以被写入远程储存装置，并且此外，只有当事务日志记录被写入远程储存装置时，事务才提交。偏离这样的过程可能导致源数据库和目标数据库之间的事务不一致。

图7是示出用于生成关于复制数据库的事务日志的过程流程700的示意图。过程流程700可被执行以确保一个或更多个次要部署是储存在主要部署中的数据库数据的准确和最新的表示。这可以确保一个或更多个次要部署在系统故障或主要部署计划的停机时间的情况下准备好接管作为主要部署。过程流程700示出了从左向右进行的时间线。在图7中，在时间线上方示出了在内部事务状态下发生的事务，并且在时间线下方示出了为支持并发控制和事务处理而采取的动作。在时间t

在实施例中，在712、在转换到提交状态时、在时间t

在实施例中，如图7所示的在时间t

图8示出了从目标部署dep2向源部署dep1发送刷新请求。该刷新请求可以由次要部署向主要部署发起以准备将客户端连接从主要部署转换到次要部署(使得次要部署承担主要部署的角色)。刷新请求可以由与客户端账户相关联的用户或系统管理员手动发起以准备在部署之间转换客户端连接。这可以在为当前主要部署的计划的停机时间做准备时进行模拟，也可以在为当前主要部署的意外系统错误或意外不可用做准备时发起。

源部署dep1包括表T的活动文件列表。目标部署d2也包括表T的活动文件列表。如清单框所示，作为示例，当前表版本是342号。该清单包括相关全局文件引用的列表。目标部署d2根据清单将342号表版本的所有活动文件转化为全局文件引用列表。本地添加的微分区fdn27和fdn28分别转化为全局文件引用(dep2，fdn27)和(dep2，fdn28)。如图8所示，只有全局文件引用作为表清单的一部分被发送，并且只有活动文件被发送。

图9是示出用于复制数据库的快照响应900的示意图。响应于刷新请求800，快照响应900由源部署dep1生成。快照响应900可以由主要部署发送到发送刷新请求的次要部署。快照响应900包括以下项中的一项或更多项：(a)要添加到表中的所有微分区元数据；(b)处于重新加密状态的实际微分区；(c)要从表中移除的所有全局微分区引用；(d)从目标部署dep2发送的表版本；以及(e)复制主密钥，微分区是根据该复制主密钥重新加密的。在实施例中，快照响应900被划分为快照响应消息、EP文件和微分区。快照响应900消息可以包括指向EP文件的指针。EP文件可以包括添加的微分区元数据和删除的全局文件引用。EP文件和微分区可以被复制到目标部署d2的入站卷(inbound volume)。

图9示出了源部署dep1向目标部署dep2传输快照响应900。源部署dep1和目标部署dep2中的每个包括表T的活动文件列表。快照响应900出于说明的目的描绘了表版本号342，并指示要被添加和删除的文件和元数据。在图9所示的实施例中，快照响应900指示(fdn15及其相关联的元数据)应该与(fdn16_g(dep0，fdn6)及其相关联的元数据)一起被添加。快照响应900指示应当删除(dep1，fdn12)和(dep0，fdn4)以及(dep2，fdn27)。

图9示出了目标部署dep2的表版本号342被发送回目标部署dep2。如源部署dep1和目标部署dep2之间的差异所示，并且如快照响应900所示，具有短名称fdn15和fdn16_g的微分区需要被添加到目标部署dep2处的表T。此外，具有全局文件引用(dep1，fdn12)、(dep0，fdn4)和(dep2，fdn27)的微分区需要从表T中移除。微分区fdn15和fdn16_g将被重新加密并上载到目标部署dep2的入站卷。复制主密钥是快照响应的一部分(图9中未示出)。

图10是示出用于复制数据库的快照响应的导入1000的示意图。快照响应可由次要部署导入，以准备次要部署具有数据库数据的准确和最新的副本，使得次要部署可在需要时承担主要部署的角色。

在实施例中，当导入快照响应时，如果需要，目标部署dep2处的表将回退到所发送的表版本。快照响应的添加文件可以基于DML的作业ID接收本地短名称，并且可以包括后缀或其它合适的标识符(后缀“_g”在图9-11中被示出)。原始全局文件引用可以被储存作为元数据的一部分。可以使用内存中索引在目标部署dep2将需要被删除的全局文件引用转化为本地短名称。在实施例中，本地短名称被添加到DML的EP文件中作为被删除的短名称部分的一部分。

如图10所示的快照响应的导入1000示出了表T在必要时被回退到表版本号342。如图10中的实施例所示，使用附加有“_g”的本地短名称(例如fdn25_g和fdn26_g)将添加的文件添加到表中。保留原始全局文件引用(包括(dep1，fdn15)和(dep0，fdn6))。此外，被删除的全局文件引用被转化为本地短名称，本地短名称包括(dep1，fdn12)、(dep0，fdn4)和(dep2，fdn27)，它们被转化为fdn22_g、fdn24_g和fdn27。另外，如图10所示，本地删除的短名称被添加到DML的EP文件的删除部分。该表可以由压缩器修剪，并且两个表都可以包含相同的状态。

图11是示出用于复制数据库的部署架构1100的示意图。部署架构1100包括部署D1、部署D2和部署D3。部署D1包括D1复制桶1204，在D1复制桶1204中部署D1接收来自其它部署的消息。类似地，部署D2包括D2复制桶1210，并且部署D3包括D3复制桶1216。复制桶1204、1210、1216中的每个被分成子桶，每个部署包括一个子桶。复制桶1204、1210、1216的每个子桶可以独立地配置有许可和访问凭证。部署D1包括D1 EP/FDN桶1206(即，元数据和微分区桶)，部署D2包括D2 EP/FDN桶121(即，元数据和微分区桶)，并且部署D3包括D2 EP/FDN桶1218(即，元数据和微分区桶)。

在实施例中，当生成新部署时，生成该部署的新复制桶(包括所有部署的所有子桶)，使得其它部署可以向新部署发送消息。此外，可以将部署的新子桶添加到所有其它部署的复制桶中，使得新部署可以向现有部署发送消息。在实施例中，操作(ops)将需要转到每个现有部署以给新部署创建两个新阶段(入站和出站)以注册新部署。

如图11所示的消息传递基础设施提供了使得部署能够通过交换桶上的文件来交换通用消息的基础设施。消息可以经由云储存进行交换，并且对于关联的客户端账户可以是透明的。对于关联的客户端账户，似乎该账户仅与本地微分区上的常规数据保护者(DPO)进行交互。消息服务层可以封装如何对消息DPO进行序列化和交换。

图12是示出包括用于复制数据库的三个部署的全局部署组1200的示意图。在如本文所公开的数据库复制期间，元数据在部署复制组(可称为部署组)内被持久化和交换。生成部署组以使得在每个部署组之间的复制成为可能。在实施例中，每个部署维护组中所有其它部署的列表(包括其自身)。在实施例中，使用“创建部署”数据定义语言(DDL)在每个部署中手动维护该列表，该“创建部署”数据定义语言(DDL)将被用于在组中添加新部署。该DDL可以在每个现有部署上执行。在部署中，可以将账户设置为全局(相对于本地)以形成新的账户复制组或加入现有的账户复制组。只有属于相同账户复制组的账户才可以在组中复制数据。在实施例中，形成新的账户复制组最初是响应于将两个或更多个客户端账户链接在一起的客户端账户请求而执行的。新账户可能会自动与从其发出创建语句的账户放在同一复制组中。

在实施例中，单个账户组中的账户可以将本地对象提升为全局对象，或者可以直接创建全局对象。在各种实施例中，对象可以包括数据库、用户、角色或仓库。一旦对象是全局的，它就可以在全局账户组中的任何账户内进行复制。复制全局对象是通过以下方式实现的：首先在要复制对象的所有账户上为该全局对象创建本地副本对象，以及然后按计划或连续地明确刷新这些副本。在实施例中，只有数据库可以由账户管理员设置为全局的，并且副本只可以由数据库的所有者明确刷新。

在实施例中，存在三类元数据要管理和复制。一类元数据针对部署，其包括关于通过复制手动创建和复制的部署组的每个部署的元数据。一类元数据针对全局账户，其中部署的所有全局账户可以复制到该部署所属的部署组中的所有其它部署。一类元数据包括全局数据库，全局数据库包括账户上的所有全局数据库，这些全局数据库也可以在相同账户组中复制。在实施例中，只有关于全局数据库的所有副本的信息在账户组中被复制到账户组存在的部署子集。

图12示出了使用包括三个部署(部署D1、部署D2和部署D3)的全局部署组的示例。如图12所示，部署D1包括五个账户，五个账户包括D1.A1、D1.A2、D1.A3、D1.A4和D1.A5。部署D2包括四个账户，四个账户包括D2.A1、D2.A2、D2.A3和D2.A4。部署D3包括四个账户，四个账户包括D3.A1、D3.A2、D3.A3和D3.A4。在图12所示的实施例中，存在不属于任何组并且不能具有全局对象的四个本地账户。四个本地账户包括D1.A3、D2.A2、D3.A3和D3.A4并且用虚线示出。只有全局账户(即，用实线示出且阴影部分没有填充、浅灰色填充或深灰色填充的账户)可以创建或复制全局数据库。在图12所示的示例中，存在包括DB1、DB2、DB3和DB4的四个全局数据库。同一全局数据库只可以在同一账户组中存在或复制。在图12所示的示例中，DB1和DB2是只可以在包括D1.A1、D1.A4、D2.A4和D3.A2的账户组内复制的全局数据库。此外，DB3只可以在包括D1.A2和D2.A1的账户组内复制。此外，DB4只可以在包括D1.A5和D2.A3的账户组内复制。另外，如图12所示，全局数据库不一定被全局账户组内的所有账户复制。例如，深色阴影账户组的客户端所有者(与DB1和DB2相关联)没有使用D1.A4账户复制DB2。

在实施例中，关于全局对象的所有副本的元数据被复制到账户组中的所有账户。在特定实施例中，这可以允许本地账户(即，用虚线示出的那些)管理员列出组中任何全局对象的所有副本(本地的或远程的)。这可以使客户端账户管理员能够通过指定正在创建的新对象是该全局对象的副本来在账户组(例如，以无填充、浅灰色填充或深灰色填充示出的账户组)中的其它账户中生成该全局对象的新副本。

例如，账户D2.A4的客户端账户(与深灰色填充账户组相关联)希望将全局数据库DB2复制到该账户。在该账户中，客户端账户可以执行命令以显示全局数据库。该命令将列出账户组中所有全局数据库的副本。基于此示例，该命令将显示五个示例，如下表1所示。

如表1所示，“复制组”列描绘相同数据库的所有副本的相同的值。数据库副本像账户组中的账户一样链接在一起。这些数据库还形成复制组，其标识号等于复制组号。关于上述示例，D2.A4的客户端账户可以通过发出命令在名称为“0400d847-4199-4f79-9a74-381761bc0cc9”的数据库复制组中创建新副本来这样做。应当理解，副本的本地名称可以是任何名称，并且指定复制组标识号使得数据库成为与该组中的其它数据库相同的复制组的一部分。在生成新的数据库副本后，D2.A4的客户端账户然后可以发出命令以显示所有数据库副本，并且然后将接收一个包含刚刚生成的副本的列表，如下面的表2所示。

除上述示例外，从该组中任何账户(即D1.A1或D1.A4)发出的相同命令将生成完全相同的列表。复制的元数据的传播可能需要一段时间(例如可能需要几秒钟)，并且在这段时间之后所有其它部署都将知道新的副本。

类似于“显示全局数据库”命令，可以发出“显示全局账户”命令以生成组中的账户的集合的列表。继续上述示例，如果D3.A2的客户端账户发出“显示全局账户”命令，则它将返回如下面表3中的列表。

如表3所示，由于对于给定客户只有一个账户复制组，因此未公开账户复制组标识号。从部署组中的任何客户端账户运行相同的命令时，该命令将生成显示所有账户组的列表，并且在这种情况下，可以添加一列，该列显示复制组标识号。

部署组中的每个部署都可以维护关于组中所有全局账户的元数据。再次，使用上述示例，每个部署可以维护所有全局账户的列表，即D1.A1、D1.A2、D1.A4、D1.A5、D2.A1、D2.A2、D3.A1和D3.A3。所有全局账户的列表都可以完全被复制。此外，每个部署将维护关于该部署中存在的账户组的子集中的所有全局对象的元数据。仍然使用该示例，部署D1维护关于无填充、浅灰色和深灰色子组拥有的所有全局对象的元数据。因为部署D2仅托管来自深灰色且没有填充的账户组的账户，所以它仅需要维护关于属于这两个账户组的数据库的元数据。此外，部署D3必须仅维护关于在浅灰色和无填充账户组中的全局数据库的信息。

在每个部署中，可以利用单个数据持久性对象(“DPO”)，并可以将其命名为GlobalEntitiesDPO。DPO描述了可以保留在元数据储存装置中的元数据对象的表示，其中元数据储存装置与数据库数据分开。GlobalEntitiesDPO是特定于“全局”或“复制”对象的DPO。全局/复制特定信息可以包括源部署信息、源账户信息、复制UUID、外部UUID等。单个DPO可以储存关于包括全局账户的所有全局对象副本的元数据。可以在账户组中将账户建模为相同全局账户的副本。因此，关于全局账户和达到级别的账户实体(to-level accountentities)(例如数据库、用户、角色和仓库)的信息是统一的。此外，对于每个部署，GlobalEntitiesDPO可以储存关于部署需要知道的任何全局实体副本的信息，即关于部署需要知道的所有全局账户和数据库副本(例如，部署中存在的任何账户组中的任何副本)的信息。

除了在部署之间复制其内容的GlobalEntitiesDPO之外，部署还可以标识部署中是全局的所有实体。为此，不需要新的DPO，但可以增强可以保留在元数据储存装置中的对象的现有表示(可以称为“BaseDictionaryDPO”。可以为全局标识号添加字段，如果不为空，则其将指示字典实体(dictionary entity)是全局的。此外，可以通过添加名称为“全局的”的新切片(slice)来索引所有全局字典实体以查找给定全局标识号的任何全局实体。在实施例中，这可以简化在特定部署或特定账户中查找特定类型的所有全局实体的过程。

在实施例中，生成全局数据库包括在全局数据库复制组中创建第一主副本。创建此第一个主副本后，可自动为其创建全局数据库复制组。可以使用“复制组”命令创建组中的其它副本。

在实施例中，全局对象可以被转化回本地对象。可以向客户端或管理员账户提供改变账户的命令以将现有的全局账户转换为本地账户。作为此命令的副作用，可以使账户内的所有全局对象成为本地的。此外，可以使用类似的命令将单个全局数据库制作回常规本地数据库。

在实施例中，对副本所做的任何更改将被复制到对该更改感兴趣的所有其它部署。更改可以包括创建、丢弃(drop)、更新或其它调整。对更改的复制将尽可能快地进行，并且可能在不到五秒钟的时间内进行。此外，即使没有任何更改，也将在定期的时间段(例如每小时一次)复制部署中创建的所有副本。这可以确保如果发生任何故障，仍然会有一定的覆盖范围。

图13是用于在多部署数据库系统中转换客户端连接的方法1300的示意性流程图表图。方法1300可以由任何合适的计算资源(例如如本文所公开的资源管理器402或复制和故障转移管理器528)来执行。

方法1300开始于1302，并且在1302，计算资源维护在客户端与数据库的第一部署之间的客户端连接，使得数据库流量发生在第一部署处。方法1300继续，并且在1304，计算资源生成引用第一部署的第一连接对象和第二部署的第二连接对象的唯一标识。在1306，计算资源接收第一部署不可用的通知。在1308，计算资源向第二部署提供外部连接组唯一标识以用于第二部署确定客户端是否应该被连接到第二部署。外部连接组唯一标识向客户端提供客户端与哪个连接组相关联的指示。外部连接组唯一标识可以基于唯一标识。如果客户端应该被连接到第二部署，则在1310，计算资源从第二部署接收统一资源定位符(URL)。

图14是描绘示例计算设备1400的框图。在一些实施例中，计算设备1400用于实现本文讨论的一个或更多个系统和部件。例如，计算设备1400可以允许用户或管理员访问资源管理器1402。此外，计算设备1400可以与本文描述的任何系统和部件交互。因此，计算设备1400可以用于执行各种程序和任务，例如在本文中所讨论的程序和任务。计算设备1400可以用作服务器、客户端或任何其他计算实体。计算设备1400可以是各种计算设备(例如台式计算机、笔记本计算机、服务器计算机、手持计算机、平板计算机等)中的任何一种。

计算设备1400包括一个或更多个处理器1402、一个或更多个存储器设备1404、一个或更多个接口1406、一个或更多个大容量储存设备1408、以及一个或更多个输入/输出(I/O)设备1410，它们全部都耦合到总线1412。处理器1402包括执行储存在存储器设备1404和/或大容量储存设备1408中的指令的一个或更多个处理器或控制器。处理器1402还可以包括各种类型的计算机可读介质，诸如，高速缓冲存储器。

存储器设备1404包括各种计算机可读介质，例如易失性存储器(例如随机存取存储器(RAM))和/或非易失性存储器(例如只读存储器(ROM))。存储器设备1404还可以包括可重写ROM，诸如，闪存。

大容量储存设备1408包括各种计算机可读介质，例如磁带、磁盘、光盘、固态存储器(例如闪存)等等。在大容量储存设备1408中还可以包括各种驱动器以使得能够从各种计算机可读介质读取和/或写入各种计算机可读介质。大容量储存设备1408包括可移动介质和/或不可移动介质。

I/O设备1410包括允许将数据和/或其它信息输入到计算设备1400、或从计算设备1400取回数据和/或其它信息的各种设备。示例I/O设备1410包括光标控制设备、键盘、小键盘、麦克风、监视器或其它显示设备、扬声器、打印机、网络接口卡、调制解调器、透镜、CCD或其它图像捕获设备、等等。

接口1406包括允许计算设备1400与其它系统、设备或计算环境交互的各种接口。示例接口1406包括任何数量的不同的网络接口，例如到局域网(LAN)、广域网(WAN)、无线网络、和互联网的接口。

总线1412允许处理器1402、存储器设备1404、接口1406、大容量储存设备1408、以及I/O设备1410彼此通信、以及与耦合到总线1412的其它设备或部件通信。总线1412表示在几种类型的总线结构中的一种或更多种，诸如系统总线、PCI总线、IEEE 1394总线、USB总线等等。

为了说明的目的，程序和其他可执行程序部件在本文中被示出为离散的块，但是应当理解，这种程序和部件可以在不同时间驻留在计算设备1400的不同存储部件中，并且由处理器1402执行。可替代地，在本文中描述的系统和程序可以通过硬件、或硬件、软件和/或固件的组合来实现。例如，一个或更多个专用集成电路(ASIC)可经编程来执行本文所描述的系统和程序中的一个或更多个。如本文所使用的，术语“模块”旨在传达为了执行查询操作的全部或部分的目的用于完成过程的实现器件(例如通过硬件、或硬件、软件和/或固件的组合)。

以下示例涉及另外的实施例。

示例1是用于在多部署数据库系统中转换客户端连接的系统。系统包括用于维护客户端和第一部署之间的客户端连接的装置。系统包括用于生成引用第一部署的第一连接对象和第二部署的第二连接对象的唯一标识的装置。系统包括用于接收第一部署不可用的通知的装置。系统包括用于向第二部署提供外部连接组唯一标识以用于第二部署确定客户端是否应该被连接到第二部署的装置。系统包括用于从第二部署接收统一资源定位符的装置。

示例2是如示例1中的系统，其中，确定客户端是否应该被连接到第二部署包括第二部署使用外部连接组唯一标识执行查找，其中：如果查找为真，则客户端连接应该转换到第二部署；并且如果查找为假，则客户端连接不应转换到第二部署。

示例3是如示例1-2中任一示例的系统，其中，客户端连接将客户端指向当前主要部署，并使流量被导向当前主要部署，其中流量包括对数据库数据的更新或对数据库数据的查询中的一个或更多个。

示例4是如示例1-3中任一示例的系统，其中，客户端连接使得对数据库数据的更新首先在当前主要部署上执行，使得所述更新可以基于当前主要部署而被传播到一个或更多个次要部署。

示例5是如示例1-4中任一示例的系统，其中，第一部署和第二部署是以下项中的一项或更多项：由不同的计算资源服务；位于不同的地理区域；由不同的基于云的数据库提供商提供服务；储存与客户端相关联的不同数据库数据；或者储存与不同客户端相关联的不同数据库数据。

示例6是如示例1-5中任一示例的系统，其中，第一部署不可用的通知包括以下项中的一项或更多项：从第一部署接收的无效连接的通知；或者从第一部署接收的错误代码。

示例7是如示例1-6中任一示例的系统，其中，用于向第二部署提供外部连接组唯一标识的装置被配置为还向一个或更多个附加部署提供外部连接组唯一标识，以确定第二部署或一个或更多个附加部署中的哪一个部署匹配外部连接组唯一标识并且应该被连接到客户端，并且其中第二部署或一个或更多个附加部署中只有一个部署匹配外部连接组唯一标识。

示例8是如示例1-7中任一示例的系统，其中，由于客户端和第一部署之间的无效连接，第一部署是不可用的，其中由于以下项中的一项或更多项，第一部署是不可用的：第一部署处的错误；第一部署的计划的停机时间；第一部署处的断电；第一部署处的意外停机时间；或者中断客户端和第一部署之间的客户端连接的计划的转换。

示例9是如示例1-8中任一示例的系统，还包括用于将客户端连接从第一部署转换到第二部署使得在第二部署处执行数据库流量的装置，其中，用于转换客户端连接的装置被配置为响应于从第二部署接收到统一资源定位符而转换。

示例10是如示例1-9中任一示例的系统，其中，客户端连接使得对数据库数据的更新在可应用的主要部署处执行，并且其中，该系统还包括用于执行以下操作的装置：将在可应用的主要部署处对数据库数据进行的更新复制到一个或更多个次要部署使得一个或更多个次要部署包括数据库数据的最新版本并且如果可应用的主要部署变得不可用，则可以接管作为新的主要部署。

示例11是用于在多部署数据库系统中转换客户端连接的方法。方法包括维护客户端和第一部署之间的客户端连接，使得数据库流量在第一部署处发生。方法包括生成引用第一部署的第一连接对象和第二部署的第二连接对象的唯一标识。方法包括接收第一部署不可用的通知。方法包括向第二部署提供外部连接组唯一标识以用于第二部署确定客户端是否应该被连接到第二部署。方法包括如果客户端应该被连接到第二部署，则从第二部署接收统一资源定位符。

示例12是如示例11中的方法，其中，第一部署不可用的通知基于客户端和第一部署之间的无效连接，其中，由于以下项中的一项或更多项，第一部署不可用：第一部署处的错误；第一部署的计划的停机时间；第一部署处的断电；第一部署处的意外的停机时间；或者中断客户端和第一部署之间的客户端连接的计划的转换。

示例13是如示例11-12中任一示例中的方法，还包括响应于从第二部署接收到统一资源定位符，将客户端连接从第一部署转换到第二部署，使得在第二部署执行数据库流量。

示例14是如示例11-13中任一示例中的方法，其中，向第二部署提供外部连接组唯一标识包括从客户端向第二部署发送REST(表现层状态转化)请求。

示例15是如示例11-14中任一示例中的方法，其中，接收第一部署不可用的通知包括从第一部署接收错误代码，并且其中，该方法还包括：响应于接收到错误代码，向第一部署发送重试请求；从第一部署接收新的错误代码；以及响应于从第一部署接收到新的错误代码，向第二部署提供外部连接组唯一标识。

示例16是可编程为执行储存在非暂时性计算机可读储存介质中的指令的处理器，所述指令包括：维护客户端和第一部署之间的客户端连接，使得数据库流量发生在第一部署处；生成引用第一部署的第一连接对象和第二部署的第二连接对象的唯一标识；接收第一部署不可用的通知；向第二部署提供外部连接组唯一标识，以用于第二部署确定客户端是否应该被连接到第二部署；以及如果客户端应该被连接到第二部署，则从第二部署接收统一资源定位符。

示例17是如示例16中的处理器，其中，第一部署不可用的通知基于客户端和第一部署之间的无效连接，其中，由于以下项中的一项或更多项，第一部署不可用：第一部署处的错误；首第一部署的计划的停机时间；第一部署处的断电；第一部署处的意外的停机时间；或者中断客户端和第一部署之间的客户端连接的计划的转换。

示例18是如示例16-17中任一示例中的处理器，其中，指令还包括，响应于从第二部署接收到统一资源定位符，将客户端连接从第一部署转换到第二部署，使得在第二部署执行数据库流量。

示例9是如示例16-18中任一示例中的处理器，其中，接收第一部署不可用的通知包括从第一部署接收错误代码，并且其中，所述指令还包括：响应于接收到错误代码，向第一部署发送重试请求；从第一部署接收新的错误代码；以及响应于从第一部署接收到新的错误代码，向第二部署提供外部连接组唯一标识。

示例20是如示例16-19中任一示例中的处理器，其中，确定客户端是否应该被连接到第二部署包括第二部署使用唯一标识执行查找，其中：如果查找为真，则客户端连接应该转换到第二部署；并且如果查找无效或为假，则客户端连接不应转换到第二部署。

示例21是实现如本文公开的方法、系统和设备的“真实世界”示例。应当理解，这个真实世界示例是非限制性的，并且仅作为示例性实现方式被提供仅用于解释目的。在这个示例中，“客户端”可以指关于数据库系统的账户，其与数据库连接并且传输对数据库的更新和查询。此外，在该示例中，“用户”可以指与客户端相关联的个人或实体。

在示例21中，客户端具有三个数据库部署(部署D1、部署D2和部署D3)。三个部署中的每个位于不同的地理区域。部署D1位于美国西海岸，部署D2位于美国东海岸，以及部署D3位于中国。用户更喜欢西海岸部署(即D1部署)是数据库数据的主要部署。因此，用户也更喜欢东海岸部署(即部署D2)和中国部署(即部署D3)两者都是次要部署。每个部署维护数据库数据的完整副本(包括所有表、所有微分区、所有版本历史记录和所有元数据)。出于任何原因，用户可能更喜欢将部署D1作为主要部署。例如，部署D1可能更靠近用户的营业地点，部署D1的运营可能更便宜，用户可能认为部署D1更可靠，等等。可替代地，用户可能不具有关于哪个部署是主要部署的任何偏好，并且这可以由基于云的数据库提供商默认设置。

关于示例21，当客户端在数据库上发起DML命令(即插入、更新、删除或合并)时，将在主要部署(即位于西海岸的部署D1)上执行DML命令。通过本文公开的复制方法和系统(例如参见图6-11)，对主要部署进行的更新被传播到每个次要部署。用户可能希望使部署D1(即西海岸部署)离线以进行计划的维护。在准备使部署D1离线时，客户端可能让每个次要部署向部署D1发送刷新请求，以确保每个次要部署是部署D1的准确和最新的副本。用户可能希望在部署D1离线进行计划的维护时将部署D2作为新的临时主要部署。此外，当部署D2暂时用作主要部署并且部署D1离线时，用户可能希望使部署D3用作部署D2的备份。因此，部署D3将继续用作次要部署，以及部署D2将临时用作新的主要部署。客户端或与数据库提供商相关联的系统管理员可以发起连接转换，使得客户端连接到部署D2而不是部署D1，为部署D2离线做准备。

关于示例21，连接转换被发起，并且部署D1不能再与客户端进行通信。部署D1向客户端返回无效连接的通知。响应于从部署D1接收到无效连接的通知，客户端向部署D2和部署D3提供外部连接组UUID(即，conn_uuid，参见216或316)，以确定哪个次要部署应该成为新的主要部署。部署D2和部署D3中的每个部署接收外部连接组唯一标识，并使用外部连接组唯一标识执行查找。当部署D2执行查找时，查找将为真，因为部署D2被计划成为新的主要部署。响应于查找为真，部署D2将向客户端返回URL。客户端将使用URL以连接到部署D2，并在部署D2处恢复数据库操作。当部署D3使用外部连接组唯一标识执行查找时，由于未计划部署D3承担主要部署的角色，因此查找将返回无效或错误的结果。响应于查找无效，部署D3将返回查找无效的指示，并且客户端将不尝试连接到部署D3。只要有必要，客户端就可以连接到部署D2。例如，客户端可以在部署D1离线的时间期间连接到部署D2，以及然后转换回部署D1。在客户端转换回部署D1之前，需要将部署D1离线时对部署D2所做的所有更新传播到部署D1，使得部署D1是数据库数据的准确且最新的表示。

示例22是类似于示例21的真实世界示例。在示例22中，没有从部署D1到部署D2的计划的连接转换。相反，由于系统错误、断电或其他故障，部署D1意外地变得不可用，并且部署D2必须承担主要部署的角色，使得即使主要部署(即，部署D1)意外地不可用，数据库操作也可以继续。示例22表示其中如本文公开的复制方法、系统和设备非常有益并且为客户端提供安全的实现方式。

在示例22中，部署D1意外地变得不可用。对于客户端到数据库的连接没有计划的连接转换。因为部署D1不可用，所以客户端不能再连接到部署D1。客户端接收错误代码。客户端向部署D1发送重试请求，并再次接收错误代码。客户端向部署D2和部署D3中的每个部署发送查找请求。连接请求包括外部连接组UUID(即“conn__uuid”)。类似于关于示例21讨论的实现方式，部署D2和部署D3中的每个部署使用外部连接组UUID来执行查找。因为部署D2是当部署D1变得不可用时的默认备份部署，所以部署D2执行的查找将返回为真，并且部署D2将向客户端提供URL，使得客户端可以连接到部署D2。

本文所述的系统和方法允许将数据作为与计算(或处理)资源分开的服务来储存和访问。即使没有从执行平台分配计算资源，数据也可用于虚拟仓库而无需从远程数据源重新加载数据。因此，数据是独立于与数据相关联的计算资源的分配而可用的。所描述的系统和方法对于任何类型的数据都是有用的。在特定实施例中，数据以结构化的优化格式储存。数据储存/访问服务与计算服务的解耦也简化了不同用户和组之间的数据共享。如本文所讨论的，即使在其它虚拟仓库访问相同数据的同时，每个虚拟仓库也可以访问它具有访问权限的任何数据。此架构支持运行查询，而无需在本地高速缓存中储存任何实际数据。本文所述的系统和方法能够进行透明的动态数据移动，该透明的动态数据移动根据需要以对系统用户透明的方式将数据从远程储存设备移动到本地高速缓存。此外，因为(由于数据储存服务与计算服务的解耦)任何虚拟仓库可以访问任何数据，所以该架构支持数据共享而无需事先进行数据移动。

尽管根据特定优选实施例描述了本公开，但是，鉴于本公开的益处，其它实施例(包括未提供本文阐述的所有益处和特征的实施例，它们也在本公开的范围内)对于本领域普通技术人员将是明显的。要理解的是，其他的实施例可以被使用，而不偏离本公开的范围。