CN113474666B - 分布式数据库中节点故障检测与解决 - Google Patents

分布式数据库中节点故障检测与解决 Download PDF

Info

Publication number
CN113474666B
CN113474666B CN202080015570.1A CN202080015570A CN113474666B CN 113474666 B CN113474666 B CN 113474666B CN 202080015570 A CN202080015570 A CN 202080015570A CN 113474666 B CN113474666 B CN 113474666B
Authority
CN
China
Prior art keywords
node
nodes
suspicious
connected component
list
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
CN202080015570.1A
Other languages
English (en)
Other versions
CN113474666A (zh
Inventor
S·博达格拉
R·夏埃尔
P·D·史密斯
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.)
NIMBUSDB Inc
Original Assignee
NIMBUSDB 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 NIMBUSDB Inc filed Critical NIMBUSDB Inc
Priority to CN202311335678.0A priority Critical patent/CN117929911A/zh
Publication of CN113474666A publication Critical patent/CN113474666A/zh
Application granted granted Critical
Publication of CN113474666B publication Critical patent/CN113474666B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/181—Eliminating the failing redundant component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/08—Locating faults in cables, transmission lines, or networks
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Locating Faults (AREA)

Abstract

本文描述了用于检测和解决分布式数据库系统中的故障的方法和系统。分布式数据库系统中的第一节点可以检测与分布式数据库系统中的至少一个其他节点的通信中断。这指示网络故障。响应于检测到该故障，第一节点开始故障解决协议。这调用邻居节点之间的相应可疑节点列表的协调广播。每个节点将其自己的可疑节点列表与其邻居的可疑节点列表进行比较，以确定哪些节点仍直接相互连接。每个节点确定这些直接连接的节点的最大组以及其是否在该组中。如果节点不在该组中，则使其自己发生故障以解决网络故障。

Description

分布式数据库中节点故障检测与解决
相关申请的交叉引用
本申请根据美国法典第35篇第119条(e)款要求2019年2月1日提交的题为“节点故障检测与解决”的美国申请号62/800,009的优先权权益，该申请的公开内容在此通过引用整体并入本文。
背景技术
分布式数据库中的数据和元数据存储在相互通信的多个节点上。但是，节点之间有时会发生通信中断。例如，分布式数据库系统中的节点本身可能会处于不一致状态，从而发生崩溃或故障。在其他情况下，在分布式数据库系统内的节点上运行的虚拟机或进程可能崩溃或发生故障。在其他情况下，分布式数据库系统中的第一节点和第二节点之间的通信链路可能发生故障。例如，连接分布式数据库系统中的两个或多个节点的网络(例如，局域网、广域网、以太网等)可能发生故障，从而中断节点之间的通信。
发明内容
本文描述了分布式数据库系统。分布式数据库系统可以包括多个节点。多个节点中的每个节点可以包括对应的处理器和对应的存储器。多个节点中的每个节点可以与多个节点中的每个其他节点连接。多个节点中的第一节点处的处理器可以被配置为通过以下方式解决分布式数据库系统中的故障：识别多个节点中的可疑节点，向多个节点中的邻居节点广播第一可疑节点列表，从至少一个其他邻居节点接收第二可疑节点列表，基于连接信息确定第一节点是否在分布式数据库的获胜全连接组件中，响应于确定第一节点在多个节点的获胜全连接组件中，继续操作第一节点，并且响应于确定第一节点不在多个节点的获胜全连接组件中，使第一节点发生故障，从而解决故障。可疑节点可以是多个节点中由于分布式数据库系统故障而不再连接到第一节点的节点。第一可疑节点列表可以包括可疑节点。邻居节点可以是多个节点中在网络故障后仍然直接连接到第一节点的节点。获胜全连接组件可以包括多个节点中一半以上的节点，并且获胜全连接组件中的每个节点直接连接到获胜全连接组件中的每个其他节点。
本文描述了一种用于解决分布式数据库中的故障的方法。分布式数据库可以包括多个节点，多个节点中的每个节点可以直接连接到多个节点中的每个其他节点。该方法可以包括在多个节点中的第一节点处：检测与多个节点中的第二节点的通信中断，响应于检测到中断，在多个节点中的邻居节点之间发起相应可疑节点列表的协调广播，基于相应可疑节点列表确定连接信息，以及至少部分地基于连接信息解决故障。邻居节点可以是多个节点中仍然直接连接到第一节点的节点。第一节点的可疑节点列表包括第二节点。
本文描述了一种用于解决分布式数据库中的故障的方法。分布式数据库可以包括多个节点，多个节点中的每个节点可以连接到多个节点中的每个其他节点。该方法可以包括响应于检测到故障：在多个节点中的第一节点处：确定第一节点是否与多个节点中的至少一半节点连接，响应于确定第一节点直接与多个节点中少于一半的节点连接，使第一节点发生故障以至少部分地解决故障，响应于确定第一节点直接与多个节点中的至少一半节点连接，向多个节点中的邻居节点广播第一可疑节点列表，从邻居节点中的至少一个邻居节点接收第二可疑节点列表，确定第一可疑节点列表是否与第二可疑节点列表匹配，响应于确定第一可疑节点列表与第二可疑节点列表匹配，在故障的至少部分解决中保持第一节点运行，响应于确定第一可疑节点列表与第二可疑节点列表不匹配，基于第一可疑节点列表和第二可疑节点列表向邻居节点广播第一更新可疑节点列表，从邻居节点中的至少一个邻居节点接收至少一个第二更新可疑节点列表，至少部分地基于第一更新可疑节点列表和第二更新可疑节点列表确定多个节点的连接信息，基于连接信息确定分布式数据库的获胜全连接组件，确定第一节点是否在获胜全连接组件中，响应于确定第一节点在多个节点的获胜全连接组件中，继续操作第一节点以至少部分地解决故障，以及响应于确定第一节点不在多个节点的获胜全连接组件中，使第一节点发生故障以至少部分地解决故障。第一可疑节点列表可以包括不直接连接到第一节点的节点。邻居节点可以是在故障后仍直接连接到第一节点的节点。获胜全连接组件包括多个节点中一半以上的节点，并且获胜全连接组件节点中的每个节点直接连接到获胜全连接组件节点中的每个其他节点。
下面更详细地讨论前述概念和附加概念的所有组合(假设此类概念并不相互矛盾)，其被认为是本文公开的发明主题的一部分。特别地，出现在本公开的结尾处的要求保护的主题的所有组合是本文公开的发明主题的一部分。在本文中使用的并且也可能出现在通过引用并入的任何公开中的术语应被赋予与本文公开的特定概念最一致的含义。
附图说明
本领域技术人员将理解，附图主要是出于说明性目的，并且无意限制本文所述的发明主题的范围。这些附图不一定是按比例绘制的；在某些情况下，本文公开的发明主题的各个方面可能在附图中被夸大或放大示出，以促进对不同特征的理解。在附图中，相似的附图标记通常指相似的特征(例如，功能相似和/或结构相似的元件)。
图1示出了解决网络故障以恢复分布式数据库中的节点之间的完整连接的过程。
图2示出了分布式数据库系统中网络故障的典型情况的示例，其中网络分区事件将分布式数据库系统分成两个不相交的全连接节点组。
图3示出了具有部分连接的三个节点的示例分布式数据库系统，该部分连接可以由图1所示的过程解决。
图4示出了具有两个链路故障的五个节点的示例分布式数据库系统，所述链路故障可以由图1所示的过程解决。
图5示出了具有四个链路故障的五个节点的示例分布式数据库系统，所述链路故障可以由图1所示的过程解决。
图6示出了图5中所示的部分连接情况的示例。
图7示出了具有三个链路故障的五个节点的示例分布式数据库系统，所述链路故障可以由图1所示的过程解决。
图8示出了具有五个链路故障的五个节点的示例分布式数据库系统，所述链路故障可以由图1所示的过程解决。
图9示出了具有单向链路故障的特殊部分连接的示例情况，所述链路故障可以由图1所示的过程解决。
图10示出了成员资格改变期间的网络故障的示例情况，所述故障可以由图1所示的过程解决。
图11示出了图1中所示的过程的示例。
图12是示出解决网络故障的扩展过程的流程图。
图13示出了当网络分区将新节点和条目节点与分布式数据库系统中的其余节点分开时分布式数据库系统中的成员资格改变。
图14是当网络分区将新节点和条目节点与分布式数据库系统中的其余节点分开时图13中场景的变体。
图15示出了当网络分区将新节点、条目节点和一些对等点与分布式数据库系统中的其余对等点分开时分布式数据库系统中的成员资格改变。
图16示出了当网络分区将条目节点与分布式数据库系统中的其余节点分开时分布式数据库系统中的成员资格改变。
图17示出了当网络分区将新节点、条目节点和一些对等点与分布式数据库系统中的其余节点分开时分布式数据库系统中的成员资格改变。
图18示出了当网络分区将新节点、条目节点和一些对等点与分布式数据库系统中的其余节点分开时分布式数据库系统中的另一种成员资格改变。
图19示出了通过节点交换故障检测消息来解决网络故障事件。
图20示出了在交换故障检测消息时处理节点故障。
图21示出了在运行故障转移时处理节点故障。
具体实施方式
分布式数据库系统包括存储分布式数据库的数据和/或元数据的片段的多个节点。分布式数据库系统中的所有节点都以使得它们可以相互通信的方式直接相互连接。但是，可能存在所述分布式数据库系统中的一个或多个节点由于网络故障而经历通信中断的情况。这些通信中断可能是由于两个或多个节点之间的通信链路故障或一个或多个节点的故障造成的。可以通过识别哪些节点仍然直接相互连接、识别最大的直接连接节点组以及使不属于该组的节点发生故障来解决这些故障，如下文更详细的解释。
分布式数据库系统
分布式数据库系统可以包括两种类型的节点，即提供对分布式数据库的用户访问的事务引擎(TE)节点，以及维护整个分布式数据库的相应磁盘档案的存储管理器(SM)节点。每个存储管理器节点通常存储整个分布式数据库的副本，而单个事务引擎节点可能仅包含分布式数据库的支持当时在该事务引擎节点处执行的事务所需的部分。
分布式数据库系统中的每个节点都有自己的处理器、存储器和通信接口，并且可以通过数据库系统网络直接与分布式数据库系统中的每个其他节点通信。任何两个节点之间的通信可以包括传输序列化消息。序列化消息可以遵循传输控制协议(TCP)或任何其他合适的消息传递协议。
分布式数据库系统中的每个节点都有唯一标识符(例如，字典id)，并在分布式数据库系统中通过唯一的标识符存储每个其他节点的列表。每个节点使用这个列表来跟踪分布式数据库系统中的每个事务引擎节点和存储管理器节点的状态。此外，每个节点可以跟踪每个数据库事务以及跟踪每个数据库记录的位置(即哪些节点存储哪些数据片段)。节点可以将该节点和事务信息存储在主目录的相应副本中，该主目录包含关于分布式数据库系统的元数据并且跨数据库中的所有节点进行复制。当新节点加入分布式数据库系统时，其从另一个节点(称为条目节点)接收主目录的副本。
跟踪数据库事务和位置数据库片段有助于分布式数据库系统维护原子性、一致性、隔离性和持久性(通常称为ACID属性)，以确保分布式数据库中数据的准确性、完整性和整体性。
网络故障与故障检测
分布式数据库系统中的每个节点以频繁的间隔向分布式数据库系统中的每个其他节点传输“心跳”消息。例如，每个节点每秒或每几秒钟向每个其他节点发送心跳消息。(可选地，接收心跳消息的节点可以向传输心跳消息的节点传输确认消息。)如果通信没有中断，分布式数据库系统中的每个节点继续直接向分布式数据库系统中的每个其他节点发送心跳消息并且直接从分布式数据库系统中的每个其他节点接收心跳消息。但是，网络故障可能会中断此类通信。检测到通信中断(例如，在预定时间量内未从另一个节点接收到心跳消息)的节点启动故障解决协议以解决网络故障。
解决网络故障
在此处介绍的故障解决过程中，分布式数据库中的节点响应于网络故障而重新组合自己，并且如果它们不是具有最低字典id排序的多数大小的最大全连接节点组的一部分，则它们自己发生故障。如果最大全连接组包括的节点少于分布式数据库系统中的节点的一半，那么所有节点可能自己发生故障。故障断开连接的节点或部分连接的节点降低了部分或全部数据库可能变得无效的可能性。故障解决过程可以以无领导方式执行，而不会阻塞或中止正在进行的数据库事务。
图1示出了解决网络故障的过程100。分布式数据库系统中的任何节点都可以响应于检测到网络故障(例如，在预定时间段内未能从另一节点接收心跳消息)启动该过程100。在102处，第一节点检测网络故障并通过创建“可疑节点”列表(即第一节点怀疑已发生故障的节点)来启动故障解决过程100。例如，第一节点的可疑列表是满足以下一个或两个条件的节点列表：(a)第一节点在预定的超时间隔(例如，pingTimeout秒)内没有从那些节点收到心跳消息；以及(b)操作系统关闭了第一节点和其他节点之间的连接。此时，如果第一节点的可疑列表包括分布式数据库系统中的每个其他节点，则第一节点自己可能发生故障以至少部分解决网络故障。
在104处，第一节点(即，发起过程100的节点)向其邻居节点广播其可疑节点列表，这些节点是在网络故障之后第一节点仍可直接与之通信的节点。(当没有网络故障时，每个节点都是分布式数据库中的每个其他节点的邻居。)邻居节点接收这个可疑列表并将它们自己的可疑列表广播给它们的邻居。取决于网络故障的性质，邻居节点的可疑列表可以与第一节点的可疑列表相同或不同。
在106处，第一节点从其邻居节点接收可疑列表并使用它们和其自己的可疑列表来构建连接图。连接图显示了第一节点实际上直接连接到分布式数据库系统中的哪些节点(即，哪些节点实际上是第一节点的邻居节点)。其他节点也构建连接图。根据网络故障的性质，这些连接图可能与第一节点的连接图相同或不同。类似地，每个连接图可能是相应节点的可疑列表的补充。
每个节点使用其连接图来识别在网络故障后仍相互直接连接的节点组。每组直接连接的节点称为“全连接组件”。在全连接组件中，每个节点在网络故障后继续与全连接组件内的每个其他节点通信。一旦每个节点识别出分布式数据库系统内的全连接组件，其就确定其是否是“获胜全连接组件”的一部分(110)。如果其不是全连接组件的一部分，则每个节点自己发生故障以解决网络故障(112)。如果其是获胜全连接组件的一部分，则其继续运行(114)。
获胜全连接组件可以但不必包括数据库中的所有数据(例如，其不必包括存储管理器节点)。该过程不考虑形成获胜全连接组件的节点的类型。(但在某些情况下，可以修改该过程以在确定获胜全连接组件时注意全连接组件中的节点的类型。)如果获胜全连接组件不包括分布式数据库中的所有数据，则用户可以进行干预以确保正确操作。
每个节点可以确定其是否是获胜全连接组件的一部分，如下所示。首先，每个节点可以基于其连接图确定其是否是全连接组件的一部分。如果没有，其自己发生故障。但是如果节点是全连接组件(或者可能多于一个全连接组件)的一部分，其基于其连接图确定其全连接组件的大小。如果节点确定其不是最大的全连接组件的一部分(基于其连接图和每个节点存储的关于分布式数据库系统中其他节点的信息)，其自己发生故障(112)。如果节点是最大的全连接组件的一部分，并且该全连接组件在网络故障之前包含分布式数据库系统中节点总数的一半以上，则该节点保持运行(114)。该全连接组件被称为“获胜全连接组件”，因为在故障解决过程100结束时，其包含分布式数据库系统中的所有运行节点。
如果节点确定有两个或多个大小相同的全连接组件，每个组件都拥有分布式数据库中一半以上的节点，并且比所有其他全连接组件大，则其实现了决胜过程以识别获胜全连接组件。决胜过程可以包括通过节点的唯一标识符对每个全连接组件中的节点进行排序。一旦对唯一标识符进行排序，节点就基于唯一标识符的字典顺序选择获胜全连接组件。例如，节点可以选择具有公共前缀之后的最低节点id的全连接组件作为获胜全连接组件。
相对于其他故障解决过程的技术优势
在解决分布式数据库中的故障方面，图1所示的故障解决过程与其他过程相比具有若干区别和优势。首先，与阻塞过程不同，图1中所示的故障解决过程在网络故障后驱逐分布式数据库中的一个或多个节点以恢复完整的全连接。阻塞是不可取的，因为其可能回滚对分布式数据库中的数据所做的更新。与其他方法不同，本文描述的过程不包括任何类型的阻塞机制。
此外，图1所示的故障解决过程不需要或不使用领导节点。相反，用于解决分布式数据库中的故障的其他方法实现了强大的领导模型。基本上，这种方法使用领导节点来做出故障解决决策。与这种基于领导者的方法不同，本文描述的过程没有做出故障解决决策的领导节点。取而代之的是，如上文参考图1所描述的，任何节点都可以启动故障解决过程，并且每个节点决定是自己发生故障还是作为过程的一部分保持运行，而无需来自领导节点的指令。
与阻塞和基于领导者的故障解决过程不同，这里公开的非阻塞、无领导者的故障解决过程可以以一致的方式处理部分连接网络故障。在部分连接网络故障中，分布式数据库系统内的网络分区可以导致节点或一组节点仅与分布式数据库系统中的节点子集进行通信。为了处理部分连接的情况，其他进程应用轮换领导模型，使领导者和通知者使用显式消息确认。在某些情况下，这导致领导权在经历通信中断的节点之间不断转换，从而可能延迟(可能无限期地)网络故障的解决。
不同的网络故障情况
过程100不使两个或更多不相交的节点组(即，不同的全连接组件)在网络故障事件之后保持运行。为了避免琐碎的解决方案(例如，使所有节点发生故障)，过程100在可能的情况下允许单组节点保持运行。
此外，如果用户选择关闭分布式数据库系统中一半或更多的幸存节点，则过程100可能不必导致其余节点发生故障。除了链路故障之外，过程100还可处理慢速链路(即，连接性慢的两个或多个节点之间的通信路径)。换句话说，过程100以相同的方式处理慢速链路和链路故障。
图2至图10示出了可以使用图1中的过程100解决的不同类型的网络故障。
情况A：图2示出了经典故障情况，其中网络分区事件将分布式数据库系统200分成两个或更多不相交的全连接节点组。如图2左侧所示，分布式数据库系统200包括三个事务引擎节点TE1、TE2和TE3以及两个存储管理器节点SM1和SM2，它们都相互连接。这些节点经由相应通信链路212a-212j相互通信：TE1经由链路212a与TE2通信，TE2经由链路212d与TE3通信，TE3经由链路212e与SM2通信，SM2经由链路212f与SM1通信，TE2经由链路212b与SM1通信，TE2经由链路212c与SM1通信，TE1经由链路212h与SM2通信，TE3经由链路212j与SM1通信，并且TE2经由链路212i与SM2通信。
在图2的中间，网络分区将合唱(chorus)分成两个不相交的节点组(两个完全连接组件202'和202”)。(合唱或合唱组是分布式数据库系统中所有节点的集合。)在这种情况下，第一全连接组件202'包括{TE1,TE2,SM1}，并且第二全连接组件202”包括{TE3,SM2}。过程100然后决定第一全连接组件202'是获胜全连接组件204'，因为其大于第二全连接组件202”并且包括分布式数据库200中一半以上的节点。获胜全连接组件204'中的节点{TE1,TE2,SM1}保持运行，并且节点TE3和SM2响应于发现它们不在获胜全连接组件204'中而自己发生故障。
情况B：图3至图8示出了部分连接的不同示例。在这些示例中的每一个中，网络分区或(双向)链路故障导致节点或一组节点仅与分布式数据库系统中的其他节点的子集进行通信。在部分连接的情况下，节点之间的连接不满足传递性——例如，节点TE1可能能够直接与节点TE2通信，节点TE2可以直接与节点SM1通信，但节点SM1不能直接与节点TE1通信。
示例B1：图3示出了具有三个节点TE1、TE2和SM1的分布式数据库系统300。如图3所示，三个节点TE1、TE2和SM1形成合唱组，其中TE1经由链路212a与TE2通信，TE2经由链路212b与SM1通信，并且SM1经由链路212c与TE1通信。TE1和TE2之间的链路212a(或TE1和TE2的数据中心之间的网络分区，假设TE1和TE2在不同的数据中心)的故障创建了两个全连接组件202'{SM1,TE1}和202”{SM1,TE2}，其中节点TE1和TE2部分连接。由于全连接组件202'和202”具有相同的尺寸，并具有在链路故障之前运行的一半以上的节点数，节点实现决胜过程，诸如如上文所讨论的字典顺序，以确定获胜全连接组件204'。在图3中，{SM1,TE1}是获胜全连接组件204'(由诸如字典顺序的决胜过程决定)，因此SM1和TE1保持运行，并且TE2自己发生故障。
示例B2：图4示出了具有五个节点TE1、TE2、TE3、SM1和SM2的合唱组的分布式数据库系统400。在此示例中，发生了两个链路故障：一个在SM1和SM2之间(链路212f)，并且另一个在SM2和TE3之间(链路212e)。这些故障产生全连接组件402'{TE1,TE2,TE3,SM1}和402”{TE1,TE2,SM2}，其中节点SM2部分地连接到仍然直接相互连接的其他节点。第一全连接组件402'{TE1,TE2,TE3,SM1}是获胜全连接组件404'，因为其包括一半以上的节点并且大于另一个获胜全连接组件402”。节点SM2发生故障，并且其他节点保持运行。
示例B3：图5示出了五节点分布式数据库系统500，其具有经历四个链路故障的五个节点TE1、TE2、TE3、SM1和SM2的合唱组。在此示例中，四个链路故障发生在TE1和SM1之间(链路212c)、TE1和SM2之间(链路212h)、TE2和TE3之间(链路212g)以及TE3和SM1之间(链路212j)。这些故障产生若干全连接组件，但只有一个具有至少三个节点：{TE2,SM1,SM2}，显示在右侧。节点TE1和TE3保持部分连接到分布式数据库，但不能直接与分布式数据库中的每个其他节点通信。结果，节点TE1和TE3发生故障，从而使{TE2,SM1,SM2}作为获胜全连接组件404'。
图6示出了图5的部分连接情况如何不能使用轮换领导模型方法解决。如图6所示，五个节点TE1、TE2、TE3、SM1和SM2在步骤1(左)下形成组。在步骤1中，所有这些节点可以不间断地相互通信。但是，如步骤2(右)所示，TE1和SM1之间(链路212c)、TE1和SM2之间(链路212h)、TE2和TE3之间(链路212g)以及TE3和SM1之间(链路212j)的通信链路出现故障。这些故障中断TE1和SM1之间、TE1和SM2之间、TE2和TE3之间以及TE3和SM1之间的直接通信。
SM1是网络故障之前的当前领导者。基于链路故障后的轮换领导方法，SM1继续假定其是领导者，因为其从TE2和SM2接收心跳消息。由于TE1没有从SM1接收到心跳消息而导致TE1和SM1之间(链路212c)的链路故障，TE1将领导权轮换给TE2。以类似的方式，由于TE3和SM1之间(链路212j)的链路故障，TE3将领导权轮换给TE1。因此，SM1、TE2和TE1快速连续取得领导权(不一定按此顺序)，但TE1未连接到SM1或SM2，因此其甚至不知道SM1是否连接到SM2。这种轮换领导权使得解决故障变得困难。
从概念上讲，如上所示，很难使基于集中式领导者的解决方案很好地处理部分连接情况，因为领导节点可能不连接到所有其他节点(因此领导者可能不知道所有其他节点的连接信息)。然而，本文描述的无领导者故障解决过程以可靠的方式处理所有这些部分连接情况，因此是对基于领导者的故障解决方法的改进。
示例B4：图7示出了具有五个节点的合唱组的分布式数据库系统700，所述五个节点具有三个链路故障：一个在TE1和SM1之间(链路212c)，另一个在TE2和TE3之间(链路212g)，并且另一个在SM1和TE3之间(链路212j)。这些故障产生全连接组件{TE1,TE2,SM2}、{TE2,SM1,SM2}和{TE1,SM2,TE3}；节点TE1和TE2部分连接。这三个全连接组件中的每一个都包括链路故障之前的合唱组中节点数量的一半以上。此外，这三个全连接多数组具有相同的大小。因此，节点实施决胜过程，诸如字典排序，以识别获胜全连接组件704'。在此示例中，{TE2,SM1,SM2}是获胜全连接组件704'(由决胜过程决定)。因此，节点TE1和TE3自己发生故障以解决网络故障。
示例B5：图8示出了具有五个节点TE1、TE2、TE3、SM1和SM2的合唱组的分布式数据库系统800。在此示例中，发生了五个链路故障：TE1和SM1之间(链路212c)、TE1和SM2之间(链路212h)、TE2和TE3之间(链路212g)、TE2和SM2之间(链路212i)以及TE3和SM1之间(链路212j)。如图8所示，在这些故障之后有五个完全连接的节点组，每个节点组为两个节点的大小。这少于链路故障前合唱组中节点数的一半以上。因此，由于链路故障后没有全连接多数组，因此所有节点自己发生故障。
情况C：图9示出了部分连接的特殊情况，其中(单向)链路故障允许节点或一组节点在一个方向而不是另一个方向上与其他节点的子集进行通信。如图9所示，分布式数据库系统900中的三个节点TE1、TE2和SM1形成合唱组。然而，TE1和TE2之间(链路212a”)恰好存在单向链路故障，使得TE2可以向TE1(链路212a')发送消息，而TE1不能向TE2(链路212a”)发送消息。这种单向链路故障(类似于TE1和TE2之间的双向链路故障)创建了全连接组件902’{TE1,SM1}和902”{TE2,SM1}。由于两组全连接组件大小相同，并且包括超过一半的在链路故障之前运行的节点(即，全部3个节点中的2个)，节点实现了决胜过程以确定获胜全连接组件904'。在此示例中，{TE1,SM1}是获胜全连接组件904'(由上面呈现的决胜过程决定)。因此，节点TE1和SM1保持运行，并且节点TE2自己发生故障。
情况D：过程100还确保分布式数据库系统不应该在成员资格改变期间由于网络故障而分成多个多数组。成员资格改变是指新节点加入分布式数据库系统或分布式数据库系统的现有节点离开分布式数据库系统。图10示出了情况D的示例。在此示例中，合唱1000以三个节点TE1、SM1和SM2开始。两个节点TE2和TE3尝试加入合唱1000。在它们的加入过程中，发生网络分区，从而将分布式数据库分离成全连接组件1002'{TE2,TE3,TE1}和1002”{SM1,SM2}。两个组可保持运行，因为组成员{TE2,TE3,TE1}认为它们是合唱{TE2,TE3,TE1,SM1,SM2}的一部分并因此形成多数，并且组成员{SM1,SM2}认为它们是合唱{TE1,SM1,SM2}的一部分并且它们也因此形成多数。过程100确保只有一组保持运行。换句话说，过程100确保{TE2,TE3,TE1}和{SM1,SM2}两者不同时保持运行。
收集和共享有关可疑节点的信息
这里公开的故障解决过程(例如，过程100)是无领导者过程。响应于网络故障事件，每个节点识别其可疑列表，与其他节点交换连接信息(其自己的和可选的其他节点的连接信息)，然后做出故障解决决策。该过程使节点通过以下方式通信和交换连接信息：在过程的通信阶段结束时，每个节点应该具有有关其分区中其他节点的充分连接信息，以确保分区内的所有节点达成相同的故障解决决策。在协议进行过程中发生的任何新的网络故障事件均导致所有节点重新开始该协议。
通常，本发明的故障解决过程可以包括两个阶段：阶段1，在此期间，每个节点收集有关其他节点的可疑列表/连接的信息；以及阶段2，在此期间，每个节点基于其在阶段1期间收集的信息做出故障解决决策(例如，自己发生故障)。
在阶段1期间，每个节点最多参与两轮协调广播。这些可疑列表的协调广播包括在分区内的节点之间交换连接信息/可疑列表。在上述情况A中，每个节点进行一次协调广播。在上述情况B和C中，每个节点进行两次协调广播。在情况A、B和C下，两轮协调广播足以使所有节点就组成员资格变化达成一致。
为了使这个过程直观易懂，首先，下面介绍了未优化的连接信息交换过程，该过程涉及(n-1)轮广播，其中n是阶段1期间合唱中的节点数量。然后下面介绍优化版本的连接信息交换过程，其中每个节点最多参与两轮广播，而不管合唱中的节点数量如何。
为了清晰和简单起见，我们假设在连接信息交换过程正在进行时，没有新的网络故障事件，没有新节点加入，并且没有合唱成员节点故障。然而，本文描述的连接信息交换过程也可以扩展到所有这些事件。在介绍核心流程之后，在后面的部分中提出这些假设和/或限制。
未优化的可疑节点列表分布
首先，合唱包括n个完全连接的节点。假设发生了网络故障事件。每个节点通过以下协议来解决网络故障事件。
每个节点准备其可疑列表(可疑列表可以是空列表，如果节点(或至少认为其)在网络故障事件之后完全连接到所有其他节点，就会发生这种情况)。
阶段1：每个节点进行(n-1)轮协调广播以收集有关其他节点的可疑列表/连接的信息。在第1轮中，每个节点将其可疑列表发送给其邻居节点，并等待直到其收到其邻居节点的可疑列表。在第2轮到(n-1)轮中，每个节点将其在上一轮收到的其他节点的可疑列表发送给其邻居，并等待直到其从其邻居接收到此类信息。
阶段2：每个节点现在已经收到了其分区中所有其他节点的连接信息(由于合唱包括n个节点，节点通过上述方式进行(n-1)轮广播确保每个节点获得其分区中所有其他节点的连接信息)。每个节点为其分区准备连接图，并找到具有最大尺寸(或最大集团)的连接图的全连接组件。如果存在多于一个此类全连接组件，则节点选择一个全连接组件作为获胜全连接组件，这由决胜过程决定(例如，基于全连接组件中的节点的唯一标识符的字典顺序)。如果获胜全连接组件的大小至少为(n/2+1)并且如果该节点是获胜全连接组件的成员，则该节点决定保持运行(并退出协议)；否则，该节点自己发生故障。
以下是使节点在最多两轮广播后就成员资格改变达成一致的优化。
优化1：这是一种适用于情况A(在上述部分中)涵盖的场景的优化。这是基于以下观察：如果网络故障事件将数据库划分为完全连接节点的不相交组，那么组/分区内的所有节点的可疑列表将是相同的。例如，考虑图2。在图2中，节点TE1、TE2和SM1怀疑TE3和SM2，并且节点TE3和SM2怀疑TE1、TE2和SM1。在阶段1期间的第1轮协调广播之后，如果节点的可疑列表与其所有邻居的可疑列表匹配，则该节点可以推断：(a)其是全连接组件的一部分，并且(b)其可以识别全连接组件的大小(等于合唱大小减去其可疑列表的大小)。因此，在阶段1期间的第1轮广播之后，所有节点可以就成员资格改变达成一致。
优化2：这是一种主要适用于上述情况B和C以及部分适用于情况A的优化。在未优化的过程中，所有节点参与(n-1)轮协调广播。这使每个节点知道其分区中所有其他节点的连接信息。但是，每个节点真的需要知道其分区中所有其他节点的连接信息才能做出最佳故障解决决策吗？考虑基于网络故障事件后节点的可疑列表将节点分为两类：类别(M)包括怀疑少于n/2个其他节点的节点；并且类别(N)包括怀疑多于n/2个节点的节点。怀疑多于n/2个的节点可能自己立即发生故障而不是广播可疑列表，因为它们不能成为获胜全连接组件的一部分。
例如，考虑图11。网络故障事件后，节点TE2、SM1和SM2归入类别(M)，并且节点TE1和TE3归入类别(N)。考虑类别(M)：类别(M)中的节点需要知道类别(M)中其他节点的连接信息才能做出最佳故障解决决策吗？是的。这是因为类别(M)中的节点可以与类别(M)中的其他节点一起形成大小至少为(n/2+1)的全连接组件，并且了解类别(M)中其他节点的连接信息有助于识别：(a)其是否是大小至少为(n/2+1)的全连接组件的一部分，(b)所有大小至少为(n/2+1)的全连接组件，以及(c)其是否是获胜全连接组件的一部分。类别(M)中的节点需要知道类别(N)中节点的连接信息才能做出最佳故障解决决策吗？不。这是因为类别(M)中的节点永远不能与类别(N)中的节点一起形成大小至少为(n/2+1)的全连接组件，这反过来是因为类别(N)中的节点怀疑多于(n/2)个其他节点。
现在考虑类别(N)：类别(N)中的节点需要知道类别(M)和类别(N)中的节点的连接信息才能做出最佳故障解决决策吗？不。这是因为类别(N)中的节点怀疑多于(n/2)个其他节点并且因此永远不能与任何其他节点形成大小至少为(n/2+1)的全连接组件。做出所有其他节点的连接信息将帮助类别(N)中的节点知道哪些其他节点将保持运行，但不会改变该节点不能与其他节点形成大小至少为(n/2+1)的全连接组件的事实。
因此，足够多轮的协调广播使类别(M)中的每个节点都知道类别(M)中每个其他节点的连接信息，以便分布式数据库系统中的所有节点就最佳故障解决结果达成一致就足够了。因此，作为对未优化的过程的修改，优化的过程在阶段1开始之前从类别(N)中的故障节点开始，但同时将它们保留为合唱的成员。换句话说，类别(M)中的节点将类别(N)中的节点保留在其节点列表中，直到阶段2，即使类别(N)中的节点在阶段1开始之前自己发生故障。将故障节点(在阶段1开始之前可发生故障的类别(N)的节点)保留为合唱的成员直到阶段2确保正确性，即，故障解决的结果是具有至少(n/2+1)个节点的全连接集合，其中n包括在阶段1之前作为优化发生故障的节点。(省略类别(N)节点(或任何类型的节点)可能更改n的值(组大小)和多数大小并且可以使证明结果的正确性变得更加困难。)
类别(N)中的故障节点不影响类别(M)中节点之间的连接(即类别(M)中的节点不会因为类别(N)的节点的故障而断开连接)，因为类别(M)中的任意两个节点要么直接相互连接，要么通过类别(M)的另一个节点相互连接。因此，使类别(N)节点发生故障不会影响故障解决结果的最优性。
从概念上讲，优化基本上使类别(M)的节点就故障解决结果达成共识，并使类别(N)的节点遵循该结果。通过这种优化，开始阶段1的每个节点连接到至少(n/2)个其他节点，因此连接图的直径(即，连接图中任意两个节点之间的最大距离)最大为2。因此，只需进行两轮广播即可让开始阶段1的每个节点知道开始阶段1的每个其他节点的连接。连接图的直径最大为2，因为阶段1中的每个节点连接到至少n/2个其他节点，因此任何两个节点最多被一个节点分隔。
优化的可疑节点列表分布
考虑包括n个完全连接节点的合唱。假设发生了网络故障。每个节点通过以下协议来解决网络故障。每个节点准备其可疑列表(注：可疑列表可以是空列表，如果节点(或认为其)在网络故障事件之后完全连接到所有其他节点，就会发生这种情况)。
阶段0：每个节点检查其是否怀疑多于(n-1/2)个其他节点。如果是，节点自己发生故障。(其他节点可能会在它们处于阶段1时听到此故障。如果是这样，那些节点重新开始协议并再次从阶段0开始。)
阶段1，第1轮：每个节点将其可疑列表发送给其邻居节点，并等待直到其收到其邻居节点的可疑列表。如上所述，如果节点的一个或多个邻居在阶段0中出现故障，则该节点可能会在等待其邻居的可疑列表时听到那些故障。在听到任何此类故障时，该节点将重新开始协议并再次从阶段0开始。这导致其他节点也重新开始协议。类似地，如果邻居节点重新开始协议，则节点再次从阶段0开始。此外，如上所述，此节点在此阶段不会为任何故障节点启动故障转移(即，为了确定获胜全连接组件，其将每个节点保留在其合唱中)。即使对于多轮的阶段0也是如此。
每个节点检查其可疑列表是否与其所有邻居节点的可疑列表相同。如果节点的可疑列表与其所有邻居节点的可疑列表都匹配，则表明该节点与其邻居节点完全连接。在上面的情况A(例如，图2)中覆盖了这种场景。由于开始阶段1的每个节点连接到至少(n/2)个其他节点，该节点的邻居列表大小可以是至少(n/2)(该节点与其邻居一起形成包括至少(n/2+1)个节点的组)。节点决定保持运行并退出协议。
如果节点的可疑列表与其至少一个邻居的可疑列表不匹配：则表明该节点未与其分区中的所有其他节点完全连接。上面的情况B和C涵盖了这种场景(例如，图3至图9)。此类节点无法基于第1轮中接收到的信息来决定是否保持运行。因此，其执行阶段1，第2轮。
阶段1，第2轮：每个节点将其在第1轮中接收到的其他节点的可疑列表发送给其邻居，并等待直到其从其邻居接收到其邻居的此类可疑列表。
阶段2：现在每个节点都接收到其分区中所有其他节点的连接信息。每个节点为其分区准备连接图，并找到具有至少(n/2+1)个节点(或大小至少为(n/2+1)的最大集团)的连接图的最大全连接组件。如果存在多于一个全连接组件(例如，如图7所示)，则节点选择一个全连接组件作为获胜全连接组件，这由决胜过程(例如，字典顺序)决定以使故障解决具有确定性。如果该节点是获胜全连接组件的成员，则该节点决定保持运行(并退出协议)；否则，该节点自己发生故障。
如果在分布式数据库系统正在解决网络事件的过程中发生了新的网络故障事件，则协议致使节点回溯、通过考虑新网络事件的影响来重新检查节点连接，然后做出故障解决决策。
除了新的网络故障事件外，分布式数据库系统中的节点在解决网络故障时也可能发生节点故障(例如，由于节点手动关闭而引起)。响应于节点故障，该协议使节点从阶段0重新开始，同时将故障节点保留为合唱的成员直到阶段2(通过不对故障节点运行故障转移，从而阻止其余节点从其节点列表移除故障节点)。如上所述，在阶段2之前将故障节点保留为合唱的成员确保了正确性，即，故障解决的结果是具有至少(n/2+1)个节点的全连接集合，其中n包括发生故障的节点，因此在阶段2之后只能有一个此类集合保持运行。
图12是示出解决网络故障的优化过程1200的流程图。每个节点遵循相同的过程，因此流程图从单个节点的角度示出过程1200。过程1200是按阶段详述的。
阶段0：初级阶段。在1202处，节点完全连接到合唱中的所有其他节点。本地或远程检测到可疑节点导致节点移动到阶段1。
阶段1：在1210处，节点等待一个ping(心跳)周期发生额外的ping(心跳)超时、准备其可疑列表、使用其接收到的任何可疑列表消息，然后进入阶段2。
阶段2：在1220处，节点检查其是否怀疑多于(n-1/2)个其他节点(其中n是合唱中的节点数量)。如果是，在1299处，节点自己发生故障。如果不是，节点检查自在阶段1准备其可疑列表以来是否有任何新的可疑节点。此外，该节点检查是否有任何邻居检测到新的可疑节点并因此重新开始了协议。每个节点可以为其运行的过程1200的每次迭代分配编号，称为protocolIterationNumber。每个节点在其发送的可疑列表消息中设置这个编号，并将其本地protocolIterationNumber与其从其他节点接收到的可疑列表中的protocolIterationNumber进行比较。如果节点确定其protocolIterationNumber小于邻居的protocolIterationNumber，则其确定其邻居已重新开始进程并返回阶段1。否则，该节点进入阶段3。(如果节点的protocolIterationNumber大于邻居的protocolIterationNumber，则节点重新开始了协议(可能是因为发现了新的可疑节点)，这应该会导致邻居也重新开始协议。)
阶段3：在1230处，节点向其邻居节点广播其第1轮可疑列表。节点在1232处等待第1轮可疑列表消息时，可能会检测到新的可疑节点，或者可能会听到其一个或多个邻居检测到新的可疑节点。如果是，则节点停止等待任何更多响应，并返回到阶段1。在1234处，节点从其所有邻居节点接收第1轮可疑列表消息。如果节点没有及时(例如，在预定时间段内)从其任何邻居接收到响应，则在1236处，节点将此类邻居标记为可疑节点并返回阶段1。如果节点接收到具有比其protocolIterationNumber更高的protocolIterationNumber的第1轮可疑列表，则在1238处，节点返回到阶段1的开始。在接收到来自其所有邻居的第1轮响应后，节点进入阶段4。
阶段4：在1240处，如果节点的可疑列表与其所有邻居的可疑列表匹配，则该节点确定其与其邻居节点完全连接(例如，如图2中所示)。由于开始阶段3的每个节点连接到至少(n/2)个其他节点，该节点的邻居列表大小可以是至少(n/2)(即，节点和其邻居形成包括至少(n/2+1)个节点的全连接组件或组)。在1201处，节点决定保持运行、驱逐可疑节点，并退出过程1200。
如果节点的可疑列表与其至少一个邻居的可疑列表不匹配，则该节点未与其分区中的所有其他节点完全连接(例如，如图3至图9中所示)。节点无法基于其在第1轮中接收到的信息决定是继续运行还是发生故障，因此节点进入阶段5，阶段5涉及在1250处广播第2轮可疑列表消息。
阶段5：在1250处，节点向其邻居节点广播其第2轮可疑列表(包括其原始可疑节点和其邻居节点的可疑节点)，并等待直到其从其所有邻居节点接收到第2轮可疑列表消息。在1230处广播其第1轮可疑列表消息后，该节点可以随时从其他节点接收第2轮可疑列表消息。节点累积这些第2轮可疑列表消息。在1252处，如果发生新的网络故障，如果该节点从另一个节点接收到第1轮消息，或者如果该节点听到另一个节点的故障，则该节点返回阶段1。返回阶段1后，节点丢弃所有累积的第2轮可疑列表消息。但是如果另一个节点返回并发送另一条消息，那么该消息将被保留。节点基于第1轮和第2轮可疑列表消息中的protocolIterationNumber区分这两种类型的消息。换句话说，基于protocolIterationNumber的消息包括protocolIterationNumber和轮数。
在1254处，在从其所有邻居节点接收到第2轮可疑列表消息后，该节点进入阶段6。如果发生新的网络事件或如果该节点在该节点广播其第2轮可疑列表消息后听到另一个节点的故障，则故障解决决策可能不是最佳决策。至少存在两种可能的情况：在情况(a)中，节点已经从新的可疑节点或故障节点接收到第2轮消息；并且在情况(b)中，节点没有从新的可疑节点或故障节点接收到第2轮消息。
在情况(a)中，节点可以移动到阶段6、对当前网络事件进行故障解决，然后通过重新开始协议来处理新的网络事件，或者回到阶段1(不解决当前网络事件)，然后重新开始过程1200。(这将解决当前和新的网络故障两者)。在情况(b)中，节点没有从新的可疑节点或故障节点接收到第2轮消息，因此该节点返回阶段1。但不能保证其他节点在完成阶段6之前也将返回阶段1(因为它们可能已经从新的可疑节点或故障节点接收到第2轮消息)。在这种情况下，故障解决的结果可能是次优的(也就是说，幸存的集合将小于其本可能的样子，但仍将只有一个幸存的集合)。但是将这个节点移动到阶段1不会阻止其他节点取得进展，因为这个节点已经发送了其第2轮消息。
阶段6：在1260处，节点为其分区准备连接图，并找到具有大小至少为(n/2+1)(或大小至少为(n/2+1)的最大集团)的连接图的最大全连接组件。如果存在多于一个此类组件，则节点从其中选择一个作为获胜全连接组件，这由决胜过程决定。如果该节点是获胜全连接组件的成员，则在1201处，该节点决定保持运行并驱逐不属于获胜全连接组件的节点。如果不是，在1299处，节点自己发生故障。
协议迭代编号
如上所述，分布式数据库系统中的任何节点都可以响应于检测到一个或多个可疑节点而启动故障解决协议(例如，图12中的过程1200)。并且在故障解决协议执行期间发生的任何新的网络故障事件都触发协议的重新开始。为了使节点能够检测它们收到的可疑列表消息(无论是第1轮还是第2轮)是属于协议的当前调用还是由于协议的重新开始而导致的后续调用(如果是重新开始了协议的节点，甚至是协议的先前调用)，节点将称为protocolIterationNumber的编号与故障解决协议的每次调用相关联。
每个节点维护其本地protocolIterationNumber并在其发送的可疑列表消息中设置该编号，并且每个节点将其本地protocolIterationNumber与其接收的可疑列表消息中的protocolIterationNumber进行比较。如果编号匹配，则节点推断其接收到的可疑列表消息对应于协议的当前调用。如果其接收到的可疑列表消息中的protocolIterationNumber大于其自己的protocolIterationNumber，则节点推断发送方已经启动了协议的重新开始(并因此重新开始了协议)。如果其收到的可疑列表消息中的protocolIterationNumber小于其自己的protocolIterationNumber，则节点推断发送方仍在运行协议的前一次迭代，因此忽略该消息。
每个节点可以通过以下方式维护其本地protocolIterationNumber：
(a)在数据库初始化期间和数据库重新开始期间，ProtocolIterationNumber在第一节点上设置为零。
(b)将ProtocolIterationNumber序列化为主目录的一部分，并且加入分布式数据库系统的新节点在获取主目录时从主目录主席接收当前的protocolIterationNumber。新节点在加入分布式数据库系统时接收主目录。通过在主目录中存储当前protocolIterationNumber，当前protocolIterationNumber可用于新节点。
(c)如果节点没有怀疑任何节点、已经检测到可疑节点、没有从其他节点接收到任何可疑列表消息，并且正在调用故障解决协议，则该节点递增其protocolIterationNumber。
(d)如果节点没有怀疑任何节点、已经检测到可疑节点、已经从其他节点接收到一个或多个可疑列表消息，并且正在调用故障解决协议，则该节点将其protocolIterationNumber设置为其接收到的可疑列表消息中的最大protocolIterationNumber。
(e)如果节点尚未检测到可疑节点、已经从其他节点接收到一个或多个可疑列表消息，并且正在调用故障解决协议，则该节点将其protocolIterationNumber设置为其从其他节点接收到的可疑列表消息中的最大protocolIterationNumber。
(f)如果节点正在运行故障解决协议、尚未接收到具有高于其本地编号的protocolIterationNumber的可疑列表消息，并且检测到新的网络故障事件，则其递增其protocolIterationNumber(并重新开始协议)。
(g)如果节点正在运行故障解决协议、已经接收到具有高于其本地编号的protocolIterationNumber的可疑列表消息，并且检测到新的网络故障事件，则其将其本地protocolIterationNumber设置为其接收到的可疑列表消息中的编号(并重新开始协议)。
(h)如果节点正在运行故障解决协议、已经接收到具有高于其本地编号的protocolIterationNumber的可疑列表消息，并且尚未检测到新的网络故障事件，则其将其本地protocolIterationNumber设置为其接收到的可疑列表消息中的编号(并重新开始协议)。
(i)如果节点正在运行故障解决协议并接收到具有低于其本地编号的protocolIterationNumber的可疑列表消息，则该节点忽略该消息。
这些要点可以总结如下：
(A)在数据库初始化期间和数据库重新开始期间，ProtocolIterationNumber在第一节点上设置为零。
(B)将ProtocolIterationNumber序列化为主目录的一部分，并且加入数据库的新节点在获取主目录时从主目录主席接收当前的protocolIterationNumber。
(C)如果节点正在调用故障解决协议(或者因为其已经检测到可疑节点和/或其从其他节点接收到可疑列表消息)，则该节点检查其是否接收到具有高于其本地protocolIterationNumber的protocolIterationNumber的可疑列表消息。如果是，节点将其本地protocolIterationNumber设置为其接收到的可疑列表消息中的最大protocolIterationNumber，否则其递增其protocolIterationNumber。
处理单向链路故障
可以通过将诸如上述情况D(图10)的单向链路故障作为双向链路故障处理(即，通过使故障链路两侧的节点相互怀疑)来解决单向链路故障。例如，考虑分布式数据库系统中的两个节点，即节点A和节点B。假设节点A可以向节点B发送消息，但节点B不能向节点A发送消息。由于A可以向节点B发送ping消息但不从节点B接收任何确认消息，节点A开始怀疑节点B。此时，节点B还没有怀疑节点A。但是，由于节点A开始怀疑节点B，其停止向节点B发送ping消息。这导致节点B怀疑节点A，从而将单向链路故障转换为双向链路故障。
在本文描述的过程中，仅当节点已确认先前的MsgPing消息时，该节点才发送MsgPing消息(例如，ping消息)并为特定节点设置Node::lastPingTime。这确保了单向链路故障导致链路两侧的节点相互怀疑。因此，上述协议可以解决单向链路故障或单向和双向混合链路故障。
合唱成员资格改变
如果在新节点(或一组新节点)正在加入合唱的过程中发生网络故障事件，则该过程应确保合唱不会被分成多个多数组。在图10，例如网络分区将合唱分成多数组{SM1,SM2}和少数组{TE1}。但少数组{TE1}与新节点{TE2,TE3}一起形成多数组{TE1,TE2,TE3}，从而导致两个“多数”组{TE1,TE2,TE3}和{SM1,SM2}。
解决与将新节点加入合唱相关联的问题的一种方法是，如果在新节点加入合唱的过程中发生网络故障事件，则使新节点发生故障。这可以防止当前合唱中的少数节点集与新节点形成多数组。在图10，新节点TE2和TE3(仍在加入合唱的过程中)可以发生故障，这导致TE1也发生故障，从而使数据库只有一个多数组{SM1,SM2}。在这个过程中，可以同时加入合唱的节点数量没有限制。然而，由于新节点发生故障并且当前合唱中的某些节点可能知道新节点，因此此过程可能会影响系统的可用性(取决于节点数量、奇数或偶数、在当前合唱中、尝试加入合唱的节点数量、在网络故障时知道新节点的合唱中的节点数量等)。
这个过程还可以借助请求分布式数据库中的数据片段的过程(发起者发送可用片段、对等点向发起者发送确认，以及发起者向请求者发送完整数据)以使当前合唱成员同意新节点加入合唱。该过程涉及对图12中的故障解决过程1200的以下改变以使节点在节点加入过程中就合唱大小达成一致：
在第1轮和第2轮广播期间，节点交换其完整的连接信息(即，它们的邻居节点列表及其可疑节点列表)。响应于接收到第1轮/第2轮消息，节点将其可疑和邻居节点列表与其邻居的可疑和邻居节点列表进行比较。如果节点发现其邻居知道其不知道的nj个节点，那么该节点将其合唱大小递增nj并重新开始该过程。
这个过程可以确保正确性：如果新节点由于网络分区而无法进入合唱中所有节点的节点列表，则该新节点在故障解决期间自己发生故障。如果n是合唱中的节点数量并且nj是尝试同时加入合唱但由于网络分区而无法进入所有n个节点的节点列表的节点数量，则nj个节点(新节点)在运行过程时自己发生故障，而不管它们的分区如何。因此，在第1轮之后，最多有n个节点检查它们是否在多数分区中，以决定是否保持运行。由于每个分区中的节点以合唱大小s(n≤s≤n+nj)运行并且在第1轮后合唱中最多有n个节点，所以最多有一个分区可以形成多数组，从而确保正确性。
但是，如果分区内的所有节点在开始故障解决协议后都将新节点添加到其节点列表呢？(请注意，节点在开始协议时，在阶段1期间准备它们的可疑和邻居节点列表，并缓存该信息)。没有节点可以检测到新节点已添加到其节点列表。结果，新节点的主目录可以转换到完成状态，从而使新节点参与故障解决过程，这可导致多个多数组。
例如，考虑这个场景：A合唱包括节点A、B和C，并且A是分布式数据库的片段主席/领导者(例如，片段“主目录”)。新节点D和E同时尝试加入合唱。节点A将D和E的可用消息发送给B和C。B和C没有从A收到ping消息、怀疑A，并开始协议。B和C(还)没有应用来自A的可用消息，所以用合唱成员{A,B,C}开始协议。然后B和C应用可用消息、向A发送确认消息，然后发生网络分裂。D和E上的主目录变得完整，因此A、D和E以合唱成员{A,B,C,D,E}开始协议。{A,D,E}和{B,C}两个组均认为它们可以形成多数组。
以下扩展可以防止此类情况：在应用可用消息后(或在主席节点的情况下，将主目录发送到新节点后)，节点重新开始故障解决协议(如果正在进行)，这导致节点使其缓存的可疑和邻居列表无效，并使用更大的合唱大小重新计算它们。
图13至图18示出了一些示例故障场景以及本发明的故障解决过程如何处理它们。
场景(A)：发生网络分区，从而将新节点和条目节点(主目录的发起者)与其余节点分开。
在图13中，SM3向TE1(主目录的主席)请求并接收主目录，并且在TE1向SM1和SM2发送MsgObjectAvailable(例如，消息，其告诉接收节点发送节点正在加入分布式数据库系统)之前发生网络分区。所有节点(包括SM3)开始解决协议。SM3和TE1怀疑节点SM1和SM2，并且SM1和SM2怀疑TE1(SM1和SM2不知道SM3)。SM3发生故障，因为其仍在加入合唱的过程中(其还没有从TE1收到完整消息)，TE1发生故障(在阶段0)，因为其怀疑合唱{SM1,SM2,SM3,TE1}中的两个节点，并且SM1和SM2保持运行，因为它们形成合唱{SM1,SM2,TE1}中的多数。
场景(B)：场景(A)的变体。发生网络分区，从而将新节点和条目节点(主目录的发起者)与其余节点分开。
在图14中，SM3向TE1(主目录的主席)请求并接收主目录，SM1从TE1接收MsgObjectAvailable，并且在SM2从TE1接收MsgObjectAvailable之前发生网络分区。SM3和TE1怀疑SM1和SM2，SM1怀疑SM3和TE1，并且SM2怀疑TE1(SM2不知道SM3)。SM3发生故障，因为其仍在加入合唱的过程中(其还没有从TE1收到最终的加入确认)，并且TE1和SM1发生故障(在阶段0)，因为它们怀疑合唱{SM1,SM2,SM3,TE1}中的两个节点。SM2最初只怀疑TE1(其小于n/2个节点数量，其中n＝3)，并且因此在阶段0没有发生故障，并向SM1发送阶段1第1轮消息，但在听到SM1发生故障后，其重新开始解决协议，然后自己发生故障。
场景(D)：发生网络分区，从而将新节点、条目节点和一些对等点与其余对等点分开。
在图15中，SM3向TE1(主目录的主席)请求并接收主目录，SM1从TE1接收MsgObjectAvailable，在SM2从TE1接收MsgObjectAvailable之前，网络分区将SM2与其余节点分开。SM3发生故障，因为其仍在加入合唱的过程中(其还没有从TE1收到完整消息)。SM2发生故障，因为其在合唱{SM1,SM2,TE1}中的少数分区中。TE1和SM1开始协议、没有从SM3收到(第1轮)响应、最终怀疑SM3，然后自己发生故障。
场景(E)：网络分区将条目节点(主目录的主席)与其余节点分开。
在图16中，SM3向TE1(主目录的主席)请求并接收主目录，SM1和SM2从TE1接收MsgObjectAvailable，并且网络分区将条目节点、TE1与其余节点分开。SM3发生故障，因为其仍在加入合唱的过程中。TE1发生故障，因为其在合唱{SM1,SM2,SM3,TE1}中的少数分区中。SM1和SM2开始故障解决过程、没有从SM3收到响应、最终怀疑SM3，然后自己发生故障。
场景(H)：网络分区将新节点、条目节点和一些对等点与其余节点分开。
在图17中，SM4向TE1(主目录的主席)请求并接收主目录，SM1和SM3从TE1接收MsgObjectAvailable，并且发生网络分区，从而将SM2与其余节点分开。SM4发生故障，因为其仍在加入合唱的过程中。SM2发生故障，因为其在合唱{SM1,SM2,SM3,TE1}中的少数分区中。TE1、SM1和SM3保持运行，因为它们形成合唱{SM1,SM2,SM3,SM4,TE1}中的多数组。在这种情况下，组{TE1,SM1,SM3}在原始合唱{TE1,SM1,SM2,SM3}中曾是多数，并且在新合唱{TE1,SM1,SM2,SM3,SM4}中仍然是多数。这允许TE1、SM1和SM3即使在SM4已添加到它们的节点列表之后也保持运行。通常，只要合唱大小从偶数节点变为奇数节点(在网络故障时有一个节点尝试加入合唱)，这种行为便发生。
场景(I)：网络分区将新节点、条目节点和一些对等点与其余节点分开。
在图18中，SM4和SM5向TE1(主目录的主席)请求并接收主目录，SM1和SM3从TE1接收用于SM4和SM5两者的MsgObjectAvailable，并且网络分区将SM2与其余节点分开。SM4和SM5发生故障，因为它们仍在加入合唱的过程中，SM2发生故障，因为其在合唱{SM1,SM2,SM3,TE1}中的少数组中。TE1、SM1和SM3也发生故障，因为它们形成合唱{SM1,SM2,SM3,SM4,SM5,TE1}中的少数组。在场景(H)中保持运行的节点TE1、SM1和SM3在这里发生故障，因为有两个节点尝试加入合唱，这导致这些节点成为新合唱中的少数组。
从概念上讲，具有n个节点的合唱可以容忍网络分区并且仍保持运行，该网络分区将最多(n-(n/2+1))个节点与合唱中的其余节点分开(或合唱中最多(n-(n/2+1))个节点同时发生故障)。如果单个节点尝试加入合唱，则合唱可以容忍(n-(n/2+1)-1)个节点的分离，并且如果n是奇数，则仍保持运行。对于单个新节点，合唱可以容忍(n-(n/2+1))个节点的分离，并且如果n是偶数，则仍保持运行。
设合唱的故障容限是合唱可以容忍而合唱中的所有节点都不发生故障的最大节点故障数量。在具有n个节点的合唱中，如果没有新的节点加入合唱，则合唱的故障容限为(n-(n/2+1))(表1中的第1列)。如果有单个节点尝试加入合唱，则合唱的容错下降到(n-(n/2+1))，如果n是奇数并保持在(n-(n/2+1))，如果n是偶数(表1中的第2列)。如果(同时)尝试加入合唱的新节点的数量大于1，则可能进一步降低合唱的故障容限。表1总结了合唱对合唱(n)中的各个数量的节点和同时尝试加入合唱的各个数量的节点(nj)的故障容限：
在下面的表1中，有nj个节点同时尝试加入合唱，并且多数分区中的至少一个节点已收到用于所有nj个节点的MsgObjectAvailable。
nj＝0 nj＝1 nj＝2 nj＝3 nj＝4 nj＝5 nj＝6 nj＝7 nj＝8
n＝3 1 0 0 0 0 0 0 0 0
n＝4 1 1 0 0 0 0 0 0 0
n＝5 2 1 1 0 0 0 0 0 0
n＝6 2 2 1 1 0 0 0 0 0
n＝7 3 2 2 1 1 0 0 0 0
n＝8 3 3 2 2 1 1 0 0 0
n＝9 4 3 3 2 2 1 1 0 0
n＝10 4 4 3 3 2 2 1 1 0
表1
场景B、D和F(如上所示)中的故障解决由n＝3和nj＝1的表条目捕获。此配置中的合唱故障容限为零，因此在新节点加入时(其中至少一个节点接收MsgObjectAvailable)网络分区(或任何节点故障)导致整个合唱发生故障。场景A没有被表1捕获，因为场景A中多数组中的节点都没有接收到MsgObjectAvailable。场景H被n＝4和nj＝1的条目捕获。场景H中的合唱故障容限是1。由于合唱在少数分区中具有单节点，因此合唱保持运行。场景I被n＝4和nj＝2的条目捕获。此配置中的合唱故障容限为零，因此节点加入时的网络分区导致整个合唱发生故障。
处理节点故障
本部分讨论在分布式数据库系统解决网络故障时处理一个或多个节点故障(或关闭)。如上所述，解决网络故障事件的过程涉及节点交换故障检测消息、节点基于交换的消息决定是否保持运行，以及决定保持运行的节点为可疑节点运行故障转移。该过程在图19中示出。
在图19中，合唱包括成员{A,B,C,D}。网络分区将{A,B,C}与D分开。节点A、B和C怀疑节点D、交换故障检测消息、决定保持运行，并为D运行故障转移。节点D怀疑节点A、B和C、开始故障解决协议，并且自己发生故障。
当启用ping(心跳)超时时，节点故障导致故障节点的邻居开始(或重新开始)故障解决协议、同意驱逐故障节点，并从合唱中驱逐故障节点。如果在分布式数据库系统在解决网络故障事件的过程中发生节点故障，则故障节点可能显示为故障节点的邻居的新可疑节点。这可以导致邻居重新开始协议。因此，在分区解决期间没有处理节点故障的特殊机制。相反，本文描述的过程确保响应于节点故障而开始/重新开始故障解决协议的节点就合唱成员资格达成一致。
在交换故障检测消息时处理节点故障
当节点在交换故障检测消息时出现故障时，其不会出现在其邻居的可疑节点列表上。结果，邻居节点将具有与上面讨论的过程相同的合唱成员资格/合唱大小。响应于检测到由节点故障引起的新可疑节点，邻居将使用更新的可疑列表重新开始故障解决过程。这个更新的可疑列表是由网络故障引起的可疑节点和故障节点的组合。如果邻居基于更新的可疑列表形成多数组，它们将保持运行。
在图20中，网络分区将{A,B,C}与D分开，并且节点C在节点交换消息时发生故障。节点A和B在怀疑C时重新开始协议。A和B发生故障，因为它们没有形成合唱{A,B,C,D}中的多数组。
运行故障转移时处理节点故障
当节点在运行故障转移(从合唱成员列表中移除故障节点)时出现故障时，其邻居可能已经开始或完成了其他可疑节点的故障转移。结果，邻居可能已经从其节点列表移除了一个或多个可疑节点，因此邻居可能不会在开始/重新开始协议时就合唱成员资格/合唱大小达成一致。
在图21中，合唱包括成员{A,B,C,D}。网络分区将{A,B,C}与D分开。节点A、B和C开始协议、交换故障检测消息，并决定保持运行。节点A、B和C开始为节点D进行故障转移。在A为D完成故障转移(并从其节点列表中移除D)并且B仍在为D运行故障转移时，节点C发生故障。这导致A怀疑C并以合唱{A,B,C}和可疑列表{C}开始节点故障过程。这也导致B以合唱{A,B,C,D}和可疑列表{C,D}开始节点故障过程。结果，A和B就合唱成员资格未达成一致。
在这种情况下，使节点就合唱大小达成一致如下：
在第1轮和第2轮广播期间，未发生故障的节点交换其完整的连接信息(即，其邻居节点列表和其可疑节点列表)。接收第1轮/第2轮消息后，节点将其可疑和邻居节点列表与其邻居的可疑和邻居节点列表进行比较。如果节点发现其邻居知道其不知道的nj个节点，那么该节点将其合唱大小递增nj并重新开始该故障解决过程。
因此，如果n是多数分区中的节点数量、f是故障节点的数量、e是为其运行故障转移的被驱逐节点的数量，如果(n-f)≥(s/2+1)，其中(n≤s≤n+e)，则该分区中的节点将保持运行。
但是，如果在节点运行故障解决过程时在节点上完成故障转移怎么办？为了增加保持合唱成员运行的机会，可以对故障解决过程进行以下更改：节点完成被驱逐节点的故障转移后，其将重新开始故障解决过程(如果正在进行)，这导致进程以较小的合唱大小运行。
为了使所有节点在节点以较小的合唱大小重新开始时就合唱大小达成一致，该过程可以进一步扩展如下：在第1轮和第2轮广播期间，节点交换其完整的连接信息(即，其邻居节点列表以及其可疑节点列表)。然后节点将其可疑和邻居节点列表与其邻居的可疑和邻居节点列表进行比较。如果节点发现其邻居知道其不知道的nj个节点，那么该节点将其合唱大小递增nj并重新开始该过程。稍后，如果节点的邻居通过从其合唱列表中移除rj个节点来重新开始该过程，则该节点将其合唱大小递减rj并重新开始该过程。
虽然这使节点就合唱大小达成一致，但只要具有可疑成员资格的节点和新节点发生故障，节点就不需要就合唱成员资格(或合唱大小)达成一致。换句话说，每个节点可以基于由该节点的主目录节点列表决定的合唱成员资格来运行故障解决过程。该过程确保所有节点都得出正确的结果，只要其成员资格未达成一致的任何节点要么在该过程开始前发生故障，要么在该过程中发生故障。
要了解为什么会这样，让n+nj继续成为合唱中的节点数量。n是主目录完整的节点的数量，并且nj是故障节点数量和将发生故障的节点数量(就像在节点故障情况下；这些节点的主目录可能会也可能不会在它们发生故障时是完整的)或一旦启动故障解决协议，将发生故障的新节点的数量(就像在节点加入的情况下；这些节点的主目录在它们发生故障时将不会完整)之和。
让s是参与故障解决协议的节点上的主目录节点列表的大小：n≤s≤n+nj。请注意，参与故障解决协议的所有节点上的s可能不同。
如果每个节点以将合唱大小设置为其自己的主目录节点列表大小运行协议，故障解决协议可以确保最多一个分区中的节点将保持运行吗？是的，因为由每个节点计算的多数组大小至少是(n/2+1)(因为n≤s≤n+nj)。如果分区内的每个节点都可以得出其属于多数组(n/2+1≤多数组大小<(n+nj)/2+1)的结论，那么该分区具有至少(n/2+1)个节点。由于只有n个节点参与协议，因此最多可以有一个此类分区。因此最多一个分区中的节点可以成功完成故障解决协议并保持运行。
并非分区内的每个节点都需要得出其属于多数全连接组件以便该分区成为获胜全连接组件的结论。分区内的节点子集，取决于它们的主目录节点列表大小，可能得出它们不在多数组中的结论。这些节点在该过程的阶段2(图12)期间发生故障，从而导致该分区内的其余节点重新开始该过程。但是，如果其余节点在该过程重新开始时可以得出它们属于多数组的结论，那么这足以使该全连接组件成为获胜全连接组件。
满足额外的绩效目标
如果用户选择关闭一半或更多的合唱成员节点，则无法触发故障检测。这是通过修改故障解决过程以免将手动关闭的节点视为可疑节点来实现的。
识别正在关闭的节点
在收到来自管理层的关闭请求时，节点广播消息节点状态(MsgNodeState)消息，指示其正在关闭(例如，具有节点状态NODE_STATE_SHUTTING_DOWN)。分布式数据库系统中的管理层是一层节点，用户可以经由该层节点与分布式数据库进行交互。管理层可以跟踪分布式数据库系统中的节点，并可以方便用户与分布式数据库系统中的节点之间的交互。例如，当用户想要关闭节点时，用户可以向管理层发出关闭命令，然后管理层将关闭消息发送到用户指定的节点。该过程依赖于至少一个合唱成员从正在关闭的节点接收此节点状态消息。
故障解决协议更改
可以对故障解决协议进行以下更改：
(a)在过程的阶段1(图12)期间，不要将已知正在关闭的节点视为可疑节点；以及
(b)让合唱成员谈论正在关闭的节点(例如，通过在过程的阶段3和4期间交换故障检测消息)。
以下是这些更改如何满足识别手动关闭节点的期望的示例：考虑具有节点A、B、C和D的合唱。假设用户几乎同时关闭节点C和D。假设只有节点A从C接收节点状态消息并且只有节点B从D接收节点状态消息。节点A以合唱{A,B,C,D}、可疑列表{D}和关闭节点列表{C}开始故障解决过程并向B发送第1轮故障检测消息。节点B以合唱{A,B,C,D}、可疑列表{C}和关闭节点列表{D}开始协议并向A发送第1轮故障检测消息。响应于接收到故障检测消息，节点A将其关闭节点列表更新为{C,D}，并将可疑列表更新为{}并重新开始协议。节点B也这样做。在第1轮之后，节点A和B基于合唱大小＝4并且可疑节点列表大小＝0得出它们处于多数分区中的结论，并保持运行。
但是，如果在节点关闭时发生网络分区或链路故障，修改后的协议将如何达成正确的过程？考虑这种场景：A合唱包括节点A、B、C、D和E。用户关闭节点E，并且几乎在同时，网络分区将{A,B}与{C,D}分开。假设所有节点都从E接收到节点状态消息。节点A以合唱{A,B,C,D,E}、可疑列表{C,D}和关闭节点列表{E}开始协议并向B发送第1轮故障检测消息。节点B也以合唱{A,B,C,D,E}、可疑列表{C,D}和关闭节点列表{E}开始协议并向A发送第1轮故障检测消息。在收到故障检测消息后，节点A和B得出它们处于多数分区中的结论(基于合唱大小＝5并且可疑节点列表大小＝2)并保持运行。节点C和D也以相同的逻辑保持运行。以下方法可以确保协议在这场景中达成正确的过程：如果在节点正在关闭时发生网络分区(或链路故障)，则将关闭节点视为可疑节点。
综上所述，如果用户关闭了一半或更多的合唱成员节点(设SD为这个节点集合)，那么这个过程将使其余的节点(设NSD为这个节点集合)保持运行，前提是满足下列条件：
(A)NSD中的至少一个节点从SD中的每个节点接收节点状态更改消息。
(B)NSD中的每个节点从SD中的至少一个节点接收节点状态消息。(这是因为如果NSD中的节点没有从SD中的任何节点接收到节点状态消息，那么该节点将怀疑SD中的所有节点，并将在阶段2期间自己发生故障，然后才从其他节点了解到关闭节点)。
(C)在NSD中的节点完成故障解决协议并将SD中的节点从合唱中驱逐之前，不会发生网络分区或链路故障。
结论
虽然本文已经描述和示出了各种发明实施方案，但是本领域的普通技术人员将很容易设想用于执行功能和/或获得本文所述结果和/或一个或多个优点的各种其他手段和/或结构，并且这些变化和/或修改中的每一个被认为在本文描述的发明实施方案的范围内。更普遍地，本领域技术人员将很容易地理解本文所述的所有参数、尺寸、材料和配置仅是示例性的，并且实际参数、尺寸、材料和/或配置将取决于本发明的教导所使用的特定的一个或多个应用。本领域技术人员仅仅使用常规试验就将认识到或者能够确定本文所描述的具体发明实施方案的很多等效方案。因此，应当理解，前述实施方案仅仅是通过示例的方式呈现的，并且在所附权利要求及其等同物的范围内，可以以不同于具体描述和要求保护的方式来实践本发明的实施方案。本公开的发明实施方案涉及本文所述的每个单独的特征、系统、制品、材料、套件和/或方法。此外，两个或更多个此类特征、系统、制品、材料、套件和/或方法的任何组合包括在本公开的发明范围内，只要这些特征、系统、制品、材料、套件和/或方法不相互矛盾。
而且，各种发明构思可以体现为一种或多种方法，其中已经提供了一个示例。作为该方法的一部分执行的动作可以以任何合适的方式进行排序。因此，可以构造实施方案，其中以与所示不同的顺序执行动作，其可以包括同时执行一些动作，即使在说明性实施方案中示为顺序动作。
如本文限定和使用的所有定义都应理解为具有字典定义、通过引用并入的文档中的定义和/或限定术语的普通含义。
除非明确相反地指出，否则本文在说明书和权利要求中使用的不定冠词“一个”和“一种”应理解为意指“至少一个”。
如本文在说明书和权利要求中使用的短语“和/或”应理解为意指这样结合的要素中的“一个或两个”，即，要素在某些情况下结合地存在而在其他情况下分离地存在。以“和/或”列出的多个要素应该以相同的方式解释，即，如此结合的要素中的“一个或多个”。可以可选地存在由“和/或”条款具体标识的要素之外的其他要素，无论那些具体识别的要素有关还是无关。因此，作为非限制性示例，对“A和/或B”的引用当与诸如“包括”的开放式语言结合使用时，在一个实施方案中可以指仅A(可选地包括除B之外的要素)；在另一个实施方案中，可以指仅B(可选地包括除A之外的要素)；在又一个实施方案中，可以指A和B两者(可选地包括其他要素)；等等。
如本文在说明书和权利要求中所使用，“或”应被理解为具有与以上所定义的“和/或”相同的含义。例如，当分开列表中的项目时，“或”或者“和/或”应被解释为是包括性的，即，包括至少一个，但也包括多于一个的多个要素或所列要素，以及可选地包括其他未列出的项目。仅明确指出相反的术语，诸如“仅一个......”或“恰好一个......”，或者当在权利要求中使用时，“由......组成”将指的是包括多个要素或所列要素中的仅一个要素。一般地，如本文所用的术语“或”当前置有排他性术语诸如“任一”、“之一”、“仅其中之一”或“恰好其中之一”时，仅应被解释为指示排他性选择(即，“一个或另一个但非两者”)。当在权利要求中使用时，“基本上由......组成”应具有在专利法领域中所使用的普通含义。
如本文在说明书和权利要求中所使用，在提及一个或多个要素的列表时，短语“至少一个”应被理解为是指从所列要素中的任何一个或多个要素中选择的至少一个要素，但不一定包括所列要素中具体列出的各个和每个要素中的至少一个，并且不排除所列要素中要素的任何组合。该定义还允许除了短语“至少一个”所指的要素列表中具体识别的要素之外可以可选地存在其他要素，无论那些具体识别的要素有关还是无关。因此，作为非限制性示例，“A和B中的至少一个”(或等效地，“A或B中的至少一个”，或等效地“A和/或B中的至少一个”)在一个实施方案中可以指至少一个，可选地包括多于一个A，而不存在B(并且可选地包括除B之外的要素)；在另一个实施方案中，可以指至少一个，可选地包括多于一个B，而不存在A(并且可选地包括除A之外的要素)；在又一个实施方案中，可以指至少一个，可选地包括多于一个A，以及至少一个，可选地包括多于一个B(并且可选地包括其他要素)；等等。
在权利要求以及以上说明书中，所有过渡性短语，诸如“包括”、“包含”、“携带”、“具有”、“含有”、“涉及”、“持有”、“由......组成”等应理解为开放式的，即意指包括但不限于。如美国专利局专利审查程序手册第2111.03节所述，仅过渡性短语“由……组成”和“基本上由……组成”应分别是封闭的或半封闭的过渡性短语。

Claims (32)

1.一种解决分布式数据库中的故障的方法，所述分布式数据库包括多个节点，所述多个节点中的每个节点直接连接到所述多个节点中的每个其他节点，所述方法包括响应于检测到所述故障：
在所述多个节点中的第一节点处：
识别所述多个节点中的可疑节点，所述可疑节点为所述多个节点中因所述故障而不再连接到所述第一节点的节点；
向所述多个节点中的邻居节点广播第一可疑节点列表，所述第一可疑节点列表包括所述可疑节点，所述邻居节点为所述多个节点中在所述故障后仍直接连接到所述第一节点的节点；
从所述邻居节点中的至少一个邻居节点接收第二可疑节点列表；
至少部分地基于所述第一可疑节点列表和所述第二可疑节点列表确定所述多个节点的连接信息；
基于所述连接信息确定所述第一节点是否在所述分布式数据库的获胜全连接组件中，其中所述获胜全连接组件包括所述多个节点中一半以上的所述节点，并且所述获胜全连接组件节点中的每个节点直接连接到所述获胜全连接组件节点中的每个其他节点；
响应于确定所述第一节点在所述多个节点的所述获胜全连接组件中，继续操作所述第一节点；以及
响应于确定所述第一节点不在所述多个节点的所述获胜全连接组件中，使所述第一节点发生故障以解决所述故障。
2.如权利要求1所述的方法，其中广播所述第一可疑节点列表包括广播协议迭代编号，所述协议迭代遍号指示由所述第一节点调用的所述方法的迭代。
3.如权利要求2所述的方法，其还包括：
将所述协议迭代编号与通过所述第二可疑节点列表接收到的协议迭代编号进行比较。
4.如权利要求2所述的方法，其还包括：
将所述协议迭代编号序列化为主目录的一部分，其中所述主目录包括所述多个节点中的所述节点的列表。
5.如权利要求1所述的方法，其中确定所述连接信息还包括在所述第一节点处：
至少部分地基于所述连接信息确定连接图；以及
从所述连接图中识别所述获胜全连接组件。
6.如权利要求5所述的方法，其中识别所述获胜全连接组件包括：
基于所述获胜全连接组件的大小和所述多个节点的大小确定所述获胜全连接组件。
7.如权利要求1所述的方法，其中确定所述第一节点是否在所述获胜全连接组件中包括在所述第一节点处基于所述连接信息识别所述获胜全连接组件。
8.如权利要求7所述的方法，其中识别所述获胜全连接组件包括：
基于所述连接信息确定所述分布式数据库的第一全连接组件，所述第一全连接组件中的每个节点直接连接到所述第一全连接组件中的每个其他节点；
基于所述连接信息确定所述分布式数据库的第二全连接组件，所述第二全连接组件与所述第一全连接组件不同，所述第二全连接组件中的每个节点直接连接到所述第二全连接组件中的每个其他节点；
确定所述第一全连接组件包括(i)比所述第二全连接组件更多的节点以及(ii)所述多个节点中的一半以上的所述节点；以及
选择所述第一全连接组件作为所述获胜全连接组件。
9.如权利要求7所述的方法，其中识别所述获胜全连接组件包括：
基于所述连接信息确定所述分布式数据库的第一全连接组件，所述第一全连接组件中的每个节点直接连接到所述第一全连接组件中的每个其他节点；
基于所述连接信息确定所述分布式数据库的第二全连接组件，所述第二全连接组件与所述第一全连接组件不同，所述第二全连接组件中的每个节点直接连接到所述第二全连接组件中的每个其他节点；
确定所述第一全连接组件包括(i)与所述第二全连接组件相同数量的节点以及(ii)所述多个节点中的一半以上的所述节点；以及
基于所述第一全连接组件和所述第二全连接组件中的所述节点的唯一标识符，选择所述第一全连接组件作为所述获胜全连接组件。
10.如权利要求1所述的方法，其还包括：
将所述第二可疑节点列表从所述第一节点传输到至少一个邻居节点。
11.如权利要求1所述的方法，其还包括：
至少部分地基于所述第二可疑节点列表更新所述第一可疑节点列表；以及
从所述第一节点向所述邻居节点广播所更新的第一可疑节点列表。
12.如权利要求1所述的方法，其中所述第一节点将所述多个节点中的少于一半的节点识别为可疑节点。
13.如权利要求1所述的方法，其还包括：
在所述多个节点中的第三节点处将所述多个节点中的一半以上的节点识别为可疑节点；以及
使所述第三节点发生故障以解决所述故障。
14.如权利要求1所述的方法，其还包括：
响应于检测到所述故障，使尝试加入所述多个节点的第三节点发生故障。
15.如权利要求1所述的方法，其中所述故障为第一故障，所述可疑节点为第一可疑节点，并且所述方法还包括在所述多个节点中的第三节点处：
检测所述分布式数据库中的第二故障；
识别所述多个节点中的第二可疑节点，所述第二可疑节点为所述多个节点中因所述第二故障而不再连接到所述第三节点的节点；
向所述第一节点广播第三可疑节点列表；以及
由所述第一节点重新开始所述方法。
16.一种用于解决分布式数据库中的故障的方法，所述分布式数据库包括多个节点，所述多个节点中的每个节点直接连接到所述多个节点中的每个其他节点，所述方法包括：
在所述多个节点中的第一节点处：
检测与所述多个节点中的第二节点的通信中断；
响应于检测到所述中断，在所述多个节点中的邻居节点之间发起相应可疑节点列表的协调广播，所述邻居节点为所述多个节点中仍直接连接到所述第一节点的节点，所述第一节点的所述可疑节点列表包括所述第二节点；
基于所述相应可疑节点列表确定连接信息；以及
至少部分地基于所述连接信息解决所述故障。
17.如权利要求16所述的方法，其还包括在每个邻居节点处：
将所述邻居节点的可疑节点列表与来自至少一个其他邻居节点的可疑节点列表进行比较；以及
至少部分地基于所述邻居节点的可疑节点列表与来自所述至少一个其他邻居节点的所述可疑节点列表的所述比较来确定所述连接信息的至少一部分。
18.如权利要求16所述的方法，其还包括：
在所述邻居节点中的每个邻居节点处，至少部分地基于所述连接信息准备连接图。
19.如权利要求18所述的方法，其中至少部分地基于所述连接图使所述第一节点自己发生故障。
20.如权利要求18所述的方法，其中所述协调广播包括由所述第一节点广播协议迭代编号，所述协议迭代编号指示所述第一节点调用的用于检测所述故障的故障解决协议。
21.一种用于解决分布式数据库中的故障的方法，所述分布式数据库包括多个节点，所述多个节点中的每个节点连接到所述多个节点中的每个其他节点，所述方法包括响应于检测到所述故障：
在所述多个节点中的第一节点处：
确定所述第一节点是否与所述多个节点中的至少一半的所述节点直接连接；
响应于确定所述第一节点与所述多个节点中的少于一半的所述节点直接连接，使所述第一节点发生故障以至少部分地解决所述故障；
响应于确定所述第一节点与所述多个节点中的至少一半的所述节点直接连接，向所述多个节点中的邻居节点广播第一可疑节点列表，所述第一可疑节点列表包括不直接连接到所述第一节点的节点，并且所述邻居节点为在所述故障后仍直接连接到所述第一节点的节点；
从所述邻居节点中的至少一个邻居节点接收第二可疑节点列表；
确定所述第一可疑节点列表是否与所述第二可疑节点列表匹配；
响应于确定所述第一可疑节点列表与所述第二可疑节点列表匹配，在所述故障的至少部分解决中保持第一节点运行；
响应于确定所述第一可疑节点列表与所述第二可疑节点列表不匹配，基于所述第一可疑节点列表和所述第二可疑节点列表向所述邻居节点广播第一更新的可疑节点列表；
从所述邻居节点中的至少一个邻居节点接收至少一个第二更新的可疑节点列表；
至少部分地基于所述第一更新的可疑节点列表和所述第二更新的可疑节点列表确定所述多个节点的连接信息；
基于所述连接信息确定所述分布式数据库的获胜全连接组件，其中所述获胜全连接组件包括所述多个节点中一半以上的所述节点，并且所述获胜全连接组件中的每个节点直接连接到所述获胜全连接组件中的每个其他节点；
确定所述第一节点是否在所述获胜全连接组件中；
响应于确定所述第一节点在所述多个节点的所述获胜全连接组件中，继续操作所述第一节点以至少部分地解决所述故障；以及
响应于确定所述第一节点不在所述多个节点的所述获胜全连接组件中，使所述第一节点发生故障以至少部分地解决所述故障。
22.一种分布式数据库系统，其包括：
多个节点，所述多个节点中的每个节点包括对应的处理器和对应的存储器，并与所述多个节点中的每个其他节点直接连接，其中在所述多个节点中的第一节点处的所述处理器被配置为通过以下方式解决所述分布式数据库系统中的故障：
识别所述多个节点中的可疑节点，所述可疑节点为所述多个节点中因所述分布式数据库系统中的故障而不再连接到所述第一节点的节点；
向所述多个节点中的邻居节点广播第一可疑节点列表，所述第一可疑节点列表包括所述可疑节点，所述邻居节点为所述多个节点中在所述故障后仍直接连接到所述第一节点的节点；
从所述邻居节点中的至少一个邻居节点接收第二可疑节点列表；
至少部分地基于所述第一可疑节点列表和所述第二可疑节点列表确定所述多个节点的连接信息；
基于所述连接信息确定所述第一节点是否在所述分布式数据库的获胜全连接组件中，其中所述获胜全连接组件包括所述多个节点中一半以上的所述节点，并且所述获胜全连接组件节点中的每个节点直接连接到所述获胜全连接组件节点中的每个其他节点；
响应于确定所述第一节点在所述多个节点的所述获胜全连接组件中，继续操作所述第一节点；以及
响应于确定所述第一节点不在所述多个节点的所述获胜全连接组件中，使所述第一节点发生故障以解决所述故障。
23.如权利要求22所述的分布式数据库系统，其中所述第一节点中的所述处理器被配置为利用所述第一可疑节点列表广播故障解决协议迭代编号。
24.如权利要求23所述的分布式数据库系统，其中所述第一节点中的所述处理器被配置为将所述协议迭代编号与通过所述第二可疑节点列表接收到的协议迭代编号进行比较。
25.如权利要求23所述的分布式数据库系统，其中所述第一节点中的所述处理器还被配置为将所述协议迭代编号序列化为主目录的一部分，其中所述主目录包括所述多个节点中的所述节点的列表。
26.如权利要求22所述的分布式数据库系统，其中所述第一节点中的所述处理器被配置为通过以下方式确定所述连接信息：
至少部分地基于所述连接信息确定连接图；以及
从所述连接图中识别所述获胜全连接组件。
27.如权利要求26所述的分布式数据库系统，其中识别所述获胜全连接组件包括：
基于所述获胜全连接组件的大小和所述多个节点的大小确定所述获胜全连接组件。
28.如权利要求22所述的分布式数据库系统，其中确定所述第一节点是否在所述获胜全连接组件中包括基于所述连接信息识别所述获胜全连接组件。
29.如权利要求28所述的分布式数据库系统，其中识别所述获胜全连接组件包括：
基于所述连接信息确定所述分布式数据库的第一全连接组件，所述第一全连接组件中的每个节点直接连接到所述第一全连接组件中的每个其他节点；
基于所述连接信息确定所述分布式数据库的第二全连接组件，所述第二全连接组件与所述第一全连接组件不同，所述第二全连接组件中的每个节点直接连接到所述第二全连接组件中的每个其他节点；
确定所述第一全连接组件包括(i)比所述第二全连接组件更多的节点以及(ii)所述多个节点中的一半以上的所述节点；以及
选择所述第一全连接组件作为所述获胜全连接组件。
30.如权利要求28所述的分布式数据库系统，其中识别所述获胜全连接组件包括：
基于所述连接信息确定所述分布式数据库的第一全连接组件，所述第一全连接组件中的每个节点直接连接到所述第一全连接组件中的每个其他节点；
基于所述连接信息确定所述分布式数据库的第二全连接组件，所述第二全连接组件与所述第一全连接组件不同，所述第二全连接组件中的每个节点直接连接到所述第二全连接组件中的每个其他节点；
确定所述第一全连接组件包括(i)与所述第二全连接组件相同数量的节点以及(ii)所述多个节点中的一半以上的所述节点；以及
基于所述第一全连接组件和所述第二全连接组件中的所述节点的唯一标识符，选择所述第一全连接组件作为所述获胜全连接组件。
31.如权利要求22所述的分布式数据库系统，其中所述第一节点处的所述处理器还被配置为通过以下方式解决所述分布式数据库系统中的所述故障：
将所述第二可疑节点列表从所述第一节点传输到至少一个邻居节点。
32.如权利要求22所述的分布式数据库系统，其中所述第一节点处的所述处理器还被配置为通过以下方式解决所述分布式数据库系统中的所述故障：
至少部分地基于所述第二可疑节点列表更新所述第一可疑节点列表；以及
从所述第一节点向所述邻居节点广播所更新的第一可疑节点列表。
CN202080015570.1A 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决 Active CN113474666B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311335678.0A CN117929911A (zh) 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962800009P 2019-02-01 2019-02-01
US62/800,009 2019-02-01
PCT/US2020/016449 WO2020160557A1 (en) 2019-02-01 2020-02-03 Node failure detection and resolution in distributed databases

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202311335678.0A Division CN117929911A (zh) 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决

Publications (2)

Publication Number Publication Date
CN113474666A CN113474666A (zh) 2021-10-01
CN113474666B true CN113474666B (zh) 2023-10-27

Family

ID=71842387

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202311335678.0A Pending CN117929911A (zh) 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决
CN202080015570.1A Active CN113474666B (zh) 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202311335678.0A Pending CN117929911A (zh) 2019-02-01 2020-02-03 分布式数据库中节点故障检测与解决

Country Status (5)

Country Link
US (3) US11500743B2 (zh)
EP (1) EP3918355A4 (zh)
JP (1) JP2022524931A (zh)
CN (2) CN117929911A (zh)
WO (1) WO2020160557A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117929911A (zh) 2019-02-01 2024-04-26 诺宝公司 分布式数据库中节点故障检测与解决
US11983170B2 (en) * 2020-10-14 2024-05-14 Oracle International Corporation System and method for transaction continuity across failures in a scale-out database

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101110757A (zh) * 2006-07-17 2008-01-23 华为技术有限公司 半分布式p2p网络流量管理方法、系统及设备
US7324438B1 (en) * 2003-02-13 2008-01-29 Cisco Technology, Inc. Technique for nondisruptively recovering from a processor failure in a multi-processor flow device
CN101273333A (zh) * 2005-04-13 2008-09-24 普罗格雷斯软件公司 容错分布式锁定管理
JP2010182287A (ja) * 2008-07-17 2010-08-19 Steven C Kays 適応型インテリジェント・デザイン
CN102253269A (zh) * 2011-06-07 2011-11-23 北京许继电气有限公司 基于云计算的电力实时数据一体化处理系统及设计方法
CN105429169A (zh) * 2015-11-06 2016-03-23 天津市静海县邦得电力工程有限公司 一种分布式电源接入控制系统及故障分析方法
CN105847278A (zh) * 2016-05-03 2016-08-10 杭州寒舍科技有限公司 一种分布式自适应传输路由协议
EP3150125A1 (en) * 2015-09-29 2017-04-05 Canon Kabushiki Kaisha Image processing apparatus, method of controlling image processing apparatus, and storage medium
CN107330519A (zh) * 2017-06-26 2017-11-07 西北工业大学 基于深度神经网络的故障定位方法
CN107835983A (zh) * 2015-04-16 2018-03-23 诺宝公司 使用一致的数据库快照在分布式数据库中进行备份和还原

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5991518A (en) 1997-01-28 1999-11-23 Tandem Computers Incorporated Method and apparatus for split-brain avoidance in a multi-processor system
US7774469B2 (en) 1999-03-26 2010-08-10 Massa Michael T Consistent cluster operational data in a server cluster using a quorum of replicas
WO2009122437A2 (en) * 2008-03-31 2009-10-08 Tata Consultancy Services Limited Security in mobile ad hoc networks
US20130089094A1 (en) * 2010-07-01 2013-04-11 Telefonaktiebolaget L M Ericsson (Publ) Method and Apparatus for Dissemination of Information Between Routers
US9501363B1 (en) 2013-03-15 2016-11-22 Nuodb, Inc. Distributed database management system with node failure detection
US10025344B2 (en) 2015-04-21 2018-07-17 The United States Of America As Represented By The Administrator Of Nasa Self-stabilizing distributed symmetric-fault tolerant synchronization protocol
US10747630B2 (en) * 2016-09-30 2020-08-18 Commvault Systems, Inc. Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including operations by a master monitor node
WO2020113214A1 (en) * 2018-11-30 2020-06-04 Futurewei Technologies, Inc. System and method to recover from link or node failure in a network
CN117929911A (zh) 2019-02-01 2024-04-26 诺宝公司 分布式数据库中节点故障检测与解决

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7324438B1 (en) * 2003-02-13 2008-01-29 Cisco Technology, Inc. Technique for nondisruptively recovering from a processor failure in a multi-processor flow device
CN101273333A (zh) * 2005-04-13 2008-09-24 普罗格雷斯软件公司 容错分布式锁定管理
CN101110757A (zh) * 2006-07-17 2008-01-23 华为技术有限公司 半分布式p2p网络流量管理方法、系统及设备
JP2010182287A (ja) * 2008-07-17 2010-08-19 Steven C Kays 適応型インテリジェント・デザイン
CN102253269A (zh) * 2011-06-07 2011-11-23 北京许继电气有限公司 基于云计算的电力实时数据一体化处理系统及设计方法
CN107835983A (zh) * 2015-04-16 2018-03-23 诺宝公司 使用一致的数据库快照在分布式数据库中进行备份和还原
EP3150125A1 (en) * 2015-09-29 2017-04-05 Canon Kabushiki Kaisha Image processing apparatus, method of controlling image processing apparatus, and storage medium
CN105429169A (zh) * 2015-11-06 2016-03-23 天津市静海县邦得电力工程有限公司 一种分布式电源接入控制系统及故障分析方法
CN105847278A (zh) * 2016-05-03 2016-08-10 杭州寒舍科技有限公司 一种分布式自适应传输路由协议
CN107330519A (zh) * 2017-06-26 2017-11-07 西北工业大学 基于深度神经网络的故障定位方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
分布式系统下大数据存储结构优化研究;冯汉超;周凯东;;河北工程大学学报(自然科学版)(第04期);第69-73页 *

Also Published As

Publication number Publication date
US11500743B2 (en) 2022-11-15
CN117929911A (zh) 2024-04-26
US11822441B2 (en) 2023-11-21
EP3918355A1 (en) 2021-12-08
EP3918355A4 (en) 2022-10-26
CN113474666A (zh) 2021-10-01
JP2022524931A (ja) 2022-05-11
US20230078926A1 (en) 2023-03-16
WO2020160557A1 (en) 2020-08-06
US20220147426A1 (en) 2022-05-12
US20240045776A1 (en) 2024-02-08

Similar Documents

Publication Publication Date Title
JP6382454B2 (ja) 分散ストレージ及びレプリケーションシステム、並びに方法
US8055711B2 (en) Non-blocking commit protocol systems and methods
US7139925B2 (en) System and method for dynamic cluster adjustment to node failures in a distributed data system
CN106170782B (zh) 用于在网络中的机器的大规模并行处理集群中创建高度可扩展的高可用性集群的系统和方法
US11822441B2 (en) Node failure detection and resolution in distributed databases
CN110535680B (zh) 一种拜占庭容错方法
JP3798661B2 (ja) クラスタ化コンピュータ・システム内のグループのメンバによって受信されたマージ要求を処理する方法
US20030204509A1 (en) System and method dynamic cluster membership in a distributed data system
JP2001521222A (ja) 分散型コンピュータ・システムにおいてクラスタ・メンバーシップを決定する方法
GB2484086A (en) Reliability and performance modes in a distributed storage system
CN110661841B (zh) 微服务架构中分布式服务发现集群的数据一致性方法
KR100466140B1 (ko) 분산 컴퓨팅 환경의 프로세싱 그룹들을 관리하는 방법, 시스템 및 기록매체
US7240088B2 (en) Node self-start in a decentralized cluster
WO2013166978A1 (zh) 多处理器系统的节点路由方法、控制器及多处理器系统
US8321543B2 (en) System and method for determining weak membership in set of computer nodes
CN106657334B (zh) 一种基于Chord网络模型的改进数据复制方法
Ahmed et al. In Search of a faster Consensus Algorithm (HSEB)
CN208299812U (zh) 一种基于ZooKeeper集群的主备切换系统
Zhao On the quorum requirement and value selection rule for Fast Paxos
Koutsopoulos Dynamics and Efficiency in Topological Self-Stabilization
CN115664915A (zh) 一种集群故障处理方法、系统、设备以及存储介质
SD et al. Trimarg: A Distributed Algorithm for the Formation of Highly Available Underlay Aware Overlay Networks of Event Brokers
Li et al. Active and Concurrent Maintenance of a Structured Peer-to-Peer Network Topology
Chettri et al. Gossip Based Gossip Based Information Dissemination in a Distributed Information Dissemination in a Distributed System
Damas et al. Performance Aspects of a Probabilistic Resource Location Algorithm

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
GR01 Patent grant
GR01 Patent grant