Data recovery method and device, electronic equipment and storage medium

Abstract

Embodiments of the present disclosure provide a data recovery method and device, electronic equipment and storage medium, relating to the field of databases, which can be used in the field of distributed databases. The method comprises: obtaining replica information reported by each surviving node; if it is determined that an abnormal data shard based on the replica information reported by each surviving node, determining a target replica from at least one replica of the abnormal data shard in each surviving node; and in the case that a preset recovery trigger condition is met, processing log recovery for the abnormal data shard through the target replica. Embodiments of the present disclosure ensure that the log can be advanced and consistency can be maintained when the majority is unavailable, realize non-stop recovery, do not need to suspend services or manual intervention, the recovery process is completely automated, reduce the risk of manual operation, improve the recovery efficiency and stability, and thus improve the high availability of the distributed system.

Description

Technical Field

[0001] This disclosure relates to the field of database technology, and more specifically, to a data recovery method, apparatus, electronic device, and storage medium. Background Technology

[0002] In distributed database systems, multi-replica mechanisms (such as the Raft consensus protocol) are typically used to ensure data reliability and high availability. When some nodes fail, as long as a majority of replicas remain alive, the system can still continue to provide services and maintain data consistency. However, when a failure renders a majority of replicas unavailable, existing solutions often rely on manual intervention or offline recovery tools, requiring system service interruption. The recovery process is time-consuming and prone to data loss. Summary of the Invention

[0003] This disclosure provides a data recovery method, apparatus, electronic device, and storage medium, which can solve the problem of inability to automatically recover data in scenarios where a majority of data is unavailable in the prior art. The technical solution provided by this disclosure is as follows: According to one aspect of the present disclosure, a data recovery method is provided, the method comprising: Obtain the replica information reported by each surviving node; the replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica; If an abnormal data shard is determined based on the replica information reported by each surviving node, then a target replica is determined from at least one replica of the abnormal data shard in each surviving node; the abnormal data shard is a data shard in which the number of corresponding replicas in each surviving node is no more than half of the preset number of replicas. Under the condition that the preset recovery triggering conditions are met, the target replica processes the log recovery for the abnormal data shard; the preset recovery triggering conditions include appending the application log index of the target replica to the reference commit log index, the reference commit log index being the commit log index of the target replica when each surviving node reports replica information.

[0004] Optionally, determining the target replica from at least one replica of the anomalous data shard in each surviving node includes: If the number of at least one replica for the abnormal data shard is 1, then the replica for the abnormal data shard is used as the target replica. If the number of at least one replicas for the abnormal data shard is greater than 1, then the target replica is determined from the at least one replica for the abnormal data shard based on the last log index and last log term of each replica.

[0005] Optionally, if the number of at least one replica for an anomalous data shard is greater than 1, the step of processing log recovery for the anomalous data shard through the target replica includes: The target replica copies the uncommitted logs for the anomalous data shard to other replicas of the anomalous data shard besides the target replica, and commits the uncommitted logs.

[0006] Optionally, the step of processing log recovery for the abnormal data shard through the target replica when the preset recovery trigger condition is met further includes: Get the list of replicas corresponding to each data shard; The replica list corresponding to each data shard is updated based on the replica information reported by each surviving node.

[0007] Optionally, the step of determining the target replica from at least one replica of the anomalous data shard in each surviving node further includes: If the role type of any replica in at least one replica of an anomalous data shard is learner, then the role type of the replica is updated to follower. If any replica of at least one replica of an anomalous data shard has a role type of Tiflashlearner, then that replica is marked as safe to delete.

[0008] Optionally, the step of determining the target replica from at least one replica of the anomalous data shard in each surviving node further includes: If a merge operation is received for a data range of an abnormal data shard, then determine the merge operation execution replica from at least one replica of the abnormal data shard in each surviving node. The merge operation is performed by executing a copy of the merge operation.

[0009] Optionally, the method further includes: If a replica configuration change operation related to abnormal data sharding is received, the old replica group configuration will be updated to the new replica group configuration, and the replica upgrade or downgrade operation related to the replica configuration change operation will be performed.

[0010] According to another aspect of the present disclosure, a data recovery apparatus is provided, the apparatus comprising: The replica information acquisition module is used to acquire replica information reported by each surviving node; the replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica; The target replica determination module is used to determine a target replica from at least one replica of the abnormal data shard in each of the surviving nodes if an abnormal data shard is determined based on the replica information reported by each surviving node; the abnormal data shard is a data shard in which the number of corresponding replicas in each surviving node is not greater than half of a preset number of replicas. The recovery module is used to process log recovery for the abnormal data shard through the target replica when a preset recovery trigger condition is met; the preset recovery trigger condition includes appending the application log index of the target replica to a reference commit log index, wherein the reference commit log index is the commit log index of the target replica when each surviving node reports replica information.

[0011] According to another aspect of the present disclosure, an electronic device is provided, the electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of any of the above data recovery methods.

[0012] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, implements the steps of any of the data recovery methods described above.

[0013] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the steps of any of the data recovery methods described above.

[0014] The beneficial effects of the technical solutions provided in this disclosure are: By forcing the target replica to act as the leader, logs can be advanced and consistency maintained even when a majority of replicas are unavailable. This enables non-stop recovery without interrupting services or requiring manual intervention. The recovery process is fully automated, reducing the risk of manual operation and improving recovery efficiency and stability, thereby enhancing the high availability of the distributed system. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below.

[0016] Figure 1 A schematic flowchart illustrating a data recovery method provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the architecture of a database system provided in an embodiment of the present disclosure; Figure 3 A flowchart illustrating another data recovery method provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of a data recovery device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0017] The embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions of the embodiments of this disclosure.

[0018] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this disclosure mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element are connected through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term, for example, “A and / or B” or “A, B” indicates implementation as “A,” or implementation as “B,” or implementation as “A and B.”

[0019] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0020] The following description of several exemplary embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0021] Figure 1 This is a flowchart illustrating a data recovery method provided in an embodiment of the present disclosure, as shown below. Figure 1 As shown, the method includes: Step S110: Obtain the replica information reported by each surviving node; the replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica.

[0022] Specifically, the method provided in this disclosure can be applied to database systems. Figure 2 This is a schematic diagram of the architecture of a database system provided in an embodiment of the present disclosure, such as... Figure 2 As shown, a database system can include multiple nodes: node 1, node 2, node 3, and node 4. The database system can be used to store data tables, which are divided into multiple contiguous data segments. Each data segment is called a data shard (or region). Each data shard is stored in a multi-replica manner, and a data shard can be configured with a preset number of replicas, for example... Figure 2 The default number of replicas is 3, meaning that 1 region corresponds to 3 replicas (i.e., peers).

[0023] For each data shard, the multiple replicas corresponding to that shard can form a Raft group. Within a Raft group, each replica can assume a different role, which can be a leader, follower, or learner. For example, a region might have three replicas, including one leader and two followers. Figure 2 The gray box represents the leader replica of the region.

[0024] For each data shard, the multiple replicas corresponding to that data shard reside on different nodes, for example... Figure 2 The three replicas of region1 are located on nodes 1, 2, and 3, respectively. Each node stores multiple replicas of the data shards, for example... Figure 2 Node 1 stores region1, region2, and region3, while node 2 stores region1, region3, and region5.

[0025] For each node in the database system, when the node is available (i.e., a live node), the node can automatically report the node's replica information. The node's replica information can include the replica identifier of each replica in the node, the data shard identifier corresponding to the replica, and the role type of the replica.

[0026] If the replica information reported by a node is not obtained, it means that the node has failed, and all replicas on that node will become invalid.

[0027] Step S120: If an abnormal data shard is determined based on the replica information reported by each surviving node, then a target replica is determined from at least one replica of the abnormal data shard in each surviving node; the abnormal data shard is a data shard in which the number of corresponding replicas in each surviving node is no more than half of the preset number of replicas.

[0028] Specifically, after collecting the replica information reported by each surviving node, it is possible to determine whether abnormal data sharding has occurred based on the replica information reported by each surviving node.

[0029] Among them, abnormal data shards can be data shards in which the number of corresponding replicas in each surviving node is no more than half of the preset number of replicas. For example, if the preset number of replicas is 3, then the number of replicas of the data shard in each surviving node is 1, and the data shard is considered to be an abnormal data shard.

[0030] When an abnormal data shard is identified, for each abnormal data shard, at least one replica for that abnormal data shard can be determined from multiple replicas in each surviving node, and a target replica can be determined from the determined at least one replica for that abnormal data shard, and the target replica can be set as the temporary leader.

[0031] Step S130: If the preset recovery triggering conditions are met, log recovery for abnormal data shards is performed through the target replica. The preset recovery triggering conditions include appending the application log index of the target replica to the reference commit log index. The reference commit log index is the commit log index of the target replica when each surviving node reports replica information.

[0032] Specifically, within a Raft group, each data change (such as INSERT or UPDATE) is encapsulated into a Raft Log. These logs are arranged sequentially, and each log has a unique integer index called the Log Index. The commit index refers to the highest log index in the current Raft group that has been successfully replicated by a majority of replicas. It represents the data boundary that is persisted and cannot be lost, guaranteed by the Raft consensus algorithm. Once the index of a log is less than or equal to the commit index, it means that the data change represented by this log has been safely stored on most nodes of the cluster, and the data will not be lost even if some nodes fail.

[0033] The apply index refers to the highest log index in the current Raft group (whether it's the leader or follower) where the replicas have applied their Raft logs to the local state machine (e.g., RocksDB KV storage). It represents the actual persistent state of the data in the local storage engine. A separate Apply thread asynchronously retrieves committed but unapplied logs from the Apply Queue, executes them sequentially, and updates the local KV database. The Apply Index increases after each log is applied.

[0034] Therefore, the apply index usually lags behind the commit index, and the apply index will continuously append the commit index.

[0035] For abnormal data shards, the commit log index of the target replica for the abnormal data shard is obtained when each surviving node reports replica information. This is used as a reference commit log index. Once the application log index of the target replica for the abnormal data shard has been advanced to the reference commit log index, the log recovery for the abnormal data shard is processed through the target replica to ensure that the previous logs have been applied. This ensures that the reported replica information is not outdated and guarantees data consistency.

[0036] The data processing method provided in this disclosure, compared to the prior art which cannot recover online when a majority of replicas fail, and offline recovery which requires service interruption and manual intervention and cannot meet the high availability requirements of production environments, forces the target replica to play the role of leader, ensuring that logs can be advanced and consistency maintained even when a majority of replicas are unavailable. This achieves non-stop recovery without interrupting services or requiring manual intervention. The recovery process is fully automated, reducing the risk of manual operation, improving recovery efficiency and stability, and thus enhancing the high availability of the distributed system.

[0037] As an optional embodiment, determining the target replica from at least one replica of the anomalous data shard in each surviving node includes: If the number of at least one replica for an abnormal data shard is 1, then the replica for the abnormal data shard will be used as the target replica. If the number of at least one replicas for the anomalous data shard is greater than 1, then the target replica is determined from at least one replica for the anomalous data shard based on the last log index and last log term of each replica.

[0038] Specifically, the number of at least one replica for the abnormal data shard can be obtained. If the number of at least one replica for the abnormal data shard is 1, then the replica corresponding to the abnormal data shard is taken as the target replica.

[0039] If the number of at least one replica of the abnormal data shard is greater than 1, the Last Log Index and Last Log Term of each replica corresponding to the abnormal data shard can be obtained.

[0040] In the Raft protocol, each log entry has two key attributes: an index and a term. The index is a monotonically increasing integer representing the log's position in the log sequence. The term is also a monotonically increasing integer, indicating which term's Leader replica created the log. The Last Log Index refers to the index number of the latest log entry in the replica's local Raft log; it represents the number of logs received by that replica. For example, if a replica's log index is 1-100, then its Last Log Index is 100. The Last Log Term refers to the term number of the latest log entry in the replica's local Raft log; it represents the freshness of the replica's logs. A log from a higher term means it was created by a newer Leader in a later period, and therefore this log is also more recent. For example, if the last log entry in a replica (index 100) was created by the Leader in term 5, then its Last Log Term is 5.

[0041] We can first compare the last log term of each replica and select the replica with the largest last log term. If the number of replicas with the largest last log term is 1, then the replica with the largest last log term is selected as the target replica. If the number of replicas with the largest last log term is multiple, then we continue to compare the last log indexes of these multiple replicas and select the replica with the largest last log index among these multiple replicas as the target replica.

[0042] The target replica is determined by using the last log term and last log index of each replica corresponding to the abnormal data shard, thereby ensuring that the determined target replica stores the latest log for the abnormal data shard.

[0043] As an optional embodiment, if the number of at least one replica for an abnormal data shard is greater than 1, log recovery for the abnormal data shard is processed through the target replica, including: The uncommitted logs for the anomalous data shard are copied to multiple replicas of the anomalous data shard other than the target replica via the target replica, and the uncommitted logs are committed.

[0044] Specifically, when the number of replicas corresponding to the abnormal data shard is greater than 1, under the condition that the preset recovery triggering condition is met, the target replica will copy the uncommitted logs of the abnormal data shard to other replicas in the replicas corresponding to the abnormal data shard except for the target replica, and commit the uncommitted logs, update the commit log index of the target replica, and notify other replicas to update the commit log index to ensure the consistency of the state of multiple replicas.

[0045] As an optional embodiment, under the condition that a preset recovery triggering condition is met, log recovery for the abnormal data shard is processed through the target replica, and then further includes: Get the replica list for each data shard; Based on the replica information reported by each node, the replica list corresponding to each data shard is updated.

[0046] Specifically, each data shard corresponds to a replica list. The replica list corresponding to a data shard may include the replica identifiers of the multiple replicas corresponding to that data shard, the node identifiers of the nodes where each replica resides, and the role type of each replica, etc.

[0047] When some nodes fail, all replicas in the failed node become invalid. Based on the replica information reported by each surviving node, the available replicas corresponding to each abnormal data shard can be determined. Based on the available replicas corresponding to each abnormal data shard, the replica list corresponding to that abnormal data shard is updated, and the invalid replicas in the replica list of that abnormal data shard are deleted to update the metadata.

[0048] If the number of available replicas corresponding to a certain abnormal data shard is determined to be 0 based on the replica information reported by each node, a new data shard is created. The data range corresponding to the new data shard is the same as the data range corresponding to the abnormal data shard, in order to repair the missing data range. A replica corresponding to the new data shard is created on a surviving node. Afterwards, the other replicas can be supplemented by the preset number of replicas through the scheduling node PD.

[0049] In this embodiment of the disclosure, when a majority is unavailable, the complexity of recovery is reduced and the correctness of recovery is improved by performing log advancement and metadata repair at different stages.

[0050] As an optional embodiment, the target replica is determined from at least one replica of the anomalous data shard in each surviving node, further comprising: If the role type of any replica in at least one replica of an anomalous data shard is learner, then update the role type of the replica to follower. If any replica of at least one replica of an anomalous data shard has a role type of Tiflashlearner, then the replica is marked as safe to delete.

[0051] Specifically, after determining the abnormal data shard, the role type of each replica of the abnormal data shard can be judged. If the role type of any replica of the abnormal data shard is determined to be learner, and the learner's log is more up-to-date than the logs of the remaining followers, the role type of that replica can be promoted to follower, and the follower replica can then be used as a candidate for the target replica.

[0052] For example, for a region that corresponds to one leader replica, two follower replicas, and one learner replica, when one leader replica and one follower replica in the region both fail, the majority of the region becomes unavailable. The learner replica can be promoted to a follower replica, so the number of replicas for the region is 2. The target replica can then be determined from these two follower replicas.

[0053] Considering that TiFlash cannot be the leader, but a TiFlash learner might be designated as the force leader (i.e., the target replica) due to having the latest logs, thus causing a conflict, if it is determined that any replica among the replicas of the abnormal data shard is a TiFlash learner, then the TiFlash learner replica can be marked as Tomsbone before recovery. Tomsbone is a marking mechanism in TiDB used for safe deletion. That is, when deleting an object, the object is first marked as Tomsbone before the object is physically deleted to avoid the aforementioned conflict.

[0054] As an optional embodiment, the target replica is determined from at least one replica of the anomalous data shard in each surviving node, further comprising: If a merge operation related to a data range of an abnormal data fragment is received, then determine the merge operation execution replica from at least one replica of the abnormal data fragment in each surviving node; The merge operation is performed by executing copies of the merge operation.

[0055] Specifically, in a distributed system, data segments of data shards can be merged or split. When a merge operation related to a data partition of an abnormal data shard is received, a replica can be selected from at least one replica of the abnormal data shard from each surviving node as the merge operation execution replica, and the merge operation is performed through the merge operation execution replica.

[0056] Among them, the merge operation related to the data range of the abnormal data shard refers to the merge operation involving the data range of the abnormal data partition. For example, if the data range of the abnormal data shard region1 is [1,50], and the merge operation needs to merge the data ranges [1,50] and [50,100], then this merge operation is the merge operation related to the data range of the abnormal data shard.

[0057] Furthermore, for splitting operations, if there are abnormal data fragments among the multiple sub-fragments after a data fragment is split, log recovery can be performed based on the method for abnormal data fragments described above, which will not be repeated here in the embodiments of this disclosure.

[0058] As an optional embodiment, the method further includes: If a replica configuration change operation related to abnormal data sharding is received, the old replica group configuration will be updated to the new replica group configuration, and the replica upgrade or downgrade operation related to the replica configuration change operation will be performed.

[0059] Specifically, within a Raft group, when the composition of replicas needs to be changed (i.e., a replica configuration change), a majority consensus is required from both the old configuration's member group and a member group that includes both the old and new configurations—a process known as joint consensus. If a majority is unavailable, and a replica configuration change operation related to an abnormal data shard is received, the old configuration's replica group can be forcibly updated to the new configuration's member group. Then, the upgrade or downgrade operation for the replicas related to the configuration change can be performed to ensure data consistency.

[0060] When a replica configuration change operation is a replacement operation, for example, the old replica group is C_old=[A, B, C] and the new replica group is C_new=[A, B, D], during the joint consensus phase, replica C is in the state of demoting voter (about to lose voting rights) and replica D is in the state of incoming voter (about to gain voting rights). However, if the majority is unavailable, the replica group is updated to the new configuration, then replica C is downgraded to learner and replica D is upgraded to voter.

[0061] When a replica configuration change operation is an expansion operation, such as expanding from 3 replicas to 5 replicas, the old replica group configuration is C_old=[A, B, C], and the new replica group configuration is C_new=[A, B, C, D, E]. If the majority is unavailable, the replica group configuration will be forcibly updated to the new configuration, and replicas D and E will be promoted to voter.

[0062] When a replica configuration change operation is a scaling down operation, such as scaling down from 5 replicas to 3 replicas, the old replica group configuration is C_old=[A, B, C, D, E], and the new replica group configuration is C_new=[A, B, C]. If the majority is unavailable, the replica group configuration is forcibly updated to the new configuration, and replicas D and E are downgraded to learners.

[0063] In this embodiment of the disclosure, secure recovery is supported in complex states such as split, merge, and joint consensus when the majority is unavailable, and data consistency and integrity are still guaranteed in complex and abnormal scenarios.

[0064] Figure 3 This is a flowchart illustrating a data recovery method provided in an embodiment of the present disclosure, as shown below. Figure 3 As shown, the method includes: after obtaining replica information, determining the abnormal data shard; if the role type of any replica among the replicas of the abnormal data shard is determined to be Tiflash learner, then the Tiflash learner replica can be subjected to Tombstone processing; if a merge operation related to the data range of the abnormal data shard is received, then the replica to be executed for the merge operation is determined, and the merge operation is executed; for split operations, it is necessary to determine whether there is an abnormal data shard among the multiple sub-shards after a data shard is split. Subsequently, the target replica is determined from at least one replica of the abnormal data shard among each surviving node, and this process can enter the forced leader mode. Next, the replica list corresponding to each data shard is updated according to the replica information reported by each surviving node; if the number of available replicas corresponding to a certain abnormal data shard is determined to be 0 according to the replica information reported by each node, then a new data shard is created. After the recovery operation is completed, the forced leader mode is exited, and the process ends successfully; if the recovery fails, the forced leader mode is also exited, and the process ends in a failure state.

[0065] Figure 4 This is a schematic diagram of the structure of a data recovery device provided in an embodiment of this disclosure, as shown below. Figure 4 As shown, the apparatus of this embodiment may include: The replica information acquisition module 210 is used to acquire replica information reported by each surviving node; the replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica; The target replica determination module 220 is used to determine a target replica from at least one replica of the abnormal data fragment in each of the surviving nodes if an abnormal data fragment is determined based on the replica information reported by each surviving node; the abnormal data fragment is a data fragment in which the number of corresponding replicas in each surviving node is not greater than half of the preset number of replicas. Recovery module 230 is used to process log recovery for the abnormal data shard through the target replica when a preset recovery trigger condition is met; the preset recovery trigger condition includes appending the application log index of the target replica to a reference commit log index, wherein the reference commit log index is the commit log index of the target replica when each surviving node reports replica information.

[0066] As an optional embodiment, when determining the target replica from at least one replica of the abnormal data shard in each live node, the target replica determination module is configured to: if the number of at least one replica of the abnormal data shard is 1, then the replica of the abnormal data shard is taken as the target replica; If the number of at least one replicas for the abnormal data shard is greater than 1, then the target replica is determined from the at least one replica for the abnormal data shard based on the last log index and last log term of each replica.

[0067] As an optional embodiment, if the number of at least one replica for an abnormal data shard is greater than 1, the recovery module, when processing log recovery for the abnormal data shard through the target replica, is used to: The target replica copies the uncommitted logs for the anomalous data shard to other replicas of the anomalous data shard besides the target replica, and commits the uncommitted logs.

[0068] As an optional embodiment, the device further includes a copy update module for: Get the list of replicas corresponding to each data shard; The replica list corresponding to each data shard is updated based on the replica information reported by each surviving node.

[0069] As an optional embodiment, the device further includes a role type update module, configured to: update the role type of any replica in at least one replica of the abnormal data shard to follower if the role type of the replica is learner; If any replica of at least one replica of an anomalous data shard has a role type of Tiflashlearner, then that replica is marked as safe to delete.

[0070] As an optional embodiment, the device further includes a merging operation processing module for: If a merge operation is received for a data range of an abnormal data shard, then determine the merge operation execution replica from at least one replica of the abnormal data shard in each surviving node. The merge operation is performed by executing a copy of the merge operation.

[0071] As an optional embodiment, the device further includes a copy configuration change module for: If a replica configuration change operation related to abnormal data sharding is received, the old replica group configuration will be updated to the new replica group configuration, and the replica upgrade or downgrade operation related to the replica configuration change operation will be performed.

[0072] The apparatus of this disclosure embodiment can execute the method provided in this disclosure embodiment, and its implementation principle is similar, and it has corresponding technical effects. The actions performed by each module in the apparatus of each embodiment of this disclosure correspond to the steps in the method of each embodiment of this disclosure. For a detailed functional description of each module of the apparatus, please refer to the description in the corresponding method shown above, and it will not be repeated here.

[0073] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0074] This disclosure provides an electronic device including a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the steps of the method provided in any optional embodiment of this disclosure. Compared with the prior art, it can achieve the following: by forcing the target replica to act as the leader, it ensures that the log is advanced and consistency is maintained even when a majority is unavailable, enabling non-stop recovery without interrupting services or requiring manual intervention. The recovery process is fully automated, reducing the risk of manual operation, improving recovery efficiency and stability, and thus enhancing the high availability of the distributed system.

[0075] In one alternative embodiment, an electronic device is provided, such as Figure 5 As shown, Figure 5 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this disclosure.

[0076] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0077] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0078] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0079] The memory 4003 is used to store computer programs that execute embodiments of the present disclosure, and is controlled by the processor 4001 to execute them. The processor 4001 is used to execute the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0080] Among them, electronic devices include, but are not limited to: mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), wearable devices, etc., as well as fixed terminals such as digital TVs, desktop computers, etc.

[0081] This disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0082] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0083] It should be understood that although arrows indicate various operation steps in the flowcharts of the embodiments of this disclosure, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this disclosure, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured as required, and the embodiments of this disclosure do not limit this.

[0084] The above description is only an optional implementation method for some implementation scenarios of this disclosure. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this disclosure without departing from the technical concept of this disclosure also fall within the protection scope of the embodiments of this disclosure.

Claims

1. A data recovery method, characterized in that, include: Obtain the replica information reported by each surviving node; The replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica; If an abnormal data shard is determined based on the replica information reported by each surviving node, then a target replica is determined from at least one replica of the abnormal data shard in each surviving node; the abnormal data shard is a data shard in which the number of corresponding replicas in each surviving node is no more than half of the preset number of replicas. If the preset recovery trigger conditions are met, log recovery for the abnormal data shard is processed through the target replica. The preset recovery trigger condition includes appending the application log index of the target replica to the reference commit log index, where the reference commit log index is the commit log index of the target replica when each surviving node reports replica information.

2. The method according to claim 1, characterized in that, Determining the target replica from at least one replica of the anomalous data shard in each surviving node includes: If the number of at least one replica for the abnormal data shard is 1, then the replica for the abnormal data shard is used as the target replica. If the number of at least one replicas for the abnormal data shard is greater than 1, then the target replica is determined from the at least one replica for the abnormal data shard based on the last log index and last log term of each replica.

3. The method according to claim 1, characterized in that, If the number of at least one replica for an abnormal data shard is greater than 1, the step of processing log recovery for the abnormal data shard through the target replica includes: The target replica copies the uncommitted logs for the anomalous data shard to other replicas of the anomalous data shard besides the target replica, and commits the uncommitted logs.

4. The method according to claim 1, characterized in that, The process of recovering logs for the abnormal data shard by processing the target replica when the preset recovery trigger conditions are met further includes: Get the list of replicas corresponding to each data shard; The replica list corresponding to each data shard is updated based on the replica information reported by each surviving node.

5. The method according to claim 1, characterized in that, The step of determining the target replica from at least one replica of the anomalous data shard in each surviving node further includes: If the role type of any replica in at least one replica of an anomalous data shard is learner, then the role type of the replica is updated to follower. If any replica of at least one replica of an anomalous data shard has a role type of Tiflash learner, then that replica is marked as safe to delete.

6. The method according to claim 1, characterized in that, The step of determining the target replica from at least one replica of the anomalous data shard in each surviving node further includes: If a merge operation is received for a data range of an abnormal data shard, then determine the merge operation execution replica from at least one replica of the abnormal data shard in each surviving node. The merge operation is performed by executing a copy of the merge operation.

7. The method according to claim 1, characterized in that, The method further includes: If a replica configuration change operation related to abnormal data sharding is received, the old replica group configuration will be updated to the new replica group configuration, and the replica upgrade or downgrade operation related to the replica configuration change operation will be performed.

8. A data recovery device, characterized in that, include: The replica information acquisition module is used to acquire replica information reported by each surviving node; the replica information reported by each surviving node includes the replica identifier of each replica in the surviving node, the data shard identifier corresponding to the replica, and the role type of the replica; The target replica determination module is used to determine a target replica from at least one replica of the abnormal data shard in each of the surviving nodes if an abnormal data shard is determined based on the replica information reported by each surviving node; the abnormal data shard is a data shard in which the number of corresponding replicas in each surviving node is not greater than half of a preset number of replicas. The recovery module is used to process log recovery for the abnormal data shard through the target replica when a preset recovery trigger condition is met. The preset recovery trigger condition includes appending the application log index of the target replica to the reference commit log index, where the reference commit log index is the commit log index of the target replica when each surviving node reports replica information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

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

Images