CN111656340A - 在数据库系统中的数据复制和数据故障转移 - Google Patents

在数据库系统中的数据复制和数据故障转移 Download PDF

Info

Publication number
CN111656340A
CN111656340A CN201980010014.2A CN201980010014A CN111656340A CN 111656340 A CN111656340 A CN 111656340A CN 201980010014 A CN201980010014 A CN 201980010014A CN 111656340 A CN111656340 A CN 111656340A
Authority
CN
China
Prior art keywords
deployment
primary
primary deployment
database
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201980010014.2A
Other languages
English (en)
Other versions
CN111656340B (zh
Inventor
本诺特·戴奇维勒
埃里克·罗宾逊
马丁·亨切尔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Snowflake Co
Original Assignee
Snowflake Computing Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Snowflake Computing Inc filed Critical Snowflake Computing Inc
Publication of CN111656340A publication Critical patent/CN111656340A/zh
Application granted granted Critical
Publication of CN111656340B publication Critical patent/CN111656340B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Abstract

公开了数据库数据的复制和故障转移。一种方法包括复制存储在初级部署中的数据库数据，使得数据库数据还被存储在次级部署中。该方法包括当初级部署是不可用的时在次级部署处执行对数据库数据的一个或更多个更新，以及当初级部署再次变得可用时将该一个或更多个更新传播到初级部署。该方法包括当初级部署是可用的时在初级部署处执行对数据库数据的查询。

Description

在数据库系统中的数据复制和数据故障转移
相关申请的交叉引用
本申请要求2018年7月6日提交的标题为“SYSTEMS,METHODS,AND DEVICES FORDATABASE REPLICATION”的美国临时申请序列号62/694,656的利益，该临时申请的公开通过引用以其整体并入本文，包括但不限于在下文中特别出现的那些部分，通过引用进行的并入在下面的例外的情况下做出：如果上面提及的临时申请的任何部分与本申请不一致，则本申请取代所述上面提及的临时申请。
技术领域
本公开涉及数据库，且更具体地涉及在数据库系统中的数据复制和故障转移(failover)。
背景
数据库广泛用于在计算应用中的数据存储和访问。数据库存储的目标是以有组织的方式提供大量的信息，使得它可以被访问、管理和更新。在数据库中，数据可以被组织成行、列和表。不同的数据库存储系统可以用于存储不同类型的内容，例如书目、全文本、数字和/或图像内容。此外，在计算中，可以根据数据库的组织方法来将不同的数据库系统分类。有许多不同类型的数据库，包括关系数据库、分布式数据库、云数据库、面向对象的数据库以及其他数据库。
数据库被各种实体和公司使用来存储可能需要被访问或分析的信息。在一个示例中，零售公司可以在数据库中存储所有销售交易的列表。数据库可以包括关于交易何时发生、它发生在何处、交易的总成本、在交易中购买的所有物品的标识符和/或描述等的信息。同一零售公司还可以在此同一数据库中存储例如雇员信息，雇员信息可以包括雇员姓名、雇员联系信息、雇员工作历史、雇员工资率等。根据该零售公司的需要，雇员信息和交易信息可以存储在同一数据库的不同表中。当零售公司想要了解存储在数据库中的信息时，它可能有“查询”它的数据库的需要。该零售公司可能想要找到关于例如在某个商店工作的所有雇员的姓名、在某个日期工作的所有雇员、在某个时间范围期间针对某个产品做出的所有交易等的数据。
当零售店想要查询它的数据库以从数据库中提取某些有组织的信息时，对数据库数据执行查询语句。根据指示什么信息应该由查询返回的一个或更多个查询谓词，该查询返回某些数据。该查询从数据库中提取特定数据，并将该数据格式化为可读形式。可以用数据库所理解的语言例如结构化查询语言(“SQL”)来写查询，因此数据库系统可以确定什么数据应该被定位以及它应该如何被返回。该查询可以请求存储在数据库内的任何相关信息。如果适当的数据可以被找到以对查询做出响应，则数据库有可能揭示复杂的趋势和活动。只能通过成功地执行的查询的使用来利用这个能力。
传统的数据库管理需要公司供应基础设施和资源来管理在数据中心中的数据库。传统数据库的管理可能是非常昂贵的，且需要由具有宽范围的技术技能集的多个人进行监督。传统的关系数据库管理系统(RDMS)需要大规模的计算和存储资源，并且具有有限的可扩展性。大量数据可以跨多个计算设备被存储。服务器可以管理数据，使得客户可以使用本地部署的(on-premises)操作对其进行访问。对于希望拥有内部数据库服务器的实体，该实体必须在硬件和数据库的基础设施的资本投资上、以及用于存储数据库基础设施的相当大的物理空间上花费相当多的资源。此外，在断电或其他灾难情况期间，数据库可能非常容易遭受数据丢失。这种传统的数据库系统具有显著的缺点，这些缺点可以由基于云的数据库系统减轻。
云数据库系统可以通过云平台被部署和交付，该云平台允许组织和最终用户存储、管理和检索来自云的数据。一些云数据库系统包括通过在计算云之上安装数据库软件来实现的传统数据库架构。数据库可以通过Web浏览器或应用编程接口(API)来访问，用于应用和服务整合。一些云数据库系统由代表客户端直接管理数据库安装、部署和资源分配任务的后端过程的供应商操作。客户端可能有通过Web浏览器和/或API访问数据库的多个最终用户。云数据库可以通过减轻丢失数据库数据的风险和允许数据由跨多个地理区域的多个用户访问来向一些客户端提供显著的好处。
对于传统数据库系统和云数据库系统，存在多种架构。一个示例架构是共享磁盘系统。在共享磁盘系统中，所有数据都被存储在从数据群集中的所有处理节点可访问的共享存储设备上。在这种类型的系统中，所有数据更改被写到共享存储设备以确保数据群集中的所有处理节点访问一致版本的数据。当在共享磁盘系统中处理节点的数量增加时，共享存储设备(以及在处理节点和共享存储设备之间的通信链路)成为减慢数据读取和写入操作的瓶颈。随着更多处理节点的添加，这一瓶颈进一步加重。因此，由于这个瓶颈问题，现有的共享磁盘系统具有有限的可扩展性。
在一些实例中，将数据库数据复制在多个位置上或在多个存储设备上可能是有益的。复制数据可以预防可能使数据变得通过云网络不可访问和/或可能导致数据将要丢失或永久不可读的系统故障。如本文所公开的，复制数据库数据可以提供额外的好处和改进。
鉴于前述内容，本文公开了用于数据库复制的系统、方法和设备。
附图简述
参考下面的附图描述了本公开的非限制性的和非穷尽的实现，在附图中，除非另有规定，否则相似的参考数字在全部各个视图中指相似或类似的部分。本公开的优点将关于下面的描述和附图变得更好理解，其中：
图1示出了根据本公开的教导和原理的检索和数据存储系统的部件的框图；
图2示出了描绘根据本公开的教导和原理的资源管理器的实施例的框图；
图3示出了描绘根据本公开的教导和原理的执行平台的实施例的框图；
图4示出了根据本公开的教导和原理的操作环境的部件的框图；
图5示出了根据本公开的教导和原理的用于生成数据库快照的过程流程的示意图；
图6示出了根据本公开的教导和原理的用于生成用于复制数据库的事务日志的过程流程的示意图；
图7示出了根据本公开的教导和原理的用于复制数据库的两个不同事务的过程流程的示意图；
图8示出了根据本公开的教导和原理的包括用于数据库的复制的准备阶段的过程流程的示意图；
图9示出了根据本公开的教导和原理的刷新请求的生成和传输；
图10示出了根据本公开的教导和原理的快照响应的生成和传输；
图11示出了根据本公开的教导和原理的快照响应的导入；
图12示出了根据本公开的教导和原理的部署架构的示意图；
图13示出了根据本公开的教导和原理的用于发送消息的过程流程的示意图；
图14示出了根据本公开的教导和原理的用于接收消息的过程流程的示意图；
图15示出了根据本公开的教导和原理的全局部署组的示意图；
图16示出了根据本公开的教导和原理的加密系统的示意图；
图17示出了根据本公开的教导和原理的加密系统的示意图；以及
图18示出了根据本公开的教导和原理的用于数据库故障转移的方法的示意流程图；以及
图19示出了根据本公开的教导和原理的示例计算设备。
详细描述
本文公开了用于在多个数据库部署或数据库提供商之间的成批数据库复制和故障转移的系统、方法和设备。本公开的系统使数据库数据存储在初级部署中，并被复制在一个或更多个次级部署中。如果在初级部署中的数据是不可用的，事务可以在次级部署中的一个或更多个上被执行。当原始初级部署再次变得可用时，在次级部署上执行的任何事务都可以传播到初级部署。该系统可以被配置成使得在当初级部署是可用的时的任何时间，对数据库数据的查询在初级部署上被执行。
在一些实例中，跨多个部署复制数据库数据是合乎需要的。对于一些数据库客户端，存储在任何次级部署中的数据代表存储在初级部署中的数据的非陈旧且最新的副本是势在必行的。所复制的数据库可能对于灾难恢复的目的是合乎需要的。如果初级部署失败或变得以其他方式不可用，一个或更多个次级部署可以充当备用物以承担操作。此外，所复制的数据库可能对于提高读取性能是合乎需要的。可以通过将请求路由到在地理上离客户端帐户最近的部署以减少总的请求处理延时来提高读取性能。鉴于前述内容，本文公开的系统、方法和设备提供了生成和更新初级部署的事务一致副本的手段，使得一个或更多个次级部署总是与初级部署同步。
在一个实施例中，数据库数据在初级部署和一个或更多个次级部署之间被复制。此外，在一个实施例中，执行从初级部署到次级部署的故障转移，并且可以执行从次级部署回到原始初级部署的故障恢复。
在一个实施例中，公开了一种用于在多个部署之间对数据库数据进行故障转移的方法。该方法包括复制存储在初级部署中的数据库数据，使得数据库数据还被存储在次级部署中。该方法包括响应于确定初级部署是不可用的而在次级部署处对数据库数据执行一个或更多个事务。该方法包括响应于确定初级部署不再是不可用的而将在数据库数据上的一个或更多个事务传播到初级部署。该方法包括当初级部署是可用的时在初级部署处对数据库数据执行查询。
数据库数据可以存储在跨地理区域可访问的基于云的存储中。这个基于云的存储指的是存储在异地(off-site)存储系统处的数据库数据，异地存储系统在一些实现中可以由第三方维护。例如，客户端可以选择利用云存储提供商来存储数据，而不是将数据存储在客户端所拥有的本地计算机硬盘驱动器或其他本地存储设备上。客户端可以通过在客户端的计算资源和存储客户端的数据的异地存储资源之间的互联网连接来访问数据。数据库数据的云存储可以提供优于传统的现场(on-site)本地存储的几个优点。当数据库数据被存储在云存储中时，可以在具有互联网连接的任何位置处访问信息。因此，数据库客户端不需要移动物理存储设备或使用同一计算机来保存、更新或检索数据库信息。此外，数据库信息可以由在不同地理位置处的多个用户同时访问、更新和保存。客户端可以通过互联网将文件的副本发送到与云存储提供商相关联的、记录这些文件的数据服务器。客户端可以通过借助于基于Web的接口或其他用户接口访问与云存储提供商相关联的数据服务器来检索数据。然后，与云存储提供商相关联的数据服务器可以将文件发送回客户端，或者允许客户端访问和操纵在数据服务器本身上的文件。
云存储系统通常包括可以为多个客户端服务的数百或数千个数据服务器。因为计算机偶尔需要维护或修理并且因为计算机偶尔出现故障，所以在多台机器上存储相同的信息是重要的。这种冗余可以确保客户端可以在任何给定时间访问它们的数据，即使在服务器故障的情况下。
在本公开的实施例中，数据库数据存储在多个云存储部署中。这样的云存储部署可以位于不同的地理位置上，并且数据库数据可以跨在每个部署中的多台机器和/或服务器被存储。云存储部署可以位于单个地理位置上，但是可以连接到不同的电源和/或使用不同的计算机器来存储数据。云存储部署可以由不同的云存储提供商操作。在这样的实施例中，数据库数据跨多个部署被复制，使得在一个部署变得不可用或出现故障的情况下，数据库数据可以继续被访问、更新和保存。在一个实施例中，数据库数据存储在初级部署中，并且还被存储在一个或更多个次级部署中。当初级部署是可用的时，初级部署可随时用于访问、查询和更新数据。如果初级部署变得不可用，以及当初级部署变得不可用时，一个或更多个次级部署可以承担操作。当初级部署再次变得可用时，可以用当初级部署是不可用的时在一个或更多个次级部署上出现的任何变化来更新初级部署。然后，已更新的初级部署可以承担操作，包括访问、查询和更新数据。
当数据存储在多个部署中时，确保数据在每个部署中是一致的很重要。当数据被更新、修改或添加到初级部署时，更新可以跨一个或更多个次级部署被传播，以确保所有部署都具有一致且最新的版本的数据。在初级部署变得不可用的情况下，每个最新的次级部署可以在数据不是陈旧的或不正确的情况下承担数据的操作。此外，当多个部署中的任何部署变得不可用时，可以稍后用在当该部署是不可用的时的时间期间进行的所有改变来更新该部署。当部署在“离线”或不可用之后被更新时，确保仅用在该部署是不可用的时间期间进行的那些改变来更新该部署可能是有益的。
现有的数据复制方法通常通过快照策略或日志记录策略来实现。在有对源数据库做出的更改之后，快照策略生成源数据库的当前状态的串行化表示。然后，基于快照来重新填充目标数据库，且这对于对源数据库做出的更改出现。日志记录策略以初始(即空的)数据库状态开始，并记录由每个成功事务对源数据库所做出的更改。更改的序列定义了源数据库的“事务日志”，且在事务日志中的每个更改都对目标数据库以确切地相同的顺序重放(replay)。
快照策略通过获取源数据库的快照并从该快照实例化(instantiate)目标数据库来解决复制。然而，使用快照策略，产生或消耗快照大致取决于如以要复制的对象的数量以及可能被存储的字节的数量测量的数据库的大小。快照策略可能需要对每个事务的O(数据库的大小)操作以维护最新的目标数据库。在源数据库上的每个成功事务之后执行O(数据库的大小)操作可能对于除了小的或相对静态的数据库之外的所有数据库是不切实际的。
日志记录策略试图通过将传播由单独事务做出的更改的成本一直降低到仅仅大致为事务本身的大小来解决快照策略的问题。在修改数据库的每个成功事务之后执行O(事务的大小)操作可能需要更少的计算资源。然而，日志记录策略需要被应用于源数据库的每个事务的日志记录，因为它是为了产生副本目标数据库而被创建的。执行O(事务日志的大小)操作以便引导(bootstrap)目标数据库可能比引导快照(bootstrap off a snapshot)更昂贵。此外，日志记录对在复制逻辑中的缺陷(bug)的抵抗力可能较低，因为在复制逻辑中的缺陷可能导致在源数据库和目标数据库之间的不一致性或偏移。当偏移出现时，尽可能快地校正它是势在必行的。如果缺陷在源数据库处(即，在日志记录的产生中)，那么它已经被记录到事务日志本身中，且这可能难以调整或校正。可选地，如果缺陷在目标数据库处(即，在日志记录的消耗中)，那么可以通过从头开始重放事务日志来重新创建目的地，但是这可能需要相当多的计算资源。
在某些实现中，快照策略或日志记录策略对于复制数据库数据都不是切合实际的或可行的。本文公开了将快照与事务日志组合的混合策略。
本文公开的用于数据库复制的混合方法将快照的使用与事务日志的使用组合。本文公开的这种方法实现在源数据库上的事务日志记录，并且实现在源数据库上的周期性快照生成。混合方法还基于源数据库的最近的快照来在目标数据库上执行初始实例化。混合方法包括以与事务日志记录被应用在源数据库上的相同的顺序在目标数据库上重放(快照后)事务日志记录。混合方法还包括基于较新的快照来周期性地刷新目标数据库，并继续应用快照后事务日志记录。如本文所公开的，混合方法被配置为确保日志记录和快照都分别是可用的，并且还被配置为将初始引导时间保持到最小值以确保初始目标状态相对于源数据库是合理地最新的。混合方法还实现用于促使并保持目标数据库与源数据库是最新的低成本方法。混合方法还实现偏移的快速校正以及任何副本的快速追赶路径，这些副本可能由于例如副本停机时间、导致处理延迟的服务或联网故障等而远远落在源后面。
在一个实施例中，存储在初级部署中的数据库数据被复制，使得数据库数据还被存储在次级部署中。由于例如用于维护或更新的预定停机时间、断电、系统故障、数据中心断电、导致数据库数据的不正确修改或删除的错误、云提供商断电等，初级部署可能变得不可用。响应于初级部署变得不可用，在数据库数据上的一个或更多个事务在次级部署上被执行。初级部署可能再次变得可用，并且在次级部署上执行的一个或更多个事务被传播到初级部署。当初级部署是可用的时，可以在初级部署上执行对数据库数据的查询。
数据库表可以响应于数据操纵语言(DML)语句例如插入命令、删除命令、合并命令等而被改动。这样的修改可以被称为出现在数据库表上的事务(该修改可以可选地在本文被称为“更新”)。在一个实施例中，每个事务包括指示事务何时被接收到和/或事务何时被完全执行的时间戳。在一个实施例中，事务包括对表进行的多个改动，并且这样的改动可能影响在表中的一个或更多个微分区。
数据库表可以在多个微分区中存储数据，其中，微分区是不可变的存储设备。当在这样的表上执行事务时，所有受影响的微分区都被重新创建以生成反映该事务的修改的新微分区。在完全执行事务之后，然后可以从数据库移除经重新创建的任何原始微分区。在表上执行的每个事务之后，生成该表的新版本。如果在表中的数据经历许多变化，例如插入、删除和/或合并，则该表可能在一段时间期间经历许多版本。该表的每个版本可以包括元数据，该元数据指示什么事务生成该表、该事务何时被排序、该事务何时被完全执行以及该事务如何改动在该表中的一行或更多行。用于低成本表版本控制的所公开的系统、方法和设备可以被运用来提供用于生成综合变化跟踪概要的有效手段，该综合变化跟踪概要指示在第一时间戳和第二时间戳之间对表做出的所有中间更改。在一个实施例中，第一时间戳指示当初级部署变得不可用时的时间，第二时间戳指示当初级部署返回到可用时的时间。
在一个实施例中，表中的所有数据被自动划分到被称为微分区的不可变存储设备内。微分区可以被考虑为批处理单元，其中每个微分区具有连续的存储单元。作为示例，每个微分区可以包含在50MB和500MB之间的未压缩数据(注意，在存储区中的实际大小可能更小，因为数据可能被压缩地存储)。表中的行的组可以被映射为以多栏式(columnar)方式组织的单独微分区。这种大小和结构允许对非常大的表进行极细粒度的修剪，这些表可以由数百万或甚至数亿个微分区组成。可以自动收集关于存储在微分区中的所有行的元数据，包括：在微分区中的每个列的值的范围；不同值的数量；和/或用于优化和高效查询处理的附加属性。在一个实施例中，可以在所有表上自动执行微分区划分。例如，可以使用当数据被插入/加载时出现的排序来透明地划分表。
查询中间修改的列表提供用于确定在两个时间点之间对数据库表做出的增量更改的综合列表的高效且低成本的手段。这优于在本领域中已知的方法，其中一系列后续表版本中的每一个必须手动地被比较以确定表如何随着时间的推移而被修改。在本领域中已知的这样的方法需要大量的存储资源和计算资源来执行。
在一个实施例中，文件元数据存储在元数据存储区中。文件元数据包含表版本和关于每个表数据微分区的信息。元数据存储区可以包括可变存储区(可以被覆盖写入或在原地被写入的存储区)，例如本地文件系统、系统、存储器或诸如此类。在一个实施例中，微分区元数据由两个数据集组成：表版本和微分区信息。表版本数据集包括表版本到所添加的微分区和所移除的微分区的列表的映射。微分区信息由关于在微分区内的数据的信息(例如包括微分区路径、微分区大小、微分区密钥id以及存储在微分区中的所有行和列的概要)组成。表的每次修改创建新的微分区和新的微分区元数据。到表中的插入创建新的微分区。从表删除移除微分区，且如果不是在微分区中的所有行都被删除则可能添加具有表中的剩余行的新微分区。更新移除微分区并用具有包含已改变的记录的行的新微分区代替它们。
在一个实施例中，元数据可以存储在不可变存储区中的元数据微分区中。在一个实施例中，系统可以针对数据库表的每次修改将元数据微分区写到云存储。在一个实施例中，系统可以下载和读取元数据微分区以计算扫描集。元数据微分区可以并行地被下载并在它们被接收到时被读取，以改进扫描集计算。在一个实施例中，系统可以周期性地在后台中合并元数据微分区。在一个实施例中，可以包括性能改进，包括预取、缓存、多栏式布局和诸如此类。此外，使用具有多栏式布局的元数据文件，安全性改进(包括加密和完整性检查)也是可能的。
在一个实施例中，经由数据库快照产生/消耗和事务日志记录产生/消耗的组合来实现副本的初始化和维护。副本可以从快照生成，并递增地被应用单独事务记录，使得副本与源数据库同步。在一个实施例中，基于快照来周期性地刷新副本，即使副本基于增量事务更新被认为是最新的。基于快照的周期刷新可以解决由于缺陷和其他问题引起的偏移问题。在一个实施例中，快照和事务日志记录为了跨部署可见性而被写到远程存储区。可以利用对事务处理基础设施的修改以确保在源数据库事务状态和在远程存储区中的事务日志记录的出现之间的事务一致性。在一个实施例中，对数据定义语言(DDL)处理逻辑的修改可以被整合到事务处理工作流中以确保DDL应用和在远程存储区中的事务日志记录的出现的一致性。
在本公开的下面的描述中，参考形成本公开的一部分的随附附图，并且，在附图中通过例证的方式示出了本公开可被实践的特定实现。应理解，可以利用其他实现，并且可以做出结构改变而不偏离本公开的范围。
在描述和主张本公开时，将根据下面阐述的定义来使用以下术语。
必须注意，如在这个说明书和所附权利要求中使用的，单数形式“a”、“an”和“the”包括复数所指对象，除非上下文另外明确地规定。
在整个该说明书中对“一个实施例(one embodiment)”、“一个实施例(anembodiment)”、“一个实现(one implementation)”、“一个实现(an implementation)”、“一个示例(one example)”或“一个示例(an example)”的提及意味着关于该实施例、实现或示例所描述的特定的特征、结构或特性被包括在本公开的至少一个实施例中。因此，上述短语在整个本说明书的各个地方中的出现并不一定都指同一实施例、实现或示例。此外，应当认识到，随此提供的附图是出于对本领域中的普通技术人员的解释目的。
如在本文使用的，术语“包括(comprising)”、“包括(including)”、“包含”及其语法等同物是不排除额外的、未列举的元素或方法步骤的包括界限的或开放式的术语。
如在本文使用的，“表”被定义为记录(行)的集合。每条记录包含表属性(列)的值的集合。表通常物理地存储在多个较小(变化的大小或固定大小)的存储单元例如文件或块中。
如在本文使用的，“划分”被定义为在物理上分离具有不同数据的记录以分离数据分区。例如，表可以基于国家属性来划分数据，导致按国家的分区。
根据本公开的实施例可以被体现为装置、方法或计算机程序产品。因此，本公开可采用完全包括硬件的实施例、完全包括软件的实施例(包括固件、驻留软件、微代码等)或组合软件和硬件方面的实施例的形式，在本文中这些实施例通常可以全部被称为“电路”、“模块”或“系统”。此外，本公开的实施例可采用体现在表达式的任何有形介质中的计算机程序产品的形式，该表达式具有在介质中体现的计算机可用程序代码。
可以利用一个或更多个计算机可用或计算机可读介质的任何组合。例如，计算机可读介质可包括便携式计算机磁盘、硬盘、随机存取存储器(RAM)设备、只读存储器(ROM)设备、可擦除可编程只读存储器(EPROM或快闪存储器)设备、便携式光盘只读存储器(CDROM)、光学存储设备和磁存储设备中的一个或更多个。可以用一种或更多种编程语言的任何组合来写用于执行本公开的操作的计算机程序代码。可以将这样的代码从源代码编译成计算机可读汇编语言或适合于该代码将在其上被执行的设备或计算机的机器代码。
还可在云计算环境中实现实施例。在本描述和随附的权利要求中，“云计算”可以被定义为用于实现对可配置计算资源(例如，网络、服务器、存储区、应用和服务)的共享池的普遍、方便、按需网络访问的模型，该共享池可经由虚拟化被快速提供并以最小管理努力或服务提供商交互被释放，然后相应地按比例调整。云模型可由各种特性(例如，按需自助式服务、广泛的网络访问、资源池化(resource pooling)、快速弹性以及所测量的服务)、服务模型(例如软件即服务(“SaaS”)、平台即服务(“PaaS”)和基础设施即服务(“IaaS”))以及部署模型(例如私有云、社区云、公共云和混合云等)组成。
在所附的附图中的流程图和框图示出了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实现的架构、功能和操作。在这点上，在流程图或框图中的每个块可代表包括用于实现指定的逻辑功能的一个或更多个可执行指令的代码的模块、段或部分。还将注意，框图和/或流程图的每个块以及在框图和/或流程图中的块的组合可由执行指定功能或行动的专用的基于硬件的系统、或专用硬件和计算机指令的组合实现。这些计算机程序指令还可存储在计算机可读介质中，该计算机可读介质可指导计算机或其他可编程数据处理装置以特定方式起作用，使得存储在计算机可读介质中的指令产生包括实现在流程图和/或框图的一个或多个块中所指定的功能/行动的指令装置的制造物品。
本文描述的系统和方法可以使用新的数据处理平台在灵活和可扩展的数据仓库上操作。在一些实施例中，所描述的系统和方法运用支持基于云的存储资源、计算资源和诸如此类的云基础设施。示例基于云的存储资源以低成本提供按需可用的相当大的存储容量。此外，这些基于云的存储资源可以是容错的和高度可扩展的，这在私有数据存储系统中实现起来可能是昂贵的。示例基于云的计算资源是按需可用的，并且可以基于资源的实际使用水平来定价。通常，云基础设施以快速方式动态地被部署、重新配置和退出运行。
在所描述的系统和方法中，数据存储系统利用基于SQL(结构化查询语言)的关系数据库。然而，这些系统和方法可应用于任何类型的数据库和任何类型的数据存储和检索平台，使用任何数据存储架构并使用任何语言来在数据存储和检索平台内存储和检索数据。本文描述的系统和方法还提供了支持在不同客户/客户端之间以及在同一客户/客户端内的不同用户之间的计算资源和数据的隔离的多租户系统。
现在参考图1，示出了用于运行本文公开的方法的计算机系统。如图1所示，资源管理器102可以耦合到多个用户104、106和108。在特定的实现中，资源管理器102可以支持希望访问数据处理平台100的任何数量的用户。例如，用户104、106、108可以包括例如提供数据存储和检索请求的最终用户、管理本文所描述的系统和方法的系统管理员和与资源管理器102交互的其它部件/设备。
资源管理器102提供支持在数据处理平台100内的所有系统和部件的操作的各种服务和功能。资源管理器102可以耦合到元数据110，元数据110与在整个数据处理平台100中存储的全部数据相关联。在一些实施例中，元数据110可以包括存储在远程数据存储系统中的数据以及从本地高速缓存可得到的数据的概要。另外，元数据110可以包括关于数据在远程数据存储系统和本地高速缓存中如何被组织的信息。元数据110可以允许系统和服务确定一段数据是否需要在不加载或访问来自存储设备的实际数据的情况下被处理。
资源管理器102还可以耦合到执行平台112，执行平台112提供执行各种数据存储和数据检索任务的多个计算资源，如下面更详细讨论的。执行平台112可以耦合到作为存储平台114的一部分的多个数据存储设备116、118和120。尽管在图1中示出了三个数据存储设备116、118和120，但是执行平台112能够与任何数量的数据存储设备通信。在一些实施例中，数据存储设备116、118和120是位于一个或更多个地理位置上的基于云的存储设备。例如，数据存储设备116、118和120可以是公共云基础设施或私有云基础设施的一部分。数据存储设备116、118和120可以是硬盘驱动器(HDD)、固态驱动器(SSD)、存储集群或任何其它数据存储技术。另外，存储平台114可以包括分布式文件系统(例如Hadoop分布式文件系统(HDFS))、对象存储系统和诸如此类。
在特定的实施例中，经由一个或更多个数据通信网络来实现在资源管理器102与用户104、106和108、元数据110和执行平台112之间的通信链路。类似地，经由一个或更多个数据通信网络来实现在执行平台112与存储平台114中的数据存储设备116、118和120之间的通信链路。这些数据通信网络可以利用任何通信协议和任何类型的通信介质。在一些实施例中，数据通信网络是耦合到彼此的两个或更多个数据通信网络(或子网络)的组合。在替代实施例中，使用任何类型的通信介质和任何通信协议来实现这些通信链路。
如图1所示，数据存储设备116、118和120从与执行平台112相关联的计算资源解耦。该架构基于变化的数据存储/检索需要以及访问数据处理平台100的用户和系统的变化的需要来支持对数据处理平台100的动态改变。动态改变的支持允许数据处理平台100响应于对在数据处理平台100内的系统和部件的变化的需求而快速按比例调整。计算资源与数据存储设备的解耦支持大量数据的存储而不需要相应的大量计算资源。类似地，资源的这种解耦支持在特定时间利用的计算资源的显著增加而不需要可用的数据存储资源的相应增加。
资源管理器102、元数据110、执行平台112和存储平台114在图1中被示为单独的部件。然而，资源管理器102、元数据110、执行平台112和存储平台114中的每一个可以被实现为分布式系统(例如，跨在多个地理位置处的多个系统/平台分布)。此外，资源管理器102、元数据110、执行平台112和存储平台114中的每一个可以根据从用户104、106、108接收的请求的改变以及数据处理平台100的变化的需要而被按比例扩大或缩小(独立于彼此)。因此，数据处理平台100是动态的，并且支持定期改变以满足当前的数据处理需要。
图2是描绘资源管理器102的实施例的框图。如图1所示，资源管理器102包括耦合到数据存储设备206的访问管理器202和密钥管理器204。访问管理器202可以为本文所描述的系统处理认证和授权任务。密钥管理器204可以管理在认证和授权任务期间使用的密钥的存储和认证。请求处理服务208管理接收到的数据存储请求和数据检索请求。管理控制台服务210支持由管理员和其他系统管理者对各种系统和过程的访问。
资源管理器102还可以包括SQL编译器212、SQL优化器214和SQL执行器210。SQL编译器212解析SQL查询并为查询生成执行代码。SQL优化器214基于需要被处理的数据来确定执行查询的最佳方法。SQL执行器216执行针对由资源管理器102接收的查询的查询代码。查询调度器和协调器218将接收到的查询发送到适当的服务或系统用于编译、优化和分派到执行平台112。虚拟仓库管理器220管理在执行平台中实现的多个虚拟仓库的操作。
此外，资源管理器102包括配置和元数据管理器222，其管理与存储在远程数据存储设备中和本地高速缓存中的数据相关的信息。监视器和工作负荷分析器224监督由资源管理器102执行的过程，并管理任务(例如，工作负荷)跨在执行平台中的虚拟仓库和执行节点的分配。配置和元数据管理器222以及监视器和工作负荷分析器224耦合到数据存储设备226。
资源管理器102还包括复制和故障转移管理器228，其管理数据复制请求、数据库故障转移和数据库故障恢复。例如，复制和故障转移管理器228管理和调度在多个数据库存储资源和数据库部署之间的成批数据复制。在一个实施例中，复制和故障转移管理器228可以管理使存储在初级部署内的数据成为在一个或更多个次级或备用部署内的副本的复制。此外，复制和故障转移管理器228可以管理在初级部署发生故障时数据库操作从初级部署到次级部署的转移，和/或可以管理在初级部署再次变得可用时数据库操作从次级部署回到初级部署的转移。复制和故障转移管理器228可以确保在多个部署之间的一致的数据复制，并且还可以确保当第二部署再次变得可用时，在第二部署是不可用的时的对第一部署进行的任何更新被传播到第二部署。
图3是描绘执行平台的实施例的框图。如图3所示，执行平台112包括多个虚拟仓库302、304和306。每个虚拟仓库包括多个执行节点，每个执行节点包括高速缓存和处理器。尽管图3中所示的每个虚拟仓库302、304和306包括三个执行节点，但是特定的虚拟仓库可以包括任何数量的执行节点而不偏离本公开的范围。此外，在虚拟仓库中的执行节点的数量是动态的，使得当存在额外需求时新的执行节点被创建，并且当现有执行节点不再是必要的时它们被删除。
每个虚拟仓库302、304、306能够访问图1所示的数据存储设备116、118、120中的任何一个。因此，虚拟仓库302、304、306不一定被分配到特定的数据存储设备116、118、120，且替代地，它们可以访问来自数据存储设备116、118、120中的任何一个的数据。类似地，图3所示的每个执行节点可以访问来自数据存储设备116、118、120中的任何一个的数据。在一些实施例中，特定的虚拟仓库或特定的执行节点可以临时被分配到特定的数据存储设备，但是该虚拟仓库或执行节点可以稍后访问来自任何其他数据存储设备的数据。
在图3的示例中，虚拟仓库302包括三个执行节点308、310和312。执行节点308包括高速缓存314和处理器316。执行节点310包括高速缓存318和处理器320。执行节点312包括高速缓存322和处理器324。每个执行节点308、310、312与处理一个或更多个数据存储和/或数据检索任务相关联。例如，特定的虚拟仓库可以处理与特定用户或客户相关联的数据存储和数据检索任务。在其他实现中，特定虚拟仓库可以处理与特定数据存储系统或特定类别的数据相关联的数据存储和数据检索任务。
类似于上面讨论的虚拟仓库302，虚拟仓库304包括三个执行节点326、328和330。执行节点326包括高速缓存332和处理器334。执行节点328包括高速缓存336和处理器338。执行节点330包括高速缓存340和处理器342。另外，虚拟仓库306包括三个执行节点344、346和348。执行节点344包括高速缓存350和处理器352。执行节点346包括高速缓存354和处理器356。执行节点348包括高速缓存358和处理器360。
尽管图3所示的执行节点各自包括一个高速缓存和一个处理器，但是替代实施例可以包括包含任何数量的处理器和任何数量的高速缓存的执行节点。此外，高速缓存在不同的执行节点当中可能在大小上不同。图3所示的高速缓存在本地执行节点中存储从在存储平台114(见图1)中的一个或更多个数据存储设备检索的数据。因此，高速缓存减少或消除了在一贯地从远程存储系统检索数据的平台中出现的潜在瓶颈问题。不是重复地访问来自远程存储设备的数据，本文描述的系统和方法而是访问来自在执行节点中的高速缓存的数据，这明显更快并且避免了瓶颈问题。在一些实施例中，使用提供对所缓存的数据的快速访问的高速存储器设备来实现高速缓存。每个高速缓存可以存储来自在存储平台114中的任何存储设备的数据。
此外，高速缓存资源和计算资源可以在不同的执行节点之间有所不同。例如，一个执行节点可以包含相当多的计算资源和最少的高速缓存资源，使该执行节点对需要相当多的计算资源的任务有用。另一个执行节点可以包含相当多的缓存资源和最少的计算资源，使该执行节点对需要缓存大量数据的任务有用。在一些实施例中，当创建特定执行节点时，基于将由该执行节点执行的预期任务来确定与该执行节点相关联的高速缓存资源和计算资源。
此外，与特定执行节点相关联的高速缓存资源和计算资源可以基于由该执行节点执行的变化的任务随着时间的推移而改变。例如，如果由特定执行节点执行的任务变得更处理器密集的，则该执行节点可以被分配更多的处理资源。类似地，如果由执行节点执行的任务需要较大的高速缓存容量，则该执行节点可以被分配更多的高速缓存资源。
尽管虚拟仓库302、304、306与图1的相同执行平台112相关联，但是虚拟仓库可以使用在多个地理位置处的多个计算系统来实现。例如，虚拟仓库302可以由在第一地理位置处的计算系统实现，而虚拟仓库304和306由在第二地理位置处的另一计算系统实现。在一些实施例中，这些不同的计算系统是由一个或更多个不同实体维护的基于云的计算系统。
另外，在图3中每个虚拟仓库被示为具有多个执行节点。可以使用在多个地理位置处的多个计算系统来实现与每个虚拟仓库相关联的多个执行节点。例如，虚拟仓库302的特定实例在特定地理位置处的一个计算平台上实现执行节点308和310，并且在另一地理位置处的不同计算平台处实现执行节点312。选择特定计算系统来实现执行节点可以取决于各种因素，例如特定执行节点所需的资源的水平(例如，处理资源要求和高速缓存要求)、在特定计算系统处可用的资源、在地理位置内或在地理位置之间的网络的通信能力以及哪些计算系统已经实现在虚拟仓库中的其他执行节点。执行平台112也是容错的。例如，如果一个虚拟仓库发生故障，则快速地用在不同地理位置处的不同虚拟仓库代替该虚拟仓库。
特定的执行平台112可以包括任何数量的虚拟仓库302、304、306。此外，在特定执行平台中的虚拟仓库的数量是动态的，使得当需要额外的处理和/或缓存资源时，新的虚拟仓库被创建。类似地，当与现有的虚拟仓库相关联的资源不再是必要的时，现有的虚拟仓库可以被删除。
图4是描绘操作环境400的实施例的框图，其中多个用户通过负载平衡器和在虚拟仓库组中包含的多个虚拟仓库来访问多个数据库。环境400包括虚拟仓库资源管理器408和布置在虚拟仓库组416中的多个虚拟仓库410、412和414。虚拟仓库资源管理器408可以被包含在资源管理器102中。具体地，多个用户402、404和406通过虚拟仓库资源管理器408和虚拟仓库组416来访问多个数据库418、420、422、424、426和428。在一些实施例中，用户402-406通过资源管理器102(图1)来访问虚拟仓库资源管理器408。在一些实施例中，在资源管理器102内实现虚拟仓库资源管理器408。
用户402-406可以向虚拟仓库资源管理器408提交数据检索和数据存储请求，虚拟仓库资源管理器408将数据检索和数据存储请求路由到在虚拟仓库组416中的适当的虚拟仓库410-414。在一些实现中，虚拟仓库资源管理器408提供用户402-406到虚拟仓库410-414的动态分配。当提交数据检索或数据存储请求时，用户402-406可以指定虚拟仓库组416来处理该请求而不指定将处理该请求的特定虚拟仓库410-414。这种安排允许虚拟仓库资源管理器408基于效率、可用资源和在虚拟仓库410-414内的所缓存的数据的可用性来跨虚拟仓库410-414分配多个请求。在确定如何路由数据处理请求时，虚拟仓库资源管理器408考虑可用资源、当前资源负荷、当前用户的数量和诸如此类。
在一些实施例中，容错系统响应于虚拟仓库的故障而创建新的虚拟仓库。新的虚拟仓库可以在同一虚拟仓库组中，或者可以在不同地理位置处的不同虚拟仓库组中被创建。
每个虚拟仓库410-414被配置成与所有数据库418-428的子集通信。例如，在环境400中，虚拟仓库410被配置成与数据库418、420和422通信。类似地，虚拟仓库412被配置成与数据库420、424和426通信。而且，虚拟仓库414被配置成与数据库422、426和428通信。在替代实施例中，虚拟仓库410-414可以与数据库418-428中的任何一个(或全部)通信。
尽管环境400示出了一个虚拟仓库组416，但是替代实施例可以包括任何数量的虚拟仓库组，每个虚拟仓库组与任何数量的虚拟仓库相关联。例如，可以为每个客户或用户组创建不同的虚拟仓库。此外，可以为不同的实体或访问不同数据集的任何其他组创建不同的虚拟仓库。多个虚拟仓库组可以具有不同的大小和配置。在特定环境中的虚拟仓库组的数量是动态的，且可以基于在该环境中的用户和其他系统的变化的需要而改变。
图5是示出用于生成数据库快照的过程流程500的示意图。数据库快照使在不同位置中实例化源数据库的副本(例如将存储在初级部署中的数据库数据复制到次级部署中)成为可能。快照捕获数据库的一个或更多个对象，例如数据库的结构(例如范式(schema)、表、视图等)和/或数据库的内容(即，行)。在某些实施例中，当快照反映在特定时间点处的数据库的事务一致视图时，就会出现在概念上最干净的方法。在一个实施例中，事务一致时间点快照不是严格的要求，并且生成可以通过一组事务日志记录的应用而被带到事务一致状态的快照就足够了。
过程流程500示出了描绘在时间t1创始并在时间t6完成的快照的时间线。过程流程500开始，并且在502快照被创始。在504在时间t2生成对象X的快照，以及在510在时间t5生成对象Y的快照。应当认识到，对象X和对象Y可以代表数据库中的任何两个对象。如所示，在506在时间t3修改对象X，以及在508在时间t4修改对象Y。在504生成对象X的快照之后，在506修改对象X。在510生成对象Y的快照之前，在508修改对象Y。在512快照结束。
根据单独对象快照是如何被生成的语义，图5中所示的过程流程500可能产生或可能不产生对象X和Y的事务一致时间点表示。如果对象的快照表示基于对象在快照被创始的时间的状态而生成，则快照本身将是在快照开始的时刻的数据库的事务一致表示。例如在图5的上下文中，语义将对应于基于在时间t1的状态来产生X和Y两者的快照表示，并且将导致提供在时间点t1的X和Y两者的事务一致视图的快照。然而，如果对象的快照表示基于在对象的快照表示被生成的时间的该对象而生成，则快照在任何时间点都不一定是数据库的事务一致表示。例如在图5的上下文中，语义将对应于基于X在时间t2的状态产生X的快照表示以及基于Y在时间t5的状态产生Y的快照表示。这种组合将产生对应于从来不存在且可能是无效(取决于在506和508的两个修改之间的关系(如果有的话))的数据库状态的快照。
例如，当在时间t3的修改将一列添加到表X、以及在时间t4的修改基于涉及在表X上的新列的CTAS来创建表Y时，可能出现潜在的异常状态。CTAS本质上通过对数据库执行选择查询来生成新的表对象。该选择查询可能涉及数据库中的多个表。在一个示例实现中，在对象X和Y的数据和结构之间可能存在相依性。在这样的实现中，可能存在这样一种情形，其中对象X没有列，即使对象Y基于对象X的数据和结构而被创建。这种情形可能产生结构变化和内容变化可能以微妙的方式交互的可能性。可能存在导致确保的不一致性的其他情形。例如，如果对X和Y的修改是单个事务的一部分，那么基于当前状态来产生快照将导致撕裂的事务，其中事务的一部分反映在快照中，而事务的另一部分不反映在快照中。
在一个实施例中，不管快照如何生成，都可能通过以快照开始、然后将在快照时间范围期间生成的任何日志记录以日志记录的串行化顺序进行应用，来在快照时间结束时将目标带到事务一致状态。在这样的实施例中，前面的陈述假设应用日志记录是幂等操作，其中目标数据库已经反映由特定日志记录进行的更新，并且应用该日志记录是空操作。在这种示例的上下文中，将与在时间t3和时间t4的修改有关的日志记录应用于所生成的快照将导致从时间t6时起一致的结束状态，而不管单独对象快照如何生成。
在数据库复制的实施例中，快照提供目标数据库的初始状态，所有后续的更改将被应用在该初始状态上。在一个实施例中，为存储在初级部署中的数据库数据生成快照，使得该数据库数据可以被复制在一个或更多个次级部署中。在另一个实施例中，当初级部署或一个或更多个其他次级部署是不可用的时，为次级部署生成快照以捕获对存储在该次级部署中的数据库数据做出的任何更新。如果快照与源数据库不一致，目标数据库也将与源数据库不一致。将另外的更改应用于不一致的起始点通常并不校正不一致性。例如，如果客户端帐户进行了从源数据库(在一个实施例中，源数据库是初级部署)到已经从源数据库(在这种情况下，初级部署)偏移的副本次级部署的故障转移，最后效果是数据损坏和/或数据丢失。因为故障转移可以在任何时间发生，所以确保在源数据库(例如初级部署)和目标数据库(例如次级部署)之间的事务一致性对数据库复制的价值主张可能至关重要。在一个实施例中，确保从快照构建的数据库的一致性是用于随时建立和维护在源数据库和目标数据库之间的一致性的构造块。
生成数据库快照
在一个实施例中，包括数据库的各种信息包括元数据文件。元数据文件的实现在本文可以被称为表达式属性(Expression Property)“EP”文件。EP文件可以特别包括累积表元数据，该累积表元数据包括关于在数据库中的整个表中存储的所有数据的信息。EP文件还可以包括分组表达式属性，其包括关于在表内的微分区分组中存储的数据的信息。EP文件还可以包括微分区统计信息，其包括关于在表的特定微分区中存储的数据的信息，例如最小/最大值、空计数、条目数量等。EP文件还可以包括列表达式属性，其包括关于在表的微分区的特定列中存储的数据的信息。本文公开的元数据文件可以特别包括EP文件或者可以包括包含关于数据库数据的信息的任何其他文件。
元数据文件包括描述数据库的结构的信息，并且可以包括在数据库中的任何范式的列表和属性、在每个范式中的表和视图的列表和属性、在每个表或视图中存在的列的列表和属性等。单独表内容可以由EP文件和任何其他形式的元数据文件的组合来定义。单独表内容的单独元组值可以存储在微分区中。在一个实施例中，包括在事务时间的特定点处的特定表的内容的精确微分区集合被包括在一组元数据文件的内容中。在一个实施例中，元数据文件可以被考虑为包括微分区的列表。微分区和元数据文件都是不可变的，且可以在存储区中被存储和加密。在一个实施例中，在事务时间的特定点处与表有关的元数据文件的列表被维护在与数据库数据分离的元数据储存器中。
在一个实施例中，用于生成数据库的快照的起始点是存储在元数据中的DatabaseDPO(“数据库数据持久化对象”)。DatabaseDPO是用于与存储在元数据中的持久目录信息交互的数据结构。DatabaseDPO本身实际上是包括在数据库内的所有对象(即快照所需的所有对象)的树的根。在扎根于期望DatbaseDPO处的树中的每个对象可以被串行化到快照中。对象的串行化表示可以封装在远程位置(目标数据库)上重新创建该对象的精确副本所必需的一切。
对于表，可能存在如何使表内容串行化的额外问题。在一个实施例中，读取整个表并使内容串行化可能需要大量的计算资源，并且可能导致非常大的快照大小。在这样的实施例中，使该表的元数据文件的列表串行化可能就足够了。因此，当快照在目标数据库处被消耗时，元数据文件可以被复制到目标，在目标处被读取以导出具有所有元组的微分区的列表，并且那些微分区也可以被复制到目标。元数据文件和微分区都可以在快照中被加密，并且可以包括将允许目标获得适当密钥以将文件解密的信息。在目标处的文件可能需要用由目标管理的新密钥重新加密。在一个实施例中，表的快照映像包括元数据文件列表作为表内容的表示。此外在一个实施例中，快照包括一些信息以使目标能够获得用于制作元数据文件和微分区的副本的一个或更多个密钥。
生成事务日志记录
在一个实施例中，事务日志记录确保日志记录本身包括足够的信息以在目标上正确且明确地再产生事务更改。这可以被满足，因为由事务日志应用的更改在提交(commit)时间是已知的，并且该方法可以包括捕获和串行化由事务做出的元数据更改。在一个实施例中，对于所有目标数据库，事务日志记录是可访问的，而不管部署、区域或底层云提供商。事务日志记录可以被写到远程存储区。
在一个实施例中，初级部署变得不可用，并且所有数据库操作被转移到次级部署。在当初级部署是不可用的时的时间期间，对数据库数据的所有更新都可以在次级部署上被执行。可以为在次级部署上执行的所有更新生成事务日志记录，并且当初级部署不再是不可用的时，事务日志记录可以用于将那些更新传播到初级部署。在这样的实施例中，事务日志记录的使用可以确保只有那些新的更新(对次级部署做出的)在初级部署上被执行，并且没有陈旧数据或先前摄取的数据被传播到初级部署。
在一个实施例中，依据事务日志记录何时被生成，本文所公开的系统、方法和设备被配置成确保事务日志记录的写入实际上是事务本身的一部分。只有事务提交，事务日志记录才可以被写到远程存储区，此外，只有事务日志记录被写到远程存储区，事务才提交。偏离这样的过程可能导致在源数据库和目标数据库之间的事务不一致性。
图6是示出用于生成用于复制数据库的事务日志的过程流程600的示意图。过程流程600示出了从左到右前进的时间线。在图6中，在内部事务状态中出现的事务在时间线上方示出，被采用来支持并发控制和事务处理的动作在时间线下方示出。在时间t0，在602事务是打开的并且在活动状态中，并且此时没有数据操纵语言(DML)动作被执行。在时间t1，DML语句的处理正在进行中。在DML语句处理期间，过程流程600包括在604获得在受影响的表上的文件锁以支持将同一表作为目标的多个并发DML操作。应当认识到，在604获得文件锁可以出现任何次数，并且将在多语句事务中出现多次。在时间t2，开始提交处理，并且提交处理的开始在606通过转换到预提交状态来被记录。在时间t3，在608在事务中被修改的所有表上获得表锁。在608已获取所有表锁之后，在时间t4，在610利用帐户级Lamport时钟以生成新的且唯一的事务标识。在一个实施例中，在608获取所有表锁之后才在610获得事务标识确保在任何两个可能冲突的事务之间的明确的提交排序(基于Lamport时钟值)。在610获得事务标识之后，在时间t5事务能够在612转换为提交状态。在一个实施例中，在612到提交状态的转换可以代表事务的“不可返回点”620。在此转换之前，由于用户动作、处理错误、系统故障等，事务提交本身仍可能被取消或中止。然而，一旦在612转换到提交状态发生，从系统角度来看，事务实际上被提交了。在时间t5，事务的效果被应用于系统，并且不再能回滚。还要注意，在时间t5(在时间线下方)，新的表版本现在在614由其他并发运行的事务可读。在时间t6，由事务持有的所有锁在616被释放。释放锁使(在604或608)在这些锁上等待的任何可能冲突的事务能够获取所需的锁以通过提交协议取得进展。在时间t7，事务在618转换到已提交状态，并且完成所有处理。在一个实施例中，在时间t5之后的任何故障都不会导致事务的回滚。例如，如果处理事务的节点在时间t5之后立即出现故障，例如新节点将在它停止的地方再继续处理，释放锁，并将事务向前滚进到完成。
在一个实施例中，在612转换为提交状态时，在时间t5将事务日志记录写到远程存储区。在某些实施例中，在时间t5之前将事务日志记录写到远程存储区可能是有问题的，因为处理流程600在时间t5之前中止事务也许仍然是可能的。此外，在时间t5之后写事务日志记录作为提交后处理的一部分可以避免错误的事务问题。
在一个实施例中，如图6所示，在时间t5之后写事务日志记录作为提交后处理的一部分可以避免错误的事务问题，但是可能展现出这样的可能性，即在时间t5与将事务日志写到远程存储区之间的故障可能导致事务被提交在源数据库上而不是在目标数据库上。因为到远程存储区的写入可能是事务后处理的一部分，所以它可以合理地被假设为发生在源再次是可操作的并且事务清理继续进行到完成之后的某个时间点。在它发生之后，目标可以提取该更改，并且可能不再有丢失的事务。然而，当存在如图7所示的故障转移720时，可能出现问题情形。如果存在从源到目标的故障转移720，其出现在越过不可返回点620和到远程存储区的写入之间的窗口中。在这种情况下，事务可能被提交在源上，且将不存在于目标上。在一个实施例中，如果到远程存储区的写入位于时间t5和时间t6(在616所有锁被释放)之间，那么失去的全部可能是到一个或更多个表的最后一次写入，并且此外，没有所附属的写入的事务提交的明确确认被发送回最终用户。
图7是示出用于复制数据库的两个不同事务的过程流程700的示意图。过程流程700示出了在存在不合时宜的故障转移720的情况下可能导致丢失的事务的情况。图7示出了在时间t5与元数据的交互不仅将事务转换到提交状态而且在一个原子操作中将任何修改的表的新版本暴露给系统的其余部分的情况。作为结果，如在过程流程700中示出的事件的序列也许是可能的。
图7中的过程流程700示出了两个不同事务(事务T1和事务T2)的假设时间线。由事务T1采取的动作出现在时间线上方，由事务T2采取的动作出现在时间线下方。在时间t0，事务T1在702对表T执行写操作。在时间t1，作为预提交处理的一部分，事务T1在704获得表T的锁。在时间t2，事务T1通过原子地转换到提交状态并通过在706提交新的可读版本而将表T的、具有由事务T1执行的写入的新版本暴露给系统的其余部分，来越过“不可返回点”。在图7所示的过程流程700中，任何各种原因可能使事务日志记录到远程存储区的写入被延迟。因此，事务T1依然在提交后处理中，且尚未将事务日志记录写到远程存储区，尚未释放在表T上的锁，以及尚未将成功报告回最终用户。在时间t3，事务T2在708读取表T的最新版本(包括由事务T1执行的写入)作为创建/填充表X的CTAS操作的一部分。在时间t4，这个新事务越过“不可返回点”，并在710被提交。在某些实现中，这种转换是可能的，因为事务T2不需要在表T上的锁，因为它只能从表T读取，并因此它不被仍持有在表T上的锁的事务T1阻止。在时间t5，该新事务在712将它的日志记录写到远程存储区。事务T1的日志记录还未被写到远程存储区。过程流程700还包括到副本的故障转移720。在如图7所示的实施例中，副本与源数据库的任何版本都不是事务一致的。副本包括事务T2的结果，但不包括事务T1的结果，尽管事务T2读取由事务T1创建的表T的版本。事务T1实际上被丢失，但是依赖于事务T1的事务T2还没有被丢失。因此，在图7所示的实施例中，数据库是不一致的。最终，事务T1的事务日志记录在714处将被写到远程存储区，但是如图7所示，故障转移720可能出现在任何时间点，包括在714处成功写到远程存储区之前，这导致潜在的丢失的事务。
如图7所示的丢失写或丢失事务问题的潜在暴露可能源于在事务日志记录与被写到数据库的表的新版本关联之前，系统的其余部分可采用该新版本。可以通过不使表的新版本对系统的其余部分可见直到在到远程存储区的写入发生之后为止，来避免图7中示出的丢失事务实施例。本文公开了在推迟新表版本的暴露直到在到远程存储区的写入发生之后为止而不干扰现有提交后逻辑的方法。该方法包括将准备阶段合并到事务，如图8所示。
图8是示出包括用于数据库的复制的准备阶段的过程流程800的示意图。引入准备阶段以推迟新表版本的暴露直到在到远程存储区的写入发生之后为止，而不干扰现有提交后逻辑。准备阶段可以出现在获取表锁之后且在转换到提交状态之前。在一个实施例中，准备阶段的目的是将系统转换为一种状态，在该状态中，事务在清理或恢复期间被提交，甚至在实际提交之前存在故障的情况下。准备阶段将事务日志记录写到远程存储区。只有在确认成功写入到远程存储区之后，事务才从那时起以相同的语义转换为提交阶段(例如，使任何所修改的对象的新版本可由系统的其余部分读取)，如在图6-7所示的协议中的。
过程流程800包括正式提交点，其中在814事务日志记录被写到数据库，且这可以被称为“不可返回的硬点”826。过程流程800还包括在时间t5在812的准备状态。在812到准备状态的状态转换可以被称为“不可返回的软点”824。在时间t0，在802事务是打开的并且在活动状态中，并且此时没有DML动作被执行。在时间t1，DML语句的处理正在进行中。在DML语句处理期间，处理流程800包括在804获得在受影响的表上的文件锁以支持以同一表作为目标的多个并发DML操作。在时间t2，提交处理开始，并且提交处理的开始在806通过转换到预提交状态而被记录。在时间t3，在808在事务中被修改的所有表上获得表锁。已在808获取所有表锁之后，在时间t4，在810利用帐户级Lamport时钟来生成新的且唯一的事务标识。在一个实施例中，在808获取所有表锁之后才在810获得事务标识确保任何两个可能冲突的事务之间的明确的提交排序(基于Lamport时钟值)。在时间t5，事务在812进入准备状态，这可以被考虑为不可返回的软点824。然后，事务在814将事务日志记录写到数据库，这可以被考虑为不可返回的硬点826。在时间t7，在816进入提交状态，并且新版本在818是可读的。在时间t8，在820释放所有锁。在时间t9，事务在822进入已提交状态。
由于如关于图7所讨论的事务日志记录到数据库的延迟写入，在812到准备状态的转换可以被称为不可返回的软点824。简而言之，对数据库的写入可能超时或终止，但随后会出现包括被写入的条目。原始写入可以有效地盖写由重写产生的条目的版本。在当对数据库的写请求非决定性地终止时和在该写实际上出现在数据库上时之间可能存在不小的延迟。因此，存在在写请求的非决定性终止之后但是在该写出现在数据库中的时间点之前的时间窗口，在该时间窗口期间，在数据库中的用于确定条目是否存在的检查可能返回“假阴性”——即，检查没有看到条目，因此它假定该写没有发生并且将不会发生，但是实际上，该写已经发生或者将要发生并且条目还不是可见的。如果检查指示条目不存在，则假定记录未被写入并回滚事务是不安全的——如果条目在检查之后出现，则事务将不在源处被应用，而将可能在目标处被应用，这可能产生不一致性。因此，在当事务在准备状态中时出现故障的情况下，安全的行动过程可以是通过确保事务日志记录被重写到数据库、转换到提交状态以及执行提交后动作以完成事务来将事务向前滚进到完成。因此，在812到准备状态的转换可以被表征为不可返回的软点824，因为事务实际上没有被提交，但是事务的唯一可用的终止状态是一次成功提交。
在出现故障转移的实施例中，可以修改过程流程800的语义。如果当事务在802在活动状态中或在806在预提交状态中时出现故障转移，则事务的结果将不出现在目标中，因为事务日志记录还没有在814被写到数据库，所以它不能被目标提取。如果当事务在816在提交状态中或在822在已提交状态中时出现故障转移，则事务的结果将出现在目标中，因为截至故障转移时事务日志记录已经在814被写到数据库，所以它将被目标提取。
如果当事务在812在准备状态中时出现故障转移，则事务的结果可能出现或可能不出现在目标中，取决于截至故障转移时事务日志记录是否被写到数据库。此外，如果目标因为事务日志记录在故障转移时在数据库中是可见的而提取事务，则它可能在目标处被应用，因为源向前滚进到完成并且相关联的客户端帐户尚未被告知成功或失败。此外，如果目标因为在故障转移时事务日志记录在数据库中是不可见的而没有提取事务，则不一致性可以被避免，因为源没有暴露写的结果，且没有将成功报告回相关联的客户端帐户。
根据图8中示出的过程流程800，如本文所讨论的，可以保持某些关系。如果两个事务有冲突的写入，则第一次提交的写入的事务标识可能低于第二次提交的写入的事务标识。这个排序使得写入在表锁上同步，并且在锁在808被获得之后且在锁在814被释放之前，事务标识在时间810被获得。此外，如果两个事务有冲突的写入，则第一次提交的写入的事务日志记录可能出现在第二次提交的写入的事务日志记录之前。这个排序可以被保证，因为事务标识排序被保证，因为事务日志记录写入发生在事务持有表锁的时候。此外，如果一个事务(读取者)读取由另一个事务(写入者)产生的表版本，则写入者的事务日志记录可能在新的表版本被读取者读取之前出现。这个顺序可以被保证，因为在814对数据库的写入发生在818新的表版本变得可读取之前。
在一个实施例中，可能保证冲突的写入的提交顺序对于源数据库和目标数据库两者将是相同的。用于将事务日志记录应用于目标的逻辑必须实施适当的排序，但这也许是可能的，因为在数据库中(关于冲突)的事务日志记录的出现被保证与这些冲突在源处被解决的顺序相同。在一个实施例中，可以由复制基础设施负责来确保事务日志记录应用的适当排序被实施。
在一个实施例中，两个不相关的事务可能以与在源中的它们的事务标识顺序不同的顺序出现在数据库中。例如，具有标识abc的事务可以使它的日志记录在具有标识xyz的事务的日志记录之前出现在数据库中，假定这两个事务彼此没有冲突且没有对彼此的依赖。这可能发生，例如，如果具有ID abc的事务在812进入准备状态且然后停止，在此之后，具有标识xyz的事务在812进入准备状态，并且成功地将它的日志记录记录到数据库。通常，这不造成事务一致性问题，因为在两个不相关的事务之间的顺序是未限定的。如果由于某种原因，确保事务日志记录以事务标识顺序出现在数据库中变成必要条件，则可以增强事务日志记录逻辑，以通过例如引入事务日志锁和/或停止写入直到具有较低事务标识的所有准备的事务都被刷新到数据库为止，来实施这个排序。
在一个实施例中，当生成表的内容的快照(例如，元数据文件列表和隐含的微分区列表)时，公共时间语义可以通过提取对应于开始快照时间的表版本来实现。这样的实施例也许变得可能，因为所有DML通过适当的锁被同步，所有DML通过内部Lamport时钟被排序，并且所有过去的版本被保留，一直到时间旅行限制。
图9是示出用于复制数据库的刷新请求900的示意图。在一个实施例中，将目标部署的表的状态同步到源部署的表的状态包括(a)将刷新请求从目标部署发送到源部署；(b)将快照响应从源部署发送到目标部署；以及(c)将快照响应导入到目标部署内。图9所示的刷新请求900计算在目标部署处的表的活动微分区的清单。清单包括当前表版本和在表版本处活动的一组全局微分区参考。在如图9所示的实施例中，没有其他元数据或本地文件微分区短名称被发送。
图9示出了将刷新请求从目标部署dep2发送到源部署dep1。源部署dep1包括表T的活动文件的列表。目标部署d2还包括表T的活动文件的列表。如在清单框中描绘的，作为例证，当前表版本为No.342。清单包括相关全局文件参考的列表。根据清单，目标部署d2将在表版本No.342处的所有活动文件转换为全局文件参考的列表。在本地添加的微分区fdn27和fdn28分别被转换为全局文件参考(dep2,fdn27)和(dep2,fdn28)。如本文所使用的，跟随有数字的命名约定“fdn”可以指在数据库的表中的某个微分区。如图9所示，只有全局文件参考作为表的清单的一部分被发送，并且只有活动文件被发送。
图10是示出用于复制数据库的快照响应1000的示意图。快照响应1000由源部署dep1响应于刷新请求900而生成。快照响应1000包括下列项中的一项或更多项：(a)待添加到表的所有微分区元数据；(b)在重新加密状态中的实际微分区；(c)待从表移除的所有全局微分区参考；(d)从目标部署dep2发送的表版本；以及(e)微分区被重新加密的复制主密钥。在一个实施例中，快照响应1000被划分成快照响应消息、元数据文件和微分区。快照响应1000消息可以包括指向元数据文件的指针。元数据文件可以包括所添加的微分区元数据和所删除的全局文件参考。元数据文件和微分区可以被复制到目标部署d2的入站卷(inbound volume)。
图10示出了源部署dep1向目标部署dep2传输快照响应1000。源部署dep1和目标部署dep2中的每一个都包括表T的活动文件的列表。快照响应1000为了说明目的而描绘表版本No.342，并指示待添加和删除的文件和元数据。在图10所示的实施例中，快照响应1000指示(fdn15及其相关联的元数据)应该连同(fdn16_g(dep0,fdn6)及其相关联的元数据)一起被添加。快照响应1000指示(dep1,fdn12)和(dep0,fdn4)以及(dep2,fdn27)应该被删除。
图10示出了目标部署dep2的表版本No.342被发送回目标部署dep2。如在源部署dep1和目标部署dep2之间的差异中所示的并且如在快照响应1000中所描绘的，具有短名称fdn15和fdn16_g的微分区需要被添加到在目标部署dep2处的表T。此外，具有全局文件参考(dep1,fdn12)、(dep0,fdn4)和(dep2,fdn27)的微分区需要从表T移除。微分区fdn15和fdn16_g将被重新加密并上传到目标部署dep2的入站卷。复制主密钥是快照响应的一部分(未在图10中示出)。
图11是示出用于复制数据库的快照响应的导入1100的示意图。在一个实施例中，当导入快照响应时，如果必要，在目标部署dep2处的表将被回滚到所发送的表版本。快照响应的所添加的文件可以接收基于DML的作业ID的本地短名称，并且可以包括后缀或其他合适的标识符(后缀“_g”在图9-11中被描绘)。原始全局文件参考可以作为元数据的一部分被存储。需要被删除的全局文件参考可以使用存储器中的索引在目标部署dep2处被转换为本地短名称。在一个实施例中，本地短名称被添加到属于DML命令的元数据文件，作为所删除的短名称部分的一部分。
如图11所示的快照响应的导入1100示出了如果必要，表T被回滚到表版本No.342。如在图11中的实施例中所示的，使用附加有“_g”的本地短名称(例如fdn25_g和fdn26_g)来将所添加的文件添加到表。保留原始全局文件参考，包括(dep1,fdn15)和(dep0,fdn6)。此外，所删除的全局文件参考被转换为本地短名称，包括(dep1,fdn12)、(dep0,fdn4)和(dep2,fdn27)，它们被转换为fdn22_g、fdn24_g和fdn27。另外，如图11所示，在本地删除的短名称被添加到属于DML命令的元数据文件的所删除的部分。该表可以被压缩程序修剪，并且两个表可以包含相同的状态。
图12是示出用于复制数据库的部署架构1200的示意图。部署架构1200包括部署D1、部署D2和部署D3。部署D1包括D1复制bucket 1204，其中它从其他部署接收消息。类似地，部署D2包括D2复制bucket 1210，部署D3包括D3复制bucket 1216。复制bucket 1204、1210、1216中的每一个都被分成子bucket，每个部署包括一个子bucket。复制bucket 1204、1210、1216的每个子bucket可以独立地配置有许可和访问凭证。部署D1包括D1 EP/微分区bucket 1206，部署D2包括D2 EP/微分区bucket 121，以及部署D3包括D2 EP/微分区bucket1218。
在一个实施例中，复制的所有阶段都在专用数据库下被创建，使得当创建部署时该数据库可以由短名称提及，并且部署可以被逻辑地分组。在一个实施例中，DeploymentDPO被用来存储将由消息传送服务和基础设施的其他部分使用的部署信息。在一个实施例中，DeploymentDPO是常规字典实体，并且通过创建、显示和删去语句的对它的访问被限制。DeploymentDPO是包括关于特定部署的信息(即元数据)的数据结构。DeploymentDPO可用于涉及该特定部署的操作。
复制bucket 1204、1210、1216中的每一个可以具有被激活的服务器侧加密。此外，包括客户数据的所有文件可以在客户端侧上被加密。一个部署可以具有对它自己的复制bucket的完全访问，而一个部署对在另一个部署的复制bucket上的它的子bucket可能只具有写访问，其中它将消息写到该子bucket。
在一个实施例中，当生成新部署时，生成该部署的新复制bucket，包括所有部署的所有子bucket，使得其他部署可以向新部署发送消息。此外，可以将该部署的新子bucket添加到所有其他部署的复制bucket，使得新部署可以向现有部署发送消息。
如图12所示的消息传送基础设施提供了使部署能够通过交换在bucket上的文件来交换通用消息的基础设施。消息可以通过云存储来交换，并且对于相关联的客户端帐户可以是透明的。对于相关联的客户端帐户，可能出现该帐户仅与在本地元数据上的常规数据持久化对象(DPO)交互。消息服务层可以对messageDPO如何被串行化和交换进行封装。
图13是示出用于在复制数据库时发送消息的过程流程1300的示意图。过程流程1300开始，并且在1302新消息被发起并存留到存储区。在1304消息正准备发送，并且在1306客户端帐户呼叫，指示消息应该被发送。在所有文件被上传之后，在1308消息准备好发送，并且在1310消息服务提取一批消息。在1312，消息服务周期性地提取准备好发送的一批消息并将它们移动到发送程序片(sending slice)，并且在1314消息服务将消息写到bucket。在消息文件已被生成并且消息已被发送之后，在1316消息将被接收侧清除并且从存储区移除。如果在1322在准备期间出现错误或者消息在准备程序片(preparing slice)中过期，则在1320从云存储清除上传的文件。在1318清理消息被发送到接收部署之后，消息可以从存储区移除。在1312，消息服务周期性地提取准备好发送的一批消息并将它们移动到发送程序片。在一个实施例中，消息发送服务计算并缓存用于包装数据加密密钥的所导出的密钥。消息服务可能进一步需要将当前和下一个分集器(diversifier)以及当前和下一个消息文件名存留在存储区中。
图14是示出用于在复制数据库时接收消息的过程流程1400的示意图。过程流程1400包括在1402消息服务从复制bucket下载消息文件并对该消息文件解串行化。在1404，消息被解串行化并存留到存储区。在1406接收到消息，并且在1408提取一批接收到的消息。在1410，消息处理服务形成一批接收到的消息并将它们移动到准备好处理程序片。在1412工作者线程处理消息之后，在1414消息为清理做好准备。在1416清理器从云存储移除消息文件，且然后在1418消息可以从元数据移除。
在一个实施例中，消息的清理发生在接收侧上，因为发送方仅具有对复制bucket的写访问。在消息被处理之后，清理服务可以清除在云存储上的所有相关文件，并将消息从存储区移除。在一个实施例中，对于在准备期间出错的所有消息，清理请求被发送到接收部署。
图15是示出包括用于复制数据库的三个部署的全局部署组1500的示意图。在如本文所公开的数据库复制期间，元数据在部署复制组(可以被称为部署组)内被存留和交换。生成部署组以实现在每个部署组之间的复制。在一个实施例中，每个部署维护在组中的所有其他部署的列表，包括其本身。在一个实施例中，使用“create deployment”数据定义语言(DDL)在每个部署内手动地维护列表，此DLL将用于在组中添加新的部署。此DDL可以在每个现有部署上被执行。在部署内，帐户可以变成全局的(相对于本地)以形成新的帐户复制组或加入现有的帐户复制组。只有作为同一帐户复制组的部分的帐户可以在该组当中复制数据。在一个实施例中，响应于将客户端的两个或更多个帐户链接在一起的客户端帐户请求而最初执行形成新帐户复制组。新帐户可以自动放置在与发出create语句的帐户相同的复制组中。
在一个实施例中，在单个帐户组内的帐户可以将本地对象升级为全局的，或者可以直接创建全局对象。在各种实施例中，对象可以包括数据库、用户、角色、仓库、全局连接、组织等。一旦对象是全局的，它就可以在全局帐户组中的任何帐户内被复制。复制全局对象通过首先在该对象将被复制到的所有帐户上为该全局对象创建本地副本对象且然后明确地、按计划或连续地刷新这些副本来实现。在一个实施例中，只有数据库可以由帐户管理员制定为全局的，并且副本可以仅由数据库的所有者明确地刷新。
在一个实施例中，存在用于管理和复制数据库数据的三类元数据。一类元数据针对部署，包括关于通过复制来手动地创建和复制的部署组的每个部署的元数据。一类元数据针对全局帐户，其中部署的所有全局帐户可以复制到在它所属的部署组内的所有其他部署。一类元数据包括全局数据库，包括在一个帐户上的所有全局数据库，其也可以在同一帐户组内被复制。在一个实施例中，只有关于全局数据库的所有副本的信息在帐户组中被复制到帐户组所存在的部署子集。
图15示出了使用包括三个部署——部署D1、部署D2和部署D3——的全局部署组的示例。如图15所示，部署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。在图15所示的实施例中，存在不作为任何组的部分并且不能具有全局对象的四个本地帐户。这四个本地帐户包括D1.A3、D2.A2、D3.A3和D3.A4并用虚线示出。只有全局帐户(即，用实线示出的且以无填充、浅灰色填充或深灰色填充加阴影的帐户)可以创建或复制全局数据库。在图15所示的示例中，存在四个全局数据库，包括DB1、DB2、DB3和DB4。同一全局数据库只可以在同一帐户组内存在或被复制。在图15所示的示例中，DB1和DB2是只可以在包括D1.A1、D1.A4、D2.A4和D3.A2的帐户组内被复制的全局数据库。此外，DB3只可以在包括D1.A2和D2.A1的帐户组内被复制。此外，DB4只可以在包括D1.A5和D2.A3的帐户组内被复制。另外，如图15所示，全局数据库不一定被在全局帐户组内的所有帐户复制。例如，(与DB1和DB2相关联的)深色加阴影的帐户组的客户端所有者没有用D1.A4帐户复制DB2。
在一个实施例中，关于全局对象的所有副本的元数据被复制到帐户组中的所有帐户。在某些实施例中，这可以允许本地帐户(即，用虚线示出的那些帐户)管理员列出在组中的任何全局对象的所有本地或远程副本。这可以使客户端帐户管理员能够通过指定正在被创建的新对象是全局对象的副本来在帐户组(例如，以无填充、浅灰色填充或深灰色填充示出的帐户组)中的其他帐户中生成该全局对象的新副本。
作为示例，(与深灰色填充帐户组相关联的)帐户D2.A4的客户端帐户希望将全局数据库DB2复制到该帐户。在该帐户中，客户端帐户可以执行显示全局数据库的命令。该命令将列出在帐户组中的所有全局数据库的副本。基于此示例，该命令将显示五个示例，如下面在表1中所示。
表1
地区 帐户 复制组 名称
D1 A1 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D1 A4 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D3 A2 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D1 A1 0400d847-4199-4f79-9a74-381761bc0cc9 DB2
D3 A2 0400d847-4199-4f79-9a74-381761bc0cc9 DB2
如表1所示，“复制组”列为同一数据库的所有副本描绘相同的值。数据库副本像在帐户组中的帐户一样链接在一起。这些数据库进一步形成具有等于复制组号的标识号的复制组。进一步到上述示例，D2.A4的客户端帐户可以通过发出在名称为“0400d847-4199-4f79-9a74-381761bc0cc9”的数据库复制组中创建新副本的命令来这么做。应当认识到，副本的本地名称可以是任何名称，并且指定复制组标识号使数据库与在该组中的其他数据库一样成为同一复制组的一部分。在生成新的数据库副本之后，D2.A4的客户端帐户然后可以发出显示所有数据库副本的命令，且然后将接收到具有刚刚生成的副本的列表，如下面在表2中所示。
表2
地区 帐户 复制组 名称
D1 A1 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D1 A4 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D3 A2 b4a193a3-77cc-49dc-a9c8-2a2ee1ae9b1e DB1
D1 A1 0400d847-4199-4f79-9a74-381761bc0cc9 DB2
D3 A2 0400d847-4199-4f79-9a74-381761bc0cc9 DB2
D2 A4 0400d847-4199-4f79-9a74-381761bc0cc9 DB5
进一步到上述示例，从该组中的任何帐户(即D1.A1或D1.A4)发出的相同命令将生成确切地相同的列表。所复制的元数据的传播可能花费一段时间，例如可能花费几秒钟，且在这段时间之后，每个其他部署都将知道新的副本。
类似于“show global databases”命令，“show global accounts”命令可以被发出以生成在组中的帐户集合的列表。继续上述示例，如果D3.A2的客户端帐户发出“showglobal accounts”命令，它将返回如在下面的表3中的列表。
表3
Figure BDA0002600351960000361
Figure BDA0002600351960000371
如表3所示，帐户复制组标识号未被暴露，因为对于给定客户只有一个帐户复制组。当从在部署组中的任何客户端帐户运行同一命令时，该命令将生成显示所有帐户组的列表，且在这种情况下，显示复制组标识号的一列可以被添加。
存储关于全局实体的元数据
在部署组中的每个部署可以维护关于在该组中的所有全局帐户的元数据。再次，使用上述示例，每个部署可以维护所有全局帐户的列表，即D1.A1、D1.A2、D1.A4、D1.A5、D2.A1、D2.A2、D3.A1和D3.A3。所有全局帐户的列表可以完全被复制。此外，每个部署将维护关于在该部署中存在的帐户组的子集中的所有全局对象的元数据。仍然使用该示例，部署D1维护关于由无填充、浅灰色和深灰色子组拥有的所有全局对象的元数据。因为部署D2只托管来自深灰色和无填充帐户组的帐户，所以它将只需要维护关于属于这两个帐户组的数据库的元数据。此外，部署D3必须仅维护关于在浅灰色和无填充帐户组中的全局数据库的信息。
在每个部署中，单个DPO可以被利用，并被命名为GlobalEntitiesDPO。GlobalEntitesDPO是维护关于被复制的实体(例如帐户、数据库、组织和/或连接)的信息和/或元数据的数据结构。单个DPO可以存储关于包括全局帐户的所有全局对象副本的元数据。帐户可以在帐户组中被建模为同一全局帐户的副本。因此，关于全局帐户和顶层帐户实体(例如数据库、用户、角色和仓库)的信息是统一的。此外，对于每个部署，GlobalEntitiesDPO可以存储关于部署需要知道的任何全局实体副本的信息，即关于部署需要知道的所有全局帐户和数据库副本(例如，在部署上存在的任何帐户组中的任何副本)的信息。
除了GlobalEntitiesDPO(其内容在部署之间被复制)之外，部署还可以识别在部署中的是全局的所有实体。为此，新的DPO不是需要的，但可以增强现有的BaseDictionaryDPO。BaseDictionaryDPO是DPO数据结构的底层抽象，其可用于管理在目录中可访问的信息。可以为全局标识号添加字段，该字段如果不为空则指示字典实体是全局的。此外，可以通过添加名称为“global”的新对象来索引所有全局字典实体以在给定全局标识号的情况下找到任何全局实体。在一个实施例中，这可以简化在特定部署中或在特定帐户中找到某个类型的所有全局实体的过程。
在一个实施例中，生成全局数据库包括创建在全局数据库复制组中的第一主副本。当创建这个第一主副本时，可以为它自动创建全局数据库复制组。可以使用“replication group”命令来创建在组中的其他副本。
在一个实施例中，全局对象可以被转换回本地对象。可以向客户端或管理员帐户提供改动帐户的命令以将现有的全局帐户转换成本地帐户。作为此命令的附带效应，在帐户内的所有全局对象都可以变成本地的。此外，可以使用类似的命令来使单个全局数据库变回常规的本地数据库。
在一个实施例中，对副本做出的任何更改将被复制到对该更改感兴趣的所有其他部署。更改可以包括创建、删去、更新或其他调整。更改的复制将尽快进行，并且可能在少于五秒钟内进行。此外，将在定期的时间段例如每小时一次对在部署中创建的所有副本进行复制，即使什么也没有改变。这可以确保如果任何事情失败，仍然会有一些覆盖。
此外，副本元数据的复制可以在后台进行。副本的元数据可以由拥有副本的客户端帐户或管理员改变，并且做出该更改的事务也可以利用通知来通知更改被做出。在一个实施例中，通知有效载荷(notification payload)仅仅是消耗更改的域。更改一被做出，线程就将更改复制到所有相关部署。对于帐户更改，这可以是在部署组中的所有部署，以及对于数据库更改，它们可以只是复制有帐户的部署子集。
在一个实施例中，复制更改利用全局消息传送框架。可以每部署使用一个全局消息来推送更改。相同的信息可以被复制多于一次，因此只有当该更改的所有全局消息已被列入队列时，才可以从存储区移除更改通知。
图16是示出用于复制数据库的加密系统1600的示意图。在一个实施例中，通过用不同的密钥将每个文件加密并限制对HSM(硬件安全模块)的访问的次数来执行加密。此外，加密可以确保没有对KMS的跨部署访问。在一个实施例中，消息文件包括串行化的GlobalMessageDPO的列表、下一个消息文件的名称以及用于下一个消息文件的分集器。GlobalMessageDPO可以指向一个或更多个消息主体文件。在一个实施例中，可以用可以由Java生成的随机数据加密密钥(DEK)来将消息文件加密。也可以用随机DEK来将消息主体文件加密。每个DEK可以由从全局主密钥(GMK)和在前一个消息文件中指定的分集器导出的密钥来包装。可以使用HMAC算法在HSM上执行密钥推导。导出的密钥可以被缓存在全局服务中，使得如果分集器没有改变，密钥可以被重新利用来包装下一个DEK。包装的DEK可以存储在云存储中的消息文件的头部中。在一个实施例中，分集器是可以在任何时间段改变的时间戳值，并且例如可以每小时进行改变。由于时间戳，目标可以拒绝早于例如一天或某个其他合适的时间段的分集器。这样，目标可以在分集器上实施一组粒度较小的属性。
图16示出了用于在加密复制的数据中使用的加密系统1600。加密系统1600包括HSM(硬件安全模块)全局主密钥(HSMGMK)1602。GSMGMK 1602被提供到多个部署。例如，在1618用HMAC包装DEK1，在1620用所缓存的HMAC包装DEK2，以及在1622用新的HMAC包装DEK3。DEK1下一文件1604被馈送到DEK2下一文件1606，DEK2下一文件1606被进一步馈送到DEK3下一文件1608。消息文件包括GlobalMessageDPO的列表(1614a,1614b,1614c)、名称和用于下一个消息文件的分集器(1610,1612a,1612b)。在一个实施例中，GlobalMessageDPO 1614a、1614b、1614c指向零个或更多个消息主体文件1616a-1616e。在一个实施例中，每个消息主体文件1616a-1616e用随机DEK加密，并且每个DEK由从HMSGMK和前一消息文件的分集器导出的密钥包装。如图16所示，消息主体文件1616a用DEK4加密，消息主体文件1616b用DEK5加密，消息主体文件1616c用DEK6加密，消息主体文件1616d用DEK7加密，以及消息主体文件1616e用DEK8加密。包装的DEK可以存储在云存储上的消息文件的头部中。导出的密钥可以被缓存和重新利用。此外，下一个分集器1610、1612a、1612b可以以任何合适的时间间隔例如每小时改变。
图17是示出用于复制数据库的利用客户端管理的密钥对文件的加密1700的示意图。当复制数据时，元数据文件和微分区从源部署被复制到目标部署。在一个实施例中，这涉及两次复制操作。首先，将文件从源部署的微分区卷复制到目标部署的入站阶段(inbound stage)。其次，将文件从目标部署的入站阶段复制到目标部署的微分区卷。在不能直接跨部署访问微分区卷的实施例中，双拷贝是必要的，因此在目标部署上绕过入站阶段。
在一个实施例中，数据复制由从目标部署到源部署的刷新请求900触发。刷新请求900由源部署所生成的快照响应1000应答。快照响应1000在消息主体文件中包括字典元数据连同元数据文件名称的列表和随机复制主密钥(RepMK)的快照，该字典元数据包括例如范式DPO、表DPO等。RepMK由源部署的HSM生成。在一个实施例中，每次复制操作包括将所有文件重新加密。当将文件复制到入站卷中时，使用从RepMK和每个文件的文件名导出的单独密钥来将文件重新加密。当将文件复制到目标微分区卷中时，使用在目标部署上的客户帐户的相应元数据文件主密钥和表主密钥来将文件重新加密。在一个实施例中，RepMK在作为快照响应的一部分被发送之前利用HSMGMK来包装。
在一个实施例中，当复制利用客户管理的密钥的客户端帐户的文件时，刷新请求900包括公共密钥。公共密钥是利用在目标部署上的客户KMS密钥生成的公共-私有密钥对的一部分。在快照响应1000中的已被包装的RepMK在被发送之前另外由公共密钥包装。因此在一个实施例中，RepMK被包装两次：第一次由HSMGMK包装，第二次由公共密钥包装。在从入站阶段到目标微分区卷的第二次复制期间，首先利用私有密钥将RepMK解开包装，然后利用HSMGMK解开包装。
如图17所示，源部署1702包括KMS 1706a和HSM 1708a。KMS 1706a和HSM 1708a用于产生AMK 1710a和TMK 1712a。在1714，用从源EPFM/TMK导出的密钥来将文件加密。目标部署1704包括它自己的KMS 1706b和HSM 1708b，KMS 1706b和HSM 1708b用于生成AMK 1710b和TMK 1712b。在1716在入站阶段处用从RepMK导出的密钥将文件加密，并且在1718在微分区卷处用从目标EP/TMK导出的密钥将文件加密。当从目标部署1704发送到源部署1702时，在1720刷新请求包括来自KMS的公共密钥。在1722，快照响应包括用HSMGMK和公共密钥包装的RepMK，快照响应由源部署1702生成并被传输到目标部署1704。如所示，刷新请求包括从在目标部署上的客户KMS密钥导出的公共密钥，快照响应包括用HSMGMK和公共密钥双重包装的随机RepMK。使用从RepMK和每个文件的文件名导出的单独密钥来将在入站阶段中的文件加密。此外在一个实施例中，照常利用元数据文件主密钥和表主密钥来将在微分区卷(源或目标)中的文件加密。
图18是用于在初级部署和次级部署之间的数据库的故障转移的方法1800的示意流程图。方法1800可以由一个或更多个计算资源(例如如本文公开的资源管理器102、执行平台112和/或复制和故障转移管理器228)执行。
方法1800开始，并且在1802计算资源复制存储在初级部署中的数据库数据，使得数据库数据还被存储在次级部署中。方法1800继续，并且在1804计算资源确定初级部署是不可用的。初级部署可能由于例如断电、导致在初级部署处的数据库数据的不正当的修改或删除的错误、数据中心断电、云提供商断电、错误、预定停机时间等而不可用。方法1800继续，并且在1806计算资源响应于确定初级部署是不可用的而在次级部署处对数据库数据执行一个或更多个事务。一个或更多个事务可以包括数据操纵语言(DML)语句(例如插入、删除、更新和/或合并命令)、在数据库数据上执行的查询等。方法1800继续，并且在1808计算资源确定初级部署不再是不可用的并且已返回到可用状态。方法1800继续，并且在1810计算资源响应于确定初级部署再次是可用的而将在数据库数据上的一个或更多个事务传播到初级部署。在一个实施例中，一个或更多个事务通过如本文公开的混合复制方法被传播到初级部署。在一个实施例中，通过被写到数据库的事务日志(如在例如图6-8中所公开的)来确定在次级部署上执行的一个或更多个事务。在一个实施例中，根据在图9-11中提供的公开来刷新初级部署。方法1800使得当初级部署是可用的时，计算资源(例如资源管理器102和/或执行平台112)在初级部署处执行对数据库数据的查询(见1812)。
图19是描绘示例计算设备1900的框图。在一些实施例中，计算设备1900用于实现本文讨论的系统和部件中的一个或更多个。例如，计算设备1900可以允许用户或管理员访问资源管理器1902。此外，计算设备1900可以与本文描述的任何系统和部件进行交互。因此，计算设备1900可以用于执行各种过程和任务，例如在本文中所讨论的那些过程和任务。计算设备1900可以起服务器、客户端或任何其他计算实体的作用。计算设备1900可以是各种各样计算设备(例如台式计算机、笔记本计算机、服务器计算机、手持计算机、平板计算机和诸如此类)中的任何一种。
计算设备1900包括一个或更多个处理器1902、一个或更多个存储器设备1904、一个或更多个接口1906、一个或更多个大容量存储设备1908以及一个或更多个输入/输出(I/O)设备1910，它们全部都耦合到总线1912。处理器1902包括执行在存储器设备1904和/或大容量存储设备1908中存储的指令的一个或更多个处理器或控制器。处理器1902还可以包括各种类型的计算机可读介质，例如高速缓存存储器。
存储器设备1904包括各种计算机可读介质，例如易失性存储器(例如随机存取存储器(RAM))和/或非易失性存储器(例如只读存储器(ROM))。存储器设备1904还可以包括可重写ROM，例如快闪存储器。
大容量存储设备1908包括各种计算机可读介质，例如磁带、磁盘、光盘、固态存储器(例如快闪存储器)等。在大容量存储设备1908中还可以包括各种驱动器以使从各种计算机可读介质读取和/或写到各种计算机可读介质成为可能。大容量存储设备1908包括可移动介质和/或不可移动介质。
I/O设备1910包括允许数据和/或其他信息被输入到计算设备1900或从计算设备1900被检索的各种设备。示例I/O设备1910包括光标控制设备、键盘、小键盘、麦克风、监视器或其他显示设备、扬声器、打印机、网络接口卡、调制解调器、透镜、CCD或其他图像捕获设备和诸如此类。
接口1906包括允许计算设备1900与其他系统、设备或计算环境交互的各种接口。示例接口1906包括任何数量的不同的网络接口，例如到局域网(LAN)、广域网(WAN)、无线网络和互联网的接口。
总线1912允许处理器1902、存储器设备1904、接口1906、大容量存储设备1908和I/O设备1910与彼此通信以及与耦合到总线1912的其他设备或部件通信。总线1912代表若干类型的总线结构(例如系统总线、PCI总线、IEEE 1394总线、USB总线等)中的一种或更多种。
为了说明的目的，程序和其他可执行程序部件在本文中被示为分立的块，但是应当理解，这样的程序和部件可以在不同时间驻留在计算设备1900的不同存储部件中，并且由处理器1902执行。可选地，在本文中描述的系统和过程可以以硬件、或硬件、软件和/或固件的组合来实现。例如，一个或更多个专用集成电路(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是如在示例1-10中的任一项中的系统，还包括用于响应于初级部署变得不可用而将客户端帐户连接从初级部署转移到次级部署的装置。
示例12是如在示例1-11中的任一项中的系统，其中用于将一个或更多个事务传播到初级部署的装置被配置为仅传播该一个或更多个事务，而不复制在初级部署变得不可用之前已经存在于初级部署中的任何数据。
示例13是如在示例1-12中的任一项中的系统，其中用于将一个或更多个事务传播到初级部署的装置被配置为基于全局文件标识符来确定该一个或更多个事务，该全局文件标识符指示在数据库数据中的哪些文件自从初级部署变得不可用以来被更新。
示例14是一种方法。该方法包括复制存储在初级部署中的数据库数据，使得数据库数据还被存储在次级部署中。该方法包括响应于确定初级部署是不可用的而在次级部署处对数据库数据执行一个或更多个事务。该方法包括响应于确定初级部署不再是不可用的而将在数据库数据上的一个或更多个事务传播到初级部署。该方法使得当初级部署是可用的时在初级部署处对数据库数据执行查询。
示例15是如在示例14中的方法，还包括当初级部署和次级部署中的每一个都是可用的时在初级部署和次级部署处对数据库数据执行新的事务。
示例16是如在示例14-15中的任一项中的方法，还包括响应于确定初级部署是不可用的而在初级部署是不可用的持续时间内将对数据库数据的查询的执行从初级部署转移到次级部署。
示例17是如在示例14-16中的任一项中的方法，其中将查询的执行从初级部署转移到次级部署发生在初级部署被确定为不可用的之后次级部署变得可用于执行查询的用户定义的最大可接受的时间段内。
示例18是如在示例14-17中的任一项中的方法，还包括通过确定下列项中的一项或更多项来确定初级部署是不可用的：在初级部署处出现了断电、出现了导致在初级部署处的数据库数据的不正当的修改或删除的错误、在初级部署处出现了数据中心断电、初级部署的云提供商经历了断电、在初级部署处出现了错误或者初级部署正在经历预定停机时间。
示例19是一种处理器，其能够编程来执行存储在非暂时性计算机可读存储介质中的指令，该指令包括：复制存储在初级部署中的数据库数据，使得数据库数据还被存储在次级部署中；响应于确定初级部署是不可用的而在次级部署处对数据库数据执行一个或更多个事务；响应于确定初级部署不再是不可用的而将在数据库数据上的一个或更多个事务传播到初级部署；以及当初级部署是可用的时，在初级部署处对数据库数据执行查询。
示例20是如在示例19中的处理器，其中指令还包括当初级部署和次级部署中的每一个都是可用的时在初级部署和次级部署处对数据库数据执行新的事务。
示例21是如在示例19-20中的任一项中的处理器，其中指令还包括响应于确定初级部署是不可用的而在初级部署是不可用的持续时间内将对数据库数据的查询的执行从初级部署转移到次级部署。
示例22是如在示例19-21中的任一项中的处理器，其中指令还包括通过确定下列项中的一项或更多项来确定初级部署是不可用的：在初级部署处出现了断电、出现了导致在初级部署处的数据库数据的不正当的修改或删除的错误、在初级部署处出现了数据中心断电、初级部署的云提供商经历了断电、在初级部署处出现了错误或者初级部署正在经历预定停机时间。
本文描述的系统和方法允许数据作为与计算(或处理)资源分离的服务被存储和访问。即使没有从执行平台分配计算资源，数据对虚拟仓库也是可用的而不需要从远程数据源重新加载数据。因此，数据是可用的，与数据相关联的计算资源的分配无关。所描述的系统和方法对于任何类型的数据都是有用的。在特定实施例中，数据以结构化的优化格式被存储。数据存储/访问服务与计算服务的解耦也简化了在不同用户和组当中的数据的共享。如本文所讨论的，每个虚拟仓库可以访问它具有访问许可的任何数据，甚至在与其他虚拟仓库正在访问相同数据的同一时间进行访问。这个架构支持运行查询而无需在本地高速缓存中存储任何实际数据。本文描述的系统和方法能够进行透明的动态数据移动，其根据需要以对系统的用户透明的方式将数据从远程存储设备移动到本地高速缓存。此外，这个架构支持数据共享而无需预先的数据移动，因为由于数据存储服务与计算服务的解耦，任何虚拟仓库可以访问任何数据。
虽然根据某些优选实施例描述了本公开，但是给定本公开的益处，其他实施例对于本领域中的普通技术人员将是明显的，包括不提供本文所阐述的所有益处和特征的实施例，这些实施例也在本公开的范围内。应理解，其他实施例可以被利用而不偏离本公开的范围。

Claims (22)

1.一种系统，包括：
用于复制存储在初级部署中的数据库数据使得所述数据库数据还被存储在次级部署中的装置；
用于确定所述初级部署是不可用的装置；
用于响应于确定所述初级部署是不可用的而在所述次级部署处执行对所述数据库数据的一个或更多个事务的装置；
用于确定所述初级部署不再是不可用的装置；
用于响应于确定所述初级部署不再是不可用的而将对所述数据库数据的所述一个或更多个事务传播到所述初级部署的装置；以及
用于当所述初级部署是可用的时在所述初级部署处执行对所述数据库数据的查询的装置。
2.根据权利要求1所述的系统，还包括用于当所述初级部署和所述次级部署中的每一个都是可用的时在所述初级部署和所述次级部署处执行对所述数据库数据的新的事务的装置。
3.根据权利要求1所述的系统，还包括用于在所述初级部署是不可用的持续时间内将对所述数据库数据的查询的执行从所述初级部署转移到所述次级部署的装置。
4.根据权利要求1所述的系统，其中所述初级部署和所述次级部署位于不同的地理位置上。
5.根据权利要求1所述的系统，其中所述初级部署和所述次级部署由不同的基于云的存储提供商提供。
6.根据权利要求1所述的系统，还包括用于当所述初级部署或所述次级部署中的任一个的可用性状态改变时向与所述数据库数据相关联的帐户提供通知的装置。
7.根据权利要求1所述的系统，还包括用于遵守在所述初级部署被确定为不可用的之后所述次级部署变得可用于执行对所述数据库数据的查询的用户定义的最大可接受的时间段的装置。
8.根据权利要求1所述的系统，其中用于确定所述初级部署是不可用的装置包括用于确定下列项中的一项或更多项的装置：
在所述初级部署处出现了断电；
出现了导致在所述初级部署处的所述数据库数据的不正当的修改或删除的错误；
在所述初级部署处出现了数据中心断电；
所述初级部署的云提供商经历了断电；
在所述初级部署处出现了错误；或者
所述初级部署正在经历预定停机时间。
9.根据权利要求1所述的系统，还包括用于在响应于所述初级部署变得不可用而将数据库操作从所述初级部署转移到所述次级部署时遵守应用能够容忍丢失的用户定义的最大数量的数据库事务的装置。
10.根据权利要求1所述的系统，其中用于复制存储在所述初级部署中的所述数据库数据的装置包括用于响应于所述初级部署变得不可用而进行复制的装置。
11.根据权利要求1所述的系统，还包括用于响应于所述初级部署变得不可用而将客户端帐户连接从所述初级部署转移到所述次级部署的装置。
12.根据权利要求1所述的系统，其中用于将所述一个或更多个事务传播到所述初级部署的装置包括用于仅传播所述一个或更多个事务而不复制在所述初级部署变得不可用之前已经存在于所述初级部署中的任何数据的装置。
13.根据权利要求1所述的系统，其中用于将所述一个或更多个事务传播到所述初级部署的装置包括用于基于全局文件标识符来确定所述一个或更多个事务的装置，所述全局文件标识符指示在所述数据库数据中的哪些文件自从所述初级部署变得不可用以来被更新。
14.一种方法，包括：
复制存储在初级部署中的数据库数据，使得所述数据库数据还被存储在次级部署中；
响应于确定所述初级部署是不可用的而在所述次级部署处执行对所述数据库数据的一个或更多个事务；
响应于确定所述初级部署不再是不可用的而将对所述数据库数据的所述一个或更多个事务传播到所述初级部署；以及
当所述初级部署是可用的时，在所述初级部署处执行对所述数据库数据的查询。
15.根据权利要求14所述的方法，还包括当所述初级部署和所述次级部署中的每一个都是可用的时在所述初级部署和所述次级部署处执行对所述数据库数据的新的事务。
16.根据权利要求14所述的方法，还包括响应于确定所述初级部署是不可用的，在所述初级部署是不可用的持续时间内将对所述数据库数据的查询的执行从所述初级部署转移到所述次级部署。
17.根据权利要求16所述的方法，其中将查询的执行从所述初级部署转移到所述次级部署发生在所述初级部署被确定为不可用的之后所述次级部署变得可用于执行查询的用户定义的最大可接受的时间段内。
18.根据权利要求14所述的方法，还包括通过确定下列项中的一项或更多项来确定所述初级部署是不可用的：
在所述初级部署处出现了断电；
出现了导致在所述初级部署处的所述数据库数据的不正当的修改或删除的错误；
在所述初级部署处出现了数据中心断电；
所述初级部署的云提供商经历了断电；
在所述初级部署处出现了错误；或者
所述初级部署正在经历预定停机时间。
19.一种处理器，其能够编程来执行存储在非暂时性计算机可读存储介质中的指令，所述指令包括：
复制存储在初级部署中的数据库数据，使得所述数据库数据还被存储在次级部署中；
响应于确定所述初级部署是不可用的而在所述次级部署处执行对所述数据库数据的一个或更多个事务；
响应于确定所述初级部署不再是不可用的而将对所述数据库数据的所述一个或更多个事务传播到所述初级部署；以及
当所述初级部署是可用的时，在所述初级部署处执行对所述数据库数据的查询。
20.根据权利要求19所述的处理器，其中所述指令还包括当所述初级部署和所述次级部署中的每一个都是可用的时在所述初级部署和所述次级部署处执行对所述数据库数据的新的事务。
21.根据权利要求19所述的处理器，其中所述指令还包括响应于确定所述初级部署是不可用的，在所述初级部署是不可用的持续时间内将对所述数据库数据的查询的执行从所述初级部署转移到所述次级部署。
22.根据权利要求19所述的处理器，其中所述指令还包括通过确定下列项中的一项或更多项来确定所述初级部署是不可用的：
在所述初级部署处出现了断电；
出现了导致在所述初级部署处的所述数据库数据的不正当的修改或删除的错误；
在所述初级部署处出现了数据中心断电；
所述初级部署的云提供商经历了断电；
在所述初级部署处出现了错误；或者
所述初级部署正在经历预定停机时间。
CN201980010014.2A 2018-07-06 2019-04-23 在数据库系统中的数据复制和数据故障转移 Active CN111656340B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862694656P 2018-07-06 2018-07-06
US62/694,656 2018-07-06
PCT/US2019/028794 WO2020009737A1 (en) 2018-07-06 2019-04-23 Data replication and data failover in database systems

Publications (2)

Publication Number Publication Date
CN111656340A true CN111656340A (zh) 2020-09-11
CN111656340B CN111656340B (zh) 2023-07-18

Family

ID=69059202

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980010014.2A Active CN111656340B (zh) 2018-07-06 2019-04-23 在数据库系统中的数据复制和数据故障转移

Country Status (6)

Country Link
US (5) US11151161B2 (zh)
EP (2) EP4283482A3 (zh)
KR (1) KR102307371B1 (zh)
CN (1) CN111656340B (zh)
DE (1) DE202019005483U1 (zh)
WO (1) WO2020009737A1 (zh)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102307371B1 (ko) * 2018-07-06 2021-10-05 스노우플레이크 인코포레이티드 데이터베이스 시스템 내의 데이터 복제 및 데이터 장애 조치
US11144631B2 (en) 2018-09-11 2021-10-12 Apple Inc. Dynamic switching between pointer authentication regimes
US11086840B2 (en) 2018-12-07 2021-08-10 Snowflake Inc. Transactional streaming of change tracking data
US11200256B2 (en) * 2019-04-11 2021-12-14 International Business Machines Corporation Record replication for multi-column partitioning on distributed database systems
US10952222B1 (en) * 2019-06-11 2021-03-16 Amazon Technologies, Inc. Isolated and flexible network data transmission between computing infrastructure collections
US11392617B2 (en) * 2020-03-26 2022-07-19 International Business Machines Corporation Recovering from a failure of an asynchronous replication node
CN111581016B (zh) * 2020-04-14 2021-05-18 上海爱数信息技术股份有限公司 一种现代应用的副本数据管理系统及方法
US11501014B2 (en) * 2020-05-07 2022-11-15 International Business Machines Corporation Secure data replication in distributed data storage environments
US10949402B1 (en) 2020-05-26 2021-03-16 Snowflake Inc. Share replication between remote deployments
US11436110B2 (en) * 2021-02-11 2022-09-06 Huawei Technologies Co., Ltd. Distributed database remote backup
US11263206B1 (en) * 2021-03-02 2022-03-01 Coupang Corp. Systems and methods for multi-nodal stream processing framework for partitioned database
US11163797B1 (en) * 2021-03-21 2021-11-02 Snowflake Inc. Database replication to remote deployment with automated fulfillment
KR102351220B1 (ko) 2021-10-08 2022-01-14 주식회사 이글루시큐리티 대용량 데이터 처리 시 효율적인 서버 부하 분산을 위한 db 이중화 방법 및 이를 지원하는 장치
US11886437B2 (en) 2021-12-08 2024-01-30 International Business Machines Corporation Reduced latency query processing
US11874751B2 (en) 2021-12-09 2024-01-16 International Business Machines Corporation Operating a data center
US11734301B1 (en) * 2022-03-23 2023-08-22 Snowflake Inc. Selective table replication to enable stream replication
US11645231B1 (en) * 2022-04-24 2023-05-09 Morgan Stanley Services Group Inc. Data indexing for distributed query execution and aggregation
US20230359646A1 (en) * 2022-05-09 2023-11-09 Walmart Apollo, Llc System and method for service synchronization
US20230401232A1 (en) * 2022-06-09 2023-12-14 Snowflake Inc. Cross-cloud replication of recurrently executing data pipelines

Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030158869A1 (en) * 2002-02-20 2003-08-21 International Business Machines Corporation Incremental update control for remote copy
CN101211289A (zh) * 2006-12-26 2008-07-02 国际商业机器公司 恢复操作管理系统和方法
US20080244026A1 (en) * 2002-05-13 2008-10-02 At&T Delaware Intellectual Property, Inc., Formerly Known As Bellsouth Intellectual Property Real-Time Notification of Presence Changes
US20090213864A1 (en) * 2008-02-25 2009-08-27 International Business Machines Corporation Inbound blocking of data received from a lan in a multi-processor virtualization environment
US7627584B2 (en) * 2005-11-30 2009-12-01 Oracle International Corporation Database system configured for automatic failover with no data loss
CN101681383A (zh) * 2007-05-21 2010-03-24 Nhn株式会社 用于数据库管理系统的数据复制方法及系统
US20110047294A1 (en) * 2005-06-29 2011-02-24 Visa U.S.A., Inc. Adaptive gateway for switching transactions and data on unreliable networks using context-based rules
WO2012067964A1 (en) * 2010-11-16 2012-05-24 Actifio, Inc. Systems and methods for data management virtualization
CN102648448A (zh) * 2009-10-26 2012-08-22 亚马逊技术股份有限公司 供应并管理已复制数据
CN102656565A (zh) * 2009-10-26 2012-09-05 亚马逊技术股份有限公司 已复制数据的故障切换和恢复
US20130254590A1 (en) * 2010-11-26 2013-09-26 Telefonaktiebolaget L M Eriscsson (PUBL) Real time database system
US20140032981A1 (en) * 2012-07-26 2014-01-30 Apple Inc. Intermediate database management layer
US20150254142A1 (en) * 2014-03-06 2015-09-10 Software Ag Systems and/or methods for data recovery in distributed, scalable multi-tenant environments
US20150378840A1 (en) * 2014-06-25 2015-12-31 Heping Shang Ensuring the same completion status for transactions after recovery in a synchronous replication environment
US20160124663A1 (en) * 2014-10-29 2016-05-05 Commvault Systems, Inc. Accessing a file system using tiered deduplication
US20160246865A1 (en) * 2015-02-25 2016-08-25 International Business Machines Corporation Zero-data loss recovery for active-active sites configurations
US9804935B1 (en) * 2015-01-26 2017-10-31 Intel Corporation Methods for repairing a corrupted database to a new, correct state by selectively using redo and undo operations
US20180068008A1 (en) * 2016-09-02 2018-03-08 Snowflake Computing, Inc. Incremental Clustering Maintenance Of A Table

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7827136B1 (en) * 2001-09-20 2010-11-02 Emc Corporation Management for replication of data stored in a data storage environment including a system and method for failover protection of software agents operating in the environment
US7228326B2 (en) * 2002-01-18 2007-06-05 Bea Systems, Inc. Systems and methods for application deployment
US8095511B2 (en) * 2003-06-30 2012-01-10 Microsoft Corporation Database data recovery system and method
US20050071195A1 (en) * 2003-09-30 2005-03-31 Cassel David A. System and method of synchronizing data sets across distributed systems
US7353231B1 (en) * 2005-10-21 2008-04-01 At&T Corp. Flip-flap mechanism for high availability, online analytical processing databases
US7725764B2 (en) * 2006-08-04 2010-05-25 Tsx Inc. Failover system and method
US20110047413A1 (en) * 2009-08-20 2011-02-24 Mcgill Robert E Methods and devices for detecting service failures and maintaining computing services using a resilient intelligent client computer
US20120159234A1 (en) * 2010-12-15 2012-06-21 Microsoft Corporation Providing resilient services
US10545987B2 (en) * 2014-12-19 2020-01-28 Pure Storage, Inc. Replication to the cloud
US20190102841A1 (en) * 2017-10-04 2019-04-04 Servicenow, Inc. Mapping engine configurations with task managed workflows and grid user interfaces
KR102307371B1 (ko) * 2018-07-06 2021-10-05 스노우플레이크 인코포레이티드 데이터베이스 시스템 내의 데이터 복제 및 데이터 장애 조치

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030158869A1 (en) * 2002-02-20 2003-08-21 International Business Machines Corporation Incremental update control for remote copy
US20080244026A1 (en) * 2002-05-13 2008-10-02 At&T Delaware Intellectual Property, Inc., Formerly Known As Bellsouth Intellectual Property Real-Time Notification of Presence Changes
US20110047294A1 (en) * 2005-06-29 2011-02-24 Visa U.S.A., Inc. Adaptive gateway for switching transactions and data on unreliable networks using context-based rules
US7627584B2 (en) * 2005-11-30 2009-12-01 Oracle International Corporation Database system configured for automatic failover with no data loss
CN101211289A (zh) * 2006-12-26 2008-07-02 国际商业机器公司 恢复操作管理系统和方法
CN101681383A (zh) * 2007-05-21 2010-03-24 Nhn株式会社 用于数据库管理系统的数据复制方法及系统
US20090213864A1 (en) * 2008-02-25 2009-08-27 International Business Machines Corporation Inbound blocking of data received from a lan in a multi-processor virtualization environment
CN102648448A (zh) * 2009-10-26 2012-08-22 亚马逊技术股份有限公司 供应并管理已复制数据
CN102656565A (zh) * 2009-10-26 2012-09-05 亚马逊技术股份有限公司 已复制数据的故障切换和恢复
US20180067822A1 (en) * 2009-10-26 2018-03-08 Amazon Technologies, Inc. Failover and recovery for replicated data instances
WO2012067964A1 (en) * 2010-11-16 2012-05-24 Actifio, Inc. Systems and methods for data management virtualization
US20130254590A1 (en) * 2010-11-26 2013-09-26 Telefonaktiebolaget L M Eriscsson (PUBL) Real time database system
US20140032981A1 (en) * 2012-07-26 2014-01-30 Apple Inc. Intermediate database management layer
US20150254142A1 (en) * 2014-03-06 2015-09-10 Software Ag Systems and/or methods for data recovery in distributed, scalable multi-tenant environments
US20150378840A1 (en) * 2014-06-25 2015-12-31 Heping Shang Ensuring the same completion status for transactions after recovery in a synchronous replication environment
US20160124663A1 (en) * 2014-10-29 2016-05-05 Commvault Systems, Inc. Accessing a file system using tiered deduplication
US9804935B1 (en) * 2015-01-26 2017-10-31 Intel Corporation Methods for repairing a corrupted database to a new, correct state by selectively using redo and undo operations
US20160246865A1 (en) * 2015-02-25 2016-08-25 International Business Machines Corporation Zero-data loss recovery for active-active sites configurations
US20180068008A1 (en) * 2016-09-02 2018-03-08 Snowflake Computing, Inc. Incremental Clustering Maintenance Of A Table

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
LISA WU等: "Hardware Partitioning for Big Data Analytics", 《IEEE MICRO》 *
S. ELNIKETY等: ""Database replication using generalized snapshot isolationg"" *
刘秉春等: "数据库备份两例故障的恢复与解决方法", 《万方数据库》 *
李卫东;: "梅钢主机系统高可用性分析" *
王嘉豪等: "\"集群数据库系统的日志复制和故障恢复\"" *

Also Published As

Publication number Publication date
KR102307371B1 (ko) 2021-10-05
US20230267131A1 (en) 2023-08-24
WO2020009737A1 (en) 2020-01-09
US20220215041A1 (en) 2022-07-07
EP3714372A1 (en) 2020-09-30
US20200104310A1 (en) 2020-04-02
EP3714372A4 (en) 2021-02-24
US11151161B2 (en) 2021-10-19
US11630845B2 (en) 2023-04-18
EP4283482A3 (en) 2024-01-24
US11314777B2 (en) 2022-04-26
CN111656340B (zh) 2023-07-18
US20220019600A1 (en) 2022-01-20
US20200012659A1 (en) 2020-01-09
KR20200100173A (ko) 2020-08-25
DE202019005483U1 (de) 2020-10-28
EP4283482A2 (en) 2023-11-29

Similar Documents

Publication Publication Date Title
CN111656340B (zh) 在数据库系统中的数据复制和数据故障转移
US20220237166A1 (en) Table partitioning within distributed database systems
US10997207B2 (en) Connection management in a distributed database
US20190332595A1 (en) Disconnected operation within distributed database systems
Goel et al. Towards scalable real-time analytics: An architecture for scale-out of OLxP workloads
US20120158650A1 (en) Distributed data cache database architecture
KR20180021679A (ko) 일관된 데이터베이스 스냅샷들을 이용한 분산 데이터베이스에서의 백업 및 복원
Lipcon et al. Kudu: Storage for fast analytics on fast data
EP3000034A1 (en) Index update pipeline
US10776165B2 (en) Optimized database resource handling
Chohan et al. Database-agnostic transaction support for cloud infrastructures
Viotti et al. Hybris: Robust hybrid cloud storage
US20230418711A1 (en) Repairing unresolved dangling references after failover
Scotti et al. Comdb2 bloomberg's highly available relational database system
Armend et al. Transactional Support in the Cloud: Taking Advantage of Classic Approaches

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: Montana

Applicant after: SNOWFLAKE COMPUTING Inc.

Address before: California, USA

Applicant before: SNOWFLAKE COMPUTING Inc.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant
CP03 Change of name, title or address

Address after: Montana

Patentee after: Snowflake Co.

Country or region after: U.S.A.

Address before: Montana

Patentee before: SNOWFLAKE COMPUTING Inc.

Country or region before: U.S.A.