Master node determination method and storage medium, electronic device, and program product

Abstract

The embodiment of the application provides a cluster master node determination method and a storage medium, an electronic device and a program product, and relates to the field of computers, wherein the method comprises the following steps: in response to a first master request of a first node in a cluster, determining the first node as a candidate master node of the cluster; in the case that a second master request of a second node in the cluster is detected within a first detection period corresponding to the first master request, acquiring a first cluster state associated with the first node and a second cluster state associated with the second node, wherein the first cluster state indicates a cluster running state stored on the first node when the first master request is triggered, and the second cluster state indicates a cluster running state stored on the second node when the second master request is triggered; and in the case that the second cluster state contains more update time stamps than the first cluster state, determining the second node as the master node of the cluster.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method for determining the master node of a cluster, as well as storage media, electronic devices, and program products. Background Technology

[0002] In distributed storage systems, when a cluster lacks a master node for various reasons, multiple nodes may simultaneously attempt to take over control. This simultaneous attempt can lead to inconsistencies in the cluster state. Therefore, arbitration is needed to determine the new master node. Traditional arbitration methods often disregard the age of the cluster state associated with each node, typically granting master status to the node that first initiates the takeover request (i.e., the "master snatching" request), even if its state is older. This results in inaccurate determination of the cluster master node.

[0003] Therefore, there is a technical problem in the related technologies where the determination of the master node of the cluster is inaccurate. Summary of the Invention

[0004] This application provides a method for determining the master node of a cluster, as well as a storage medium, electronic device, and program product, to at least solve the technical problem of inaccurate determination results of the master node of a cluster in related technologies.

[0005] According to one embodiment of this application, a method for determining the master node of a cluster is provided, comprising: in response to a first master-grabbing request from a first node in the cluster, determining the first node as a candidate master node of the cluster; if a second master-grabbing request from a second node in the cluster is detected within a first detection period corresponding to the first master-grabbing request, obtaining a first cluster state associated with the first node and a second cluster state associated with the second node, wherein the first cluster state indicates the cluster running state stored on the first node when the first master-grabbing request is triggered, and the second cluster state indicates the cluster running state stored on the second node when the second master-grabbing request is triggered; if the second cluster state contains more update timestamps than the first cluster state, determining the second node as the master node of the cluster.

[0006] According to one embodiment of this application, a cluster master node determination apparatus is provided, comprising: a first determination unit, configured to determine the first node as a candidate master node of the cluster in response to a first master-grabbing request from a first node in the cluster; an acquisition unit, configured to acquire a first cluster state associated with the first node and a second cluster state associated with the second node when a second master-grabbing request from a second node in the cluster is detected within a first detection period corresponding to the first master-grabbing request, wherein the first cluster state indicates the cluster operating state stored on the first node when the first master-grabbing request is triggered, and the second cluster state indicates the cluster operating state stored on the second node when the second master-grabbing request is triggered; and a second determination unit, configured to determine the second node as the master node of the cluster when the second cluster state contains more update timestamps than the first cluster state.

[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0008] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0009] According to the embodiments provided in this application, in response to a first master-claiming request from a first node in the cluster, the first node is determined as a candidate master node of the cluster. If a second master-claiming request from a second node in the cluster is detected within a first detection period corresponding to the first master-claiming request, the first cluster state associated with the first node and the second cluster state associated with the second node are obtained. If the second cluster state is a cluster state that follows the first cluster state, the second node is determined as the master node of the cluster. By quickly obtaining and comparing the associated cluster states of the first and second nodes when they initiate the master-claiming request within the detection period, unnecessary state competition and unnecessary waiting (comparison completed within the detection period) are avoided, reducing system complexity. Furthermore, it ensures that the node with the updated state can become the master node, avoiding data inconsistency caused by a node with an older state taking over. Through this dynamic detection and comparison of node states, the embodiments provided in this application can preferentially select the node with the latest state as the master node, while avoiding unnecessary waiting, achieving the technical effect of improving the accuracy of the determination result of the cluster master node, and solving the technical problem of low accuracy in the determination result of the cluster master node. Attached Figure Description

[0010] Figure 1 This is a hardware structure block diagram of a method for determining the master node of a cluster according to an embodiment of this application.

[0011] Figure 2 This is a flowchart of a method for determining the master node of a cluster according to an embodiment of this application.

[0012] Figure 3 This is a timing diagram of an arbitration interaction method according to an embodiment of this application.

[0013] Figure 4 This is a timing diagram of another arbitration interaction method according to an embodiment of this application.

[0014] Figure 5 This is a structural block diagram of a cluster master node determination device according to an embodiment of this application. Detailed Implementation

[0015] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of a computer terminal for a cluster master node determination method according to an embodiment of this application. Figure 1 As shown, a computer terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0018] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the cluster master node determination method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0019] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0020] As an optional solution, this embodiment provides a method for determining the master node of a cluster, such as... Figure 2 As shown, it includes:

[0021] S202, in response to the first master-preemption request from the first node in the cluster, determines the first node as the candidate master node of the cluster;

[0022] S204, if a second master-grabbing request is detected in the first detection period corresponding to the first master-grabbing request, the first cluster state associated with the first node and the second cluster state associated with the second node are obtained, wherein the first cluster state indicates the cluster running state stored on the first node when the first master-grabbing request is triggered, and the second cluster state indicates the cluster running state stored on the second node when the second master-grabbing request is triggered.

[0023] S206, if the second cluster state contains more update timestamps than the first cluster state, the second node is determined as the master node of the cluster.

[0024] Optionally, this embodiment can be applied, but is not limited to, to distributed storage systems facing network partitioning. By using an arbitration device to dynamically compare and decide the status of cluster nodes, it effectively avoids the split-brain phenomenon, where multiple nodes simultaneously believe themselves to be the master node. Specifically, the arbitration device first responds to the first node's master-claim request, marking it as a candidate master node. However, if a second node's master-claim request is received in a subsequent detection period, the arbitration device compares the cluster status of the two nodes. If the second node's cluster status is newer or better, the arbitration device selects the second node as the master node to ensure the consistency and up-to-dateness of the cluster status, thereby guaranteeing the continuity and integrity of data services. This method not only avoids the inconsistency problems that may arise from older nodes taking over the cluster but also reduces system service interruption time, improving system availability and performance.

[0025] Optionally, in this embodiment, the first node and the second node refer to two storage nodes in the cluster that are trying to become the master node, which may have temporarily lost contact due to network partitioning.

[0026] Optionally, in this embodiment, the first master-preemption request and the second master-preemption request refer to the requests sent by the first node and the second node to the arbitration device, indicating that they wish to become the master node of the cluster.

[0027] Optionally, in this embodiment, the first detection period refers to the time window during which the arbitration device detects network partitioning and node status after receiving the first master-grabbing request. The first detection period is the detection time interval set by the yield timer (a timer maintained internally by the first node) for the first master-grabbing request, and can be set to a range of several seconds to tens of seconds, such as the common 5 seconds or 10 seconds. However, this value can be adjusted up or down according to factors such as system network latency, heartbeat cycle, fault detection and recovery strategies. The first cluster status and the second cluster status refer to the cluster operating status stored by the first node and the second node when their master-grabbing requests are triggered, respectively, including key indicators such as the current cluster activity information, data distribution, and node health status.

[0028] Optionally, in this embodiment, when the first node in the cluster detects a network partition or other conditions triggering the master node election process, it sends a first master-grabbing request to the arbitration device. After receiving the first master-grabbing request, the arbitration device identifies it as the first node to actively request to become the master node and marks it as a candidate master node.

[0029] During the first detection period, if the arbitration device receives a second master-claim request from the second node, it will no longer determine the master node solely based on the order of the requests, but will instead resort to a more detailed comparison. The arbitration device will obtain the cluster state information recorded when the first and second nodes each triggered their master-claim requests, namely the first cluster state and the second cluster state.

[0030] If the second node's cluster state is more advanced than the first node's (i.e., contains more updated or later timestamps), the arbitration device will select the second node as the cluster master. This decision-making mechanism ensures that the latest cluster state is preserved, avoiding data loss or service degradation and enhancing the overall stability of the cluster. Ultimately, based on the state comparison results, the arbitration device will officially determine a master node and notify the other nodes in the cluster.

[0031] The embodiments provided in this application, by rapidly acquiring and comparing the associated cluster states of the first and second nodes when initiating master-claim requests within the detection period, avoid unnecessary state competition and unnecessary waiting (comparison completed within the detection period), reducing system complexity. Furthermore, it ensures that the node with the updated state can become the master node, preventing data inconsistency caused by older nodes taking over. Through this dynamic detection and comparison of node states, the embodiments provided in this application can preferentially select the node with the latest state as the master node, while avoiding unnecessary waiting, thus achieving the technical effect of improving the accuracy of the cluster master-node determination result.

[0032] As an optional approach, if the second cluster state contains more update timestamps than the first cluster state, determining the second node as the cluster master node includes:

[0033] If the second cluster state contains more update timestamps than the first cluster state, the second node will be updated as a candidate master node.

[0034] If no other node in the cluster makes a master-preempting request within the second detection period corresponding to the second master-preempting request, the second node will be determined as the master node.

[0035] Optionally, in this embodiment, the second detection period is a time window used to detect whether other nodes initiate a master-preemption request after the arbitration device determines the second node as a candidate master node. This period is a critical time period for the arbitration device to make the final master node decision. The second detection period is the detection time period set by the yield timer (a timer maintained internally by the second node) for the second master-preemption request, which can be, but is not limited to, set to a range of several seconds to tens of seconds, such as the common 5 seconds or 10 seconds. Optionally, in this embodiment, other nodes in the cluster are other storage nodes that may exist in the cluster besides the first and second nodes. These nodes may also initiate a master-preemption request under specific conditions and participate in the master node election.

[0036] Optionally, in this embodiment, when the arbitration device determines that the cluster state of the second node has been updated, it will cancel the candidate master node status of the first node and update the second node as the new candidate master node. This step ensures that the node whose state has been updated has the opportunity to become the master node, maintaining the consistency and up-to-dateness of the cluster state.

[0037] During the second detection cycle, the arbitration device will continuously monitor the network to detect whether any other nodes have initiated a master-preemption request. If no other node's master-preemption request is detected during the second detection cycle, the second node will be officially determined as the master node, responsible for the control and coordination of the cluster.

[0038] Understandably, this process is based on the principle of "directly promoting to controller when the state is more advanced and there are no other competitors," which reduces the uncertainty in the master node election process and speeds up the arbitration process.

[0039] The embodiments provided in this application ensure that nodes with more advanced states have the opportunity to become master nodes. At the same time, a second detection cycle is set to confirm that no other nodes initiate competition, thereby avoiding unnecessary state comparisons and competition, simplifying the decision-making path, realizing state priority and decision simplification, and ensuring that the most suitable master node can be quickly and accurately determined when the distributed system faces network partitions.

[0040] As an optional approach, if the second cluster state contains more update timestamps than the first cluster state, determining the second node as the cluster master node includes:

[0041] If a third master-preemption request is detected in the third node of the cluster during the second detection period, the third cluster status associated with the third node is obtained, wherein the third cluster status indicates the cluster running status stored on the third node when the third master-preemption request is triggered.

[0042] If the second cluster state contains more update timestamps than the third cluster state, the second node will be determined as the master node.

[0043] Optionally, in this embodiment, the third node is another node that may exist in the cluster. It may also initiate a master election request under certain conditions and participate in the election of the master node. The third master election request and the third cluster state are similar to the master election requests and associated cluster states of the first node and the second node, respectively representing the master node election request initiated by the third node and the cluster running state recorded by the third node when the request is triggered.

[0044] Optionally, in this embodiment, when the arbitration device is in the second detection cycle, i.e., evaluating whether the second node can become the master node, if it simultaneously detects that the third node has also initiated a master-claiming request, the arbitration device will obtain the third cluster state of the third node. This acquisition action is to further compare the cluster states between the second and third nodes to ensure that the elected master node has the latest cluster information.

[0045] After the arbitration device compares the cluster states of the second and third nodes, if the cluster state of the second node is newer or more advanced than that of the third node, the arbitration device will officially determine the second node as the cluster master node. This step provides the final decision for master node election while ensuring the up-to-dateness of the state, preventing a node with an older state from becoming the master node, thereby maintaining the consistency of the cluster state and the continuity of data services.

[0046] Through the embodiments provided in this application, during network partitioning or node failures, when there are more than three nodes in the cluster, the master node decision-making process can be controlled more finely to ensure that the node with the latest state becomes the master node. Based on the foregoing, if the arbitration device detects that a third node has also initiated a master node preemption request during the second detection cycle, it will obtain the third node's third cluster state for comparison. If the second node's cluster state (second cluster state) is more up-to-date than the third node's cluster state (third cluster state), then the second node will be ultimately determined as the cluster master node. This mechanism can effectively avoid the risks caused by the uncertainty of the cluster state. Even in complex and ever-changing network environments, it can quickly determine the latest node as the master node through state comparison, thereby avoiding data service interruptions or errors caused by state inconsistencies.

[0047] As an optional approach, after obtaining the state of the third cluster associated with the third node, the method further includes:

[0048] If the third cluster state contains more update timestamps than the second cluster state, the third node is updated as a candidate master node, and the third detection cycle corresponding to the third master grabbing request is started. The third detection cycle is used to verify whether the third node is the master node.

[0049] Optionally, in this embodiment, the third detection period is activated by the arbitration device after determining that the third node is a candidate master node, and is used to further verify whether the third node should become the master node of the cluster. The third detection period is the detection time period set by the yield timer (a timer maintained internally by the third node) for the third master grabbing request, which can be set to a range of several seconds to tens of seconds, such as the common 5 seconds or 10 seconds.

[0050] Optionally, in this embodiment, when the arbitration device receives the third host-grabbing request from the third node during the second detection cycle and obtains its third cluster status, it will enter the subsequent decision-making process.

[0051] If the third node's third cluster state is updated or more advanced than the second node's second cluster state, the arbitration device will remove the second node from the candidate master node list and update the third node as the new candidate master node. This update action reflects the arbitration device's decision-making principle based on state comparison, ensuring that the node with the most up-to-date state has a chance to become the master node.

[0052] After updating the third node as a candidate master node, the arbitration device will initiate a third detection cycle to monitor whether the third node becomes the only candidate node with the latest state within this cycle. During the third detection cycle, the arbitration device will continuously compare the states of other nodes. If no other requests to update the master node's state are detected, the third node will be officially determined as the cluster's master node and take over cluster control. This cycle ensures the finality of the master node election decision, avoids potential node state conflicts, and enhances system stability and data consistency.

[0053] Through the embodiments provided in this application, during network partitioning or node failures, when three or more nodes exist, the arbitration device can perform more refined state comparisons and master node verification. By setting a third detection cycle, the arbitration device can continuously verify whether the third node has the latest cluster state among all competitors, thereby accurately determining the master node in a multi-node environment and maintaining the high availability and data consistency of the distributed storage system. This decision-making method not only embodies the principle of state priority but also ensures the finality of the decision and the stability of the system through the detection cycle mechanism.

[0054] As an optional approach, before determining the first node as a candidate master node in response to the first master-claiming request from the first node in the cluster, the method further includes:

[0055] Get at least one master-grabbing request from at least one node in the cluster, wherein the effective duration of each master-grabbing request is the same and the effective duration is less than the first detection period and less than the second detection period.

[0056] The first master-claiming request of the first node is determined from at least one master-claiming request, wherein the first master-claiming request is the master-claiming request that was triggered earliest among at least one master-claiming requests.

[0057] Optionally, in this embodiment, the effective duration refers to the length of time that the preemptive request remains valid on the arbitration device. This duration determines the response time and processing mechanism of the arbitration device to the request.

[0058] Optionally, in this embodiment, when a network partition or node failure occurs in the cluster, multiple nodes may initiate master-preemption requests almost simultaneously, and at least one master-preemption request refers to a portion or all of these request sets.

[0059] Optionally, in this embodiment, when the cluster faces network partition or other failures, the arbitration device will collect master-claiming requests from at least one node. These requests may come from multiple nodes in the cluster, including but not limited to the first node, the second node, and the third node.

[0060] To ensure the fairness and efficiency of the arbitration process, the validity period for each master node preemption request on the arbitration device is set to be the same, and this duration is shorter than the first and second detection cycles. This validity period prevents requests from expiring or timed out, ensuring that the arbitration device can respond to node preemption requests in a timely manner, while also allowing sufficient time for comparing node states and verifying the master node.

[0061] Upon receiving at least one master-preemption request, the arbitration device will identify and determine the earliest triggered master-preemption request, i.e., the first node's master-preemption request. The principle of earliest trigger time ensures that the arbitration device can prioritize responding to the node that initiated the master-preemption request earliest, granting it initial candidate master-node status.

[0062] Once the first request to claim master node is identified as the earliest triggered request, the arbitration device will follow the first-come, first-served principle and treat it as a preliminary candidate master node, thus initiating the master node election and state comparison process.

[0063] The embodiments provided in this application determine the first master-claiming request based on the earliest trigger time, and preliminarily identify the first node as a candidate master node. This preliminary determination provides a starting point for subsequent state comparisons, ensuring that the node that initiates the master-claiming request earliest has priority in the election process. Simultaneously, the decision logic of the arbitration device fully considers the complexity of multiple nodes initiating master-claiming requests. By setting an effective duration and a mechanism for identifying the earliest trigger time request, it ensures the fairness and efficiency of master node election, providing strong support for the stable operation and rapid recovery of the distributed storage system in the face of network partitions or node failures.

[0064] As an optional approach, after obtaining the first cluster state associated with the first node and the second cluster state associated with the second node, the method further includes:

[0065] If the first cluster state contains more update timestamps than the second cluster state, the first node will be determined as the master node.

[0066] The first notification information is sent back to the second node, which is used to indicate that the second attempt to take over the host failed and to instruct the second node to prohibit external services.

[0067] Optionally, in this embodiment, the first notification information refers to the instruction information sent by the arbitration device to a non-master node (such as the second node) after determining the master node. It includes a notification that the second master request failed, as well as an instruction requiring the second node to suspend or prohibit external services.

[0068] In a distributed system, when a node is determined to be a non-master node or has an outdated state, that node will be required to stop providing any external data services or control functions to avoid data inconsistency or service conflicts.

[0069] Optionally, in this embodiment, if the arbitration device, after comparing the cluster states of the first node and the second node, finds that the first node's first cluster state is updated or more advanced than the second node's second cluster state, then it will officially determine the first node as the cluster's master node. Once determined, the master node will be responsible for coordinating the operation of the entire cluster and providing data services and control functions to the outside world.

[0070] After the first node is determined to be the cluster's master node, the arbitration device sends a first notification message to the second node, informing it that its attempt to become the master node failed. This first notification message also includes an instruction to prohibit the second node from providing external services, requiring it to suspend all external services and control functions to maintain cluster consistency and data service integrity. This instruction prevents non-master nodes from providing services in an outdated state, thus preventing data inconsistency and potential system failures.

[0071] Through the embodiments provided in this application, after obtaining the cluster status of the first and second nodes, the arbitration device can not only determine the latest node as the master node based on status comparison, but also send a first notification message to the node with the older status, informing it that its master request failed and requiring it to prohibit external services. This mechanism ensures that when a network partition or node failure occurs, the cluster can quickly and accurately determine the node with the latest status and most suitable to be the master node. At the same time, by prohibiting non-master node services, data inconsistency and service conflicts are avoided, maintaining the high availability and data consistency of the cluster.

[0072] As an optional approach, after obtaining the first cluster state associated with the first node and the second cluster state associated with the second node, the method further includes:

[0073] If the second cluster state contains more update timestamps than the first cluster state, a second notification message is sent to the first node. The second notification message is used to indicate that the first master-grabbing request failed and to instruct the first node to prohibit external services.

[0074] Optionally, in this embodiment, the second notification message is similar to the first notification message. This is a message sent by the arbitration device to a node with an older status (such as the first node), which includes an indication that its attempt to become the host failed and a requirement to prohibit external services.

[0075] Optionally, in this embodiment, if the arbitration device determines that the cluster state of the second node is newer or more advanced than that of the first node, it means that the second node is in the most recent state and is more suitable as the master node.

[0076] In this situation, the arbitration device will send a second notification message to the first node, indicating that the first attempt to seize the initiative was unsuccessful and requesting the first node to cease providing all external services.

[0077] The second notification message clarified that the first node's attempt to become the master failed and emphasized that the first node must immediately cease providing external services. This instruction ensures that older nodes in the cluster do not interfere with the operation of the cluster led by the node with the most recent state, thus maintaining system consistency and stability.

[0078] According to the embodiments provided in this application, when the arbitration device detects that the second cluster state is updated to the first cluster state, indicating that the second node is more suitable to be the next master node, it immediately sends a second notification message to the first node. The second notification message explicitly indicates that the first master-claim request has failed and requires the first node to immediately cease all external services, including but not limited to data read / write, status query, and control interface. This mechanism ensures that nodes with older states will not continue to provide services, avoiding data inconsistency and potential system failures.

[0079] As an optional approach, before determining the first node as a candidate master node in response to the first master-claiming request from the first node in the cluster, the method further includes:

[0080] Obtain at least two sub-clusters obtained after performing a partitioning operation on the first cluster, wherein the first master node of the first cluster is located in the target sub-cluster among at least two sub-clusters after the partitioning operation;

[0081] In at least two sub-clusters, the sub-cluster outside the target sub-cluster is identified as the cluster with the master node to be determined.

[0082] Optionally, in this embodiment, the first cluster refers to the complete initial cluster state without network partitions or failures, including all nodes and resources.

[0083] Optionally, in this embodiment, the partitioning operation is the operation of dividing the first cluster into at least two independent sub-clusters when the cluster encounters a network partition or failure, in order to adapt to the isolation between nodes.

[0084] Optionally, in this embodiment, the target sub-cluster refers to the sub-cluster containing the first master node of the first cluster, that is, the small cluster where the first master node is located after the partitioning operation. The clusters whose master nodes need to be determined refer to other sub-clusters besides the target sub-cluster, and these sub-clusters need to determine new master nodes to continue providing services.

[0085] Optionally, in this embodiment, when the first cluster encounters network partitioning or node failure, the arbitration device (or management system) will perform a partitioning operation on the first cluster, forming at least two mutually isolated sub-clusters. The purpose of the partitioning operation is to adapt to changes in network conditions and ensure that each sub-cluster can operate independently without being affected by other parts.

[0086] After the partitioning operation, the original primary master node will reside in a sub-cluster, which is called the target sub-cluster. Since the target sub-cluster already contains the primary master node, theoretically, there is no need to re-elect a master node, unless the primary master node itself fails or is deemed outdated.

[0087] For sub-clusters other than the target sub-cluster, since they do not contain the original first master node, a new master node needs to be determined. These sub-clusters are called the clusters awaiting master node determination, and they will initiate master-claiming requests. The arbitration device will determine the new master node based on the latest cluster status information.

[0088] According to the embodiments provided in this application, when a cluster encounters network partitioning or node failure, resulting in the need to divide the cluster into at least two sub-clusters, the arbitration device (or management system) first needs to identify the target sub-cluster where the original master node resides, as well as those sub-clusters that require a new master node election. The sub-cluster where the original first master node resides, i.e., the target sub-cluster, in principle, does not need a new master node election because it already has a relatively stable node control center that is likely up-to-date in its state. However, for other sub-clusters outside the target sub-cluster, since they have lost direct communication capabilities with the first master node, a new master node needs to be elected from these clusters where a master node is yet to be determined to ensure the continuity of cluster services and data consistency. This process involves each sub-cluster node initiating a master-claim request to the arbitration device, which then determines which nodes are more suitable to become the new master node by comparing the states of each node based on the latest cluster state information.

[0089] As an optional approach, before determining the first node as a candidate master node in response to the first master-claiming request from the first node in the cluster, the method further includes:

[0090] Obtain the third cluster obtained after performing a merge operation on the first and second clusters, wherein the third cluster includes the first master node and the second master node of the second cluster;

[0091] If the first and second master nodes are updated to non-master nodes, the third cluster is identified as the cluster with the master node to be determined.

[0092] Optionally, in this embodiment, the first cluster refers to an existing and running cluster with its own master node, i.e., the first master node. The second cluster refers to another independently running cluster with its own master node, i.e., the second master node.

[0093] Optionally, in this embodiment, the merge operation is an operation performed when two or more clusters need to be integrated into a larger cluster under specific conditions. This operation may occur in scenarios such as network recovery, system expansion, or cluster fusion. The third cluster refers to the new cluster formed by the integration of the first and second clusters after the merge operation; it includes the first master node and the second master node.

[0094] Optionally, in this embodiment, when two independently operating clusters (the first cluster and the second cluster) need to be merged due to network recovery, system requirements, or management decisions, the arbitration device will participate in supervising and confirming this operation. After the merge operation is completed, the arbitration device needs to obtain the overall information of the new cluster (the third cluster) formed by the merge, including the status of the first master node and the second master node therein.

[0095] After the merge operation, in order to re-elect a master node, the arbitration device first updates the status of the first master node of the first cluster and the second master node of the second cluster to a non-master node state. This update process signifies that the original master node no longer performs the duties of a master node, and the cluster is in a transition period, waiting for a new master node to be elected.

[0096] After updating the states of the first and second master nodes, the third cluster becomes the cluster awaiting master node determination, meaning that the third cluster needs to determine a new master node through a master node contention process. This determination process is to ensure that the merged cluster has a unified control center to maintain service continuity and data consistency.

[0097] According to the embodiments provided in this application, when two independently operating clusters (a first cluster and a second cluster) need to be merged for some reason, this process involves not only physical or network-level integration but also requires the system to logically redefine the role of the master node to adapt to the new cluster structure and operational requirements. After the merge operation, the arbitration device or management system needs to reassess the status of the cluster's master node to ensure that each cluster has a unified and up-to-date control center after the merge.

[0098] Specifically, once the arbitration device confirms the merge operation of the first and second clusters, it acquires information about the resulting third cluster. Subsequently, to re-elect a master node, it updates the status of the original first master node of the first cluster and the second master node of the second cluster to non-master nodes, meaning these two nodes will no longer perform the duties of a master node. In this state, the third cluster is designated as the cluster awaiting a master node determination. Nodes within the cluster will initiate master-claim requests, and the arbitration device, based on the latest node status information, compares and determines the new master node to ensure the stable operation of the merged cluster and the consistency of data services.

[0099] As an optional approach, determining the first node as a candidate master node for the cluster includes:

[0100] Write the first node's information into the arbitration device, where the arbitration device does not store any node information; or,

[0101] Replace the historical node information of the historical master node stored in the arbitration device with the first node information. The historical master node is a node in the cluster that has stopped providing external services.

[0102] Optionally, in this embodiment, the first node information includes key information such as the ID, status, and timestamp of the first node, which is used by the arbitration device to identify and compare the node status and decide whether to identify the first node as a candidate master node.

[0103] Optionally, in this embodiment, historical node information refers to the node information stored in the arbitration device that was previously determined to be the master node, which may no longer be the master node due to network partitioning, failure, or status update.

[0104] Optionally, in this embodiment, when the arbitration device has not yet stored any node information (i.e., during system initialization or when all nodes are offline and restarted), after the first node successfully requests to become the master node, its first node information will be written to the arbitration device for the first time. This step makes the first node a preliminary candidate master node of the cluster, but its status still needs to be further verified to ensure that it is up-to-date.

[0105] When the arbitration device already stores information about the historical master node, but the historical master node has ceased service due to failure or other reasons, if the first node successfully requests to become the new master node, its information will replace the historical master node's information. This replacement operation indicates that the first node, based on the latest status information, has replaced the historical master node and become the new candidate master node.

[0106] Through the embodiments provided in this application, in a multi-node competition state, the arbitration device can always make decisions based on the latest status information to ensure that the node most suitable as the master node gets control, thereby improving the availability and reliability of the cluster service.

[0107] As an optional approach, updating the second node as a candidate master node includes:

[0108] The first node information stored in the arbitration device is replaced with the second node information. The node corresponding to the node information stored in the arbitration device is the candidate master node. At most one node's node information is stored in the arbitration device at the same time.

[0109] Optionally, in this embodiment, when the second node submits a request to take over the master node and passes the verification of the arbitration device, and is determined to be a new candidate master node, the information of the first node stored in the arbitration device will be removed or marked as invalid.

[0110] Subsequently, the arbitration device will store the new second node information, which means that the second node has become the new candidate master node, and its status information occupies a unique position in the arbitration device.

[0111] Optionally, in this embodiment, the node information stored in the arbitration device always corresponds to the node currently identified as a candidate master node. The storage design of the arbitration device follows the principle of uniqueness, meaning that at any given time, the arbitration device can only store one piece of node information, which corresponds to the current candidate master node. This avoids confusion and conflict during the arbitration process and ensures the clarity of the system when determining the master node.

[0112] According to the embodiments provided in this application, when a second node is determined as a new candidate master node due to its superior state, the node information stored in the arbitration device will undergo a critical replacement operation. This operation aims to ensure that the node information stored in the arbitration device always corresponds to the current candidate master node, and that at any given time, the arbitration device only stores one such piece of information to maintain the stability of the cluster and the unity of decision-making.

[0113] As an alternative approach, after determining the second node as the cluster's master node, the method also includes:

[0114] Perform a state upgrade operation on the second node, wherein the state difference between the upgraded second node and the cluster state of any node in the cluster is greater than a preset difference range.

[0115] Optionally, in this embodiment, the state upgrade operation refers to the process of updating and upgrading the cluster state of the second node after it has been determined as the master node of the cluster, so as to ensure that its state is significantly ahead of any other node in the cluster.

[0116] Optionally, in this embodiment, the preset difference range is a threshold set by the system to measure whether the differences between cluster states are sufficient to support the leadership of the master node. If the state differences exceed this range, the node is considered suitable to be upgraded to a new master node.

[0117] Optionally, in this embodiment, this step occurs after the arbitration device determines, based on the comparison results, that the second node is the master node of the cluster and has the optimal state to lead the entire cluster.

[0118] Once the second node is designated as the master node, to prevent other nodes from attempting to reclaim the master position during potential network partitions or fault recovery, the system needs to perform a state upgrade operation on the second node. The purpose of the state upgrade operation is to improve the cluster state of the second node, making its state significantly better than all other nodes for a period of time, thereby strengthening its leadership position in the cluster.

[0119] After the status upgrade, the second node will have a cluster state that is significantly different from any other node in the cluster, exceeding a preset range. This operation ensures that even if a network failure occurs and recovery is made, the second node, with its leading status, can quickly restore cluster services, reduce service interruption time, and prevent other nodes from attempting to regain master node status.

[0120] The implementation of the state upgrade operation provided in this application not only enhances the leadership of the second node in the cluster but also provides greater assurance for the system in dealing with complex network environments and fault recovery. By significantly upgrading the state of the master node, uncertainty and service interruption time caused by network partitions or node failures can be reduced, ensuring that even in adverse environments, the master node can quickly recover and take over control of the cluster services, thereby improving the high availability of the distributed storage system and the continuity of data services.

[0121] As an optional solution, the aforementioned method for determining the master node of a cluster can be applied to an arbitration scenario in a fast distributed storage system. In this scenario, high availability is a core requirement of the storage system, which achieves high availability at the control head level through multi-controller redundancy. These multiple controllers need to form a coordinated cluster. When some controllers fail, the surviving controllers need to take over the cluster's operations. When a network partition occurs between controllers, one of the partitions needs to take over the cluster. Cluster takeover should adhere to the principle of uniqueness; that is, when there are multiple possible takeover partitions, the takeover strategy should ensure that at most one partition can take over. Otherwise, if multiple partitions take over, a split-brain phenomenon will occur, preventing the cluster from providing consistent services. When the number of cluster nodes is odd, at most one network partition with more than half the nodes will occur, in which case the partition with more than half the nodes should take over the cluster. When the total number of cluster nodes is even, if a network split occurs, a third-party arbitration device is needed to break the tie and achieve unique partition takeover.

[0122] Traditional arbitration technology involves introducing one or more third-party devices (usually disks) that can communicate with all nodes (controllers) within the cluster. When a cluster network split occurs, both partitions can preemptively claim the arbitration device on a first-come, first-served basis.

[0123] Traditional arbitration techniques do not consider the age of the two nodes. If an arbitration request from an older node arrives at the arbitration device first, followed by a request from a newer node, the older node will eventually take over the cluster, resulting in the loss of some state data from the newer nodes. Business layers that rely on cluster services need additional retry and redo logic to handle potential data loss; otherwise, system errors may occur.

[0124] In traditional arbitration techniques, a node that fails to preempt the hostage needs to passively wait for several heartbeat cycles before it can stop providing service. Before this cycle is reached, the taking over node must also suspend service because the non-taking over node might still be able to provide state read services. If the taking over node starts providing state read and write services too early, clients accessing the cluster state might write the latest state to the taking over node and then send state read requests to the non-taking over nodes, resulting in reading outdated state data and causing data inconsistency in the application. To prevent data inconsistency, the current practice is to agree on a disconnection and exit time on all nodes. After a network partition occurs, the taking over node needs to suspend services for at least this time. This impacts the system's service availability.

[0125] To overcome the aforementioned shortcomings, this embodiment significantly expands upon the existing general technical solutions' "reserve-success-release-takeover" and "reserve-failure-yield" protocols. The system composition remains two storage nodes and one arbitration device. A timing diagram of an arbitration interaction method is shown below. Figure 3 As shown, it specifically includes:

[0126] Storage nodes 1 and 2 were originally in the same cluster, but a connection loss occurred. Storage node 1 holds a newer cluster state s1, while storage node 2 holds a cluster state s2 that is not newer than s1. At the same time, the arbitration reservation request of storage node 1 arrives at the arbitration device first.

[0127] Storage node 1 and storage node 2 start a yield timer with a duration of t, which is agreed upon by the system. If the timer expires and the takeover is not completed, the nodes will unconditionally stop operations, and the node status will change to offline.

[0128] Storage node 1 attempts to acquire the arbitration device and succeeds. Subsequently, storage node 2's arbitration device reservation request reaches the arbitration device, which returns a reservation conflict and continues to retry. Storage node 1 initiates a status read request to the arbitration device. The returned status is empty (or has a status but older than storage node 1's own status s1). Storage node 1 then writes its own status s1 to the arbitration device, and releases the arbitration device after completion. Storage node 1 then cancels the yield timer and starts a takeover timer with a duration T>t.

[0129] Storage node 1 begins continuously monitoring the `yield` bit (a flag that a storage node sets when it finds itself not the latest state node or is in a disadvantageous position in the arbitration competition, indicating that it is willing to "yield" or voluntarily "abstain" and will no longer attempt to become the cluster master node) and the `takeover` bit (a flag that indicates a node is taking over control of the cluster, meaning that the node believes itself to be the latest state node, has successfully completed the arbitration process, and is ready to assume the responsibilities of the master node). If storage node 2 can establish a connection with the arbitration device, its arbitration reservation request will succeed. After successful reservation, storage node 2 reads the information from the arbitration device, finds that `s1>=s2`, and therefore no longer attempts to take over. After stopping local external services, it writes the `yield` bit.

[0130] If storage node 2 cannot connect to the storage device, it waits for the yield timer to expire, then stops all services and enters an offline state.

[0131] If storage node 1 detects the yield bit before the takeover timer expires, it confirms that the other party has relinquished takeover. If the yield bit is not detected by the timer expires, it can be inferred that the other party has stopped operations and gone offline, based on the fact that the takeover timer duration T is greater than and the yield timer duration t. Therefore, the arbitration device is reserved again. Upon successful arbitration, the takeover timer is canceled, and the local state is quickly raised to s1', which is newer than s1. The difference between s1' and s1 must be greater than the maximum allowable difference in state between nodes within the cluster. The arbitration device is then released.

[0132] The following example assumes that the storage node 2 with the older state is the first to preempt arbitration. A timing diagram of another arbitration interaction method is shown below. Figure 4 As shown, it specifically includes:

[0133] Optionally, in this embodiment, storage node 1 and storage node 2 start a yield timer with a duration of t, which is agreed upon. If the timer expires and the takeover is not completed, the node will unconditionally stop its services, and its state will change to offline. Storage node 2 attempts to acquire the arbitration device and succeeds.

[0134] Subsequently, the arbitration device reservation request from storage node 1 arrives at the arbitration device, which returns a reservation conflict and then continues to retry. Storage node 2 initiates a status read request to the arbitration device. The returned status is empty (or has a status but older than storage node 1's own status s1). Storage node 1 then writes its own status s2 to the arbitration device, and releases the arbitration device after completion. Storage node 2 then cancels the yield timer and starts a takeover timer with a duration of T>t.

[0135] Storage node 2 begins continuously monitoring the yield bit and takeover bit. Storage node 1's arbitration reservation request succeeds. After successful reservation, storage node 2 reads the information from the arbitration device and finds that s1 > s2, therefore it will attempt to take over, writing the local state s1 and takeover bit. Storage node 1 cancels the yield timer and starts the takeover timer.

[0136] Storage node 1 releases the arbitration device and begins monitoring the yield bit. Storage node 2 detects the takeover bit. Storage node 2 cancels the takeover timer. Storage node 2 re-initiates the arbitration device reservation, and writes the yield bit upon success.

[0137] If storage node 1 detects the yield bit before the takeover timer expires, it confirms that the other party has relinquished takeover. It then reserves the arbitration device again; upon successful arbitration, it cancels the takeover timer and quickly raises its local state to s1', which is newer than s1. The difference between s1' and s1 must be greater than the maximum permissible state difference between nodes within the cluster.

[0138] If the yield bit is not detected by the time the takeover timer expires, it can be inferred that the peer has stopped service and gone offline, based on the fact that the takeover timer duration T is greater than and the yield timer duration t. Therefore, the arbitration device is reserved again. Upon successful arbitration, the takeover timer is canceled, and the local state is quickly raised to s1', which is newer than s1. The difference between s1' and s1 must be greater than the maximum allowable difference in state between nodes within the cluster. The arbitration device is then released.

[0139] The embodiments provided in this application enhance system stability. Through the extended protocol, it is ensured that only the node with the latest state can take over the cluster when both sites in the storage cluster can connect to the arbitration device. System availability is also enhanced. By using the yield bit interaction, the waiting time associated with the takeover timer is avoided. Typically, the takeover timer duration is set to several network heartbeat cycles, approximately 5-10 seconds. However, with the yield bit interaction, this duration can be shortened to several disk access latency, thus being compressed to sub-second levels, significantly reducing service downtime after system network partitioning.

[0140] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0141] This embodiment also provides a cluster master node determination device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0142] Figure 5 This is a structural block diagram of the cluster master node determination device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0143] The first determining unit 502 is used to respond to the first master-claiming request of the first node in the cluster and determine the first node as a candidate master node of the cluster.

[0144] The acquisition unit 504 is used to acquire the first cluster state associated with the first node and the second cluster state associated with the second node when a second host-grabbing request is detected in the first detection period corresponding to the first host-grabbing request. The first cluster state indicates the cluster running state stored on the first node when the first host-grabbing request is triggered, and the second cluster state indicates the cluster running state stored on the second node when the second host-grabbing request is triggered.

[0145] The second determining unit 506 is used to determine the second node as the master node of the cluster when the second cluster state contains more update timestamps than the first cluster state.

[0146] As an optional solution, the second determining unit 506 includes:

[0147] The first update module is used to update the second node as a candidate master node when the second cluster state contains more update timestamps than the first cluster state.

[0148] The first determination module is used to determine the second node as the master node if no master-preemption request from other nodes in the cluster is detected within the second detection period corresponding to the second master-preemption request.

[0149] As an optional solution, the second determining unit 506 includes:

[0150] The first acquisition module is used to acquire the third cluster status associated with the third node when a third master-grabbing request is detected in the third node in the cluster during the second detection period. The third cluster status indicates the cluster running status stored on the third node when the third master-grabbing request is triggered.

[0151] The second determination module is used to determine the second node as the master node when the second cluster state contains more update timestamps than the third cluster state.

[0152] As an optional solution, the device also includes:

[0153] The second update module is used to update the third node as a candidate master node after obtaining the status of the third cluster associated with the third node, and if the status of the third cluster contains more update timestamps than the status of the second cluster, and start the third detection cycle corresponding to the third master grabbing request. The third detection cycle is used to verify whether the third node is a master node.

[0154] As an optional solution, the device also includes:

[0155] The second acquisition module is used to acquire at least one master-grabbing request of at least one node in the cluster before determining the first node as a candidate master node in response to the first master-grabbing request of the first node in the cluster, wherein the effective duration of each master-grabbing request in the at least one master-grabbing request is the same, and the effective duration is less than the first detection period and less than the second detection period.

[0156] The third determining module is used to determine the first master-grabbing request of the first node from at least one master-grabbing request before determining the first node as a candidate master node of the cluster in response to the first master-grabbing request of the first node in the cluster, wherein the first master-grabbing request is the master-grabbing request with the earliest trigger time among at least one master-grabbing request.

[0157] As an optional solution, the device also includes:

[0158] The fourth determination module is used to determine the first node as the master node after obtaining the first cluster state associated with the first node and the second cluster state associated with the second node, provided that the first cluster state contains more update timestamps than the second cluster state.

[0159] The first feedback module is used to send a first notification message to the second node after obtaining the status of the first cluster associated with the first node and the status of the second cluster associated with the second node. The first notification message is used to indicate that the second attempt to take over the host failed and to instruct the second node to prohibit external services.

[0160] As an optional solution, the device also includes:

[0161] The second feedback module is used to, after obtaining the first cluster status associated with the first node and the second cluster status associated with the second node, provide second notification information to the first node if the second cluster status contains more update timestamps than the first cluster status. The second notification information is used to indicate that the first master-grabbing request failed and to instruct the first node to prohibit external services.

[0162] As an optional solution, the device also includes:

[0163] The third acquisition module is used to acquire at least two sub-clusters obtained after performing a partitioning operation on the first cluster before determining the first node as a candidate master node in response to the first master-grabbing request of the first node in the cluster. The first master node of the first cluster is located in the target sub-cluster among the at least two sub-clusters after the partitioning operation.

[0164] The fifth determination module is used to determine the sub-cluster outside the target sub-cluster as the cluster to be determined as the master node before determining the first node as the candidate master node in response to the first master-grabbing request of the first node in the cluster.

[0165] As an optional solution, the device also includes:

[0166] The fourth acquisition module is used to acquire the third cluster obtained after performing a merge operation on the first cluster and the second cluster in response to the first node's first master-grabbing request in the cluster and before determining the first node as a candidate master node of the cluster. The third cluster includes the first master node and the second master node of the second cluster.

[0167] The sixth determination module is used to determine the third cluster as the cluster with the master node to be determined before determining the first node as a candidate master node in response to the first master-grabbing request of the first node in the cluster, and after updating the first master node and the second master node to non-master nodes.

[0168] As an optional solution, the first determining unit 502 includes:

[0169] The writing module is used to write the first node's information into the arbitration device, where the arbitration device does not store any node information; or,

[0170] The first replacement module is used to replace the historical node information of the historical master node stored in the arbitration device with the first node information, wherein the historical master node is a node in the cluster that has stopped providing external services.

[0171] As an optional solution, the first update module includes:

[0172] The second replacement module is used to replace the first node information stored in the arbitration device with the second node information. The node corresponding to the node information stored in the arbitration device is a candidate master node. At most one node's node information can be stored in the arbitration device at the same time.

[0173] As an optional solution, the device also includes:

[0174] The upgrade module is used to perform a state upgrade operation on the second node after it has been determined as the master node of the cluster. The state difference between the cluster state of the upgraded second node and the cluster state of any node in the cluster is greater than a preset difference range.

[0175] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0176] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0177] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0178] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0179] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0180] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0181] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0182] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium storing the computer program product, wherein the computer program, when executed by a processor, implements the steps of the methods in various embodiments of this application.

[0183] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0184] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0185] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining the master node of a cluster, characterized in that, include: In response to the first master-claiming request from the first node in the cluster, the first node is determined as the candidate master node of the cluster; If a second host-grabbing request is detected in the cluster within the first detection period corresponding to the first host-grabbing request, the first cluster state associated with the first node and the second cluster state associated with the second node are obtained. The first cluster state indicates the activity information, data distribution and node health status of the cluster stored on the first node when the first host-grabbing request is triggered, and the second cluster state indicates the activity information, data distribution and node health status of the cluster stored on the second node when the second host-grabbing request is triggered. If the second cluster state contains more update timestamps than the first cluster state, it is determined that the second cluster state is better than the first cluster state, and the second node with the better cluster state is updated as the candidate master node. If no other node in the cluster makes a master-preemption request within the second detection period corresponding to the second master-preemption request, the second node will be determined as the master node.

2. The method according to claim 1, characterized in that, The method further includes: If a third master-grabbing request is detected in the third node of the cluster during the second detection period, the third cluster status associated with the third node is obtained, wherein the third cluster status indicates the cluster running status stored on the third node when the third master-grabbing request is triggered. If the second cluster state contains more update timestamps than the third cluster state, the second node is determined as the master node.

3. The method according to claim 2, characterized in that, After obtaining the state of the third cluster associated with the third node, the method further includes: If the third cluster state contains more update timestamps than the second cluster state, the third node is updated to the candidate master node, and the third detection period corresponding to the third master grabbing request is started. The third detection period is used to verify whether the third node is the master node.

4. The method according to claim 1, characterized in that, Before determining the first node as a candidate master node of the cluster in response to the first master-claiming request of the first node in the cluster, the method further includes: Obtain at least one master-claiming request from at least one node in the cluster, wherein the effective duration of each master-claiming request is the same, and the effective duration is less than the first detection period and less than the second detection period; The first master-grabbing request of the first node is determined from the at least one master-grabbing request, wherein the first master-grabbing request is the master-grabbing request with the earliest trigger time among the at least one master-grabbing requests.

5. The method according to claim 1, characterized in that, After obtaining the first cluster state associated with the first node and the second cluster state associated with the second node, the method further includes: If the first cluster state contains more update timestamps than the second cluster state, the first node is determined as the master node; The first notification information is sent back to the second node, wherein the first notification information is used to indicate that the second attempt to claim the host failed, and to instruct the second node to prohibit external services.

6. The method according to claim 1, characterized in that, After obtaining the first cluster state associated with the first node and the second cluster state associated with the second node, the method further includes: If the second cluster state contains more update timestamps than the first cluster state, a second notification message is sent to the first node. The second notification message is used to indicate that the first master-grabbing request failed and to instruct the first node to prohibit external services.

7. The method according to claim 1, characterized in that, Before determining the first node as a candidate master node of the cluster in response to the first master-claiming request of the first node in the cluster, the method further includes: Obtain at least two sub-clusters after performing a partitioning operation on a first cluster, wherein the first master node of the first cluster is located in the target sub-cluster among the at least two sub-clusters after the partitioning operation; The sub-cluster outside the target sub-cluster among the at least two sub-clusters is identified as the cluster with the master node to be determined.

8. The method according to claim 7, characterized in that, Before determining the first node as a candidate master node of the cluster in response to the first master-claiming request of the first node in the cluster, the method further includes: Obtain a third cluster obtained after performing a merge operation on the first cluster and the second cluster, wherein the third cluster includes the first master node and the second master node of the second cluster; If the first master node and the second master node are updated to non-master nodes, the third cluster is determined as the cluster with the master node to be determined.

9. The method according to claim 1, characterized in that, The step of determining the first node as a candidate master node of the cluster includes: Write the first node information of the first node into the arbitration device, wherein the arbitration device does not store any node information; or, Replace the historical node information of the historical master node stored in the arbitration device with the first node information, wherein the historical master node is a node in the cluster that has stopped providing external services.

10. The method according to claim 9, characterized in that, The step of updating the second node to the candidate master node includes: The first node information stored in the arbitration device is replaced with the second node information, wherein the node corresponding to the node information stored in the arbitration device is the candidate master node, and the arbitration device stores at most one node's node information at any given time.

11. The method according to any one of claims 1 to 10, characterized in that, After determining the second node as the master node of the cluster, the method further includes: A state upgrade operation is performed on the second node, wherein the state difference between the cluster state of the upgraded second node and the cluster state of any node in the cluster is greater than a preset difference range.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

Images