CN115421972A - 一种分布式数据库故障恢复的方法与系统 - Google Patents

一种分布式数据库故障恢复的方法与系统 Download PDF

Info

Publication number
CN115421972A
CN115421972A CN202211016464.2A CN202211016464A CN115421972A CN 115421972 A CN115421972 A CN 115421972A CN 202211016464 A CN202211016464 A CN 202211016464A CN 115421972 A CN115421972 A CN 115421972A
Authority
CN
China
Prior art keywords
node
data
consensus
logs
state
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.)
Pending
Application number
CN202211016464.2A
Other languages
English (en)
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.)
Shanghai Yunxi Technology Co ltd
Original Assignee
Inspur Software Group 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 Inspur Software Group Co Ltd filed Critical Inspur Software Group Co Ltd
Priority to CN202211016464.2A priority Critical patent/CN115421972A/zh
Publication of CN115421972A publication Critical patent/CN115421972A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • 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/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • 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/2365—Ensuring data consistency and integrity
    • 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
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Computational Linguistics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明特别涉及一种分布式数据库故障恢复的方法与系统。该分布式数据库故障恢复的方法与系统，将共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，存储在一个与用户数据相对独立的存储引擎中；在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。该分布式数据库故障恢复的方法与系统，能够完整的恢复节点内存中的全部数据，使得节点恢复至宕机前的一致状态，保证了分布式数据库系统中数据的一致性和完整性。

Description

一种分布式数据库故障恢复的方法与系统
技术领域
本发明涉及计算机存储技术领域，特别涉及一种分布式数据库故障恢复的方法与系统。
背景技术
随着企业数字化程度的加深，越来越多的业务被搬到了线上，伴随而来的是业务数据量的高速增长，传统的单机数据库越来越难以满足企业日新月异的发展需求。分布式数据库是利用现代计算机网络技术将物理上分散的计算存储单元连接成逻辑上统一的数据库系统，具备分布式事务处理能力，可灵活扩展，支持高可用和高并发，有效地弥补了传统单机数据库系统扩展性差、投入产出比低等突出问题，在业务需求快速变化的环境中，为企业的高速发展扫清了技术障碍。
分布式数据中各个节点在物理空间上是分散的，在逻辑上是对等，各个节点具备一定的自治能力。数据在分布式数据库中分布是透明的，采用冗余副本的方式保证数据高可用，多个数据副本之间的一致性一般是通过分布式共识算法来保证。例如：在OceanBase中是通过Paxos算法实现多个数据副本间的一致性，在CockroachDB中使用Raft算法保证了多数据副本间的一致性。通常根据业务的需求，将数据数据副本的数量设置为奇数(3或者5)，在不超过半数副本发生故障(所在节点)的场景下，不会影响到整个数据库系统的可用性。
分布式数据库系统中不同节点上存储的数据是彼此隔离的，依赖于数据库节点中的存储引擎。例如：在CockroachDB中每个数据库节点中使用RocksDB/Pepple作为存储引擎，在TiDB中使用每个数据库节点中使用TiKV作为存储引擎。在存储引擎中一般会使用预写式日志(Write-Ahead logging，缩写WAL)来保证操作的原子性和持久性，即所有的修改在生效之前都要先写入Log文件中。Log文件中通常包括Redo(重做)和Undo(撤销)信息。假设一个程序在执行某些操作的过程中系统故障了。重启系统后，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了WAL，程序就可以检查Log文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。ARIES是WAL技术常用的算法，其核心策略为：
1)涉及对象的任何变更都要先记入日志，并且日志必须要先于对象被写入磁盘(如附图1所示)；
2)在系统故障重启时，ARIES通过Redo数据库在故障之前的操作，使数据库恢复到故障之前那一刻的状态，然后Undo掉故障时没有完成的事务；
3)将在Undo事务时对数据库所做的操作记录日志，保证在重复重启时不会重做。
例如：在RocksDB中的每个更新操作都会写到两个地方：
1)写到磁盘上的WAL日志；
2)一个名为MemTable的内存数据结构，后续会被刷盘到SST文件。
WAL会把MemTable的操作序列化之后以日志文件形式存储在磁盘中。在数据库出现崩溃的时候，WAL文件可以用于重新构建MemTable，帮助数据库恢复数据库到一个一致的状态。当一个MemTable被安全地写入磁盘之后，相关的WAL日志会变成过期的，然后会被归档，最终归档的日志会在一定时间后从磁盘上删除。
为了在节点故障重启时，能够完整的恢复节点内存中的全部数据，使得节点恢复至宕机前的一致状态，保证分布式数据库系统中数据的一致性和完整性，本发明提出了一种分布式数据库故障恢复的方法与系统。
发明内容
本发明为了弥补现有技术的缺陷，提供了一种简单高效的分布式数据库故障恢复的方法与系统。
本发明是通过如下技术方案实现的：
一种分布式数据库故障恢复的方法，其特征在于：将共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，存储在一个与用户数据相对独立的存储引擎中；
在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
在节点故障重启时，先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
所述共识日志的应用操作具有幂等性。
所述共识日志的提交状态是指已提交日志的最大编号，所述共识日志的清理状态是指已清理日志的最大编号，通过共识日志的提交状态与清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来。
所述节点上各个数据分片的最新的快照信息要求每个从副本保留最近一次主副本发送来的快照信息；在节点重启时，快照信息能够快速恢复数据分片的初始状态，即数据分片由快照的方式进行创建。
所述宕机前节点上每个数据分片的初始的描述信息不包括在节点宕机前已经被清理的数据分片；在节点重启时，数据分片的初始描述信息能够唯一标识该数据分片的起始状态，即数据分片由分裂方式进行创建。
一种分布式数据库故障恢复的系统，其特征在于：包括共识日志管理模块、数据分片管理模块和节点恢复模块；
所述共识日志管理模块负责生成并管理共识日志，获取共识日志的提交状态和共识日志的清理状态信息，并将共识日志、共识日志的提交状态和共识日志的清理状态信息存储在一个与用户数据相对独立的存储引擎中；
所述数据分片管理模块负责获取并管理节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，并将获取的信息存储在一个与用户数据相对独立的存储引擎中；
所述节点恢复模块负责在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
在节点故障重启时，所述节点恢复模块先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
本发明的有益效果是：该分布式数据库故障恢复的方法与系统，能够完整的恢复节点内存中的全部数据，使得节点恢复至宕机前的一致状态，保证了分布式数据库系统中数据的一致性和完整性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
附图1为本发明数据库系统中WAL机制示意图。
附图2为本发明键值存储系统数据组织方式示意图。
附图3为本发明Split场景下Range回放过程示意图。
附图4为本发明Merge场景下Range回放过程示意图。
附图5为本发明Snapshot场景下Range回放过程示意图。
附图6为本发明Transfer场景下Range回放过程示意图。
附图7为本发明混合场景下Range回放过程示意图。
附图8为本发明基于Store的Raft Log递归回放恢复内存数据的过程示意图。
具体实施方式
为了使本技术领域的人员更好的理解本发明中的技术方案，下面将结合本发明实施例，对本发明实施例中的技术方案进行清楚，完整的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
分析分布式数据库系统现有设计上的一些弊端。以CockroachDB为例，在CockroachDB中为了保证多个数据副本之间的一致性，写入操作需要依赖Raft算法。Raft算法在运行可以分为两个阶段，在共识阶段主副本将写入的用户数据封装进Raft Log，通过消息将Raft Log传递其他副本。主副本在确认半数以上副本收到消息后进入到应用阶段，在应用阶段解析出Raft Log中包含的用户数据写入到存储引擎中，同时给上层应用响应，完成写入操作。由上可知，在共识阶段中Raft Log需要写入到存储引擎中保存，在应用阶段需要将存储引擎中Rfat Log读出，解析出其中的用户数据然后再将用户数据写入到存储引擎，这个过程同一份数据会经历至少4次写入。为了保证系统故障时数据不会丢失，在存储引擎中任何写入都需要先写入到WAL中并且进行落盘，然后才能将数据写入内存，并且针对WAL的写入还必须是有序的，这在很大程度上限制了存储引擎的写入性能，进而会对整个分布式数据库系统的性能产生严重影响。在TPCC测试场景中仅仅将CockroachDB中RocksDB的WAL禁用掉，就能使得TPMC有10％的提升。如果在禁用RocksDB的WAL同时并行写MemTable，那么写入性能将会进一步的提升。禁用WAL后一旦系统发生故障就可能会造成数据的丢失，必须要设计一种新的方式使得丢失的数据能够被完整的恢复回来。
Raft Log作为Raft算法运行过程中产生的、为了保证算法运行正确性的一种数据冗余存储的方式，Raft Log中包含有全量的写入数据，因此在理论上可以使用Raft Log来恢复系统故障时存储引擎因禁用WAL而丢失的部分数据，前提是必须要将Rfat Log和用户数据存储到彼此独立的存储引擎中。详细来说，在Raft算法的共识阶段，主副本将写入的用户数据封装进Raft Log，写入到Raft Log存储引擎以及缓存，同时通过消息将Raft Log传递其他副本。其他副本在收到主副本发送过来的Raft Log后，写入到Raft Log存储引擎以及缓存，同时发送确认消息给主副本。主副本收到过半数的确认消息后，将Raft Log从缓存或者Raft Log存储引擎中取出，解析出其中的用户数据然后写入用户数据存储引擎。其他副本收到主副本应用消息后执行相同的操作。当系统发生故障后在重启时，从Raft Log存储引擎中取出用户数据引擎中丢失数据对应的Raft Log，解析出其中的用户数据再次写入到用户数据存储引擎，使得用户数据存储引擎恢复到系统故障前的一致状态。对于整个分布式数据库系统而言，共识日志存储引擎承担数据一致性和完整性的职责，而用户数据引擎则专注于用户数据的各项操作。目的是使得数据库系统各功能模块之间职责更加清晰，同时降低数据的冗余程度，减少不必要写入性能损耗，也便于后续用户数据引擎各项性能优化(内存表的并行写入)的开展，进而提高分布式数据库系统的整体运行效率。
该分布式数据库故障恢复的方法，将共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，存储在一个与用户数据相对独立的存储引擎中；
在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
在节点故障重启时，先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
所述共识日志的应用操作具有幂等性。
所述共识日志的提交状态是指已提交日志的最大编号，所述共识日志的清理状态是指已清理日志的最大编号，通过共识日志的提交状态与清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来。
所述节点上各个数据分片的最新的快照信息要求每个从副本保留最近一次主副本发送来的快照信息；在节点重启时，快照信息能够快速恢复数据分片的初始状态，即数据分片由快照的方式进行创建。
所述宕机前节点上每个数据分片的初始的描述信息不包括在节点宕机前已经被清理的数据分片；在节点重启时，数据分片的初始描述信息能够唯一标识该数据分片的起始状态，即数据分片由分裂方式进行创建。
该分布式数据库故障恢复的系统，包括共识日志管理模块、数据分片管理模块和节点恢复模块；
所述共识日志管理模块负责生成并管理共识日志，获取共识日志的提交状态和共识日志的清理状态信息，并将共识日志、共识日志的提交状态和共识日志的清理状态信息存储在一个与用户数据相对独立的存储引擎中；
所述数据分片管理模块负责获取并管理节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，并将获取的信息存储在一个与用户数据相对独立的存储引擎中；
所述节点恢复模块负责在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
在节点故障重启时，所述节点恢复模块先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
下面，以CockroachDB v22.1.0为例进行详细阐述。
在CockroachDB中，Raft Log表示共识日志、Hard State表示共识日志的提交状态、Truncate State表示共识日志的清理状态、Snapshot表示数据分片的快照信息、Range表示数据分片、Replica表示数据分片的单个副本、Replica State表示数据分片的描述信息。
如附图2所示，将Raft Log、Hard State、Truncate State、Snapshot以及ReplicaState存放在共识日志存储引擎(具体可以选用BadgerDB)中，将用户数据在内其他数据存放到用户数据存储引擎(具体可以选用RocksDB)中，并且禁用掉RocksDB中的WAL功能。
CockroachDB中同一个Range内的Raft Log是严格按照Index顺序进行提交以及应用的，回放Raft Log恢复内存数据时，在同一个Range内，根据BadgerDB中记录的HardState，将Applied Index至Commit Index之间的Raft Log依次应用至状态机即可恢复内存中的数据。但是，由于Range会进行Split，相邻的Range会进行Merge，不同Store上Range还会通过Snapshot形式进行转移。因此，回放Raft Log需要以Store为单位进行。
在Store重启过程中，先扫描获取Store中保存的全部Range Descriptor(即该Store内保存的全部数据分片的描述信息)，加入到Replay Queue，在Raft Scheduler完成初始化之后，遍历Replay Queue中的Range Descriptor。针对每个Range Descriptor对应的Range依次回放Applied Index至Commit Index之间的Raft Log，期间如果Range遇到Split，不采取任何额外操作，正常进行Split；如果Range遇到Merge，则阻塞Left Range(原有的数据分片)的回放，开始加载Right Range(通过分离产生的数据分片)并进行回放，Right Range回放完毕后，再重启Left Range的回放，直至Left Range完成回放，将该过程称之为基于Store的Raft Log递归回放过程。在递归回放过程中，如果Range需要迁移到其他Store，则在该Store上清理对应Range即可；如果Merge操作涉及Range是由其他Store通过Snapshot迁移至该Store，则根据BadgerDB中保存的Snapshot应用之后生成对应Range，继续参与后续的操作。
下面根据Range回放过程涉及的Split、Merge、Snapshot和Transfer四种场景以及混合场景进行详细说明。
场景一：分裂Split
如附图3所示，Range 66通过Split产生Range 92，在节点(Store)宕机之前已经完成了Split操作。由于内存中数据并未全部落盘，当节点重启后，Range 66状态回退到Split操作之前。根据HardState(保存在BadgerDB中)中CommitIndex以及AppliedState(保存在RocksDB中)中的AppliedIndex可以确定需要进行回放的RaftLog的范围，按顺序从BadgerDB中取出对应的RaftLog进行回行。当回放至Index:25003RaftLog时，通过Split生产Range 92，待Range 92完成初始化后，将其加入到回放流程中，进行回放。
场景二：融合Merge
如附图4所示，Range 84通过Merge操作合并Range 92，在节点(Store)宕机之前已经完成了Merge操作，由于内存中数据并未全部落盘，当节点重启后Range 84和Range92的状态都回退到Merge操作之前。假设Range 84先于Range 92进行回放，同样根据Hard State(BadgerDB)中记录的Committed Index与Applied State(RocksDB)中的积累AppliedIndex可以确定Range 84需要进行回放的Raft Log的范围，当Range 84回放至Index:2298Raft Log时，检测到需要执行Merge操作且Right Range为Range 92，阻塞Range84回放流程，初始化Range 92并进行回放，当Range 92上Raft Log全部完成回放后能够满足Merge操作的各项要求，此时重启Range 84回放流程执行Merger操作以及后续的回放流程。注意：这里需要保证Merge操作落盘之后才能清理Badger DB中对应Range的全部数据。
场景三：快照Snapshot
如附图5所示，Range 157通过Snapshot方式转移到其他Store后续又通过Snapshot方式转移回来的过程，在节点(Store)宕机之前已经完成了上述过程，由于内存中数据并未全部落盘，当节点重启后Range 157的状态回退到应用Snapshot之前，无法主动回放Range 157(RocksDB中找不到RangeDesc)。当Range 62回放至Index:124RaftLog时检查到需要合并Range 157，阻塞Range 62回放流程，通过储存在BadgerDB中的Snapshot初始化Range 157并且回放全部待会回的RaftLog。完上述操作后，重启Range 62回放流程执行Merger操作以及后续的回放流程。
场景四：转移Transfer
如附图6所示，Range 308转移到其他Store的过程，在节点(Store)宕机之前已经完成了上述转移过程(Range 308的数据可能由GCQueue异步清理)，由于内存中数据并未全部落盘，当节点重启后Range 308的状态回退到转移操作之前。重启后若Range 308数据未被清理，可根据HardState中CommitIndex以及AppliedState中的AppliedIndex可以确定需要进行回放的RaftLog的范围，按顺序从BadgerDB中取出对应的RaftLog进行回行。若Range308数据已被清理则无须处理。
场景五：混合场景
如附图7所示，基于单个Store多Range的混合场景，在T10时刻节点(Store)宕机，T1时刻的数据已经落盘，在节点重启后需要利用RaftLog回放T1～T10之间的各项操作，使得Store恢复至宕机前的状态。整体回放流程如下图所示，共分为4步骤。
步骤一：根据RocksDB中存储的RangeDesc，可将对应的Range进行初始化并确定起始状态，对应到混合场景中的Range 100和Range 101在T1时刻状态。
步骤二：在已经完成初始化的Replica上利用递归回放策略，按次序回放RaftLog，过程中会遇到Split、Merge、Snapshot以及Transfer各种操作，完成回放流程后可将对应的Replica恢复至节点宕机前的时刻，对应到混合场景中Range 100、104、103、105、101以及102可以恢复至T10时刻状态。
步骤三：根据BadgerDB中保存的Snapshot以及ReplicaState查找出未被恢复的Replica，并完成对应Replica的初始化，对应到混合场景中Range 106和Range 107完成了初始化，Range 106恢复至T4时刻状态，Range 107恢复至T3时刻状态。
步骤四：重复步骤二中的递归回放过程，完成回放流程后可将对应的Replica恢复至节点宕机前的时刻，对应到混合场景中Range 106、107以及108可以恢复至T10时刻状态。
至此Store上全部副本均恢复至宕机前T10时刻状态。
综上，将基于Store的Raft Log递归回放恢复内存数据的过程总结，如附图8所示。
与现有技术相比，该分布式数据库故障恢复的方法与系统，具有以下特点：
第一、将共识日志与用户数据分离存储，利用共识日志、状态数据以及快照数据取代存储引擎中的预写日志，显著减少了数据在存储引擎中的写入次数。
第二、解决了现有分布式存储系统中由于顺序写入预写日志而导致的写入性能受限的问题，显著降低了分布式数据库系统中各节点的写入延迟。
第三、在节点故障重启时，采用基于Store的共识日志递归回放的方法，能够完整的恢复节点内存中的全部数据，使得节点恢复至宕机前的一致状态，保证了分布式数据库系统中数据的一致性和完整性，显著提升了分布式数据库系统的整体性能。
以上所述的实施例，只是本发明具体实施方式的一种，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。

Claims (8)

1.一种分布式数据库故障恢复的方法，其特征在于：将共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，存储在一个与用户数据相对独立的存储引擎中；
在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
2.根据权利要求1所述的分布式数据库故障恢复的方法，其特征在于：在节点故障重启时，先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
3.根据权利要求2所述的分布式数据库故障恢复的方法，其特征在于：所述共识日志的应用操作具有幂等性。
4.根据权利要求2所述的分布式数据库故障恢复的方法，其特征在于：所述共识日志的提交状态是指已提交日志的最大编号，所述共识日志的清理状态是指已清理日志的最大编号，通过共识日志的提交状态与清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来。
5.根据权利要求2所述的分布式数据库故障恢复的方法，其特征在于：所述节点上各个数据分片的最新的快照信息要求每个从副本保留最近一次主副本发送来的快照信息；在节点重启时，快照信息能够快速恢复数据分片的初始状态，即数据分片由快照的方式进行创建。
6.根据权利要求2所述的分布式数据库故障恢复的方法，其特征在于：所述宕机前节点上每个数据分片的初始的描述信息不包括在节点宕机前已经被清理的数据分片；在节点重启时，数据分片的初始描述信息能够唯一标识该数据分片的起始状态，即数据分片由分裂方式进行创建。
7.一种分布式数据库故障恢复的系统，其特征在于：包括共识日志管理模块、数据分片管理模块和节点恢复模块；
所述共识日志管理模块负责生成并管理共识日志，获取共识日志的提交状态和共识日志的清理状态信息，并将共识日志、共识日志的提交状态和共识日志的清理状态信息存储在一个与用户数据相对独立的存储引擎中；
所述数据分片管理模块负责获取并管理节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息，并将获取的信息存储在一个与用户数据相对独立的存储引擎中；
所述节点恢复模块负责在节点故障重启时，采用基于Store的共识日志递归回放的方法，通过独立存储的共识日志、共识日志的提交状态、共识日志的清理状态、节点上各个数据分片的最新的快照信息以及宕机前节点上每个数据分片的初始的描述信息将节点状态恢复至宕机前的一致状态，进而保证数据库系统数据的一致性和完整性。
8.根据权利要求7所述的分布式数据库故障恢复的系统，其特征在于：在节点故障重启时，所述节点恢复模块先根据共识日志的提交状态和共识日志的清理状态唯一确定回放哪些共识日志能够将内存中的数据完整恢复回来；然后，根据节点上各个数据分片的最新的快照信息，以创建快照的方式恢复数据分片的初始状态；最后，根据宕机前节点上每个数据分片的初始的描述信息，以分裂方式创建数据分片，恢复数据分片的起始状态。
CN202211016464.2A 2022-08-24 2022-08-24 一种分布式数据库故障恢复的方法与系统 Pending CN115421972A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211016464.2A CN115421972A (zh) 2022-08-24 2022-08-24 一种分布式数据库故障恢复的方法与系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211016464.2A CN115421972A (zh) 2022-08-24 2022-08-24 一种分布式数据库故障恢复的方法与系统

Publications (1)

Publication Number Publication Date
CN115421972A true CN115421972A (zh) 2022-12-02

Family

ID=84199077

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211016464.2A Pending CN115421972A (zh) 2022-08-24 2022-08-24 一种分布式数据库故障恢复的方法与系统

Country Status (1)

Country Link
CN (1) CN115421972A (zh)

Similar Documents

Publication Publication Date Title
US20230129099A1 (en) Adaptive query routing in a replicated database environment
JP2501152B2 (ja) アンドゥ―ログ使用の最大利用のための方法及び装置
CN111143389B (zh) 事务执行方法、装置、计算机设备及存储介质
US7925633B2 (en) Disaster recovery system suitable for database system
US6377959B1 (en) Redundant database recovery through concurrent update and copy procedures
US8918362B2 (en) Replication processes in a distributed storage environment
CN105359099B (zh) 索引更新管线
US10599630B2 (en) Elimination of log file synchronization delay at transaction commit time
CN113396407A (zh) 用于利用区块链技术扩充数据库应用的系统和方法
WO2018098972A1 (zh) 一种日志恢复方法、存储装置和存储节点
CN105302667B (zh) 基于集群架构的高可靠性数据备份与恢复方法
WO2022048416A1 (zh) 操作请求的处理方法、装置、设备、可读存储介质及系统
US20150269185A1 (en) Transaction processing method and apparatus
CN113326006A (zh) 一种基于纠删码的分布式块存储系统
Kończak et al. Recovery algorithms for paxos-based state machine replication
CN115658245B (zh) 一种基于分布式数据库系统的事务提交系统、方法及装置
CN110825546A (zh) 一种面向高可用数据库集群的恢复方法、系统及设备终端
US8818943B1 (en) Mirror resynchronization of fixed page length tables for better repair time to high availability in databases
WO2022033269A1 (zh) 数据处理的方法、设备及系统
CN110196788B (zh) 一种数据读取方法、装置、系统及存储介质
CN115421972A (zh) 一种分布式数据库故障恢复的方法与系统
CN115202925A (zh) 基于rdma的支持细粒度容错的共识方法及系统
WO2024193138A1 (zh) 事务处理方法及相关设备
CN118093251B (zh) 一种故障处理方法、装置及电子设备和存储介质
WO2023193495A1 (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
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20240729

Address after: Room 305-22, Building 2, No. 1158 Zhangdong Road and No. 1059 Dangui Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai, 200120

Applicant after: Shanghai Yunxi Technology Co.,Ltd.

Country or region after: China

Address before: 250100 Ji'nan hi tech Zone No. 2877, Shandong Province

Applicant before: INSPUR SOFTWARE GROUP Co.,Ltd.

Country or region before: China