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