CN113168404B - 用于在分布式数据库系统中复制数据的系统和方法 - Google Patents

用于在分布式数据库系统中复制数据的系统和方法 Download PDF

Info

Publication number
CN113168404B
CN113168404B CN202080006927.XA CN202080006927A CN113168404B CN 113168404 B CN113168404 B CN 113168404B CN 202080006927 A CN202080006927 A CN 202080006927A CN 113168404 B CN113168404 B CN 113168404B
Authority
CN
China
Prior art keywords
page
log
copy
copies
store
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.)
Active
Application number
CN202080006927.XA
Other languages
English (en)
Other versions
CN113168404A (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.)
Huawei Cloud Computing Technologies Co Ltd
Original Assignee
Huawei Cloud Computing Technologies Co Ltd
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 Huawei Cloud Computing Technologies Co Ltd filed Critical Huawei Cloud Computing Technologies Co Ltd
Publication of CN113168404A publication Critical patent/CN113168404A/zh
Application granted granted Critical
Publication of CN113168404B publication Critical patent/CN113168404B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • G06F11/1451Management of the data involved in backup or backup restore by selection of backup contents
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094Redundant storage or storage space
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1469Backup restoration techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2358Change logging, detection, and notification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273Asynchronous replication or reconciliation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1658Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80Database-specific techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82Solving problems relating to consistency
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84Using snapshots, i.e. a logical point-in-time copy of the data

Abstract

一种方法包括:接收对数据库的页的改变的指示,并将与该页对应的新日志记录添加到包括日志记录的公共日志,该新日志记录描述对该页进行的改变并被分配不同的版本号。该方法还包括将新日志记录同步写入一组日志记录副本中的每个日志记录副本,并且将新日志记录不同步写入该页的所有页存储副本,以更新存储在每个页存储副本上的页,其中,该页的每个存储副本服务该页的读取。响应于从预定数量个页存储副本接收到对日志记录的写入的确认,从公共日志中丢弃该日志记录。

Description

用于在分布式数据库系统中复制数据的系统和方法
相关申请的交叉引用
本申请要求于2019年3月15日提交的发明名称为“用于在分布式数据库系统中复制数据的系统和方法”、申请号为No.16/355,521的美国专利申请的优先权,其全部内容以引入的方式并入本文。
背景技术
数据库系统使得大量数据能够被存储、管理、更新、和分析。在分布式数据库系统中,数据可以存储和分布在存储节点的集群上,其中,每个存储节点包括一个或若干个非易失性存储设备。数据库系统中的数据可以被组织成单元,这些单元称为页,数据库系统中的页的所有改变可以使用分配给页的最新改变的编号来枚举,该编号称为页版本。用于读取数据库中的页的特定读请求可以指定特定页版本。
由于集群中的一个或多个存储节点可能出现偶发性故障或暂时不可用,所以可以将数据的多个副本存储在多个存储节点上。因此,如果存储页的某个存储节点暂时性或永久性故障,那么数据库系统可以使用一个或多个其他存储节点来恢复丢失的数据。然而,因为将数据的多个副本存储在多个存储节点上需要具有大量的额外存储设备,故增加了数据库系统的成本。
发明内容
管理分布式数据库系统中的数据的存储的一种方式是对页和日志记录(例如,描述页的改变的记录)都应用相同的复制策略。使用这种方法,页和日志记录都存储在相同的、专用的一组N个存储节点上。更具体地,当N个专用存储节点中的第一预定数量W个(其中W小于或等于N)存储节点确认了特定写请求时,该写请求被认为是已被服务。为了读取页,可以将读请求发送至若干存储节点,当第二预定数量R个(其中R+W>N)存储节点返回相同的结果时,该读请求被认为是已被服务。因为增加存储节点的数量N使得更多存储节点可用于恢复操作并且可用于服务读请求,因此增加了数据库系统的持久性(即,降低了不可逆的数据损失的概率)和读请求的读可用性(即,降低了暂时无法服务读请求的概率)。然而,增加存储节点的数量可能具有不利后果。例如,由于使用了更多的存储,故增加存储节点的数量可能会增加成本;以及,在数据修改期间,可能需要花费额外的精力来确保副本一致性,从而增加了时延并消耗额外的计算资源,例如处理资源、网络资源、以及存储资源。此外,数据库系统响应写请求的可用性可能会随着页存储副本数量的增加而降低。
根据本文描述的示例实施方式,分布式数据库系统对页存储和日志存储使用不同的复制策略。对于页存储的复制策略是指定以下的一组规则:分布式数据库系统总共需要多少个页存储副本、向哪些页存储副本发送日志记录、以及在确定日志记录是持久的之前分布式数据库系统应该接收多少确认。对于日志存储的复制策略是指定以下的一组规则:分布式数据库系统总共需要多少个日志记录副本、向哪些日志存储副本发送日志记录、以及在确定日志记录是持久的之前分布式数据库系统应该接收多少确认。如本文所述,根据示例实施方式的复制策略的使用可以增强分布式数据库系统的性能。例如,复制策略的使用可以提供对于读请求和写请求的相对较高的读可用性,同时使用相对少量的页存储副本。此外,如本文所述,复制策略可以实现一种识别长期和短期连锁页存储副本失效并从中恢复的鲁棒方式。
根据本公开的一方面,提供了一种方法,该方法包括:接收对数据库的页进行改变的指示,并将与该页对应的新日志记录添加到包括日志记录的公共日志,该新日志记录描述对该页进行的改变并被分配不同的版本号。该方法还包括:将新日志记录同步写入一组日志存储副本中的每个日志存储副本,并将新日志记录不同步写入该页的所有页存储副本,以更新存储在每个页存储副本上的上述页,其中,上述页的页存储副本服务上述页的读取。响应于从预定数量的页存储副本接收到对上述日志记录的写入的确认,从上述公共日志丢弃上述新日志记录。
根据本公开的另一方面,提供了一种用于存储指令的非暂时性机器可读存储介质,当由机器执行时,上述指令使上述机器:接收对数据库的页进行改变的指示;将与该页对应的新日志记录添加到包括日志记录的公共日志,该新日志记录描述对该页进行的改变并被分配不同的版本号;将新日志记录同步写入一组日志存储副本中的每个日志存储副本;将新日志记录不同步写入该页的所有页存储副本,以更新存储在每个页存储副本上的上述页,其中,上述页的页存储副本服务上述页的读取;响应于从预定数量的页存储副本接收到对上述日志记录的写入的确认,从上述公共日志丢弃上述新日志记录。
根据本公开的另一方面,提供了一种装置,该装置包括处理器和存储器。该存储器存储指令,当由处理器执行时,该指令使处理器:接收对数据库的页进行改变的指示;将与该页对应的新日志记录添加到包括日志记录的公共日志,该新日志记录描述对该页进行的改变并被分配不同的版本号;将新日志记录同步写入一组日志存储副本中的每个日志存储副本;将新日志记录不同步写入该页的所有页存储副本,以更新存储在每个页存储副本中的上述页,其中,上述页的页存储副本服务上述页的读取;响应于从预定数量的页存储副本接收到对上述日志记录的写入的确认,从上述公共日志丢弃上述新日志记录。
可选地,在任一前述方面中,在另一实施方式中,上述日志存储副本和上述页存储副本位于不同的存储节点,并且上述存储节点位于不同的可用性空间。
可选地,在任一前述方面中,在另一实施方式中,上述一组日志存储副本中的日志存储副本的数量与上述页存储副本的数量相同。
可选地,在任一前述方面中,在另一实施方式中,上述一组日志存储副本中的日志存储副本的数量与上述页存储副本的数量不同。
可选地,在任一前述方面中,在另一实施方式中,上述一组日志存储副本包括位于不同可用性空间的至少三个日志存储副本。
可选地,在任一前述方面中,在另一实施方式中,上述可用性空间与不同的地理位置相关联。
可选地,在任一前述方面中,在另一实施方式中,不同步写入页存储副本以使页的改变生效包括:向第一页存储副本发送指令以允许在第二子集的第一节点和第二节点之间使用对等gossip协议,以更新存储在第一节点上的页存储副本,从而使存储在第一节点上的页存储副本的改变生效。
可选地,在任一前述方面中,另一实施方式包括:读取上述页,其中,该读取包括选择页存储副本中的一个页存储副本,并从选择的页存储副本中读取上述页。
可选地,在任一前述方面中,在另一实施方式中,选择页存储副本包括确定与上述页的读取相关联的请求逻辑序列号,并基于由选择的页存储副本确认的逻辑序列号选择页存储副本。
可选地,在任一前述方面中,在另一实施方式中,检测页存储副本的失效,并且响应于检测到的失效执行恢复操作。执行恢复操作包括:生成新页存储副本以替换失效的页存储副本,并使该页的新页存储副本和至少一个其他页存储副本在第二节点子集中的至少一个其他节点和替换节点之间使用数据的对等复制。
可选地,在任一前述方面中,在另一实施方式中,可以检测页存储副本中的多个页存储副本的连锁失效,并响应于检测到的连锁失效执行恢复操作。执行恢复操作可以包括:识别与发生连锁失效的页对应的一组日志记录;从第一节点子集中的至少一个节点中读取识别的一组日志记录;基于读取的识别的一组日志记录写入多个页存储副本。
可选地,在任一前述方面中,在另一实施方式中,检测连锁失效可以包括:确定确认了与上述页对应的日志记录的写入的给定页存储副本;确定其他页存储副本当前都没有确认该日志记录的写入。
可选地,在任一前述方面中,另一实施方式包括检测上述一组日志存储副本中的日志存储副本的失效;选择新的一组日志存储副本;以及将新日志记录同步写入一组日志存储副本中的每个日志存储副本。
附图说明
图1是根据示例实施方式的分布式数据库系统的示意图。
图2是根据示例实施方式的分布式数据库系统响应于页被修改而执行的阶段的图示。
图3是根据示例实施方式的分布式数据库系统处理读请求的流程图。
图4是根据示例实施方式的由于一个或多个页存储副本的暂时或永久失效而由分布式数据库系统用于恢复数据的过程的流程图。
图5A和图5B示出了根据示例实施方式的连锁长期和短期页存储副本失效以及从这些失效恢复的示例时间线。
具体实施方式
根据本文描述的示例实施方式,分布式数据库系统在存储节点的集群中的存储节点处存储数据库的数据。在该背景下,“存储节点(storage node)”指的是独立存储单元,并且可以包括一个或多个持久性或非易失性存储设备,例如磁介质驱动器设备、固态驱动器设备、非易失性存储器存储设备等。作为更具体的示例,特定存储节点可以是独立的计算机系统,该计算机系统包含一个或多个存储设备、存储区域网络(storage area network,SAN)等等。可以使用基于块的(block-based)存储或基于文件的(file-based)存储将数据存储在存储节点的存储设备中。数据库的数据存储在存储节点的一个或多个持久性或非易失性存储设备上。
通常,分布式数据库系统维护数据库,并存储称为数据库页(或“页”)的数据单元。作为示例,“页”可以是对应于与数据库表或其一部分相关联的数据值的数据。页被分配给分布式数据库系统中的页存储(page store)。存储该页(以及数据库中的其他页)的存储节点在本文中称为“页存储”,并且由于页存储的复制,集群中实际包括页存储的多个副本,称为“页存储副本(page store replicas)”。更具体地,如本文进一步所述,存储节点的集群中的每个存储节点包含数据库中的一个或多个页被分配至的页存储副本。页存储副本可以用于重建被分配给页存储副本的页,并且可以服务该页的读取。
分布式数据库系统维护并存储公共日志,该公共日志包括对于数据库的所有改变的日志记录。在该背景下,“公共日志(common log)”指的是日志记录的有序列表,并且每个日志记录对应于数据库中的特定页并描述对数据库中的特定页的预期修改或改变。分布式数据库系统管理公共日志中与特定页对应的日志记录,并将其写入该页的所有页存储副本(即,该特定页被分配至的所有页存储副本),以更新该特定页,从而对该特定页的读请求可以被服务。分布式数据库系统还将公共日志的日志记录写入日志存储副本以维持持久性(persistency)。如本文进一步所述,分布式数据库系统可以通过从公共日志中截断或删除与特定页对应的日志记录来维护公共日志,这些特定页的修改或改变被数据库管理系统认为是已经提交给页存储副本,以阻止公共日志(其为只能添加(append only)的日志)无限地增长。在本公开中,存储由数据库管理系统写入的公共日志的日志记录的存储节点被称为“日志存储(logstore)”。由于日志存储的复制,存储节点的集群中实际包括日志存储的多个副本,称为“页存储副本”。存储节点的集群中的给定存储节点可以包含日志存储副本、页存储副本、或者日志存储副本和页存储副本。
如本文所述,分布式数据库系统的DBMS可以从页存储副本中读取页,并将公共日志中的日志记录写入日志存储副本和页存储副本。在该背景下,从页的页存储副本(即,该页被分配至的页存储副本)中读取该页指的是,分布式数据库系统的DBMS向页存储副本发送读请求(或如本文另外提及的“读取(read)”),并且页存储副本响应于该读请求而提供该页以服务该读请求。“读取”可以包括该页的标识符以及待从页存储副本中读取的该页的版本。将公共日志中的日志记录写入日志存储副本指的是,分布式数据库系统的DBMS将写请求(或如本文另外提及的“写入(write)”)发送至日志存储副本,以使得位于不同存储节点的日志存储副本存储该公共日志中的日志记录。公共日志中的每个日志记录描述了页的改变(例如,页中的一个或多个数据值的改变)。如果读请求或写请求被满足,则该请求被“服务(served)”。
在分布式数据库系统中,管理如何将页写入页存储副本和如何从页存储副本中读取页有许多潜在方式;特别地,管理如何将数据库中的页的改变(例如,与页对应的日志记录)传播至这些页被分配至的页存储副本以及日志存储副本,以及管理页存储副本如何服务读请求,存在许多潜在方式。一种方式是使用存储策略,该策略指定相同的N个存储节点将包含页存储副本(每个存储节点一个)和日志存储副本(每个存储节点一个)。使用该方法,可以使用指定如下的复制策略:对应于给定页的日志记录被写入N个页存储,并且当给定页的W(其中W<N)个专用页存储副本确认了给定写请求时,认为完成了用于写入描述给定页的改变的日志记录的该写请求。该复制策略还可以指定,对于读请求(即,读取给定页的请求),该读请求可以送至给定页的N个页存储副本中的若干个,并且当给定页的R个(其中R+W>N)页存储副本返回给定页时,可以认为完成了该读请求。不管如何选择N、W、和R,在从给定页的大量页存储副本获得的对读请求的高可用性以及由于给定页的大量页存储副本而导致的不利影响(例如成本、延迟、以及对于写请求的较差可用性)之间可能会存在权衡。
根据示例实施方式,为了增加对于写请求的可用性并限制页存储副本的数量,使用指定如下的存储策略:日志存储副本可以位于与页存储副本不同的存储节点处,并且对将公共日志中的日志记录写入页存储副本和写入日志存储副本使用不同的复制策略。更具体地,根据一些实施方式,分布式数据库系统包括存储节点的大集群中的一组存储节点。该组存储节点中的每个存储节点包含页的页存储副本(即,特定页被分配至的页存储副本)。分布式数据库系统包括日志存储副本,然而,这些日志存储副本不被限于在该组存储节点处。相应地,当对数据库中的页进行改变时,分布式数据库系统的DBMS将描述对数据库中的该页进行的改变的新日志记录添加到公共日志,该公共日志包括描述对数据库的各个页进行的改变的现有日志记录。分布式数据库系统将公共日志中的日志记录(包括该新日志记录)写入一组日志存储副本,以存储在这些日志存储副本上。此外,为了使改变生效,分布式数据库系统将新日志记录同步写入日志存储副本,并且将新日志记录不同步写入所有页存储副本。
更具体地,根据示例实施方式,当由于客户端设备处的用户活动而发生对数据库中的特定页的改变时,分布式数据库系统进行四个阶段(本文进一步描述):第一阶段是为对应于该页的新日志记录编序号或编版本号,并且将该新日志记录添加到公共日志(该新日志记录描述了对数据库中的特定页的改变);第二阶段是将新日志记录写入日志存储副本(即,写入公共日志中的描述该页的改变的新日志记录);第三阶段是将日志记录写入专用页存储副本(例如,该特定页总是被分配至的页存储副本),以将新日志记录存储在专用页存储副本上,从而该专用页存储副本反映该特定页的改变;第四阶段是管理公共日志,当至少一个专用页存储副本确认了写请求时(这指示了已经认为该新日志记录已提交至专用页存储副本),从公共日志中移除该新日志记录。注意,这四个阶段可以顺序执行,或者阶段二和阶段三可以并行执行。还要注意,对于对数据库中的特定页进行的改变,重复所有四个阶段。
在四阶段过程的第一阶段中,分布式数据库系统接收对数据库中的特定页的改变的指示,并生成与该页对应的新日志记录。数据库通过将逻辑序列号(logical sequencenumber,LSN)分配给新日志记录来为与特定页的改变对应的新日志记录编版本号。该新日志记录包括被改变的页的标识符以及被分配给该新日志记录的LSN。然后,该新日志记录被添加到公共日志。该新日志记录描述了对页进行的改变(例如,要改变特定字节或特定一组字节)。因此,公共日志包含对于数据库中的页的所有改变的编好序号或版本号的日志记录。
在第二阶段,分布式数据库系统将写请求发送至日志存储副本和该页的专用页存储副本(例如,该特定页被分配至的页存储副本),以将该新日志记录写入日志存储副本和页存储副本。更具体地,根据示例实施方式,分布式数据库系统将新日志记录同步写入数据库系统的包括N个日志记录副本的任何子集。在该背景下,“同步写入”指的是分布式数据库系统在所有N个日志存储副本都确认了写请求的条件下,认为该写请求成功(因此,向与用户关联的客户端设备确认了同步写入)。如果包含N个日志存储副本的子集中的日志存储副本之一的任何存储节点故障,则DBMS选择N个日志存储副本的另一子集来同步写入新日志记录。
根据示例实施方式,写入“包括N个日志存储副本的任何子集”指的是分布式数据库系统独立于该页的N个专用页存储副本,选择任何N个日志存储副本以用于新日志记录的写入。例如,假设N=3,并且要对数据库中的特定页进行三个改变,得到日志记录1、2、3,每个日志记录描述对特定页的三个改变之一。作为示例,分布式数据库系统可以向在存储节点A、B、C处的日志存储副本发送写请求,以将日志记录号1写入在存储节点A、B、C处的日志存储副本,从而使对特定页的第一改变生效;向在存储节点A、D、F处的日志存储副本发送写请求,以将日志记录2写入在存储节点A、D、F处的日志存储副本,从而使对特定页的第二改变生效;以及向在存储节点B、G、H处的日志存储副本发送写请求,以将日志记录3写入在存储节点B、G、H处的日志存储副本,从而使对特定页的第三改变生效。注意,对于所有三个改变,分布式数据库系统可以将日志记录1、2、3不同步写入该页的三个专用页存储副本,这三个专用页存储副本可以位于相同的三个存储节点处(如本文针对阶段三所述)。
根据示例实施方式,数据库系统包括给定页的N个页存储副本,并且分布式数据库系统将与给定页对应的日志记录写入该页的N个页存储副本中的每个页存储副本(即,该页的所有N个页存储副本),直到给定页的N个页存储副本之一变为不可用。此时,分布式数据库系统可以执行如下所述的恢复操作,以恢复该给定页的变为不可用的该页存储副本,或者如果该页存储副本无法变为可用,则创建给定页的新页存储副本。分布式数据库系统还将存在于公共日志中的与给定页对应的日志记录写入一组日志存储副本中的每个日志存储副本,直到N个日志存储副本之一变为不可用,此时,分布式存储系统可以选择一组不同的N个日志存储副本(其可以或可以不包含上述一组日志存储副本中的任何先前日志存储副本)。因此,即使N个页存储副本都没有确认与页对应的日志记录(即,描述该页的改变的日志记录)的写入,只要N个日志存储副本中的预定数量个日志存储副本已经确认了与该页对应的日志记录的写入,分布式数据库系统就可以向客户端设备确认对数据库中的该页的改变。虽然N个页存储副本位于固定位置(例如,在集群中的固定存储节点处),但与该页对应的日志记录可以被写入存储节点的集群中的任何可用日志存储副本。
根据一些实施方式,分布式数据库系统可以将N个存储节点分布在N个可用性空间上(即,分布式数据库系统可以限制每个日志存储副本位于与包含其他日志存储副本的存储节点不同的可用性空间所关联的存储节点)。在该背景下,“可用性空间”对应于特定地理位置,从而如果与一个可用性空间关联的特定存储节点故障(例如由于停电或自然灾害),该故障预期不会影响与其他可用性空间关联的存储节点。作为更具体的示例,根据一些实施方式,包含日志存储副本的存储节点可以位于不同的数据中心中,并且这些数据中心可以相距数百英里。
在第三阶段,分布式数据库系统向该页的N个专用页存储副本发出非同步写请求。在该背景下,“非同步写请求”指的是分布式数据库系统发出写请求,并且分布式数据库系统不等待来自该页的N个专用页存储副本中的任一个对该写请求的确认,就向从其接收特定页的改变的客户端设备确认写入。相反,如本文进一步所述,由于对等gossip协议(本文进一步描述),分布式数据库系统假设该页的页存储副本将最终一致。
因此,根据示例实施方式,分布式数据库系统将与特定页对应的公共日志的日志记录不同步写入任何N个日志存储副本以存储日志记录,并且写入N个存储节点的专用集合以改变存储在这些专用存储节点上的页存储副本。因此,对于以上N=3的示例,三个存储节点(例如存储节点M、P、Z)可以专用于存储给定页的三个页存储副本并服务该页的读取。当该页发生改变时,对应于数据片段1、2、3,虽然每个日志记录集合(对应于每个数据片段)可以被写入三个存储节点的不同集合,但分布式数据库系统将数据片段1、2、3非同步写入相同的存储节点M、P、Z(假设该示例中没有失效)。
第四阶段涉及当该页的对应改变已经被提交到该页的专用页存储副本时,通过从公共日志中移除日志记录来管理公共日志。以这种方式,最终,该页的所有N个专用页存储副本都确认非同步写请求,并且当这种情况发生时,数据库管理系统截断公共日志以移除对应于该页的日志记录。相应地,数据库管理系统从日志存储副本中丢弃对应于从公共日志移除的日志记录的日志记录。在该背景下,“丢弃日志记录”指的是不将日志记录占用的存储空间返回到可用存储空间列表以供以后重用。
根据示例实施方式,为了从数据库中读取给定页,DBMS可以向该页被分配至的任何页存储副本发送读取页的读请求。该读请求必须附有LSN,这样,请求页的特定版本。如本文进一步所述,该页被分配至的给定页存储副本可以服务或无法服务读请求,这取决于给定页存储副本是否包含与所请求的版本对应的页;如果所请求的页是不可用的,则分布式数据库系统可以向另一页存储副本发送读取页的读请求。
如上所述,用于读取存储在分布式数据库系统的数据库中的页的读请求伴有LSN。如果该页被分配至的特定页存储副本无法服务该读请求,则可以在另一页存储副本上尝试该特定读请求。
根据示例实施方式,分布式数据库系统在每次从客户端设备接收到对数据库中的特定页进行的改变的指示时,重复上述四阶段过程。特定页的改变可以是由于在客户端设备的用户活动而引起。
如本文进一步所述,上述复制和存储策略允许对于短期和长期页存储副本失效(failure,也称故障)的有效数据恢复,并且还是一种识别长期和短期连锁页存储副本失效并从其恢复的方式。
参考更具体的示例,图1示出了根据示例实施方式的分布式数据库系统100。通常,分布式数据库系统100包括存储节点110的集群。此外,集群可以在可用性区域116之间划分(图1中示出了P个可用性空间116-1,116-2...,116-P作为示例)。以这种方式,根据示例实施方式,每个可用性空间116可以对应于不同的物理位置,从而在一个可用性空间116处的故障预期不会影响到其余可用性空间116。根据一些实施方式,每个可用性空间116可以与特定数据中心相关联,并且,根据示例实施方式,对应可用性空间116的数据中心可以位于不同的地理位置(例如,相距数百英里)。
根据一些实施方式,数据库管理器150代表一个或多个物理机器(计算机、机架式计算机等),其包含机器可执行指令(“软件”)和实际硬件,例如存储器170和一个或多个处理器182。
根据示例实施方式,处理器182可以执行机器可执行指令(“软件”),并且可以包括一个或多个中央处理单元(central processing unit,CPU)、一个或多个CPU处理核、一个或多个微控制器等。此外,根据其他示例实施方式,处理器182可以是不执行机器可执行指令的专用硬件电路,例如现场可编程门阵列(field programmable gate array,FPGA)、专用集成电路(application specific integrated circuit,ASIC)等。
存储器170通常是非暂时性存储介质,例如可以包括半导体存储设备、光学存储设备、磁存储设备、固态存储设备、相变存储设备、忆阻器、根据这些存储技术中的一种或多种形成的存储设备的存储介质等等。此外,存储器170可以由存储设备的组形成,可以由多个存储设备的组形成,可以由通过总线或其他互连连接的存储器形成,等等。
根据示例实施方式,存储器170可以存储机器可执行指令172(或“软件”)。机器可执行指令172(“软件”)包括用于创建和管理数据库的软件(未示出)。该软件通常称为数据库管理系统(database management system,DBMS)。当由一个或多个处理器182执行时,DBMS的机器可执行指令使处理器182创建和管理数据库并执行本文描述的本发明的方法。DBMS包括各种模块或引擎,例如数据库事务引擎154、写引擎160、读引擎164、恢复引擎168、和/或这些模块或引擎的任何组合。存储器170还可以存储数据174,数据174可以是表示要写入日志存储副本和页存储副本的日志记录的数据、将页存储数据(例如,被分配给页存储副本的页)写入存储节点110所涉及的数据、与从存储节点110读取数据相关的数据、与由于失效页存储副本而恢复数据相关联的数据、代表最新LSN的数据等等。如图1所示,根据示例实施方式,数据库管理器150和存储节点110可以在网络构架118上进行通信。
根据示例实施方式,网络构架118可以包括任何类型的有线或无线通信网络,包括蜂窝网络(例如,全球移动通信系统(Global System for Mobile Communications,GSM)、3G、长期演进(Long Term Evolution,LTE)、全球微波接入互通(WorldwideInteroperability for Microwave Access,WiMAX)等)、数字用户线(digital subscriberline,DSL)网络、电缆网络(例如同轴网络、光纤网络等)、电话网络、局域网(local areanetwork,LAN)、广域网(wide area network,WAN)、全球网络结构(例如,网络构架通讯互联网流量)、或其任何组合。
根据特定实施方式,分布式数据库系统100可以存储与关系数据库或非关系数据库有关的结构化数据、非结构化数据、或半结构化数据。无论其特定形式如何,对数据库中的数据的改变都可以从客户端190(例如,通过网络构架118连接的客户端)通信给在数据库管理器150上运行的DBMS 172。根据示例实施方式,客户端190可以是基于处理器的系统,例如(作为示例)台式计算机、膝上型计算机、平板计算机、可穿戴计算设备、智能电话等等。通常,与客户端190交互的用户可以使数据库中的数据(例如数据库的特定页)发生改变。这种页的改变会影响在存储节点110处的该页的页存储副本的对应集合。
根据示例实施方式,数据库事务引擎154可以处理从客户端190传送的数据库事务请求,并且响应于这些请求,可以使数据库的页发生对应改变。相应地,这些改变影响对应的页存储副本。不管改变的来源是哪里,当发生对页的改变时,写引擎160可以进行上述四阶段过程,以将描述该改变的新日志记录写入日志存储副本和该页被分配至的页存储副本(即,该页的页存储副本)。如图1所示,DBMS可以使用读引擎164来处理读请求,以从该页的页存储副本读取数据库中的页,并且如本文进一步所述,使用恢复引擎168以恢复由于该页的一个或多个页存储副本失效而不可用的数据。
结合图1参见图2,根据一些实施方式,现在将详细描述当发生对页的改变时更新页存储副本220和将日志记录写入日志存储副本212的四阶段过程。更具体地,根据示例,特定页的页存储副本的数量是三(即,N=3),并且该特定页的页存储副本220位于集群的三个不同存储节点110。此外,日志存储副本212位于集群中的任何三个存储节点110。
如附图标记210所示(图2),在客户端设备190处的用户活动产生对数据库中的特定页的改变,从而产生与该特定页对应的新日志记录。该新日志记录包含表示该特定页的改变的对应数据分段(例如,一个或多个字节)。如以上第一阶段所述,新的日志记录被分配LSN。然后,日志记录被添加到由DBMS维护的公共日志。公共日志包括描述数据库中的页的所有改变的日志记录。对应地,该改变影响该特定页的页存储副本220。
如附图标记216所示,写引擎160执行同步写入,以将与该页对应的新日志记录写入存储节点110处的任何三个日志存储副本212。在该背景下,“同步写入”表示在写引擎160认为公共日志的日志记录已经成功地写入所有三个日志存储副本212之后,所有该三个日志存储副本212都向DBMS确认了该写入,并且对数据库中的页的改变被确认到客户端设备190。
如附图标记214所示,写引擎160将与该页对应的描述该页的改变的新日志记录(即,新日志记录)非同步写入该页的三个页存储副本220(即,该页被分配至的三个页存储副本)。在该背景下,“非同步写入”指的是对于特定写请求,DBMS不接收指示该特定写入已完成的确认。因此,如附图标记226所示,在将新日志记录写入该页的页存储副本220之后(但可能在该页的所有页存储副本220确认该写入之前),向客户端设备190确认该写入。
根据示例实施方式,每个页存储副本220从公共日志接收与特定页对应的新日志记录,并且更新该给定特定页。每个页存储副本220知道该特定页的任何丢失版本(由于LSN的排序),并且知道最大LSN,低于最大LSN的所有LSN都已经由该特定页的页存储副本220进行处理。如本文进一步所述,这一知识允许特定页的页存储副本220向运行在数据库管理器150上的DBMS报告特定页的最大LSN,并且如本文进一步所述,DBMS使用这一知识来检测和响应页存储副本失效。此外,日志存储副本212可以向页存储副本220提供描述对数据库中的页进行的改变的日志记录。DBMS可以指示特定页的页存储副本220使用对等gossip通信协议来将数据分段提供给特定页的另一页存储副本220(其丢失了该数据分段)。
根据示例实施方式,当确定数量(称为“X”,在该示例中可以是1、2、或3)的页存储副本220确认了非同步写入,则根据示例实施方式,DBMS不在存储器170中保持该新日志记录,并且不尝试重新发送这些新日志记录,而是依赖于gossip协议来确保最终所有页存储副本都接收都所有日志记录。如附图标记261所示,仅当所有N个页存储副本都确认了该新日志记录的写入时,DBMS才截断公共日志以移除该新日志记录。
由于描述特定页的改变的日志记录被非同步写入该特定页被分配至的页存储副本220,因此,不依赖于这种写机制本身来确保日志记录被存储在该特定页被分配至的所有页存储副本220中。相反,根据示例实施方式,使用“gossip协议”来确保日志记录被存储在该特定页被分配至的所有页存储副本220中。在该背景下,“gossip协议”指的是包含页存储副本220的存储节点110之间的对等通信,从而页存储副本220向彼此提供任何丢失的日志记录。例如,页存储副本Q可能丢失了被分配LSN=7的日志记录,但在询问包含另一页存储副本T的另一存储节点110后,页存储副本Q可以知道页存储副本T包含该丢失的日志记录。因此,包含页存储副本T的存储节点110可以向页存储副本Q提供被分配LSN=7的日志记录。
如附图标记260所示,根据示例实施方式,DBMS可以周期性地向页存储副本220传送请求,询问关于页存储副本220的最大LSN,即,页存储副本具有所有数据的最大LSN。页存储副本220基于由存储在页存储副本220上的本地记录提供的内容(inventory)来确定最大LSN。例如,如果特定页存储副本220存储有LSN为1至4和6的日志记录(因此,丢失了日志记录5),则该页存储副本的最大LSN为4。如本文进一步所述,DBMS使用最大LSN来选择页存储副本220进行读取、确定从公共日志移除哪些日志记录(如附图标记231所示)、识别失效模式、执行恢复操作等。
因此,总的来说,对于写,DBMS向描述数据库中的页的变化的每个日志记录分配版本号(例如LSN),并将日志记录存储在公共日志中。写引擎160随后将公共日志的日志记录同步写入集群存储节点中的存储节点110处的任何N个日志存储副本,以将日志记录存储在这N个日志存储副本中的每个日志存储副本上。当选择这些三个日志存储副本时,如果包含日志记录副本之一的特定存储节点110不可用,则选择另一节点并相应地更新元数据。由于同步写入,所以日志记录是持久的,并且对应地,向从其接收对数据库中的页的改变的客户端设备确认写请求。写引擎160还将公共日志中与特定页对应的日志记录(例如,公共日志中描述该特定页的改变的所有日志记录)非同步写入该特定页的N个页存储副本220。此外,根据示例实施方式,将日志记录非同步写入该页的页存储副本220可以与将日志记录同步写入日志存储副本212并行进行。根据示例实施方式,在该页的预定数量(例如一个)的页存储副本220确认了上述非同步写入后,写引擎160可能不会重新尝试写入到该特定页的N个页存储副本220,以避免使数据库资源过载。随后可以在该特定页的N个页存储副本220之间使用gossip协议,以更新该特定页的所有N个页存储副本220。
一般地,在两个页存储副本220之间,gossip协议可以如下进行。首先,包含两个页存储副本220的存储节点110彼此建立连接,接着,两个页存储副本枚举和交换信息以确定每个页面存储副本220具有和不具有哪些数据项。每个页存储副本220可以向页存储副本220发送丢失的日志记录。Gossip协议可以基于对等或广播通信,这取决于特定的实施方式。因此,依据gossip协议,在给定页存储副本220接收到特定日志记录后,该日志记录可以传播至一个或多个其他页存储副本220,而无需来自分布式数据库系统100的上层的协调。
对于读,要注意的是页存储副本220在给定时间可能彼此不一致,一个副本220可能会滞后于另一副本。解决这种一致性问题的一个方式是使用法定人数读取(quorumread)。然而,由于通过LSN使用版本控制,故可以不使用法定人数读取。相反,根据示例实施方式,读引擎164(图1)利用LSN来请求被分配特定LSN的日志记录,或者请求具有最新版本(具有最高LSN的版本)的日志记录。根据上述写路径,读引擎164知道任何特定页的日志记录的最新确认的版本。
通常,读引擎164可以从某页的任何页存储副本220读取该页。因此,如果该页的特定页存储副本220不可用于服务读取,则读引擎164可以查询该页的另一页存储副本220。此外,如果该页的特定页存储副本220还没有接收到与该页对应的直到所请求的LSN的所有日志记录,则读引擎164可以查询该页的另一页存储副本220。然而,如果作为读取目标的该页的页存储副本220已经接收到与该页对应的直到所请求LSN的所有日志记录,则该页的该页存储副本可以用于服务读取并返回所请求的页。
因此,结合图1参见图3,根据一些实施方式,读引擎164可以执行操作以从数据库读取页。用于读取数据库中的页的读请求例如可以响应于客户端190上的用户活动而生成(框304)。如图3所示,读请求可以指定特定LSN或可以指定最新版本。读引擎164可以选择(框308)该页的下一候选页存储副本220以服务读请求,并确定(判定框312)该页的候选页存储副本220是否已经接收到与该页对应的直到所请求的LSN的日志记录。注意,判定框312中的确定可以基于LSN的知识进行,LSN由该页的候选页存储副本220确认,并且使用对该页的候选页存储副本220的查询确定。在框316,如果该页的候选页存储副本220已经接收到与该页对应的直到所请求LSN的所有日志记录,则读引擎164选择该页的该页存储副本220并向该页的所选择的页存储副本发送读请求。否则,在框308,读引擎164选择该页的另一候选页存储副本220。如果所选择的该页的页存储副本220仍然可用(判定框320),则该页的页存储副本220服务上述读请求(框324)。否则,如果在此期间,所选择的该页的页存储副本220变为不可用(由于包含所选择的页存储副本220的存储节点110变为不可用),则操作返回框308以选择该页的另一候选页存储副本220。
根据其他示例实施方式,该页的页存储副本的数量N可以大于三或小于三。对于严格的持久性保证,该页的三个页存储副本可能已经足够。公共日志的日志记录的初始同步三向写入保证了该日志记录可持久存储在三个不同存储节点上的三个页存储副本中。对于持久性,日志记录的位置并不重要。日志记录保留在公共日志中,直到该日志记录被确认已持久存储到该页的三个页存储副本。因此,在任何给定时间点,日志记录的至少三个副本在持久性存储中并且可用。
关于本文描述的系统和方法的读和写可用性,每个页存储副本失效的概率可以表示为“x”。对于本文描述的使用页的三个页存储副本的示例实施方式,与该页对应的编好版本的日志记录存储在公共日志中,并且与该页对应的编好版本的日志记录被写入三个不同的日志存储副本212和该页的三个页存储副本220。当存在任何三个日志存储副本212可用时,上述写入被服务;并且,因为无法进行写入的概率不依赖于所包含的特定存储节点的可用性,因此该概率实际为零。换句话说,只要存在任何三个日志存储副本212可用,就可以进行写入。只要该页的页存储副本220之一可用,就可以服务读取。无法服务读取的概率为x3
本文所述的方法和系统进一步增强了对页存储副本失效的检测,并增强了当此类失效发生时对页的恢复。更具体地,通常可能存在三种类型的页存储副本失效。
第一类页存储副本失效是短期失效,例如某页的页存储副本220在少于预定时间内不可用的失效(例如,少于15分钟的持续时间内不可用)。对于这种短期失效,该页的页存储副本220可能丢失公共日志中存在的一些日志记录。然而,因为该页的一个或多个其他页存储副本220可以提供丢失的日志记录,因此该页的页存储副本220可以使用gossip协议恢复这些丢失的日志记录。
另一类失效是长期失效,使得页存储副本220损坏或在相对长的一段时间内(例如,超过十五分钟的一段时间)不可用。恢复引擎168(图1)可以通过监控该页的特定页存储副本220在多长时间内不可用来检测这一类失效,并且恢复引擎168可以如下执行恢复。首先,恢复引擎168可以创建该页的新页存储副本220来替换该页的失效的页存储副本220。例如,恢复引擎168可以在某个可用性空间中的另一存储节点上创建新的页存储副本220,该可用性空间不同于与该页的其他页存储副本220相关联的任何其他可用性空间116。在一些实施例中,恢复引擎168可以通过将该页的另一现有页存储副本220复制到不同可用性空间116中的存储节点110以替换该页的失效的页存储副本220,从而创建该页的新页存储副本220。
另一类失效是由于某页的多个页存储副本220的连锁短期和长期失效引起的失效。由于这些连锁失效,如果包含某页的页存储副本220的存储节点损坏,并且该页的页存储副本220包含一些与该页对应的在该页的任何其他页存储副本220上都不可用的日志记录,则恢复引擎168通过从公共日志中读取与该页对应的日志记录来恢复与该页对应的日志记录。换句话说,如本文进一步通过示例所述,恢复引擎168可以通过从公共日志中读取与该页对应的日志记录并将这些日志记录写入该页的合适页存储副本220来恢复该页的最新版本。
结合图1参见图4,根据一些实施方式,恢复引擎168执行方法400以处理页存储副本失效。依据方法400,恢复引擎168确定(判定框404)某页的特定页存储副本220无法服务该页的读请求和写请求是否是暂时性的。例如,由于这种无法服务,恢复引擎168可以确定该页的页存储副本220无法服务读请求或确认写请求是否已经持续了超过预定时间(例如,超过15分钟持续时间)。如果低于这一阈值,则根据一些实施方式,恢复引擎168指示没有检测到失效的页存储副本220之一执行gossip协议,以将与该页对应的丢失的日志记录提供给新创建的页存储副本。
然而,如果恢复引擎168确定失效已经超过预定持续时间,则依据判定框412,恢复引擎168可以认为该页的页存储副本220的失效是长期失效。这样的话,恢复引擎168可以通过将现有页存储复制到存储节点的集群中的另一存储节点来创建(框416)该页的新页存储副本以替换失效的页存储副本220,从而在新的位置产生该页的新页存储副本220。
如上所述,另一失效模式是由于包括多个页存储副本220的连锁短期和长期失效。如果依据判定框420,恢复引擎168确定发生了这种情况,则依据框424,恢复引擎168从公共日志中读取与分配给页存储的页对应的丢失的日志记录,并将这些日志结论写入页存储副本220以恢复丢失的日志记录。
根据一些实施方式,恢复引擎168通过检查来自该页的页存储副本220的最大LSN查询响应来检测该页的多个页存储副本220的连锁短期和长期失效。如果恢复引擎168确定同一页存储的页存储副本上报告的最大LSN减小,则根据一些示例实施方式,这是被分配为具有最新日志记录的页的页存储副本220被损坏的信号;相应地,恢复引擎168执行框424中概述的过程以恢复最新日志记录。
作为更具体的示例,图5A和图5B示出了根据示例实施方式的连锁长期和短期页存储副本失效和从这些失效恢复的示例时间线。对于该示例,分布式数据库系统100的DBMS维护公共日志512,并且分布式数据库系统100具有页的三个页存储副本220(关于图5A和图5B,具体地称为页存储副本1、页存储副本2、以及页存储副本3)。此外,图5A和图5B中示出的示例示出了沿时间线501在不同时间的不同状态512、520、524、528、532、540、544、550、554、560的推进。对于这些状态,写引擎160确定“页存储持久LSN”,指的是由各个页存储副本220报告的最大LSN的最小值。
在示例状态512,因为每个页存储副本报告的最大LSN为“1”,所以页存储持久LSN为“1”。此外,对于状态512,所有三个页存储副本1、2、3都可用。注意,对于状态512,公共日志510具有与日志记录1、2、3、4、5对应的日志记录。
对于下一示例状态520,页存储副本3暂时性地失效。此外,对于状态520,因为所有三个页存储副本220都已经确认了日志记录1的写入,所以写引擎160截断公共日志510以移除日志记录1。此外,如图5A所示,对于状态520,页存储副本1和页存储副本2各自确认了最大LSN为“2”。注意,在这个状态520,由于失效,页存储副本3没有确认最大LSN。然而,写引擎160保持页存储副本3先前确认的最大LSN为“1”。因此,该示例中,状态520的页存储持久LSN为“1”。
对于下一示例状态524,页存储副本3仍然失效,并且现在,页存储副本2也失效。此外,在该状态,写引擎160没有进一步截断公共日志520,因此对于状态520,页存储持久LSN保持为1。此外,如状态524所述,页存储副本1确认日志记录2和3的写入。此外,页存储副本1确认最大LSN为“3”,使用该信息,写引擎160更新页存储持久LSN。然而,此时,页存储副本2和3没有响应,写引擎160使用先前从页存储2和3响应的最大LSN,因此,写引擎160维持页存储持久LSN为“1”。这样,由于页存储持久LSN没有改变,所以公共日志510保持不变。
在状态528,页存储副本2和3再次变为可用;页存储副本1现在变为不可用。此外,对于状态528,页存储副本2报告最大LSN为“2”。虽然页存储副本2已经接收到日志记录4,但因为页存储副本2没有接收到日志记录3,所以页存储副本2的最大LSN仍然是“2”。此外,页存储副本3分别接收到日志记录2和4,因为页存储副本3没有接收到日志记录3,所以报告最大LSN为“2”。在状态528,图5A还示出了gossip协议用于将日志记录2的副本从页存储副本2传送到页存储副本3。写引擎160维持页存储副本1的最大LSN为“3”,即,由页存储副本1提供的先前值。如状态532所示,由于页存储持久LSN增加到“2”,所以写引擎160随后可以进一步截断公共日志510,从而移除日志记录2,留下日志记录3、4、5。
在状态532,页存储副本1保持不可用;页存储可以释放日志记录2;页存储副本2和3各自报告其最大LSN为“2”。由于页存储持久LSN保持在“2”,所以写引擎160不会进一步截断公共日志510,从而日志记录2从公共日志510中移除。
参见图5B,在下一示例状态540,恢复引擎168检测到页存储副本1的长期失效。换句话说,页存储副本1保持不可用的时间已经长于预定持续时间。因此,在状态540,恢复引擎168(在另一存储节点110)创建空页存储副本1作为替换。例如,根据一些实施方式,恢复引擎168可以在作为可用性空间116的一部分的存储节点110创建空页存储副本1,该可用性空间116不同于与页存储副本2和3关联的可用性空间。在状态540,图5B示出了页存储副本2和3具有仍未处理的日志记录3;因此,页存储副本2和3各自报告最大LSN“2”。因此,页存储持久LSN保持为“2”。
在后续步骤544,示出了对页存储副本1的日志记录的重建,通过gossip协议,日志记录4从页存储副本2传送到页存储副本1。此外,日志记录5的副本可以按类似的方式从页存储副本2或3传送。由于页存储副本1、2、或3都没有接收到日志记录3的副本,所以页存储持久LSN保持为“2”。
在状态550,使用报告的最大LSN和先前的页存储持久LSN,恢复引擎168检测多个页存储副本的连锁失效。以这种方式,页存储副本1现在可用,但是仅报告最大LSN为“2”。然而,这呈现出最大LSN的减小。换句话说,公共日志预计最大LSN为(3,2,2),但是页存储副本提供的最大LSN为(2,2,2)。因此,根据示例实施方式,这向恢复引擎168发出如下信号:已经发生了页存储副本的多个连锁失效。这样,根据示例实施方式,恢复引擎168开始从该失效模式恢复。
更具体地,在状态554,恢复引擎168重新发送写请求,以将日志记录3、4、5从公共日志510写入所有三个页存储副本1、2、3。由于日志记录3、4、5分别写入页存储副本1、2、3,所以现在所有三个页存储副本1、2、3都报告最大持久LSN为“5”。因此,如状态560所示,写引擎160随后可以截断公共日志,以从公共日志中移除日志记录5。因此,在状态560,页存储副本1、2、3各自具有处理后的直到日志记录5的日志记录。此外,每个页存储副本1、2、3都报告最大LSN为“5”,从而得到页存储持久LSN为“5”。
因此,本文描述了分布式数据库系统的复制和存储策略,其使用相对较少的页存储副本实现了更高的写可用性。在潜在的优势中,写请求实际上可能有100%的可用性。而且,读请求的可用性可以与使用相同数量的页存储副本的现有技术相媲美。本文描述的存储和复制策略可以与多种类型的数据库系统一起使用,并且可以与整体数据库和分片数据库一起使用。
尽管针对在数据库管理器150上运行的DBMS 172描述了本发明的方法,但是在替代实施例中,本发明的方法可以由在云服务提供商提供的云计算环境中的PaaS层中提供的数据库服务的DBMS执行。
尽管已经针对有限数量的实施方式描述了本公开,但是受益于本公开的本领域技术人员将理解其众多修改和变化。所附权利要求旨在覆盖所有这样的修改和变化。

Claims (20)

1.一种方法,包括:
接收对数据库的页进行改变的指示;
将与所述页对应的新日志记录添加到包括日志记录的公共日志,所述新日志记录描述对所述页进行的所述改变,并被分配不同的版本号;
将所述新日志记录同步写入一组日志存储副本中的每个日志存储副本;以及
将所述新日志记录不同步写入所述页的所有页存储副本,以更新存储在每个页存储副本上的所述页,其中,所述页的所述页存储副本服务所述页的读取;以及
响应于从预定数量的页存储副本接收到对所述新日志记录的写入的确认,从所述公共日志丢弃所述新日志记录。
2.根据权利要求1所述的方法,其中,所述日志存储副本和所述页存储副本位于不同的存储节点,并且所述存储节点位于不同的可用性空间。
3.根据权利要求1-2中任一项所述的方法,其中,所述一组日志存储副本中的日志存储副本的数量与所述页存储副本的数量相同。
4.根据权利要求1-2中任一项所述的方法,其中,所述一组日志存储副本中的日志存储副本的数量与所述页存储副本的数量不同。
5.根据权利要求1-4中任一项所述的方法,其中,所述一组日志存储副本包括位于不同可用性空间的至少三个日志存储副本。
6.根据权利要求4所述的方法,其中,所述可用性空间与不同的地理位置相关联。
7.根据权利要求1-6中任一项所述的方法,其中,将所述新日志记录不同步写入所述页的所有页存储副本包括:
向所述页存储副本中的第一页存储副本发送写请求;
接收对所述写请求的确认;以及
向所述第一页存储副本发送指令,以允许在所述第一页存储副本和第二页存储副本之间使用对等gossip协议,从而将所述新日志记录复制到所述第二页存储副本。
8.根据权利要求1-7中任一项所述的方法,还包括:
读取所述页,其中,所述读取包括选择所述页存储副本中的一个页存储副本,并从选择的所述页存储副本中读取所述页。
9.根据权利要求8所述的方法,其中,选择所述页存储副本包括确定与所述页的所述读取相关联的请求逻辑序列号,并基于由选择的所述页存储副本确认的逻辑序列号选择所述页存储副本。
10.根据权利要求1-9中任一项所述的方法,还包括:
检测所述页存储副本中的所述页的页存储副本的失效;以及
响应于检测到所述失效,执行恢复操作,其中,执行所述恢复操作包括:
创建所述页的新页存储副本,以替换失效的所述页存储副本。
11.根据权利要求10所述的方法,其中,创建所述页的所述新页存储副本包括允许所述页的所述新页存储副本和至少一个其他页存储副本使用对等复制协议,以将页从所述页的所述至少一个其他页存储副本复制到所述页的所述新页存储副本。
12.根据权利要求1-11中任一项所述的方法,还包括:
检测所述页存储副本中的多个页存储副本的连锁失效;以及
响应于检测到的所述连锁失效,执行恢复操作,其中,执行所述恢复操作包括:
识别所述公共日志中与发生所述连锁失效的所述页对应的一组日志记录;
从所述公共日志中读取识别的所述一组日志记录;以及
将识别的所述一组日志记录写入所述多个页存储副本。
13.根据权利要求12所述的方法,其中,检测所述连锁失效包括确定:
确定所述页存储副本中先前确认了与所述页对应的日志记录的写入的给定页存储副本;以及
确定其他页存储副本当前都没有确认与所述页对应的所述新日志记录的写入。
14.根据权利要求1-13中任一项所述的方法,还包括:
检测所述一组日志存储副本中的日志存储副本的失效;
选择新的一组日志存储副本;以及
将所述新日志记录同步写入所述新的一组日志存储副本中的每个日志存储副本。
15.根据权利要求1-14中任一项所述的方法,还包括用于日志存储的复制策略以及用于页存储的不同复制策略,其中,根据用于日志存储的所述复制策略确定所述一组日志存储副本中的日志存储副本的数量,并且根据用于页存储的所述复制策略确定页存储副本的数量。
16.一种非暂时性机器可读存储介质,用于存储指令,当由机器执行时,所述指令使所述机器:
接收对数据库的页进行改变的指示;
将与所述页对应的新日志记录添加到包括日志记录的公共日志,所述新日志记录描述对所述页进行的所述改变,并被分配不同的版本号;
将所述新日志记录同步写入一组日志存储副本中的每个日志存储副本;以及
将所述新日志记录不同步写入所述页的所有页存储副本,以更新存储在每个页存储副本上的所述页,其中,所述页的所述页存储副本服务所述页的读取;以及
响应于从预定数量的页存储副本接收到对所述新日志记录的写入的确认,从所述公共日志丢弃所述新日志记录。
17.一种装置,包括:
处理器;以及
用于存储指令的存储器,当由所述处理器执行时,所述指令使所述处理器:
接收对数据库的页进行改变的指示;
将与所述页对应的新日志记录添加到包括日志记录的公共日志,所述新日志记录描述对所述页进行的所述改变,并被分配不同的版本号;
将所述新日志记录同步写入一组日志存储副本中的每个日志存储副本;以及
将所述新日志记录不同步写入所述页的所有页存储副本,以更新存储在每个页存储副本上的所述页,其中,所述页的所述页存储副本服务所述页的读取;以及
响应于从预定数量的页存储副本接收到对所述新日志记录的写入的确认,从所述公共日志丢弃所述新日志记录。
18.根据权利要求17所述的装置,其中,当由所述处理器执行时,所述指令使所述处理器:
检测所述页存储副本中的所述页的页存储副本的失效;以及
响应于检测到所述失效,执行恢复操作,其中,执行所述恢复操作包括:
创建所述页的新页存储副本,以替换失效的所述页存储副本。
19.根据权利要求18所述的装置,其中,当由所述处理器执行时,所述指令使所述处理器:
通过以下创建所述页的所述新页存储副本:允许所述页的所述新页存储副本和至少一个其他页存储副本使用对等复制协议,以将页从所述页的所述至少一个其他页存储副本复制到所述页的所述新页存储副本。
20.根据权利要求17-19中任一项所述的装置,其中,当由所述处理器执行时,所述指令使所述处理器:
检测所述页存储副本中的多个页存储副本的连锁失效;以及
响应于检测到的所述连锁失效,执行恢复操作,其中,执行所述恢复操作包括:
识别所述公共日志中与遇到所述连锁失效的所述页对应的一组日志记录;
从所述公共日志中读取识别的所述一组日志记录;以及
将识别的所述一组日志记录写入所述多个页存储副本。
CN202080006927.XA 2019-03-15 2020-03-12 用于在分布式数据库系统中复制数据的系统和方法 Active CN113168404B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/355,521 US11106541B2 (en) 2019-03-15 2019-03-15 System and method for replicating data in distributed database systems
US16/355,521 2019-03-15
PCT/CN2020/078943 WO2020187120A1 (en) 2019-03-15 2020-03-12 System and method for replicating data in distributed database systems

Publications (2)

Publication Number Publication Date
CN113168404A CN113168404A (zh) 2021-07-23
CN113168404B true CN113168404B (zh) 2022-07-22

Family

ID=72422563

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080006927.XA Active CN113168404B (zh) 2019-03-15 2020-03-12 用于在分布式数据库系统中复制数据的系统和方法

Country Status (4)

Country Link
US (1) US11106541B2 (zh)
EP (1) EP3931713A4 (zh)
CN (1) CN113168404B (zh)
WO (1) WO2020187120A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108228678B (zh) * 2016-12-22 2020-10-16 华为技术有限公司 一种多副本数据恢复方法及装置
US11176174B2 (en) * 2019-07-31 2021-11-16 Mastercard International Incorporated Systems and methods for database replication
US11194501B2 (en) * 2020-01-24 2021-12-07 Netapp, Inc. Standby copies withstand cascading fails
US11657066B2 (en) 2020-11-30 2023-05-23 Huawei Cloud Computing Technologies Co., Ltd. Method, apparatus and medium for data synchronization between cloud database nodes
US11714794B2 (en) 2021-03-31 2023-08-01 Huawei Cloud Computing Technologies Co., Ltd. Method and apparatus for reading data maintained in a tree data structure
US11645254B2 (en) * 2021-09-25 2023-05-09 International Business Machines Corporation Database index modification
CN116866327A (zh) * 2023-07-11 2023-10-10 创泽智能机器人集团股份有限公司 一种基于web查看svn日志的方法及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105122241A (zh) * 2013-03-15 2015-12-02 亚马逊科技公司 具有数据库引擎和独立分布式存储服务的数据库系统
CN105324770A (zh) * 2013-04-30 2016-02-10 亚马逊科技公司 有效读出副本
CN106991113A (zh) * 2015-12-18 2017-07-28 Sap欧洲公司 数据库环境中的表格复制
CN108108476A (zh) * 2018-01-03 2018-06-01 中科边缘智慧信息科技(苏州)有限公司 高可靠分布式日志系统的工作方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9558256B2 (en) 2010-11-16 2017-01-31 Linkedin Corporation Middleware data log system
JP2014182653A (ja) 2013-03-19 2014-09-29 Canon Inc ログ管理システム、ログ管理方法、画像形成装置およびその制御方法、並びにプログラム
US9507843B1 (en) * 2013-09-20 2016-11-29 Amazon Technologies, Inc. Efficient replication of distributed storage changes for read-only nodes of a distributed database
US9552242B1 (en) * 2013-09-25 2017-01-24 Amazon Technologies, Inc. Log-structured distributed storage using a single log sequence number space
US10713275B2 (en) * 2015-07-02 2020-07-14 Mongodb, Inc. System and method for augmenting consensus election in a distributed database
US10592528B2 (en) * 2017-02-27 2020-03-17 Sap Se Workload capture and replay for replicated database systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105122241A (zh) * 2013-03-15 2015-12-02 亚马逊科技公司 具有数据库引擎和独立分布式存储服务的数据库系统
CN105324770A (zh) * 2013-04-30 2016-02-10 亚马逊科技公司 有效读出副本
CN106991113A (zh) * 2015-12-18 2017-07-28 Sap欧洲公司 数据库环境中的表格复制
CN108108476A (zh) * 2018-01-03 2018-06-01 中科边缘智慧信息科技(苏州)有限公司 高可靠分布式日志系统的工作方法

Also Published As

Publication number Publication date
WO2020187120A1 (en) 2020-09-24
US11106541B2 (en) 2021-08-31
US20200293407A1 (en) 2020-09-17
EP3931713A1 (en) 2022-01-05
CN113168404A (zh) 2021-07-23
EP3931713A4 (en) 2022-05-04

Similar Documents

Publication Publication Date Title
CN113168404B (zh) 用于在分布式数据库系统中复制数据的系统和方法
US11153380B2 (en) Continuous backup of data in a distributed data store
US11120152B2 (en) Dynamic quorum membership changes
US10229011B2 (en) Log-structured distributed storage using a single log sequence number space
US10534768B2 (en) Optimized log storage for asynchronous log updates
US9081841B2 (en) Asynchronous distributed garbage collection for replicated storage clusters
US20200012568A1 (en) Scalable log-based continuous data protection for distributed databases
JP6404907B2 (ja) 効率的な読み取り用レプリカ
US7653668B1 (en) Fault tolerant multi-stage data replication with relaxed coherency guarantees
US11030055B2 (en) Fast crash recovery for distributed database systems
US9672237B2 (en) System-wide checkpoint avoidance for distributed database systems
US9507843B1 (en) Efficient replication of distributed storage changes for read-only nodes of a distributed database
US10659225B2 (en) Encrypting existing live unencrypted data using age-based garbage collection
US9047331B2 (en) Scalable row-store with consensus-based replication
CN106547859B (zh) 一种多租户数据存储系统下的数据文件的存储方法及装置
US9652520B2 (en) System and method for supporting parallel asynchronous synchronization between clusters in a distributed data grid
US9330107B1 (en) System and method for storing metadata for a file in a distributed storage system
US10223184B1 (en) Individual write quorums for a log-structured distributed storage system
US11194501B2 (en) Standby copies withstand cascading fails
CN109992447B (zh) 数据复制方法、装置及存储介质
JP6376626B2 (ja) データ格納方法、データストレージ装置、及びストレージデバイス
CN116868173A (zh) 降低在恢复操作期间网络延时的影响
US11038960B1 (en) Stream-based shared storage system
US9794326B1 (en) Log information transmission integrity
CN112470112A (zh) 块存储系统的分布式副本

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
CB03 Change of inventor or designer information

Inventor after: Alexander de potovich

Inventor after: Per AK Larson

Inventor after: Chen Li

Inventor before: Alexander de potovich

Inventor before: Per AK Larson

Inventor before: Chen Chong

CB03 Change of inventor or designer information
TA01 Transfer of patent application right

Effective date of registration: 20220210

Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province

Applicant after: Huawei Cloud Computing Technology Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Applicant before: HUAWEI TECHNOLOGIES Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant