用于分布式数据库系统的系统范围检查点避免的制作方法
【专利说明】用于分布式数据库系统的系统范围检查点避免
[0001]背景
[0002]在一些情况下，软件堆栈的各种部件的分布可提供(或支持)容错性(例如，通过复制)、较高耐久性、和较不昂贵的解决方案(例如，通过使用许多较小的、较不昂贵的部件，而不是较少大型的、昂贵的部件)。然而，在历史上数据库已经是至少服从分布的软件堆栈的部件。例如，可能难以分布数据库同时仍确保期望它们提供的所谓ACID特性(例如，原子性、一致性、隔离性、和耐久性)。
[0003]尽管大部分现存的相关数据库未被分布，使用两个常用模型中的一个来“向外扩展”(与通过仅采用较大单片系统的“向上扩展”相反)一些现存的数据库无共享”模型和“共享磁盘”模型。一般来说，在“无共享”模型中，接收的查询分解成数据库碎片(其中的每一个包括查询部件)，这些碎片被发送至不同的计算机节点用于查询处理，并且在它们返回前收集和集合结果。一般来说，在“共享磁盘”模型中，群集中的每个计算机节点访问相同的基础数据。在采用这个模型的系统中，必须非常小心以便管理高速缓存一致性。在这两个模型中，在多个节点(包括单机数据库实例的所有功能性)上复制大型、单片数据库，并且添加“胶合”逻辑以便将它们缝合在一起。例如，在“无共享”模型中，胶合逻辑可提供分配器的功能性，所述分配器使查询细分、将它们发送至多个计算机节点、以及随后组合结果。在“共享磁盘”模型中，胶合逻辑可用来将多个节点的高速缓存融合在一起(例如，以便管理在高速缓存层处的一致性)。部署这些“无共享”和“共享磁盘”数据库系统可能花费较大，并且维持起来较复杂，以及它们可能过度服务许多数据库使用情况。
【附图说明】
[0004]图1为示出根据一个实施方案的数据库软件堆栈的各种部件的框图。
[0005]图2为示出根据一些实施方案的服务系统架构的框图，所述服务系统架构可被配置来实施基于网络服务的数据库服务。
[0006]图3为示出根据一个实施方案的数据库系统的各种部件的框图，所述数据库系统包括数据库引擎和独立分布式数据库存储服务。
[0007]图4为示出根据一个实施方案的分布式数据库优化存储系统的框图。
[0008]图5为示出根据一个实施方案的数据库系统中的独立分布式数据库优化存储系统的使用的框图。
[0009]图6为示出根据一个实施方案的可将数据和元数据存储在分布式数据库优化存储系统的给定节点上的方式的框图。
[0010]图7为示出根据一个实施方案的数据库容量的示例性配置的框图。
[0011]图8为示出根据一些实施方案的用于在分布式数据库系统中的系统范围检查点避免的方法的流程图。
[0012]图9A为展示根据一些实施方案的执行用于分布式数据库系统的快速崩溃恢复的方法的一系列图示。
[0013]图9B为示出根据一些实施方案的执行用于分布式数据库系统的快速崩溃恢复的方法的流程图。
[0014]图9C为示出根据一些实施方案的在所恢复数据库中处理访问请求的方法的流程图。
[0015]图10为示出根据各种实施方案的被配置来实施数据库系统的至少一部分的计算机系统的框图，所述数据库系统包括数据库引擎和独立分布式数据库存储服务。
[0016]虽然在本文中通过列举若干实施方案和示意性附图的实例的方式描述了实施方案，本领域的技术人员应认识到，实施方案并不限于所描述的实施方案或附图。应理解，附图和对其的详细描述并非意图将实施方案限于所公开的特定形式，而是相反，其意图在于涵盖落入由所附权利要求书所界定的精神和范围内的所有修改、等同物以及替代方案。本文中使用的任何标题都仅用于组织目的，并且并不意图用于限制描述或权利要求书的范围。贯穿本申请所使用的词语“可以”是在许可的意义上(即意指具有可能性)、而非强制的意义上(即意指必须)使用。词语“包括(include/including/includes) ”指示开放性关系并且因此意味着包括但不限于。类似地，词语“具有(have/having/has)”也指示开放性关系，并且因此意味着具有但不限于。本文使用的术语“第一”、“第二”、“第三”等用作它们后面的名词的标签，并且不暗示任何类型的排序(例如，空间、时间、逻辑等)，除非这种排序另有明确说明。
[0017]各种部件可被描述为“被配置来”执行一个或多个任务。在这类情况下，“被配置来”是一般意味着“具有在操作过程中执行一个或多个任务的结构”的宽泛叙述。因此，部件可被配置来执行任务，即使是部件当前并未执行所述任务时(例如，计算机系统可被配置来执行操作，即使是所述操作当前并未被执行时)。在一些情况下，“被配置来”可以是一般意味着“具有在操作过程中执行一个或多个任务的电路系统”的结构的宽泛叙述。因此，部件可被配置来执行任务，即使是所述部件当前并未开启时。一般而言，形成对应于“被配置来”的结构的电路系统可包括硬件电路。
[0018]为了方便描述，各种部件可被描述为执行一个或多个任务。这些描述应被解释为包括短语“被配置来”。叙述被配置来执行一个或多个任务的部件明确地意图不援引美国法典第35章第112条第六段对所述部件的解释。
[0019]“基于.”如本文所使用，此术语用于描述影响确定的一个或多个因素。此术语不排除可能影响确定的另外因素。也就是说，确定可仅仅是基于这些因素，或至少部分地基于这些因素。考虑短语“基于B确定A”。尽管B可能是影响A的确定的因素，但是这种短语不排除也基于C确定A。在其他例子中，可仅基于B来确定A。
[0020]本公开的范围包括本文公开的任何特征或特征的组合(明确地或含蓄地)或其任何概括，无论它是否缓解了本文所提出的任何或所有问题。因此，在本申请(或要求其优先权的申请)的审理过程中可以就特征的任何此类组合制定新的权利要求书。具体地，参考所附权利要求书，来自从属权利要求的特征可与独立权利要求的特征相结合，并且来自相应独立权利要求的特征可以任何适当的方式而不是仅仅以所附权利要求书中列举的具体结合来组合。
【具体实施方式】
[0021]本发明公开分布式数据库系统的系统范围检查点避免的各种实施方案。在一些实施方案中，分布式存储系统的存储节点可从数据库系统接收一个或多个重做日志记录，所述一个或多个重做日志记录链接至存储在存储节点上的特定数据页面。数据页面可以是存储用于数据库的数据的多个数据页面中的一个。至少部分地基于链接至特定数据页面的一个或多个重做日志记录，可检测特定数据页面的合并事件。可执行合并操作以将一个或多个日志记录应用至先前存储版本的特定数据页面，以产生在它的当前状态下的特定数据页面。
[0022]本发明公开用于分布式数据库系统的快速崩溃恢复的各种实施方案。在一些实施方案中，数据库系统头节点可执行故障恢复操作。在从系统故障恢复之后，可与存储用于数据库的数据的分布式存储系统的存储节点建立连接。在一些实施方案中，在与存储节点建立连接之后，数据库头节点可使得数据库可供用于访问。在至少一些实施方案中，可接收一个或多个访问请求，并且可从存储节点请求和接收一个或多个数据页面的当前状态。
[0023]本说明书首先描述被配置来实施系统范围检查点避免(例如，创建、删除、使用、操纵等)和快速崩溃恢复技术的示例性基于网络服务的数据库服务。示例性基于网络服务的数据库服务的描述中包括示例性基于网络服务的数据库服务的各个方面，如数据库引擎和独立分布式数据库存储服务。本说明书随后描述用于系统范围检查点避免和快速崩溃恢复的方法的各种实施方案的流程图。接下来，本说明书描述可实施所公开的技术的示例性系统。在整个说明书中提供各种实例。
[0024]在一些实施方案中，本文中描述的系统可实施网络服务，所述网络服务使得客户端(例如，订阅者)能够在云计算环境中操作数据存储系统。在一些实施方案中，数据存储系统可为高度可缩放的和可扩展的企业级数据库系统。在一些实施方案中，查询可指向横跨多个物理源分布的数据库存储，并且数据库系统可在所需的基础上扩大或缩小。在不同实施方案中，数据库系统可在各种类型和/或组织的数据库模式下有效工作。在一些实施方案中，客户端/订阅者可能以许多方式(例如，通过到数据库系统的SQL接口以交互方式)提交查询。在其他实施方案中，外部应用和程序可使用到数据库系统的开放数据库连接(ODBC)和/或Java数据库连接(JDBC)驱动器接口来提交查询。
[0025]更具体地，在一些实施方案中，本文描述的系统可实施面向服务的数据库架构，在所述数据库架构中单个数据库系统的各种功能部件固有地分布。例如，不是将多个完全的和单片的数据库实例(其中的每一个可包括外来功能性，如应用服务器、搜索功能性、或超过需要用来提供数据库的核心功能的其他功能性)捆绑在一起，这些系统可将数据库的基本操作(例如，查询处理、事务管理、高速缓存和存储)组织成可单独和独立缩放的层。例如，在一些实施方案中，本文所描述的系统中的每个数据库实例可包括数据库层(其可包括单个数据库引擎头节点和客户端侧存储系统驱动器)、和独立分布式存储系统(其可包括共同执行在现有系统的数据库层中常规执行的操作中的一些的多个存储节点)。
[0026]如本文更详细描述的，在一些实施方案中，数据库的一些最低水平操作(例如，备份、复原、快照、恢复、日志记录操纵、和/或各种空间管理操作)可从数据库引擎卸载至存储层，并且分布在多个节点和存储装置上。例如，在一些实施方案中，不是数据库引擎对数据库(或其数据页面)应用改变以及随后将修改的数据页面发送至存储层，对存储的数据库(或其数据页面)的改变的应用可为存储层本身的责任。在此类实施方案中，可将重做日志记录而不是修改的数据页面发送至存储层，在其之后重做处理(例如，应用重做日志记录)可稍微徐缓地并且以分布式方式执行(例如，通过后台处理)。在一些实施方案中，崩溃恢复(例如，从存储的重做日志记录重建数据页面)也可由存储层执行，以及也可由分布式(并且在一些情况下徐缓的)后台处理执行。
[0027]在一些实施方案中，因为只有重做日志(以及未修改的数据页面)被发送至存储层，在数据库层与存储层之间可存在比现有数据库系统中更少的网络流量。在一些实施方案中，每个重做日志可大约为它指定变化的对应数据页面大小的十分之一。注意从数据数据库层和分布式存储系统发送的请求可为异步的，并且多个此类请求可同时在发送中。
[0028]—般来说，在被给予数据片之后，数据库的基本要求为它可最终交还回那个数据片。为此，数据库可包括若干不同部件(或层)，其中的每一个执行不同的功能。例如，传统数据库可被认为具有三个层:用于执行查询解析、优化和执行的第一层；用于提供事务性、恢复和耐久性的第二层；以及在本地附接的磁盘上或在网络附接的存储区上提供存储的第三层。如以上指出的，对缩放传统数据库的先前尝试通常已包含复制数据库的所有三层，以及在多个机器上分布那些复制的数据库实例。
[0029]在一些实施方案中，本文描述的系统可不同于传统数据库中的来划分数据库系统的功能性，并且可在多个机器上仅分布功能部件的子集(不是完全的数据库实例)以便实施缩放。例如，在一些实施方案中，面向客户端的层可被配置来接收请求，所述请求指定存储和检索什么数据，但未指定如何存储和检索所述数据。这个层可执行请求解析和/或优化(例如，SQL解析和优化)，而另一层可负责查询执行。在一些实施方案中，第三层可负责提供结果的事务性和一致性。例如，这个层可被配置来施行一些所谓的ACID特性，具体地，把数据库作为目标的事务的原子性、维持数据库内的一致性、以及确保把数据库作为目标的事务之间的隔离。在一些实施方案中，第四层随后可负责在存在各种故障的情况下提供存储的数据的耐久性。例如，这个层可负责改变日志、从数据库崩溃恢复、管理对基础存储容量的访问和/或在基础存储容量中的空间管理。
[0030]现在转向附图，图1为示出根据一个实施方案的数据库软件堆栈的各种部件的框图。如这个实例中示出的，数据库实例可包括多个功能部件(或层)，其中的每一个提供数据库实例功能性的一部分。在这个实例中，数据库实例100包括查询解析和查询优化层(被示作110)、查询执行层(被示作120)、事务性和一致性管理层(被示作130)、和耐久性和空间管理层(被示作140)。如以上指出的，在一些现存数据库系统中，缩放数据库实例可包含复制整个数据库实例一次或多次(包括图1中示出的所有层)，以及随后添加胶合逻辑以便将它们缝合在一起。在一些实施方案中，本文描述的系统反而可将耐久性和空间管理层140的功能性从数据库层卸载至独立存储层，并且可在存储层中的多个存储节点上分布那个功能性。
[0031]在一些实施方案中，本文描述的数据库系统可保持图1所示的数据库实例的上半部的大部分结构，但可重新分布用于对存储层的备份、复原、快照、恢复、和/或各种空间管理操作的至少部分的责任。当与用来提供可缩放数据库的先前方法相比时，以这种方式重新分布功能性以及在数据库层与存储层之间紧密连接日志处理可改善性能、增加可用性和降低成本。例如，由于只有重做日志记录(其在大小上比实际数据页面小很多)可在节点上运送或在写入操作的时延路径内持续，所以可减少网络和输入/输出带宽要求。此外，数据页面的产生可在每个存储节点上独立地后台完成(如前台处理允许的)，而不阻塞进入的写入操作。在一些实施方案中，使用日志结构化、非重写的存储可允许备份、复原、快照、时间点恢复、和容量增长操作被更有效地执行，例如，通过使用元数据操纵而不是移动或复制数据页面。在一些实施方案中，存储层也可承担复制代表客户端的在多个存储节点上存储的数据(和/或与所述数据关联的元数据，如重做日志记录)的责任。例如，数据(和/或元数据)可本地(例如，在单个“可用区”内，在所述单个“可用区”中存储节点集合在它自身的物理不同的、独立的基础结构上执行)复制和/或在单个区域或不同区域中的可用区上复制。
[0032]在各种实施方案中，本文描述的数据库系统可支持用于各种数据库操作的标准或定制的应用编程接口(API)。例如，API可支持用于创建数据库、创建表格、更改表格、创建用户、删除用户、在表格中插入一个或多个行、复制值、从表格内选择数据(例如，查询表格)、取消或中止查询、创建快照、和/或其他操作。
[0033]在一些实施方案中，数据库实例的数据库层可包括数据库引擎头节点服务器，所述数据库引擎头节点服务器接收来自各种客户端程序(例如，应用)和/或订阅者(用户)的读取和/或写入请求，随后解析它们并且发展执行计划以便实施关联的数据库操作。例如，数据库引擎头节点可发展对获得用于复杂的查询和连接的结果有必要的步骤系列。在一些实施方案中，数据库引擎头节点可管理在数据库系统的数据库层与客户端/订阅者之间的通信，以及在数据库层与独立分布式数据库优化存储系统之间的通信。
[0034]在一些实施方案中，数据库引擎头节点可负责从端部客户端通过JDBC接口或ODBC接口来接收SQL请求，以及负责本地执行SQL处理和事务管理(其可包括锁定)。然而，并非在本地产生数据页面，数据库引擎头节点(或其各种部件)可产生重做日志记录，并且可将它们运送至独立分布式存储系统的适当节点。在一些实施方案中，用于分布式存储系统的客户端侧驱动器可在数据库引擎头节点上代管，并且可负责将重做日志记录路由至存储那些重做日志记录指向的区段(或其数据页面)的存储系统节点(或多个节点)。例如，在一些实施方案中，每个区段在形成保护组的多个存储系统节点上可为镜像的(或否则被形成为耐用的)ο在此类实施方案中，客户端侧驱动器可记录在其上存储每个区段的节点，并且当接收客户端请求时，可将重做日志路由至在其上存储区段的所有节点(例如，异步地和基本上同时并行)。一旦客户端侧从保护组中的存储节点的写入群体接收返回的确认(其可指示重做日志记录已被写入至存储节点)，它就可将请求的变化的确认发送至数据库层(例如，至数据库引擎头节点)。例如，在其中通过使用保护组使得数据耐用的实施方案中，数据库引擎头节点可能不能够提交事务，除非客户端侧驱动器从足够的存储节点实例接收回复以便构成写入群体。类似地，对于指向特定区段的读取请求，客户端侧驱动器可将读取请求路由至在其上存储所述区段的所有节点(例如，异步地和基本上同时并行地)。一旦客户端侧驱动器从保护组中的存储节点的读取群体接收请求的数据，它可将请求的数据返回至数据库层(例如，至数据库引擎头节点)。
[0035]在一些实施方案中，数据库层(或更具体地，数据库引擎头节点)可包括在其中临时保持最近访问的数据页面的高速缓冲存储器。在此类实施方案中，如果接收将保持在此类高速缓冲存储器中的数据页面作为目标的写入请求，除了将对应的重做日志记录运送至存储层之外，数据库引擎可对保持在它的高速缓冲存储器中的数据页面的复制应用改变。然而，不同于在其他数据库系统中，保持在这个高速缓冲存储器中的数据页面可能从不被刷新至存储层，并且它可在任何时候被抛弃(例如，在用于最近应用至高速缓存的复制的写入请求的重做日志记录已被发送至存储层和被确认之后的任何时候)。在不同实施方案中，高速缓冲存储器可实施任何的各种锁定机构，以便通过每次最多一个写入者(或多个读取者)控制访问高速缓冲存储器。然而注意在包括此类高速缓冲存储器的实施方案中，高速缓冲存储器可能未分布在多个节点上，但对于给定数据库实例可仅存在于数据库引擎头节点上。因此，可能不存在要管理的高速缓存相干性或一致性问题。
[0036]在一些实施方案中，数据库层可支持在系统中使用同步或异步读取复制品，例如，在读取请求可被路由至其的数据库层的不同节点上的数据只读副本。在此类实施方案中，如果用于给定数据库的数据库引擎头节点接收指向特定数据页面的读取请求，那么它可将请求路由至这些只读副本中的任何一个(或特定的一个)。在一些实施方案中，数据库引擎头节点中的客户端侧驱动器可被配置来通知这些其他节点关于高速缓存的数据页面的升级和/或失效(例如，以便提示它们使它们的高速缓冲存储器无效，在其之后它们可从存储层请求更新的数据页面的更新副本)。
[0037]在一些实施方案中，在数据库引擎头节点上运行的客户端侧驱动器可暴露针对存储层的专用接口。在一些实施方案中，它也可暴露针对一个或多个其他部件(例如，其他数据库引擎或虚拟计算服务部件)的传统iSCSI接口。在一些实施方案中，在存储层中用于数据库实例的存储可被模制成单个卷，所述单个卷可在大小上增长而不受限制，并且可具有不限数目的与它关联的10PS。当创建卷时，可用具体大小、用具体的可用性/耐久性特性(例如，指定它被如何复制)、和/或与它关联的1PS速率(例如，峰值和持续的)来创建它。例如，在一些实施方案中，各种不同的耐久性模型可被支持，并且用户/订阅者可以能够为它们的数据库基于它们的耐久性、性能和成本目标来指定一些复制副本、区、或区域、和/或复制是同步的还是异步的。
[0038]在一些实施方案中，客户端侧驱动器可维持关于卷的元数据，并且可将异步请求直接发送至对实现读取请求和写入请求有必要的每个存储节点，而不需要在存储节点之间的附加跳跃。例如，在一些实施方案中，响应对数据库进行改变的请求，客户端侧驱动器可被配置来确定实施用于目标数据页面的存储的一个或多个节点，以及路由指定对那些存储节点的改变的重做日志记录。存储节点随后可在将来的某个时刻负责将在重做日志记录中指定的改变应用至目标数据页面。由于返回客户端侧驱动器的写入被确认，所以客户端侧驱动器可提前在其处卷为耐用的点，并且可确认返回数据库层的提交。如先前指出的，在一些实施方案中，客户端侧驱动器可能从不将数据页面发送至存储节点服务器。这不仅可减少网络流量，还可移除对检查点或后台写入线程的需要，所述检查点或后台写入线程在先前的数据库系统中约束前台处理吞吐量。
[0039]在一些实施方案中，许多读取请求可由数据库引擎头节点高速缓冲存储器服务。然而，由于大规模的故障事件可能太常见而不允许仅在存储器中复制，写入请求可能需要耐久性。因此，本文描述的系统可被配置来最小化重做日志记录写入操作的成本，所述重做日志记录写入操作在前台延时路径中，通过将存储层中的数据存储实施成两个区域:小型仅附加的日志结构化区域，当从数据库层被接收重做日志记录时将其写入至其中；以及较大区域，在所述较大区域中日志记录合并在一起以便后台创建新版本的数据页面。在一些实施方案中，可维持存储器中结构用于每个数据页面，所述每个