CN110431533B - 故障恢复的方法、设备和系统 - Google Patents

故障恢复的方法、设备和系统 Download PDF

Info

Publication number
CN110431533B
CN110431533B CN201680091858.0A CN201680091858A CN110431533B CN 110431533 B CN110431533 B CN 110431533B CN 201680091858 A CN201680091858 A CN 201680091858A CN 110431533 B CN110431533 B CN 110431533B
Authority
CN
China
Prior art keywords
node
log
log entry
leader
identification information
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
CN201680091858.0A
Other languages
English (en)
Other versions
CN110431533A (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 Technologies Co Ltd
Original Assignee
Huawei 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 Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN110431533A publication Critical patent/CN110431533A/zh
Application granted granted Critical
Publication of CN110431533B publication Critical patent/CN110431533B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • 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/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
    • 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/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • 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/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • 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/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • 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/30—Decision processes by autonomous network management units using voting and bidding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • 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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Hardware Redundancy (AREA)

Abstract

一种故障恢复的方法，应用在分布式集群系统，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中第一节点和第二节点拥有所述故障前的最新日志，第三节点没有所述最新日志，该方法包括：第一节点故障重启后，投票状态设置为不能投票，投票状态用于指示第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；第一节点接收来自第二节点的复制日志条目消息，将第一节点的投票状态设置为可以投票，第二节点为Leader。该方法有助于提高分布式集群系统的安全性。

Description

故障恢复的方法、设备和系统
技术领域
本发明实施例涉及通信领域，尤其涉及一种故障恢复的方法、设备和系统。
背景技术
分布式系统是一种组件位于联网计算机上，组件间通过传递消息来通信和协调他们动作的系统模型。组件彼此交互以便实现共同的目标。组件的并发性是分布式系统的显着特征之一。强一致性是在并发编程(例如，在分布式共享存储器，分布式事务)领域中使用的一致性模型之一。强一致性要求：所有并行进程(或节点、处理器等)以相同的顺序看到所有访问。木筏(英文：Raft)算法是一种用来保证强一致性的典型算法，该算法应用在开放日光平台(英文：OpenDaylight platform，ODL)、开放网络操作系统(英文：Open NetworkOperating System，ONOS)等业界主流分布式控制器系统中。
Raft将一致性问题分为Leader选举、日志复制和安全性保证三个子问题。Raft将来自客户端的操作指令转化为日志，先存储(用于后续系统故障后恢复时的依据)，然后根据日志进行一致性同步，然后同步成功后，服务器标记该日志为提交状态(该提交状态指示该日志在该系统中已经具有了一致性。该系统中的大于一半的服务器已经保存了该日志，就能够保证一致性)，并执行操作指令。日志被标记为提交状态的顺序即为指令被执行的顺序。Raft算法过程保证Raft集群中所有服务器的日志被提交的顺序保持一致。
然而，在包括至少三个节点的分布式系统中，当所述分布式系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题，降低了所述分布式系统的安全性。
发明内容
本发明实施例提供的故障恢复的方法、设备和系统，解决了当所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题。
为了解决上述问题，本发明实施例第一方面提供了一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，所述方法包括：所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票，所述第二节点为Leader。
通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。
在第一方面的第一种可能的实现方式中，所述第二节点为所述第一节点故障重启前的所述分布式集群系统的leader。
通过所述第一节点故障重启前的所述分布式集群系统的leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统没有新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
在第一方面的第二种可能的实现方式中，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
通过所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；所述第一节点根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了不安全隐患的问题。
结合第一方面的第二种或第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述方法还包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；所述第一节点根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
结合第一方面或第一方面的第一种至第四种任一可能的实现方式，在第一方面的第五种可能的实现方式中，所述第一节点故障重启后，投票状态设置为不能投票包括：所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
通过在确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，才将投票状态设置为不能投票，保证了在系统初始情况下，不会将所述第一节点的投票状态设置为不能投票，从而避免了错误。
结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：所述第一节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；所述第一节点启动时，所述第一节点确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述第一节点确定所述第一节点因为故障重启导致丢失了日志。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
结合第一方面的第六种可能的实现方式，在第一方面的第七种可能的实现方式中，所述方法还包括：所述第二标识信息的初始值设置为假False，用于指示所述第一节点初次启动，还未从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；当所述第一节点从所述分布式集群系统中的其它节点或者用户端设备接收到第一条日志后，将所述第二标识信息设置为真True，用于指示所述第一节点曾经接收过所述第一条日志。
通过将第二标识信息设置为False或True，本发明实施例提供了一种更简洁、具体的配置该第二标识信息的方式。
本发明实施例第二方面提供了一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，所述方法包括：所述第一节点故障重启后，所述第二节点为Leader；所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。在第二方面的第一种可能的实现方式中，所述第二节点为所述第一节点故障重启前的所述分布式集群系统的leader。
通过所述第一节点故障重启前的所述分布式集群系统的leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统没有新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
在第二方面的第二种可能的实现方式中，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
通过所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了不安全隐患的问题。
结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述方法还包括：当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
结合第二方面的第一种至第四种任一可能的实现方式，在第二方面的第五种可能的实现方式中，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader包括：所述第一节点故障重启后，所述第二节点获得所述分布式集群系统中超过半数的赞成投票成为所述新的Leader，所述超过半数的赞成投票包括所述第二节点自己的赞成投票和所述第三节点的赞成投票，所述第二节点不能获得所述第一节点的赞成投票。
通过设置所述第一节点不能参与leader选举中的投票，使没有所述故障前的最新日志的所述第三节点不能当选为Leader，从而保证了拥有所述故障前的最新日志的所述第二节点能顺利当选Leader。
结合第二方面或第二方面的第一种至第五种任一可能的实现方式，在第二方面的第六种可能的实现方式中，还包括：所述第二节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第二节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；所述第二标识信息的初始值设置为假False，用于指示所述第二节点初次启动，还未从所述分布式集群系统中的其它节点或者用户端设备接收过所述第一条日志；当所述第二节点从所述分布式集群系统中的其它节点或者用户端设备接收到第一条日志后，将所述第二标识信息设置为真True，用于指示所述第二节点曾经接收过所述第一条日志。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
第三方面，本发明提供一种第一网络设备，用作第一节点，所述第一网络设备用于执行第一方面或第一方面的任意可能的实现方式中的方法。具体地，所述第一网络设备包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的模块。
第四方面，本发明提供一种第一网络设备，用作第一节点，所述第一网络设备包括：处理器、发送器、随机存取存储器、只读存储器以及总线。其中，处理器通过总线分别耦接发送器、随机存取存储器以及只读存储器。其中，当需要运行终端设备时，通过固化在只读存储器中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导终端设备进入正常运行状态。在第一网络设备进入正常运行状态后，在随机存取存储器中运行应用程序和操作系统，使得该处理器执行第一方面或第一方面的任意可能的实现方式中的方法。
第五方面，本发明提供一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第六方面，本发明提供一种第二网络设备，用作第二节点，所述第二网络设备用于执行第二方面或第二方面的任意可能的实现方式中的方法。具体地，所述第二网络设备包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的模块。
第七方面，本发明提供一种第二网络设备，用作第二节点，所述第二网络设备包括：处理器、发送器、随机存取存储器、只读存储器以及总线。其中，处理器通过总线分别耦接发送器、随机存取存储器以及只读存储器。其中，当需要运行终端设备时，通过固化在只读存储器中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导终端设备进入正常运行状态。在第二网络设备进入正常运行状态后，在随机存取存储器中运行应用程序和操作系统，使得该处理器执行第二方面或第二方面的任意可能的实现方式中的方法。
第八方面，本发明提供一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的指令。
第九方面，提供一种系统，所述系统包括第三方面至第五方面任一的第一网络设备和第六方面至第八方面任一的第二网络设备。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面附图中反映的仅仅是本发明的一部分实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得本发明的其他实施方式。而所有这些实施例或实施方式都在本发明的保护范围之内。
图1是本发明实施例的一种分布式系统示意图；
图2a是本发明实施例中另一种分布式系统及产生问题的示意图；
图2b是本发明实施例中又一种分布式系统及产生问题的示意图；
图3是本发明实施例中一种故障恢复的方法流程交互示意图；
图4a是本发明实施例中的分布式系统及解决问题后的示意图；
图4b是本发明实施例中的分布式系统及解决问题后的示意图；
图5a是本发明实施例中的一种第一网络设备的结构示意图；
图5b是本发明实施例中的另一种第一网络设备的结构示意图；
图6a是本发明实施例中的一种第二网络设备的结构示意图；
图6b是本发明实施例中的另一种第二网络设备的结构示意图；
图7是本发明实施例中的一种系统示意图。
具体实施方式
下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例描述的网络架构以及业务场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。
分布式系统是一种组件位于联网计算机上，组件间通过传递消息来通信和协调他们动作的系统模型。组件彼此交互以便实现共同的目标。分布式系统的三个显着特征是：组件的并发性，缺少全局时钟，以及组件的独立故障。分布式系统包括但不限于面向服务的架构系统、大规模多玩家在线游戏以及对等应用程序等。
强一致性是在并发编程(例如，在分布式共享存储器，分布式事务)领域中使用的一致性模型之一。强一致性要求：所有并行进程(或节点、处理器等)以相同的顺序看到所有访问。Raft算法是一种用来保证强一致性的典型算法，该算法应用在分布式系统中，例如，开放日光平台(英文：OpenDaylight platform，ODL)、开放网络操作系统(英文：OpenNetwork Operating System，ONOS)等业界主流分布式控制器系统中。
Raft将一致性问题分为领导者(英文：Leader)选举、日志复制和安全性保证三个子问题。Raft将来自客户端的操作指令转化为日志，先存储(用于后续系统故障后恢复时的依据)，然后根据日志进行一致性同步。同步成功后，服务器标记该日志为提交状态(该提交状态指示该日志在该系统中已经具有了一致性。该系统中的大于一半的服务器已经保存了该日志，就能够保证一致性)，并执行操作指令。日志被标记为提交状态的顺序即为指令被执行的顺序。Raft算法过程保证Raft集群中所有服务器的日志被提交顺序保持一致。
下面简单描述Raft算法中的基本术语和概念定义。
Raft算法将分布式集群系统中的节点(例如，服务器)分为Leader、跟随者(英文：follower)和候选者(英文：Candidate)三种角色。Leader负责处理用户(英文：client)请求和按序将日志复制到follower。Follower被动响应请求，根据不同请求类型和内容作出动作。Candidate为由Follower向Leader转化过程中的中间状态的角色。其中，Leader通过日志复制逻辑保证所有follower日志提交顺序都与自己日志提交顺序一致。
Raft算法将分布式集群系统中每个节点(如，服务器)的时间被切分为一个个任期(英文：Term)。每个Term包括Leader选举时间和在某个Leader下的正常操作时间。每个Term最多一个Leader。有些Term不存在Leader，此时，为选举失败的情况。
基于Raft算法的分布式集群系统(下文简称为Raft集群)一开始启动时，该系统中所有的节点均以Follower身份启动，并启动选举定时器。如果Follower选举定时器超时，则认为当前系统中不存在一个服务器作为Leader，需要发起新一轮选举。当选举出一个节点作为leader后，该作为Leader的服务器必须广播心跳，以触发其它作为Follower的服务器的选举定时器重新开始计时。这是Raft算法的心跳和超时机制。
Raft集群中各节点相关的部分状态变量包括：
当前任期(英文：currentTerm)变量：用于标识节点当前所在的Term；
投票目标(英文：votedFor)变量：Leader选举过程，Raft集群中的节点用votedFor变量来标记在当前Term中，该节点选择集群中的哪个节点为Leader。
最后日志索引(英文：lastLogIndex)变量：用于标识Raft集群中某个节点上存储的最后一条日志的索引，日志存储在数组中，索引描述了日志的存储顺序。
最后日志任期(英文：lastLogTerm)变量：用于标识Raft集群中某个节点上存储最后一条日志时，该节点所在的Term。
需要说明的是，以上描述的每个状态变量在Raft集群中的每个节点上分别维护，即每个节点分别自己生成并维护所述各个状态变量，这些状态变量在每个节点上唯一。
接下来简单描述Raft集群中Leader选举的过程。
Follower的选举定时器超时后，需要发起新一轮选举。Follower自增currentTerm变量后由Follower转为Candidate，设置votedFor变量为自身，并向Raft集群中的其它所有的节点发送请求投票消息，重复至满足以下任意条件：
a.如果该节点获得Raft集群中超过半数服务器的投票，则由Candidate转化为Leader并开始广播心跳；
b.如果该节点接收到合法Leader的日志复制请求(日志复制请求也作为心跳消息)，则说明新的Leader已经产生，自己转化为Follower；
c.如果选举超时(本周期没有选举成功)，则自增currentTerm后开始新一轮的选举。
此外，Raft集群中每个节点处理的日志可以保存在非易失性存储介质上，例如，磁盘、硬盘等掉电后数据不丢失的存储介质；也可以保存在易失性存储介质上，例如内存等掉电后数据丢失的存储介质。为了提高数据处理的效率，这些节点不是将日志数据存储在磁盘等非易失性介质上，而是会选择将日志数据存储在易失性存储介质上，日志数据的读写均在内存中完成，读写速度较快。
Raft集群包括至少三个节点，当所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题。例如，拥有最新日志的节点数量可以为M，M为
Figure GDA0002105241350000091
取下限整数N为Raft集群中节点的个数,N为大于等于3的奇数。例如，如图1所示，Raft集群有3个节点(N＝3)分别是第一节点(英文：Node1)、第二节点(英文：Node2)和第三节点(英文：Node3)。此时，
Figure GDA0002105241350000092
需要对2.5直接去掉小数位取整得到2(即取下限整数)，即有两个节点(如Node1和Node2)分别拥有最新的日志a，而其它节点(如Node3)还未同步到所述最新的日志a。在日志存储在易失性存储介质的场景中，此时如果Node1或Node2中的一个节点故障重启后，最新日志a将丢失。在重新进行Leader选举的过程中，没有存储最新日志a的Node3有可能通过选举成为新的Leader，新的Leader(Node3)向Node1和Node2等其它节点同步自己的日志，因为Node3上没有存储最新日志a，就不会把最新日志a同步到其它节点，这样就会造成最新的日志a丢失、Raft集群不安全的问题。
基于此场景，下面分别从上述故障重启的节点作为Leader角色或Follower角色两种情况来分别阐述问题。
如图2a所示，当Node1作为Leader，发生了故障，重启后，包括最新日志a的所有日志丢失。此时Node3开始申请要成为Leader，Node3向Node1和Node2分别发送请求投票消息，该请求投票消息携带Node3的本地日志信息，该本地日志信息包括lastLogIndex(例如，为正整数N)和lastLogTerm(例如，为正整数M)。因为Node2和Node1上已经分别保存了最新日志a，而Node3还未来得及同步到最新日志a，所以Node2和Node1上的LastLogIndex(例如，为N+1)一定大于Node3的LastLogIndex(为N)。当Node2收到Node3发来的该请求投票消息时，比较Node2和Node3两个节点上的lastLogIndex和lastLogTerm。如果Node2的lastLogTerm更大，或者，Node2和Node3的lastLogTerm相同但Node2的lastLogIndex更大，则确定Node2自己保存的日志更完整，则拒绝该次投票请求。同理，当Node1收到Node3发来的该请求投票消息时，比较Node1和Node3两个节点上的lastLogIndex和lastLogTerm。因为Node1重启后所有的日志等相关信息已经丢失(日志信息为空)，所以Node3的lastLogIndex更大或者lastLogTerm更大，就会确定Node3保存的日志更完整，则会接受该次投票请求，赞成Node3成为Leader。因为Raft集群只有3个节点，此时Node3分别获得了自己和Node1的2票赞成票，大于一半(1.5票)，所以当选为新的Leader，新的Leader会向Node1和Node2同步自己的日志信息，而Node3上并没有存储最新日志a，所以，整个Raft集群中将会丢失最新日志a，造成了Raft集群不安全的问题。
如图2b所示，当Node1作为Follower，发生了故障，包括最新日志a的所有日志丢失。重启后，Raft集群正好处于Leader选举的过程中，若Node3向Node1和Node2分别发送请求投票消息，该请求投票消息携带Node3的本地日志信息，该本地日志信息包括lastLogIndex(例如，为正整数N)和lastLogTerm(例如，为正整数M，M＝currentTerm+1)。因为Node1重启后所有的日志等相关信息已经丢失(日志信息为空)，所以Node3的lastLogIndex更大或者lastLogTerm更大，就会确定Node3保存的日志更完整，则Node1会接受该次投票请求，赞成N3成为Leader。Node3还会自己给自己投一票赞成票。因为Raft集群只有3个节点，此时Node3分别获得了自己和Node1的2票赞成票，大于一半(1.5票)，所以当选为新的Leader，新的Leader会向Node1和Node2同步自己的日志信息，而Node3上并没有存储最新日志a，所以，整个Raft集群中将会丢失最新日志a，造成了Raft集群不安全的问题。需要说明的是，因为Node3的lastLogTerm(为currentTerm+1)大于Node2的lastLogTerm(为currentTerm)，所以Node2接受Node3成为新的Leader，Node2变为Follower状态。
还需要说明的是，本发明实施例中所述的分布式系统与分布式集群系统是同一个意思，可以互相使用。
上面描述了本发明涉及的两种可能的应用场景，下面将基于此对本发明实施例进一步详细说明。
图3为本发明实施例提供的一种故障恢复的方法流程示意图。该方法应用于图1所示的基于Raft算法的分布式集群系统中。所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志。具体地，可以应用在图2a和2b所示的两种场景中。需要说明的是，图1、图2a和图2b仅以Raft集群的节点数为3个举例说明，实际应用场景中，节点数可以为大于等于3个，原理与此相同，为了简洁，不再赘述。
本发明实施例提供的方案包括301部分、302部分、303部分和304部分，301部分和302部分在所述第一节点上执行，303部分和304部分在所述第二节点上执行，下面分别说明。
在301部分，所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
可选地，设置投票状态为不能投票的判断条件可以是在所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，就将投票状态设置为不能投票。此外，如果确定所述第一节点的日志为空的原因为所述第一节点首次启动，就将投票状态设置为能投票。
通过在确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，才将投票状态设置为不能投票，保证了在系统初始情况下，不会将所述第一节点的投票状态设置为不能投票，从而造成错误
进一步，可选地，确定所述第一节点的日志为空的原因的方法可以通过在所述第一节点的非易失性存储介质中保存第二标识信息来实现。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。例如，在Raft集群初始启动时，所述第一节点的日志为空(之前从未接收过日志)，所述第二标识信息为0，代表假(英文：False)，用于指示所述第一节点曾经没有从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。该用户端设备为该Raft集群外的客户端(英文：Client)节点，可以是网络转发设备，如路由器、交换机；也可以是应用服务器等设备。当Raft集群运行过程中，所述第一节点从所述分布式集群系统中的其它节点(例如，第二节点)或者用户端设备接收到第一条日志，则设置该第二标识信息为1，代表真(英文：Ture)，用于指示所述第一节点曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。
当所述第一节点故障重启后，如果所述第一节点确认所述第二标识信息为1(即Ture)，并且所述第一节点的内存中存储的日志为空，则确定所述第一节点因为故障重启导致丢失了日志。
当所述第一节点故障重启后，如果所述第一节点确认所述第二标识信息为0(即False)，并且所述第一节点的内存中存储的日志为空，则确定所述第一节点为初始启动日志为空，即因为Raft集群初始启动时，集群中各节点首次启动，所以内存的日志为空。
通过将第二标识信息设置为False或True，本发明实施例提供了一种更简洁、具体的配置该第二标识信息的方式。
综上，通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。以下举例说明。
相对于图2a展示的技术问题，结合图4a所示，作为Leader的Node1故障重启后，确定因为故障重启导致日志为空，所以不能参与Leader选举过程中的投票。此时如果Node3发起投票请求，Node3就不能获得Node1的赞成投票，也不能获得Node2的赞成投票(具体请参考上述图2a所示的技术问题的描述部分)，只能获得自己投给自己的1票赞成投票，1票小于Raft集群的一半投票(1.5票)，因此不能当选为Leader。如果Node2发起投票请求，则可以获得自己投给自己的1票和Node3投给自己的1票(Node3投赞成票的原理，具体请参考上述图2a所示的技术问题的描述部分)，共2票，大于一半(1.5票)，因此当选为Leader。并将最新日志a同步给Node1和Node3，从而使最新日志a在Node1故障重启时不丢失。
相对于图2b展示的技术问题，结合图4b所示，作为Follower的Node1故障重启后，确定因为故障重启导致日志为空，所以不能参与Leader选举过程中的投票。重启后，Raft集群正好处于Leader选举的过程中，此时如果Node3发起投票请求，Node3就不能获得Node1的赞成投票，也不能获得Node2的赞成投票(具体请参考上述图2b所示的技术问题的描述部分)，只能获得自己投给自己的1票赞成投票，1票小于Raft集群的一半投票(1.5票)，因此不能当选为Leader。如果Node2发起投票请求，则可以获得自己投给自己的1票和Node3投给自己的1票(因为Node2拥有最新日志a，所以Node2的lastLogIndex大于Node3的lastLogIndex，Node3会给Node2投赞成票。具体原理请参考上述图2a或2b所示的技术问题的描述部分)，共2票，大于一半(1.5票)，因此当选为Leader。并将最新日志a同步给Node1和Node3，从而使最新日志a在Node1故障重启时不丢失。
在302部分，所述第一节点故障重启后，所述第二节点为Leader。具体地，所述第一节点故障重启后，所述第二节点获得所述分布式集群系统中超过半数的赞成投票成为所述新的Leader，所述超过半数的赞成投票包括所述第二节点自己的赞成投票和所述第三节点的赞成投票，所述第二节点不能获得所述第一节点的赞成投票。
通过设置所述第一节点不能参与leader选举中的投票，使没有所述故障前的最新日志的所述第三节点不能当选为Leader，从而保证了拥有所述故障前的最新日志的所述第二节点能顺利当选Leader。
进一步，所述第二节点为Leader包括以下三种情况，举例说明如下。
第一种情况，如图2a所示的场景中，作为Leader的Node1故障重启后，作为Follower的Node2通过选举成为新的Leader。例如，Node1故障，Node2和Node3收不到作为Leader的Node1发来的心跳，选举定时器超时，引起新一轮的Leader选举，Node2成为新的Leader。
第二种情况，如图2b所示的场景中，作为Follower的Node1故障重启时，Raft集群正在进行新一轮(即新一个任期，相应的变量currentTerm+1)的Leader选举，作为Leader的Node2通过新一轮选举成为新的Leader。
在上面两种情况中，通过Node1故障重启后的所述Raft集群选举出的新的Leader向Node1发送所述复制日志条目消息，使Node1恢复了投票权利。从而保证了在Node1故障重启时，所述Raft集群进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
第三种情况，如图2b所示的场景中，作为Follower的Node1故障重启时，Raft集群没有进行新一轮的Leader选举，作为Leader的Node2继续作为Leader(即为所述第一节点故障重启前的所述分布式集群系统的leader)行使职责。此时的Leader也可以看作是所述第一节点故障重启前的老Leader。通过该老Leader向所述Node1发送下文会描述的复制日志条目消息，使所述Node1恢复了投票权利，保证了在Node1故障重启时，Raft集群没有新一轮Leader选举的情况下，系统仍能正常工作，提升了系统的安全性。
在303部分，所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
在304部分，所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票，所述第二节点为Leader。
为了简洁，303和304部分结合起来描述。所述复制日志条目消息(英文：ReplicatedLogEntry)包括日志条目，作为Leader的第二节点将自己的所有日志条目同步更新到所述第一节点上。其中所述复制日志条目消息的数量可以等于所述日志条目的数量，也可以小于所述日志条目的数量。例如，所述日志条目的数量为M，所述复制日志条目消息的数量为N，N小于等于M，N和M为大于等于1的正整数。当N等于M时，说明每条所述复制日志条目消息中包括一条日志条目。当N小于M时，说明每条所述复制日志条目消息中包括多条日志条目(即一组日志条目)或一条日志条目。如图4a或4b所示，所述日志条目中包括最新日志a，则Node1就会收到并保存Node2同步过来的最新日志a，是最新日志a在Node1故障重启后不丢失。
所述第一节点将所述第一节点的投票状态设置为可以投票的时机可以包括以下几种情况。
第一种情况，假设第N条复制日志条目消息中包括所述故障前的最新日志，当所述第一节点接收到所述第二节点发来的第X条复制日志条目消息(X为大于等于1且小于N的正整数)，就将投票状态设置为可以投票，恢复了Leader选举中的投票权利。也就是，所述第一节点还没有同步到所述故障前的最新日志，就被恢复了投票的权利。此时如果第二节点故障，则所述故障前的最新日志会丢失，并且由于所述第一节已经具有了投票的权利，在新一轮Leader选举的过程中，会将赞成票投给其它节点，例如，投给所述第三节点，从而使所述第三节点成为新的Leader，Raft集群会继续运行，却不能识别出已经丢失了日志，因而造成了安全隐患。当然，如果第二节点没有故障，并在恢复了投票的权利后，继续将所述故障前的最新日志同步到所述第一节点上，则不会丢失该故障前的最新日志，不会发生安全隐患。
第二种情况，假设第N条复制日志条目消息中包括所述故障前的最新日志，当所述第一节点接收到所述第二节点发来的第X条复制日志条目消息(X为等于N的正整数)，就将投票状态设置为可以投票，恢复了Leader选举中的投票权利。也就是，所述第一节点同步到所述故障前的最新日志时，被恢复了投票的权利。此时如果第二节点故障，也不会造成所述故障前的最新日志会丢失，不会发生安全隐患。
由此可知，通过上述接收到复制日志条目消息恢复故障重启节点的投票权利的方法，在上述第一种情况下依然存在安全上的隐患。
为此，本发明在所述复制日志条目消息中增加第一标识信息，所述第一标识信息用于指示所述复制日志条目消息中携带的所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。
当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态，即不恢复所述第一节点的投票权利。通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
所述第二节点成为Leader前的最后一条日志可以是所述故障前的最新日志，也可以是所述故障后新接收到的一条新日志，以下分别举例说明。
首先举例说明所述第二节点成为Leader前的最后一条日志是所述故障前的最新日志。例如，如图4a或4b所示，在Node1故障重启后，如果Node2成为选举出的新Leader前的最后一条日志是最新日志a，则Node2向Node1发送ReplicatedLogEntry消息Y，该ReplicatedLogEntry消息Y包括所述最新日志a和所述第一标识信息a，所述第一标识信息a指示所述最新日志a为Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Y后，根据所述第一标识信息a，确认Node1收到了最新日志a，则保存最新日志a，并将Node1的投票状态设置为可以投票，恢复Node1的投票权利。
其次举例说明所述第二节点成为Leader前的最后一条日志是所述故障后新接收到的一条新日志。例如，如图4b所示，Node2作为Leader，在Node1故障重启时，又接收到用户端设备发来的一条日志b。然后Raft集群发起新一轮Leader选举，在Node1故障重启后，Node2又继续选举成新一轮的Leader，则日志b是Node2成为选举出的新Leader前的最后一条日志。则Node2向Node1发送ReplicatedLogEntry消息Y，该ReplicatedLogEntry消息Y包括所述最新日志a和所述第一标识信息a，所述第一标识信息a指示所述最新日志a不是Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Y后，保存最新日志a，并且不将Node1的投票状态设置为可以投票，不恢复Node1的投票权利。Node2继续向Node1发送ReplicatedLogEntry消息Z，该ReplicatedLogEntry消息Z包括所述日志b和所述第一标识信息b，所述第一标识信息b指示所述日志b是Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Z后，保存日志b，并且将Node1的投票状态设置为可以投票，恢复Node1的投票权利。需要说明的是，日志b仅仅是一个举例，在上述Node1故障重启时，还可以再接收到除日志b以外的多条新日志，如日志c、日志d等，此处不做限定。此种情况时原理与上述相同，此处不再赘述。
这样就保证了Node1在收到了最新日志a后，才能恢复投票的权利。当Node1没有收到最新日志a时，不能恢复投票的权利。此时当Node2也故障重启时，Node3节点就不能被选举为Leader(因为得不到Node1和Node2的赞成投票)，这样Raft集群就无法选举出Leader，就会识别出日志丢失，进行故障上报，通知管理员尽快解决，避免了Raft集群日志已经丢失还在继续运行引起的不安全隐患。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了安全隐患的问题。
图5a示出了上述实施例中所涉及的第一网络设备的一种可能的结构示意图。第一网络设备500A用作第一节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一网络设备500A包括：
处理单元504A，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
接收单元502A，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader。
所述处理单元504A还用于根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
可选地，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。所述处理单元504A根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存，并将所述第一节点的投票状态设置为可以投票。
所述第一网络设备500A还包括易失性存储单元，所述易失性存储单元用于存储所述日志条目。
可选地，所述处理单元504A还用于根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
可选地，所述第一节点启动后，所述处理单元504A确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
进一步，可选地，所述第一节点还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。所述第一节点启动时，所述处理单元504A用于确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述处理单元504A用于确定所述第一节点因为故障重启导致丢失了日志。
本发明实施例的第一网络设备500A可以实施上述图2a至图4b所对应的实施例中的第一节点中的各种实施功能和的步骤，为了简洁，在此不再赘述。
图5b示出了上述实施例中所涉及的第一网络设备的再一种可能的结构示意图。第一网络设备500B包括：接收器510B、处理器520B、发送器530B、随机存取存储器540B、只读存储器550B以及总线560B。其中，处理器520B通过总线560B分别耦接接收器510B、发送器530B、随机存取存储器540B以及只读存储器550B。其中，当需要运行第一网络设备500B时，通过固化在只读存储器550B中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导第一网络设备500B进入正常运行状态。在第一网络设备500B进入正常运行状态后，在随机存取存储器540B中运行应用程序和操作系统，使得：
处理器520B在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
接收器510B接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader。
处理器520B还根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
本发明实施例的第一网络设备500B可对应于上述图2a至图4b所对应的实施例中的第一节点，并且，该第一网络设备500B中的处理器520B、接收器510B等可以实现图2a至图4b所对应的实施例中的第一节点所具有的功能和/或所实施的各种步骤和方法。所述处理器520B用于执行图5a所述第一网络设备的处理单元504A的所有操作，所述接收器510B用于执行图5a所述第一网络设备的接收单元502A的所有操作。所述随机存取存储器540B用于执行图5a所述易失性存储单元的所有操作。所述只读存储器550B用于执行图5a所述非易失性存储单元的所有操作。为了简洁，在此不再赘述。
需要说明的是，本实施例也可以基于通用的物理服务器结合网络功能虚拟化(英文：Network Function Virtualization，NFV)技术实现的虚拟第一网络设备，所述虚拟第一网络设备可以是运行有用于故障恢复功能的程序的虚拟机(英文：Virtual Machine，VM)，所述虚拟机部署在硬件设备上(例如，物理服务器)。虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。
图6a示出了上述实施例中所涉及的第二网络设备的一种可能的结构示意图。第二网络设备600A用作第二节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二网络设备600A包括：
处理单元604A，用于在所述第一节点故障重启后确认所述第二节点为Leader。
发送单元606A，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
可选地，所述处理单元604A用于确认所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。所述第一标识信息的定义和描述与图2a至图4b所述的方法实施例中的描述一致，为了简洁，此处不再赘述。
可选地，所述第二网络设备600A还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第二节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。所述第二节点启动时，所述处理单元604A用于确认所述第二标识信息指示所述第二节点曾经接收过所述第一条日志，并且所述第二节点当前的日志为空，所述处理单元604A用于确定所述第二节点因为故障重启导致丢失了日志。
本发明实施例的第二网络设备600A可以实施上述图2a至图4b所对应的实施例中的第二节点中的各种实施功能和的步骤，为了简洁，在此不再赘述。
图6b示出了上述实施例中所涉及的第二网络设备的又一种可能的结构示意图。第二网络设备600B包括：接收器610B、处理器620B、发送器630B、随机存取存储器640B、只读存储器650B以及总线660B。其中，处理器620B通过总线660B分别耦接接收器610B、发送器630B、随机存取存储器640B以及只读存储器650B。其中，当需要运行第二网络设备600B时，通过固化在只读存储器650B中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导第二网络设备600B进入正常运行状态。在第二网络设备600B进入正常运行状态后，在随机存取存储器640B中运行应用程序和操作系统，使得：
处理器620B，用于在所述第一节点故障重启后确认所述第二节点为Leader。
发送器630B，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
本发明实施例的第二网络设备600B可对应于上述图2a至图4b所对应的实施例中的第二节点，并且，该第二网络设备600B中的处理器620B、发送器630B等可以实现图2a至图4b所对应的实施例中的第二节点所具有的功能和/或所实施的各种步骤和方法。所述处理器620B用于执行图6a所述第二网络设备的处理单元604A的所有操作，所述发送器630B用于执行图6a所述第二网络设备的发送单元606A的所有操作。所述只读存储器650B用于执行图6a所述非易失性存储单元的所有操作。为了简洁，在此不再赘述。
还要说明的是，本发明实施例中的第一网络设备或第二网络设备可以为多种具有计算和存储能力的设备，例如，服务器、主机、PC(personal computer，个人计算机)等计算机设备；又如，网络设备也可以为SDN(Software Defined Network，软件定义网络)控制器。
图7是本发明实施例提供的一种故障恢复的系统示意图。如图7所示，系统700包括第一网络设备710和第二网络设备720。第一网络设备710为上述图5a、5b所述的任一第一网络设备，第二网络设备720为上述图6a、6b所述的任一第二网络设备。有关系统中各设备的详细描述，请参见上述图5a-5b和图6a-6b等相关章节，此处不再赘述。
应理解，本领域技术人员在阅读本申请文件的基础上，可以针对本申请实施例中所描述的可选的特征、步骤或方法进行不需要付出创造性的组合，都属于本申请公开的实施例，只是由于描述或行文的简单没有重复赘述不同组合。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (20)

1.一种故障恢复的方法，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述方法包括：
所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述基于Raft算法的分布式集群系统选举Leader的过程中进行投票；
所述第一节点接收来自所述第二节点的复制日志条目消息，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为新的Leader前的最后一条日志；
所述第一节点根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
2.根据权利要求1所述的方法，其特征在于，所述第二节点为所述第一节点故障重启后的所述基于Raft算法的分布式集群系统选举出的所述新的Leader。
3.根据权利要求2所述的方法，其特征在于，所述方法还包括：
所述第一节点根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
4.根据权利要求1或3所述的方法，其特征在于，所述第一节点故障重启后，投票状态设置为不能投票包括：
所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
5.根据权利要求4所述的方法，其特征在于，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：
所述第一节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述基于Raft算法的分布式集群系统中的其它节点或者用户端设备接收过第一条日志；
所述第一节点启动时，所述第一节点确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述第一节点确定所述第一节点因为故障重启导致丢失了日志。
6.一种故障恢复的方法，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述方法包括：
所述第一节点故障重启后，所述第二节点为新的Leader；
所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志，当所述第一标识信息指示所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
7.根据权利要求6所述的方法，其特征在于，所述第二节点为所述第一节点故障重启后的所述基于Raft算法的分布式集群系统选举出的所述新的Leader。
8.根据权利要求7所述的方法，其特征在于，所述方法还包括：
当所述第一标识信息指示所述日志条目不包括所述第二节点成为所述新的Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
9.一种第一网络设备，用作第一节点，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一节点包括：
处理单元，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述基于Raft算法的分布式集群系统选举Leader的过程中进行投票；
接收单元，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为新的Leader，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
所述处理单元还用于根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存，并将所述第一节点的投票状态设置为可以投票。
10.根据权利要求9所述的第一网络设备，其特征在于，所述第二节点为所述第一节点故障重启后的所述基于Raft算法的分布式集群系统选举出的所述新的Leader。
11.根据权利要求10所述的第一网络设备，其特征在于，
所述第一节点还包括易失性存储单元，所述易失性存储单元用于存储所述日志条目。
12.根据权利要求11所述的第一网络设备，其特征在于，所述处理单元还用于根据所述第一标识信息确认所述日志条目不包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
13.根据权利要求9或12所述的第一网络设备，其特征在于，处理单元用于在所述第一节点故障重启后，将投票状态设置为不能投票包括：
所述第一节点启动后，所述处理单元确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
14.根据权利要求13所述的第一网络设备，其特征在于，所述处理单元确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：
所述第一节点还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述基于Raft算法的分布式集群系统中的其它节点或者用户端设备接收过第一条日志；
所述第一节点启动时，所述处理单元用于确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述处理单元用于确定所述第一节点因为故障重启导致丢失了日志。
15.一种第二网络设备，用作第二节点，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二节点包括：
处理单元，用于在所述第一节点故障重启后确认所述第二节点为新的Leader；
发送单元，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志，当所述第一标识信息指示所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
16.根据权利要求15所述的第二网络设备，其特征在于，所述处理单元用于在所述第一节点故障重启后确认所述第二节点为新的Leader包括：
所述处理单元用于确认所述第二节点为所述第一节点故障重启后的所述基于Raft算法的分布式集群系统选举出的所述新的Leader。
17.根据权利要求16所述的第二网络设备，其特征在于，当所述第一标识信息指示所述日志条目不包括所述第二节点成为所述新的Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
18.一种第一网络设备，用作第一节点，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一节点包括：
处理器，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述基于Raft算法的分布式集群系统选举Leader的过程中进行投票；
接收器，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为新的Leader，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
所述处理器还用于所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
19.一种第二网络设备，用作第二节点，应用在基于Raft算法的分布式集群系统中，所述基于Raft算法的分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述基于Raft算法的分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二节点包括：
处理器，用于在所述第一节点故障重启后确认所述第二节点为新的Leader；
发送器，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志，当所述第一标识信息指示所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
20.一种故障恢复的系统，其特征在于，所述系统包括如权利要求9至14任一所述的第一网络设备和如权利要求15至17任一所述的第二网络设备；或者所述系统包括如权利要求18所述的第一网络设备和如权利要求19所述的第二网络设备。
CN201680091858.0A 2016-12-30 2016-12-30 故障恢复的方法、设备和系统 Active CN110431533B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/113848 WO2018120174A1 (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统

Publications (2)

Publication Number Publication Date
CN110431533A CN110431533A (zh) 2019-11-08
CN110431533B true CN110431533B (zh) 2021-09-14

Family

ID=62706721

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680091858.0A Active CN110431533B (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统

Country Status (4)

Country Link
US (1) US11102084B2 (zh)
EP (1) EP3553669B1 (zh)
CN (1) CN110431533B (zh)
WO (1) WO2018120174A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10595363B2 (en) * 2018-05-11 2020-03-17 At&T Intellectual Property I, L.P. Autonomous topology management for wireless radio user equipment
CN112865995B (zh) * 2019-11-27 2022-10-14 上海哔哩哔哩科技有限公司 分布式主从系统
CN111538763B (zh) * 2020-04-24 2023-08-15 咪咕文化科技有限公司 一种确定集群中主节点的方法、电子设备和存储介质
CN114299655B (zh) * 2020-09-23 2023-09-05 成都中科信息技术有限公司 一种电子投票系统及其工作方法
CN112601216B (zh) * 2020-12-10 2022-06-21 苏州浪潮智能科技有限公司 一种基于Zigbee的可信平台告警方法与系统
CN113742254A (zh) * 2021-01-19 2021-12-03 北京沃东天骏信息技术有限公司 内存碎片治理方法、装置和系统
CN113014634B (zh) * 2021-02-20 2023-01-31 成都新希望金融信息有限公司 集群选举处理方法、装置、设备及存储介质
US11645014B1 (en) * 2021-10-26 2023-05-09 Hewlett Packard Enterprise Development Lp Disaggregated storage with multiple cluster levels
CN114189421B (zh) * 2022-02-17 2022-05-31 江西农业大学 一种领导者节点选举方法、系统、存储介质及设备
CN114518973B (zh) * 2022-02-18 2024-07-30 成都西南信息控制研究院有限公司 分布式集群节点宕机重启恢复方法
CN114448996B (zh) * 2022-03-08 2022-11-11 南京大学 基于计算存储分离框架下的冗余存储资源的共识方法和系统
CN114406409B (zh) * 2022-03-30 2022-07-12 中国船级社 一种焊接机故障状态的确定方法、装置及设备
CN115794478B (zh) * 2023-02-06 2023-06-23 天翼云科技有限公司 系统配置方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103763155A (zh) * 2014-01-24 2014-04-30 国家电网公司 分布式云存储系统多服务心跳监测方法
CN103793517A (zh) * 2014-02-12 2014-05-14 浪潮电子信息产业股份有限公司 一种基于监控机制的文件系统日志转储动态增容方法
CN104994168A (zh) * 2015-07-14 2015-10-21 苏州科达科技股份有限公司 分布式存储方法及分布式存储系统
CN105512266A (zh) * 2015-12-03 2016-04-20 曙光信息产业(北京)有限公司 一种实现分布式数据库操作一致性的方法及装置
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

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7558883B1 (en) * 2002-06-28 2009-07-07 Microsoft Corporation Fast transaction commit
US20050132154A1 (en) * 2003-10-03 2005-06-16 International Business Machines Corporation Reliable leader election in storage area network
CN103152434A (zh) * 2013-03-27 2013-06-12 江苏辰云信息科技有限公司 一种分布式云系统中的领导节点更替方法
US9047246B1 (en) * 2014-07-31 2015-06-02 Splunk Inc. High availability scheduler
CN105511987A (zh) * 2015-12-08 2016-04-20 上海爱数信息技术股份有限公司 一种强一致性且高可用的分布式任务管理系统
US10503427B2 (en) * 2017-03-10 2019-12-10 Pure Storage, Inc. Synchronously replicating datasets and other managed objects to cloud-based storage systems

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
CN103763155A (zh) * 2014-01-24 2014-04-30 国家电网公司 分布式云存储系统多服务心跳监测方法
CN103793517A (zh) * 2014-02-12 2014-05-14 浪潮电子信息产业股份有限公司 一种基于监控机制的文件系统日志转储动态增容方法
CN104994168A (zh) * 2015-07-14 2015-10-21 苏州科达科技股份有限公司 分布式存储方法及分布式存储系统
CN105512266A (zh) * 2015-12-03 2016-04-20 曙光信息产业(北京)有限公司 一种实现分布式数据库操作一致性的方法及装置

Also Published As

Publication number Publication date
EP3553669A1 (en) 2019-10-16
EP3553669A4 (en) 2019-10-16
CN110431533A (zh) 2019-11-08
US20190386893A1 (en) 2019-12-19
WO2018120174A1 (zh) 2018-07-05
US11102084B2 (en) 2021-08-24
EP3553669B1 (en) 2024-09-25

Similar Documents

Publication Publication Date Title
CN110431533B (zh) 故障恢复的方法、设备和系统
CN113014634B (zh) 集群选举处理方法、装置、设备及存储介质
US7249280B2 (en) Cheap paxos
US7856502B2 (en) Cheap paxos
US9465650B2 (en) Executing distributed globally-ordered transactional workloads in replicated state machines
EP2434729A2 (en) Method for providing access to data items from a distributed storage system
EP3008879A1 (en) Failover system and method
CN110784331A (zh) 一种共识流程恢复方法及相关节点
EP4191429B1 (en) Techniques to achieve cache coherency across distributed storage clusters
WO2017028375A1 (zh) 一种版本升级方法及系统
EP3617887B1 (en) Method and system for providing service redundancy between a master server and a slave server
US11010086B2 (en) Data synchronization method and out-of-band management device
CN114554593A (zh) 数据处理方法及装置
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
CN110781039B (zh) 哨兵进程选举方法及装置
CN113064768B (zh) 在区块链系统中切换分片节点的方法和装置
CN113157494B (zh) 区块链系统中数据备份的方法及装置
CN117215833A (zh) 分布式数据备份方法、系统、设备及存储介质
US12124423B2 (en) Optimizing the operation of a microservice cluster
CN100442248C (zh) 用于避免竞争的计算机系统同步单元
CN113568710B (zh) 一种虚拟机高可用实现方法、装置和设备
CN118331644A (zh) 一种交互控制方法、装置、设备及介质
Zhu Shaft: Serializable, highly available and fault tolerant concurrency control in the cloud
CN114721869A (zh) 一种账户余额处理方法及系统
CN115344424A (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
GR01 Patent grant
GR01 Patent grant