Multi-level disaster backup and fast recovery method for database cluster

Abstract

The application relates to the technical field of data processing, and discloses a multi-level disaster backup and rapid recovery method for a database cluster. The method is used for solving the problem that a provable global consistency recovery point construction and a recoverability confidence determination mechanism are lacked in a traditional method. The method first recovers a session locking strategy version and a parameter version, reads a baseline package and an evidence package to perform self-consistent checking to determine a resource budget; an observation window collects a same-city confirmation position, an off-site playback position, a backup end position and a transaction boundary marker, generates a global consistency anchor point candidate and performs a gate access determination; a proof package is generated, an entry is checked, a backup chain, a log segment, a transaction boundary, a metadata version and replication confirmation are checked, a recovery plan is arranged in combination with confidence arrangement with a gate and a rollback rule, after convergence, a new evidence package and a new baseline package are sealed and stored, and a session track, a ruling record and a parameter candidate are written back, and a determinable consistency rapid recovery is completed.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a multi-level disaster recovery backup and rapid recovery method for database clusters. Background Technology

[0002] As business evolves towards distributed database clusters, production systems often rely on multi-layered disaster recovery, including synchronous replication within the same city, asynchronous replication across different locations, and independent backups. Since replication, backup, orchestration, and secure management are mostly completed independently by modules, there is a lack of unified rules for consistency points, replay boundaries, and completion criteria. This can easily lead to inconsistencies between consistency guarantees and recovery speeds during failover or rapid recovery. In the prior art, for example, the published invention patent application CN103488546B discloses a method for supporting multi-level data and database online concurrent backup and recovery, which mainly uses the master controller and agent to complete the distribution, transmission and status tracking. However, it focuses on process organization and has no provable constraints on the visibility of cross-shard transactions and the alignment of consistency points across nodes in the distributed cluster. For example, the published invention patent application CN112698992B discloses a disaster recovery management method and related devices for cloud clusters, which mainly targets migration and redeployment after failure. However, it focuses on service layer orchestration and lacks a consistency mechanism for the recovery evidence, conflict resolution and global consistency recovery point construction for database backup artifacts and log incremental chains. For multi-layered disaster recovery scenarios in distributed database clusters, existing solutions often use single-node snapshot points, log positions, or task completion status as recovery references. However, when parallel commits and cross-shard transactions coexist, the commit order and transaction visibility of each node will differ. Furthermore, during asynchronous replay jitter or topology changes, it is difficult to guarantee that the same timestamp or similar log positions point to the same globally consistent point. In addition, incremental chain breaks, missing log segments, and metadata version drift can occur in the backup chain. The lack of a provable mechanism for constructing a globally consistent recovery point and a mechanism for determining recoverability confidence means that recovery cannot be performed independently of the original cluster before recovery. While topology alignment and artifact verification can be performed, they cannot adjudicate missing or conflicting data in backup and log chains. This leads to situations where full verification and long-term replay are used to achieve consistency, or verification is sacrificed to save recovery time, increasing the risk that recovery is feasible but unreliable, and data inconsistencies are only passively exposed during subsequent business reconciliation. To address the recovery uncertainty caused by the unprovable consistency points and undeterminable recoverability, a data processing technology solution is needed to complete consistency point construction, chain continuity verification, version consistency constraints, and conflict adjudication based on the evidence chain before recovery, ultimately achieving predictable and rapid recovery. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a multi-level disaster recovery backup and rapid recovery method for database clusters, which solves the problems of traditional methods lacking provable global consistency recovery point construction and recoverability confidence determination mechanisms.

[0004] To achieve the above objectives, the present invention provides the following technical solution: Multi-tiered disaster recovery and rapid recovery methods for database clusters include: S1. Trigger recovery session, lock policy version and parameter version, read baseline package and evidence package, complete self-consistency verification and determine resource budget; S2. Within the observation window, obtain the same-city confirmation location, remote playback location, backup chain end location, and transaction boundary marker, generate global consistency anchor point candidates, and determine the admission conditions. S3. Generate a proof package for anchor point candidates, and verify the consistency of backup chain, log segment, transaction boundary and metadata version in sequence to determine the confidence level; S4. Generate recovery plan packages according to confidence levels, and execute metadata recovery, core fragment priority loading, incremental loading and log replay according to the plan. Advance segmented verification and opening according to gating points, and switch to the previous anchor point when the rollback conditions are met. S5. After convergence is complete, the new evidence package and baseline package are sealed, and the session trace, adjudication record and parameter candidate are written to the disaster recovery storage.

[0005] Preferably, the process involves triggering a recovery session, locking the policy and parameter versions, reading the baseline and evidence packages, completing self-consistency verification, and determining the resource budget, including: After triggering a session recovery, a session identifier is generated and an index conflict retry is performed, along with the locking policy version, parameter version, and threshold table object. The baseline package and evidence package are read and digests are verified in two stages: catalog index and object content. The decision items are written based on the self-consistent verification of the fixed sequence, and a resource budget table is generated based on the target environment detection.

[0006] Preferably, within the observation window, the same-city confirmation location, the off-site playback location, the backup chain end location, and the transaction boundary marker are obtained, including: When obtaining the same-city confirmation location, remote playback location, backup chain end location and transaction boundary marker within the observation window, a convergence condition table is formed based on the write-back rule table to determine convergence. If the convergence condition is not met and the site is in a restricted open state, the downgrade evidence is sealed and the reason for the downgrade is recorded.

[0007] Preferably, generating globally consistent anchor point candidates and determining admission criteria includes: When generating globally consistent anchor point candidates and determining admission conditions, versioning is written into the new evidence package and the new baseline package, and read verification is performed after writing. If the verification fails, switch to the backup storage within the retry limit to rewrite, write back the session trace, decision entries and parameter candidates, and mark the parameter candidates as pending exercise verification status.

[0008] Preferably, the proof package generated for anchor point candidates includes: When generating proof packages for anchor candidates, the backup artifact directory list, log segment directory list, transaction evidence list, metadata version list, and replication confirmation list are read based on the session directory lock baseline package pointer and lock evidence package pointer, and a summary and threshold table version summary are written to each list. When the inventory index is missing, the inventory object is unreadable, or the summary verification fails, switch to the stable inventory pointer. If the switch fails, the verification path is executed using the default threshold parameter of the policy snapshot.

[0009] Preferably, the backup chain, log segments, transaction boundaries, and metadata version consistency are checked sequentially to determine the confidence level, including: Verify in sequence whether the backup chain, log segment, transaction boundary, and metadata version are consistent; Calculate the confidence level, set the threshold table to generate five types of entries: backup chain, log segment, transaction boundary, metadata version, and replication confirmation, and write the reason code and judgment basis summary respectively. Item disposal suggestions and dependency suggestions are converted into a set of allowed actions. A fixed set of levels and a fixed decision order are set to generate confidence records. The confidence records and item index objects are then written to the session directory.

[0010] Preferably, a recovery plan package is generated according to the confidence level, including: When generating a recovery plan package according to the confidence level, the input pointer of the plan package is the session directory, and the plan header contains a lock version pointer and a threshold table summary; Based on the confidence level, the task quota and gate point are linked, and the failure handling actions are set as rollback anchor point, downgrade opening, pause and wait, or switch to alternative recovery source.

[0011] Preferably, the process involves performing metadata recovery, core shard priority loading, incremental loading, and log replay according to a plan, advancing segmented verification and opening based on gating points, and switching to the previous anchor point when rollback conditions are met, including: Perform metadata recovery, core shard priority loading, incremental loading and log replay as planned, and promote verification and opening at the gating point; When a rollback is triggered, switch to the previous anchor point within the rollback limit and generate a planned update version, while keeping the version pointer unchanged; Write the degraded fragments into the open exclusion set, and write the rollback and degrade information into the execution trajectory.

[0012] Preferably, after convergence is achieved, the following are included: After convergence is completed, convergence is determined according to the convergence condition table and stage termination time window fixed in the plan package, and a convergence status record is generated. The convergence status record includes a summary of the condition table and a summary of the field names. When the open mode is set to restricted open, write the reason for the downgrade. If the convergence condition is not met, write a non-convergence flag and generate an alarm object to be processed.

[0013] Preferably, the new evidence package and baseline package are sealed, and the session trace, adjudication record, and parameter candidates are written to the disaster recovery storage, including: When sealing new evidence packages and baseline packages, versioning is performed using the sealing batch number and object version number, and a read-after-write check is performed to verify the existence of objects, the consistency of summaries, and the consistency of indexes. If the verification fails, retry according to the threshold, and write to the backup location according to the switching rules, while marking the sealed status as pending resealing; Write back the session trajectory index, adjudication entries, parameter candidate entries and their indexes to the disaster recovery storage, and set the parameter candidate status flag value to be verified in the exercise; Write completion markers to downgraded fragments, write catch-up requirement records to off-site playback fragments to be caught up, and establish bidirectional references with the evidence package.

[0014] Compared with existing technologies, this invention provides a multi-level disaster recovery backup and rapid recovery method for database clusters, which has the following beneficial effects: 1. This invention, by restoring the session locking policy version and parameter caliber, performs self-consistent verification on the baseline packet and evidence packet, solidifies thresholds and resource boundaries, obtains the same-city confirmation location, remote playback location, backup end location, and transaction boundary marker in the observation window, constructs global consistency anchor point candidates, and makes admission judgments based on gating conditions; generates a proof packet, performs itemized verification on the backup chain, log segment, transaction boundary, metadata version, and replication confirmation, and outputs the confidence level; arranges a recovery plan with gating and rollback rules based on the confidence level, and seals the new evidence packet and new baseline packet after convergence, writes back the session trajectory, adjudication record, and parameter candidates, and achieves rapid recovery where consistency points are provable, conflicts are adjudicable, and recoverability is determineable.

[0015] 2. This invention objectifies the entire process of recovery initialization, anchor point selection, evidence verification, plan arrangement, and archive write-back, and writes it into the session directory. This transforms the recovery input from online topology and manual judgment into a usable and comparable list, summary, and index. By unifying the constraints of threshold tables on gating criteria, branch decisions, and rollback suppression, it maps anomalies such as link jitter, object storage rate limiting, batch breakpoints, missing log segments, and transaction spanning into cause codes, handling suggestions, and dependency constraints. It generates traceable decision trajectories and version definitions within the session, achieving closed-loop management that ensures consistent recovery paths under different triggering sources and different center conditions, and is auditable, reproducible, and iteratively optimized. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the multi-level disaster recovery backup and rapid recovery method for database clusters according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1: Figure 1 This paper presents a multi-layered disaster recovery backup and rapid recovery method for database clusters, including: S1. Trigger the recovery session, lock the policy version and parameter version, read the baseline packet and evidence packet, complete the self-consistency verification and determine the resource budget. The specific implementation is as follows: In a feasible disaster recovery scenario, an external trigger source initiates a recovery trigger event to the disaster recovery control terminal. The recovery trigger event request body is a structured request body, including fields such as target environment identifier, business set identifier, recovery time target, recovery point target, trigger source identifier, and trigger trust. The trigger source identifier and trigger trust fields are used to distinguish between drill triggers, alarm triggers, and manual command triggers. The recovery time target ranges from 10 minutes to 240 minutes, for example, 60 minutes, and its value is based on the common disaster recovery drill window for critical businesses and the acceptable unavailability duration constraints for the business. The recovery point target ranges from 0 seconds to 3600 seconds, for example, 300 seconds, and its value is based on common rollbacks in scenarios where synchronous operations within the same city and asynchronous operations across different locations coexist. Tolerance and data replay window configuration; upon receiving a recovery trigger event, determine the pre-selected value of the strategy version for parameter normalization, match the pre-selected value of the strategy version with the identifier of the business set in the disaster recovery storage, first select the most recent version corresponding to the business set and whose effective status has not been abolished, if no match is found, select the global default version, and use the pre-selected value of the strategy version as the input summary object of the session directory, then perform parameter normalization based on the pre-selected value of the strategy version, perform boundary convergence on recovery time targets and recovery point targets that exceed the value range, and generate normalization records. The normalization records contain at least the original value, normalization value, normalization rule number, normalization timestamp, strategy version pre-selected value pointer, etc., and can be traced during subsequent caliber locking and consistency verification; After a triggered event enters the session creation phase, a recovery session identifier is generated. This identifier is 20 to 32 bits long and uses a combination of a time slice and a random factor. The time slice granularity is either seconds or tens of seconds, and the random factor is at least 8 bits long. The value is chosen to reduce collision probability and facilitate time-based retrieval during cross-center concurrent triggering. The session directory maintains four types of entries: session index objects, input summary objects, threshold table objects, and adjudication branch objects. All entries use the session identifier as the primary key and establish mutual references. The session index object is written to the disaster recovery storage atomically and includes at least the session identifier, policy version pointer, and parameter version. The session identifier includes fields such as pointer, trigger source identifier, trigger trust level, and creation timestamp. If the session directory already contains an entry with the same session identifier, or if the policy version pointer or parameter version pointer in the same session identifier entry is inconsistent with the value to be written, it is determined to be an index conflict. The session identifier is then discarded and regenerated. The maximum number of retries for the session identifier is between 1 and 3, for example, a value of 2. The basis for this value is that object storage write conflicts are usually instantaneous events and it is necessary to avoid blocking session creation for a long time. If the maximum number of retries is exceeded, the session creation is terminated and a conflict reason code is output. The reason code can be a session identifier conflict, a version pointer conflict, or an index that is not writable. After a session is created, the policy version and parameter version are locked. The policy version is a date plus a sequence number, and the parameter version is a 32-bit digest. The main purpose of these values ​​is to facilitate finding and quickly verify consistency. Once locked, they remain unchanged throughout the session's lifecycle. After locking, the above-mentioned regularization records are checked for consistency. The regularization rule is that the regularization rule number is equal to the locked policy version. If they are not equal, they are regularized again according to the locked policy version and written to the review difference record. The review difference record includes at least the difference item, the reason for the difference, and the review timestamp field, so that subsequent processing only uses the fixed standards and object pointers of the session directory. The threshold table object is parsed from the parameter version pointer and written to the session directory after the parameter version is locked. The threshold table object contains gating threshold field, branch trigger threshold field, and resource budget rule field, and carries threshold table summary and effective timestamp. The threshold table includes at least the following fields: link freshness threshold, location difference threshold, boundary marker integrity threshold, allowed rollback number, object storage request restricted threshold, object storage index read timeout threshold, summary inconsistency retry number, diagnostic mode trigger number threshold, bandwidth reservation ratio, bandwidth restricted trigger ratio, and sliding observation window parameters. The values ​​of the above thresholds are based on cross-center link heartbeat and replication confirmation delay, asynchronous playback jitter characteristics, object storage rate limiting configuration and consistency delay, as well as stability constraints and control plane verification traffic reservation constraints within the recovery window. The sliding observation window length ranges from 10 to 60 seconds, for example, 30 seconds; the link freshness threshold ranges from 5 to 60 seconds, for example, 15 seconds; the location difference threshold ranges from 0 to 600 seconds, for example, 120 seconds; the boundary marker integrity threshold ranges from 90% to 100%, for example, 98%; the allowed number of rollbacks ranges from 1 to 5, for example, 3 times; the object storage request limit threshold can be selected as a maximum number of requests per second or a maximum number of concurrent requests. The maximum number of requests per second ranges from, for example, 5000 to 50000, and the maximum number of concurrent requests is... Values ​​range from 200 to 2000; object storage index read timeout threshold ranges from 30 to 300 seconds, e.g., 120 seconds; digest inconsistency retry count ranges from 1 to 3, e.g., 2 times; diagnostic mode trigger count threshold ranges from 1 to 3, e.g., 2 times; bandwidth reservation ratio ranges from 10% to 50%, e.g., 30%; bandwidth-limited trigger ratio ranges from 40% to 70%, e.g., 50%; threshold table objects and their digests are written to the session directory as reference bases for in-session gating and branching criteria and remain read-only; After the session starts, baseline packets and evidence packets are read from the disaster recovery storage. The reading process is divided into two stages: directory index and content object. The directory index reads the object list and the summary list. The object list is a pointer to the entries in the baseline packets and evidence packets, and the summary list is the summary value and generation time of the corresponding entries. In the content object stage, the content objects are pulled from the object list and the summary is verified. The baseline packets are in key-value directory form and contain at least the following fields: topology baseline list, routing version list, configuration version list, permission version list, key reference version list, shard priority list, degradeable shard set, and authorization boundary snapshot pointer. The evidence packets contain at least the following fields: most recent stable anchor record, anchor proof summary, resource budget history trajectory, anomaly adjudication history trajectory, and parameter candidate set. After the packets are read, a packet summary and an input summary object are generated. The input summary object contains at least the following fields: baseline packet summary, evidence packet summary, reading source location identifier, and reading completion timestamp. If an anomaly occurs during the reading process, the session enters the summary anomaly branch. Anomaly conditions include at least the following: the directory indexing stage has exceeded the object storage index read timeout threshold and is still incomplete; the summary list is missing; and the item summaries are inconsistent. The object storage index read timeout threshold and the number of retries for summaries inconsistencies are taken from the threshold table object in the session directory. The summary anomaly branch switches to the backup package pointer registered in the evidence package and performs retries. The number of retries is 1 to 3, for example, 2, based on the common duration range of object storage consistency latency and short-term link jitter. If the retry still fails, the anomaly count is accumulated. When the anomaly count reaches the diagnostic mode trigger threshold, the session state switches to diagnostic mode. In diagnostic mode, a diagnostic report package is generated and written to the session directory. The diagnostic report package includes at least the failed object pointer, summary comparison result, failed branch identifier, failure reason code, and suggested next step entry. The suggested next step entry can be switched to a backup package, switched to an alternative recovery source, or stopped. While in diagnostic mode, subsequent progress is terminated and entry into the anchor point candidate generation stage is prohibited. The baseline self-consistency check is executed after being written to the packet digest. It follows a fixed check sequence, prints the structured check, and writes it to the session directory as a pre-input for observation window location acquisition. The fixed check sequence includes at least fragment range, replica set reference integrity, routing version and configuration version matching check, permission version and key reference version matching check, and authorization boundary check. The shard range check ensures the coverage set is resolvable and free of overlaps and gaps; when a migration window exists, the migration marker must include at least the migration identifier, source range, target range, migration stage, effective time window, and mapping version number, and the mapping relationship can be interpreted by the session directory; shards in the unconverged migration stage are marked as unconverged in the verification record and added to the degradeable shard set, and subsequently processed as degraded shards; the replica set reference integrity check ensures that the replica reference node identifier is in the node list and the role set meets the preset legality constraints; the route version matches the configuration version check that the route version points to the configuration version and is consistent; the permission version matches the key reference version check that the key version is resolvable and the reference relationship is closed; the authorization boundary verification inputs the authorization boundary snapshot, which must include at least the allowed role set, allowed key set, and allowed operation set, and the verification rule is that the permission version references the role and key within the allowed set and the operation set does not exceed the boundary; Any failure of an inspection triggers an adjudication branch, which follows the principle of substitution before degradation. If the baseline packet is missing, the entry is corrupted, or the summary verification fails, the pointer to the previous stable baseline packet recorded in the evidence packet is used as the substitution input, and the failed baseline packet is written to the failure index. If the substitution input is unreadable or the verification fails, the session state is switched to diagnostic mode to generate a diagnostic report packet. If the routing version is inconsistent with the configuration version or the authorization boundary verification fails, the session state is marked as metadata first, and a conflict entry is written to the adjudication branch object. The conflict entry must contain at least the fields of conflict type, condition, adjudication action, and scope of impact. The adjudication action is selected as rollback to a stable version, pause and wait, or switch to an alternative recovery source, so that subsequent recovery plans reference the conflict entry to form a sequential dependency constraint. After completing the baseline self-consistency verification, the resource budget is determined to constrain the concurrency and occupancy of subsequent anchor point candidate generation and recovery execution. The resource budget determination adopts the target environment probing input, which is a resource list, including at least the number of available nodes, node storage throughput limit, node network bandwidth limit, object storage throughput limit, object storage request limit, available encryption media status, cross-center link availability, etc., and generates a resource list summary and writes it to the session directory. The number of available nodes ranges from 3 to 256, for example 24, based on the scale of available computing nodes in the disaster recovery target environment. The object storage read throughput limit ranges from 200 megabytes per second to 20,000 megabytes per second, for example 4,000 megabytes per second, based on the throughput quota published by the object storage service side and the on-site probing results. The resource budget table should include at least the following fields: maximum number of parallel recovery streams, maximum concurrent shard loading, maximum concurrent log playback, maximum bandwidth usage, maximum disk write usage, and maximum verification usage. It should also include a budget generation basis field, which references a lock parameter version pointer and a resource inventory summary. The maximum number of parallel recovery streams should range from 2 to 32, for example, 8, and its value should be based on the resource usage sensitivity and available computing power during parallel decapsulation, verification, and writing. The maximum bandwidth usage should be calculated based on the bandwidth reservation ratio, and the available bandwidth across centers should be the statistical value of the sliding observation window defined in the threshold table. When the available bandwidth across centers within the observation window is lower than the product of the maximum bandwidth usage and the bandwidth-limited trigger ratio, the system enters a bandwidth-limited state. The branch lowers the maximum number of parallel recovery streams to 50% of the original value and raises the core shard priority by no more than 1 level and no more than the highest level. The scope of the increase can be selected as location collection coverage and task concurrency quota, without changing the shard set and anchor point entry point. The object storage request limitation determination uses the upper limit of requests per second and the upper limit of concurrent requests within the observation window. When either indicator is lower than the object storage request limitation threshold, the request limitation branch is entered, which reduces the directory read concurrency and adjusts the segment read granularity. The segment read granularity ranges from 2 megabytes to 64 megabytes, for example, 16 megabytes. The value is based on the object storage single request load limit and the rate limiting strategy to avoid long-term blocking of log segment directory and backup artifact directory reads due to rate limiting. Generate a recovery session record and write it to the session index object; the session record includes at least the following fields: session identifier, locking policy version pointer, locking parameter version pointer, threshold table summary, baseline package summary, evidence package summary, verification record summary, resource budget table summary, branch trigger flag, timestamp, etc.; the session status flag is written to the adjudication branch object, and the status flag value can be advanced, diagnostic mode, or metadata first, such as determined based on summary verification, self-consistency verification, and threshold gating trigger status.

[0019] S2. Within the observation window, obtain the same-city confirmation location, off-site playback location, backup chain end location, and transaction boundary marker; generate global consistency anchor point candidates and determine admission conditions. The specific implementation is as follows: This phase takes into account the resource budget table summary pointer from the session index object, the gate threshold field and branch priority field from the threshold table object, and the topology baseline list pointer. The output anchor candidate records and admission decision records are written to the session directory as direct inputs to the proof package. The observation window is defined parametrically, with parameters including at least the observation window length and window sliding step size. The observation window length ranges from 30 to 300 seconds, for example, 90 seconds, and is determined based on the cross-center replication jitter cycle and the link heartbeat cycle. The window sliding step size ranges from 5 to 60 seconds, for example, 15 seconds, and is determined based on increasing the candidate update granularity without significantly increasing the acquisition load. The start and end times of the observation window are based on the target environment time, and the start and end timestamps, window length, and window sliding step size are written into the session trajectory as a time reference. To reduce location mismatch caused by cross-center clock deviation, a time consistency check is performed. The time offset threshold is taken from a threshold table object, and the judgment rule is that the time offset between the target environment time and the time reference point provided by the disaster recovery storage does not exceed the time offset threshold. When the time offset threshold is exceeded, time correction is performed, aligning the start and end times of the observation window with the time reference point, and writing the offset value, correction time, corrected window parameters, correction flag, and other fields into the session trajectory. Three types of fragment location inputs and one type of transaction boundary evidence input are collected in each observation window, forming a fragment location tuple table and a transaction boundary list, respectively. The fragment location tuple table uses the fragment identifier as the primary key and includes the same-city confirmation location, off-site playback location, backup end location, fragment boundary summary, window identifier, and collection batch identifier. The transaction boundary list uses the global transaction identifier as the primary key and includes the participating fragment set summary, commit boundary marker, visibility marker, lease change marker, master control identifier, and commit timestamp. The collection source adopts a unified interface standard, and the fragment location inputs are obtained from the replication channel confirmation record stream and off-site... The playback cursor record stream and backup batch directory record stream are used to obtain the transaction boundary record stream or its mirror directory for transaction boundary evidence input. The collection method is pull or subscription, and the value is based on the available interface form of the target environment. The upper limit for retrying collection failure and the timeout threshold are identified by the threshold table object and written to the collection result field related to the collection batch identifier. The location sequence number adopts a monotonically increasing caliber within the same slice, and the caliber value is one of the log position sequence number, commit sequence number, or incremental sequence number. The same-city confirmation location, off-site playback location, and backup end location are mapped to the same monotonically increasing caliber. When the mapping cannot be established, an inconsistent caliber flag is written. The shard boundary summary mapping is derived from the transaction boundary list. The derivation rule is to merge transaction boundary entries into the corresponding shards based on the shard set summary of the participating shards, and generate fields such as the boundary closure summary and lease change summary of the shard within the observation window. The shard position tuple table writes the aforementioned summary into the corresponding shard row. The boundary marker missing ratio is calculated by using the number of committed cross-shard transaction entries in the observation window as the denominator and the number of entries with missing committed boundary markers as the numerator. The number of committed cross-shard transaction entries is counted only if the committed timestamp falls into the observation window and can be resolved by the shard set summary. The lease change convergence judgment parameter is taken from the threshold table object. The judgment rule is that if the lease change marker remains unchanged and the master control identifier remains consistent within K consecutive observation windows, it is considered convergence. K ranges from 2 to 5, for example, 3. The value is based on the common convergence window of cross-center master control switchover propagation. If the convergence condition is not met, a non-converged marker is written into the shard boundary summary. The system includes fields such as local location confirmation (segment identifier, confirmation location sequence number, confirmation timestamp, confirmation channel identifier), remote playback location confirmation (segment identifier, playback location sequence number, playback timestamp, playback channel identifier), and backup chain end location confirmation (segment identifier, backup batch number, end location sequence number, batch completion timestamp, batch verification summary). The batch verification summary is generated and written to the batch directory entry when the backup batch is completed. It is used to bind the end location to the batch object. The verification condition is that the batch verification summary is the same as the batch directory entry summary; if they are inconsistent, a batch binding failure flag is written. In case of missing data, inconsistent data, or batch binding failure, a data collection exception flag is written to the segment location tuple table, and a candidate failure reason code is written to the admission judgment record. To reduce acquisition costs and maintain stable coverage of critical shards, the shard location tuple table adopts a shard grouping incremental update mechanism. The grouping rules are jointly determined by the shard priority list and resource budget. High-priority shard groups are acquired in each observation window, while low-priority shard groups are acquired by skipping windows or change-triggered methods. Change triggering is based on changes in location sequence number or timestamp. When the confirmed location in the same city remains unchanged for two consecutive observation windows, and the off-site playback location and backup end location also remain unchanged, the acquisition interval for the corresponding shard is extended by one window sliding step. The cumulative number of skipped windows does not exceed two observation windows. To avoid long-tail shards being uncovered for extended periods, forced acquisition is performed when any shard has not been acquired for M consecutive observation windows. M is between 2 and 6, for example, 4, and the value is chosen to balance reducing acquisition overhead with maintaining the integrity of candidate coverage. When any shard is marked as acquisition abnormal, link conflict, lease non-convergence, or is included in the core shard set, acquisition is resumed in each observation window. The acquisition trajectory is written to the session trajectory, which includes at least the group acquisition strategy flag, the most recent acquisition window identifier, and the skipped window count. Generate globally consistent anchor point candidates; anchor point candidates are completed by a list object, which includes at least the following fields: anchor point number, anchor point time, shard set summary, shard anchor point location set, anchor point boundary summary, anchor point metadata summary, and constraint satisfaction status code set; the anchor point number is monotonically incremented with an initial value of 1 within the session and written to the session trajectory, and the anchor point time is the end time of the observation window; the shard set is a list of self-consistently verified topology baselines, and shards that have not converged during migration are marked with a degradation flag and a degradation note; the anchor point metadata summary consists of a routing version list, a configuration version list, a permission version list, and a key reference version list; The anchor point location for each shard is selected by hard and soft constraints. Hard constraints ensure that the anchor point location is no larger than the same-city confirmation location, no larger than the off-site replay location, and no larger than the backup end location. Soft constraints ensure that the anchor point location is as close as possible to the end of the observation window while satisfying the hard constraints, and that the transaction boundary is closed as much as possible when there are cross-shard transactions. The transaction boundary closure is determined by the shard boundary summary, which contains at least fields such as pending cross markers. If there are pending cross markers, a boundary non-closure marker is added to the anchor point candidate record. The status code values ​​are fully satisfied, close to the end of the window, link conflict, backup restricted, and off-site restricted. When a shard meets the above three hard constraints, it is called a link conflict. Link conflicts are adjudicated according to the branch priority rule table in the threshold table object to determine the consistency benchmark. The priority rule is that the confirmed location in the same city takes precedence over the backup end location, and the backup end location takes precedence over the off-site playback location. After adjudication, the conflicting shard is marked with a consistency benchmark, and the off-site playback channel is marked with a pending recovery mark, generating a recovery requirement entry. The recovery requirement entry should at least include the shard identifier, recovery start location, recovery target location, allowed time window, and source version reference field. The allowed time window prioritizes the policy snapshot field. If the corresponding field in the threshold table object is not selected, it is written into the source version reference field to maintain traceability. The recovery requirement entry is written into the session track for reference in the subsequent recovery plan dependency list. After anchor point candidates are generated, admission criteria are determined, referencing the threshold table object's gating threshold field. Link freshness is determined by the time difference between the confirmed location timestamp and the end of the window, and the time difference between the replay location timestamp and the end of the window, not exceeding the link freshness threshold. When excluding replays of conflicting links, only the freshness of the confirmed location within the same city is determined, and the exclusion reason code is written into the determination record. Location difference is determined by the difference between the confirmed location within the same city and the replay location in a different location not exceeding the location difference threshold. If it exceeds the corresponding segment anchor point location, the decision result of the confirmed location within the same city and the backup end location is used, and a restricted marker and a difference exceeding the threshold reason code are written into the record. Boundary marker integrity is determined by the boundary marker missing ratio not exceeding the boundary marker integrity threshold and the lease change convergence determination result being converged. If these conditions are not met, a failure reason code is written into the record. The allowed number of rollbacks is taken from the threshold table object to limit window rollback oscillations. The determination record must include at least the threshold table version summary, determination conclusion, failure reason code, exclusion reason code, and number of rollbacks. If any of the admission criteria are not met, an anchor point rollback branch is triggered. The rollback branch slides the observation window forward by one window step size and re-acquires data. Data is collected on the fragment groups that failed to trigger the rollback. Fragments marked as having acquisition anomalies, link conflicts, or lease non-convergence are restored to mandatory acquisition for each window. Rollback generates new anchor point candidates and writes a rollback reason code. The rollback reason code can be of the following types: too low freshness, too large gap, missing boundary marker, lease non-convergence, missing data, inconsistent caliber, batch binding failure, etc. If the rollback count meets the requirements but the candidate still fails to pass the admission criteria, the anchor point candidate is marked as low confidence and a low confidence reason code and a suggested action field are written. The suggested action field can be of the following types: enter the strict verification channel, restrict segment opening, pause and wait, etc. Generate anchor candidate records and admission decision records and write them to the session directory. Anchor candidate records should include at least the following fields: anchor number, anchor time, shard set summary, anchor position of each shard, boundary summary, metadata summary, constraint satisfaction status code, and consistency benchmark flag. Admission decision records should include at least the following fields: window parameters, threshold table version summary, decision conclusion, failure reason code, number of rollbacks, low confidence flag, and suggested action.

[0020] S3. For anchor point candidates, generate proof packages and sequentially verify the consistency of backup chains, log segments, transaction boundaries, and metadata versions to determine the confidence level. The specific implementation is as follows: After anchor candidate records and admission determination records enter the session directory, the evidence package generation and confidence level determination phase begins. The facts for this phase are the locked baseline package pointer and locked evidence package pointer in the session directory. The backup artifact directory list, log segment directory list, transaction evidence list, and metadata version list are read through the list index pointer in the session index object, and summaries of each list are written into the session track. When a list index is missing, a list object is unreadable, or summary verification fails, the stable list pointer on the previous evidence package record is executed first. If unavailable, the policy snapshot default threshold is used to enter the conservative channel, and the reason for the restriction is written. The proof package output is represented by an entry table object. Each entry table record contains at least the following fields: entry category, entry identifier, source pointer, time range, integrity flag, conflict flag, handling suggestion, dependency suggestion, and judgment basis summary. Entry categories include: backup chain, log segment, transaction boundary, metadata version, and replication confirmation (5 categories); entry identifiers include: session identifier, category code, and sequence number (5 categories); source pointer indicates the location of the corresponding list entry or object, and the time range is the entry coverage window or batch range; integrity flags include: passed, missing, and corrupt (3 categories); conflict flags include: no conflict, adjudicable, and unadjudicable (3 categories); handling suggestions include: anchor point rollback, channel exclusion, fragment degradation, subsequent completion, and forced full verification (5 categories); dependency suggestions include: no dependency, metadata first, waiting to catch up, and opening after completion (4 categories); and the judgment basis summary includes at least the trigger threshold field name, threshold table version summary, statistical caliber summary, and key count results. Backup chain entries are generated according to chain continuity rules; the backup artifact catalog list includes at least the following fields: the pointer relationship between full batches and incremental batches, batch summary, batch start and end timestamps, batch applicable shard set, and batch index object pointer; continuity determination starts from the full batch corresponding to the anchor candidate, tracing back along the incremental pointers to the last batch of the anchor candidate, requiring no missing pointers, verifiable batch summaries, no inverted batch start and end timestamps, and the interval between adjacent batches not exceeding the batch gap threshold; the batch gap threshold is taken from the threshold table object, with a value range of 0 to 300 seconds, for example, 30 seconds, and the value is based on the common upper bound of latency for object storage directory writes and replication link registration; the maximum value for the incremental chain is... The number of breakpoints can be taken from the threshold table object, with a value range of 0 to 2, for example, 0. The value is based on the requirement of high consistency business for the continuity of incremental chains. The number of breakpoints is based on the number of consecutive pointer pairs, and is counted by the number of pointer missing or batch missing events and rounded down. When the number of breakpoints exceeds the threshold, a backup chain conflict entry is generated and anchor rollback is triggered. If any of the following situations still occurs after rollback: pointer missing, batch missing, or batch digest inconsistency, it is determined to be an unclosable chain segment. The conflict mark is set to unadjudicated, the handling suggestion is set to mandatory full verification, the dependency suggestion is set to no dependency, and an unclosable reason code is written. The unclosable reason code can be of the type pointer missing, batch missing, batch digest inconsistency, etc. Log segment entries are generated according to segment continuity and availability rules. The log segment directory list includes at least the following fields: fragment identifier, segment start and end sequence number, segment summary, segment storage location list, segment availability status, segment generation time range, and segment index object pointer. The mapping from anchor point position to end segment sequence number is performed according to the log segment splitting rule table, which is located through the rule index object in the baseline package. It includes at least the following fields: fragment identifier, segment boundary generation caliber, segment size caliber, and position-to-segment mapping type. The mapping type can be either direct equivalent mapping or interval overlay mapping. The mapping result is written to the entry fields, which include at least the anchor point position sequence number, end segment sequence number, and mapping type. Segment continuity determination requires that the segment sequence numbers be continuous from the start segment to the end segment of the full batch. The threshold for the allowable missing log segments is taken from a threshold table object, ranging from 0 to 1%, for example, 0.1%. This value is based on the premise that object storage is occasionally unavailable, allowing degradation of long-tail shards. The missing segment ratio is calculated using the number of log segments that should exist within the anchor point coverage area of ​​the target shard set as the denominator and the number of missing or unreadable log segments as the numerator. Unreadable segments are determined by the fact that the entire list of segment storage locations is unreadable or the segment digest verification fails. When the missing segment ratio exceeds the threshold, a log missing conflict entry is generated and enters the adjudication path. The adjudication path takes the shard priority list as input, with priorities derived from the baseline package and self-consistently verified. When a core shard triggers a missing segment, the recommended action is anchor point rollback, the dependency recommendation is no dependency, and read retry is performed on the backup storage location. The retry threshold is taken from a threshold table object, ranging from 1 to 5, for example, 3. This value is based on the premise that object storage rate limiting and replica repair typically recover within a short time. When a long-tail shard triggers a missing segment, the recommended action is shard degradation, the dependency recommendation is to restore the shard after completion, and write this to the degraded shard flag field. Transaction boundary entries are generated according to boundary closure rules; the transaction evidence list includes at least the following fields: global transaction identifier, summary of participating shard sets, commit boundary marker, visibility marker, lease change marker, master identifier, and commit timestamp; boundary closure determination requires that the anchor point candidate boundary summary covers all committed cross-shard transactions within the observation window, and that no pending transactions cross the anchor point boundary, and that lease change convergence is determined to be converged; the boundary marker missing tolerance threshold is taken from the threshold table object, with a value range of 0 to 2%, for example, 0.5%, based on the upper limit of short-term missing records allowed in the transaction boundary record link; the missing ratio is calculated with the number of committed cross-shard transaction entries within the observation window as the denominator and the number of missing commit boundary marker entries as the numerator. Submitted entries are defined as those whose submission timestamp falls into the window and whose summaries of the participating collections can be parsed. When the proportion of pending cross-markers or missing items exceeds the threshold, a transaction boundary conflict entry is generated and a transaction convergence path is triggered. The transaction convergence path adjusts the anchor point position to the nearest position without a cross-marker and triggers anchor point rollback. The upper limit of the number of adjustments is taken from the threshold table object, with a value range of 1 to 3, for example, 2. The value is chosen to avoid repeated adjustments that could lead to the loss of control over the recovery time target. When the upper limit is exceeded, the conflict mark is set to adjudicable, the handling suggestion is set to mandatory full verification, the dependency suggestion is set to open after completion, and a boundary instability reason code is written. The boundary instability reason code can be of the types such as pending cross-markers, unconverged leases, or missing marks. Metadata version entries are generated according to version matching rules. The metadata version list must include at least the following fields: routing version, configuration version, permission version, key reference version, and topology version. The version matching determination method is that the metadata digest of the anchor candidate is consistent with the baseline packet version and consistent with the stable version recorded in the evidence packet. Inconsistency generates metadata drift entries. The conflict flag is set to adjudicable, the handling suggestion is to complete the subsequent steps, and the dependency suggestion is to prioritize metadata. The drift range and the version pointer digest before and after the drift are written. The drift range includes routing drift, permission drift, key drift, configuration drift, etc. The copy confirmation entry is generated according to the coverage rules; the coverage judgment requires that the confirmation location in the same city is less than the anchor point location, the playback location in a different location is less than the anchor point location, and it is deleted in the link conflict adjudication; the freshness judgment requires that the difference between the confirmation timestamp and the end time of the observation window is not less than the link freshness threshold, which is a threshold table object; if the freshness does not meet the requirements, a freshness deficiency entry is generated, and the handling suggestion is to backtrack the anchor point, exclude the channel, and the dependency suggestion is to wait for the catch-up or have no dependency, and write the existence of the link conflict baseline flag field as the basis for the divergence judgment; After the five types of entries are generated, a confidence record is generated. The confidence record has a fixed set of levels and a fixed judgment order. There are four levels: unavailable, requires full verification, recoverable, segmented opening, recoverable, and fast opening. The judgment order is unavailable, requires full verification, segmented opening, and fast opening. Unavailable conditions include one of the following: the core shard backup chain cannot be closed, the core shard log segment is missing and cannot be repaired, or the transaction boundary cannot be converged. Requires full verification is when there is a conflict marker that is not conflict-free and the handling suggestion is to force full verification, or the metadata has drifted and is not fresh. Segmented opening is when all core shard-related entries pass, there is a long-tail shard degradation marker, or metadata depends on it first. Fast opening is when all five types of entries pass and the coverage and freshness are satisfied. The confidence record must contain at least the following fields: level value, list of restriction reasons, set of allowed actions, threshold table version summary, key entry summary, and mapping summary. The list of reasons for restrictions is composed of the set of reason codes for entries marked as conflict-free and the set of reason codes for entries with insufficient freshness, after deduplication, and written in priority order: backup chain reason codes take precedence over log segment reason codes over transaction boundary reason codes over metadata drift reason codes over insufficient freshness reason codes. The set of allowed actions includes action types such as planned generation allowed, planned generation requires downgrading, planned generation requires full verification, and switching alternative recovery sources. The relationship between the entry handling suggestions and the set of allowed actions is solidified through mapping digests. When the handling suggestion is mandatory full verification, the set of allowed actions is planned generation requires full verification; when there is shard downgrading or channel exclusion; when core shard entries pass, the set of allowed actions is planned generation requires downgrading; when there is an anchor point rollback suggestion, the set of allowed actions is planned generation allowed and references the anchor point sequence number after rollback; when there is metadata-first dependency and other core entries pass, the set of allowed actions is planned generation allowed or planned generation requires downgrading, and metadata-first constraints are written into the dependency list. The proof includes writing the entry table and confidence records into the session directory to generate an index object. The index object includes at least the anchor number, entry table summary, confidence level, reason code set, threshold table version summary, list summary set, and rollback relationship summary, and is directly referenced in the recovery plan generation stage.

[0021] S4. Generate recovery plan packages according to confidence levels, and execute metadata recovery, core shard priority loading, incremental loading, and log replay according to the plan. Advance segmented verification and opening according to gating points, and switch to the previous anchor point when the rollback conditions are met. The specific implementation is as follows: After confidence records and proof packages are written to the session directory, the planning orchestration determines optional actions and execution paths through the proof package entry table and confidence records. Session records, baseline packages, anchor candidate records, resource budget tables, fragment location tuple tables, and verification rule objects constrain task concurrency, gating decisions, and rollback switching. The recovery plan package consists of objects. The input includes at least a session record pointer, a baseline package pointer, an anchor candidate record pointer, a proof package index object pointer, a confidence record pointer, a resource budget table pointer, a shard location tuple table index object pointer, a validation rule object pointer, a list of alternative recovery sources pointers, and a list of alternative storage locations pointers. The output includes at least a plan header, task sequence, dependency list, gate point table, resource quota table, rollback rule table, write-back rule table, and plan index field. The plan header includes at least a session identifier, anchor number, locking policy version pointer, locking parameter version pointer, threshold table version summary, confidence level, recovery time target, recovery point target, proof package index pointer, key reason code set summary, list summary set, and validation rule object summary, to solidify the criteria and the range of available actions. The task set consists of fixed phases, arranged from top to bottom as follows: metadata recovery, full load, incremental load, log replay, verification, and opening. Each task entry includes at least a task identifier, target shard set summary, input pointer, output pointer, concurrency limit, retry limit, timeout threshold, failure handling action, gating binding flag, idempotency key, and output summary. The timeout threshold ranges from 1 minute to 120 minutes, e.g., 20 minutes, based on the upper bound of the read / write duration of the object storage under rate-limited conditions. The short-term target trigger threshold ranges from 20 minutes to 60 minutes. If the recovery time target is less than 40 minutes, short recovery is selected. The task's timeout limit is changed from the short recovery timeout threshold to the short recovery timeout threshold. The short recovery timeout threshold ranges from 5 to 20 minutes, such as 10 minutes. The value is based on the fact that the time occupied by a single task is uncontrolled within the short recovery window. The retry limit ranges from 1 to 5, such as 3. The value is based on the upper bound of the common recovery count for object storage transient errors and short-term network jitter. The concurrency limit is taken from the resource quota table and is constrained by the bandwidth usage limit, disk write usage limit, and check usage limit. The concurrency limit is not adjusted during execution. The dependency list is expressed in a sequential constraint manner and is fixed when the plan is generated. It includes at least the following constraints: metadata recovery precedes data loading, full loading of core shards precedes incremental loading of core shards, incremental loading precedes log replay, and verification precedes opening. The core shard set is determined based on the baseline package shard priority list, with priority values ​​ranging from level 1 to level 3, and level 1 taking precedence. When there is a shard degradation flag, the completion task is marked as a dependency after opening in the dependency list and is executed after the core shard is opened. When there is a channel exclusion flag or a follow-up dependency suggestion, the follow-up task is marked as an optional task in the dependency list and is executed after the core shard is opened. The gating point table expresses key decisions and binds failure handling actions based on auditable conditions. Gating points include at least metadata consistency gating, core shard loading gating, transaction boundary gating, and pre-opening verification gating. The judgment conditions for metadata consistency gating are combinations of conditions such as consistent routing and configuration versions, resolvable permission versions, and resolvable key references. The judgment condition for core shard loading gating is that the percentage of core shards fully loaded reaches the segmented opening threshold, which ranges from 20% to 90%, for example, 60%. This threshold is based on common thresholds for entering restricted opening when recovery time targets are limited. The completion percentage is calculated with the number of shards in the core shard set as the denominator and the number of shards that have completed full loading and passed batch digest verification as the numerator. This statistical caliber is written into the gating point pass record. The judgment criteria for transaction boundary gating are: anchor point boundary closure entries with conflict markers cannot be adjudicated if there is no conflict, and replication confirmation entries cannot be adjudicated if they are not marked. The judgment criteria for pre-opening verification gating are: the verification rule object passes the system dictionary consistency check and the critical invariant consistency check. The verification rule object must contain at least the fields of check item identifier, check item type, input reference type, failure judgment condition, handling action, and check dependency. The check item type must contain at least four types: system dictionary consistency, routing consistency, permission consistency, and critical invariant consistency. The critical invariant consistency must contain at least the following items: shard set and shard range consistency, shard replica set resolvable, routing pointer configuration resolvable, and permission policy reference key resolvable. The input reference must contain at least the baseline packet entry digest and the metadata recovery output digest. Failure handling actions can be categorized into types such as rollback anchor, downgrade open mode, pause and wait, and switch to alternative recovery source. Each gating point has a primary action and optional actions. The activation condition for optional actions is controlled by a gating trigger count threshold, ranging from 1 to 3 (e.g., 2), used to suppress frequent rollbacks caused by occasional failures. The pause and wait action includes at least a wait duration threshold and a wait count limit. The wait duration threshold ranges from 30 seconds to 10 minutes (e.g., 2 minutes), and the wait count limit ranges from 1 to 3 (e.g., 2), with the values ​​determined by object storage consistency latency and short-term rate-limited recovery cycle. The resource quota table is used to refine the resource budget to the task granularity and associate it with the confidence level. It includes at least the following fields: maximum number of parallel recovery streams, maximum concurrent shard loading, maximum concurrent log replay, maximum bandwidth usage, maximum disk write usage, and maximum verification usage. Field values ​​reference the resource budget table in the session record. For example, the maximum bandwidth usage ranges from 100 Mbps to 10,000 Mbps, the maximum disk write usage ranges from 100 Mbps to 8,000 Mbps, and the maximum verification usage ranges from 2 to 32 parallel verification streams. The values ​​are based on the maximum read throughput of object storage, the maximum write throughput of nodes, and the maximum number of available CPU cores in the target environment detection list; when the confidence level is set to recoverable but requires full verification, the verification usage limit is increased and the loading concurrency limit is decreased; when the open gating is set to allow full opening after full verification is completed; when the confidence level is recoverable and can be opened in stages, the core shard task concurrency limit is increased and the long-tail shard task concurrency limit is decreased; the resource quota table also includes quota generation basis fields, which at least include the resource budget table summary, threshold table version summary, and confidence level fields; The rollback rule table defines rollback conditions, rollback targets, and rollback damping constraints. Rollback conditions are triggered jointly by conflict markers in the proof package entry table and execution phase exception categories, and include at least the following: backup chain breakpoint entry triggering, log segment missing ratio exceeding a threshold, transaction crossover marker appearing, metadata drift unresolved, consecutive read failures reaching a threshold, and insufficient coverage exceeding a threshold. The consecutive read failure threshold ranges from 1 to 10, for example, 3, and is based on the upper bound of the common duration of short-term jitter in object storage. Insufficient coverage is determined using a location difference threshold, which ranges from 0 seconds. Up to 600 seconds, for example 120 seconds, the value is based on the maximum catch-up gap allowed when synchronous and asynchronous operations coexist in the same city; the rollback target value is the previous anchor point sequence number, which references the stable anchor point record of the evidence package and is fixed in the session directory; the upper limit of the number of rollbacks is between 1 and 3, for example 2, the value is based on avoiding continuous rollbacks within the session that would cause the recovery time target to get out of control; after the number of rollbacks reaches the upper limit, the handling path can be to switch to an alternative recovery source or enter a path that requires full verification, and write a switching reason code, the switching reason code can be of the type such as evidence cannot be closed, link is not fresh, object is not readable, metadata conflict, etc. The write-back rule table is used to write execution traces, adjudication records, and critical states to the session directory and disaster recovery storage. It includes at least the following fields: write-back entry identifier, trigger condition, trigger gate identifier, write-back target object type, write-back target pointer, idempotent key, write-back failure retry limit, and write-back timeout threshold. The trigger condition is one of the following event types: gate pass record writing, task completion record writing, rollback trigger writing, and open mode change writing. The idempotent key includes at least the session identifier, anchor number, and write-back entry identifier, and is used to perform overwrite writing when triggered repeatedly to avoid generating conflicting records. The write-back failure retry limit ranges from 1 to 5, for example, 3. The write-back timeout threshold ranges from 30 seconds to 10 minutes, for example, 2 minutes, and the value is based on the object storage write-after-read consistency latency and short-term rate limiting period. The list of alternative recovery sources must include at least the following fields: source identifier, source type, availability flag, bandwidth limit, most recent successful timestamp, and applicable shard set. The list of alternative storage locations must include at least the following fields: object type, location identifier, readability flag, region identifier, and rate limiting level. The switching selection rule is set to the following values: availability flag is available and most recent successful timestamp is up-to-date. When the bandwidth-limited branch takes effect, sources within the same city are preferred. When the number of consecutive read failures reaches the threshold for unreadable objects, locations with different region identifiers and readability flags are preferred, and the decision record index is written. Controlled execution follows the planned package phase sequence, advancing or disposing of all gating points; metadata recovery first restores routing and configuration, restores permissions and key references, and input pointers reference the baseline package stable version entry; if metadata consistency gating fails, it reverts to the previous stable version of the evidence package record according to the action in the gating point table and retryes once; if it still fails, it switches to the alternative recovery source or terminates the session according to the switching selection rules; in the full loading phase, core fragmentation is completed first, and digest consistency verification and media availability checks are performed for each batch; once the media is available, it retryes according to the retry limit; if the limit is exceeded, it pauses and waits or switches to the alternative storage location according to the switching selection rules, and writes to the adjudication record index; in the incremental loading phase, it is executed according to the batch chain sequence; at breakpoints, it performs anchor point rollback or fragment degradation according to the evidence package disposal recommendations; when fragment degradation occurs, the degraded fragment set is written to the runtime appendix object, and simultaneously written to the open gating exclusion set, which is only used for open determination; During the log replay phase, the shard location tuple table index object is used. The replay boundary is the anchor point position of each shard in the anchor point candidate record. Simultaneously, a check is performed using the same-city confirmed location and cross-regional replay location coverage from the location tuple table. Insufficient coverage triggers channel exclusion and anchor point rollback. If the transaction boundary gating fails, anchor point rollback is triggered and a plan update version is generated. The plan update version adds a parent plan pointer and update reason code to the plan header and writes two lists: allowed change fields and prohibited change fields. Allowed change fields include at least the anchor point sequence number, task sequence pointer, rollback relationship summary, degraded shard set, exception trigger flag, and execution... The fields for row window parameters, etc., must not be changed. These fields include at least the locking strategy version pointer, locking parameter version pointer, threshold table version summary, list summary set, and verification rule object summary. During the verification phase, the verification rule object is used to check and write the verification result summary. During this phase, no check items are added or deleted, and the failure judgment conditions are not changed. The opening phase is carried out according to the gating point table. The opening mode can be either restricted opening or full opening. The triggering condition for restricted opening is that the segmented opening gating is satisfied and the verification gating before opening is not satisfied. The triggering condition for full opening is that the verification gating before opening is satisfied and the opening gating exclusion set is empty. During execution, an execution trajectory object is generated and placed in the session directory. The execution trajectory should have fields such as task identifier, start time, end time, peak resource usage, gate point pass, rollback, downgrade, exception record, adjudication record index, and write-back execution record. The exception record type adopts five values: read failure, verification failure, permission failure, key failure, and insufficient resources. Each type of exception record has at least a consecutive count, threshold reference, and trigger.

[0022] S5. After convergence is complete, the new evidence package and baseline package are sealed, and the session trajectory, adjudication record, and parameter candidates are written to the disaster recovery storage. The specific implementation is as follows: Once the recovery plan package is executed and the termination condition of the plan header write phase is met, the convergence, sealing, and write-back phase begins. The phase termination condition is stored in the summary field, which includes at least the summary of the termination gate point identifier set, the summary of the set of allowed incomplete tasks, and the termination time window threshold field. This phase takes the plan package, execution trajectory, evidence package index, confidence record, anchor candidate record, baseline package, and threshold table version summary in the session directory as input, generates a convergence status record, and completes the sealing and writing of the evidence package and baseline package. It also writes back the trajectory index, adjudication entries, and parameter candidate objects to the disaster recovery storage index directory and object directory. Convergence determination uses a convergence condition table, which is written to the plan package and fixed with the locked parameter version. Convergence status records are written to the condition table summary and field name summary, supporting the review of judgment criteria. The convergence conditions must at least meet the following conditions: core shard reaches the anchor point position, relevant key gate points pass, open mode reaches the target mode set in the plan header, and the number of rollbacks exceeds the rollback limit. The core shard set references the shard set summary representing the core in the baseline package shard priority list, and the anchor point position references the anchor point position field of each shard in the anchor point candidate record. The advancement position references the advancement position summary in the execution trajectory object. The advancement position summary must at least contain the shard identifier, advancement position sequence number, advancement timestamp, source task identifier, and summary value. The source task identifier is either an incremental loading task or a log replay task to distinguish the advancement criteria. When the advancement position sequence number is not less than the corresponding anchor point position sequence number, the shard is considered to meet the advancement conditions. The open mode status references the mode field in the open status object or the gate point passing record. The open mode status is either restricted open or fully open. The convergence determination outputs a convergence status record, which includes at least the convergence conclusion, a list of unmet conditions, a rollback count, the current open mode status, a determination timestamp, the reference anchor number, a core fragment set summary, an anchor position summary, and a progress position summary. If the convergence conclusion is met, the system enters the standard archive path. If the convergence conclusion is not met and the current open mode status is restricted, the system enters the restricted convergence branch. If the convergence conclusion is not met and the current open mode status is restricted, the session status is written with an unconverged flag and a pending action flag object, an external alarm event object is generated, and written to the session directory index. The pending action flag object includes at least the session identifier, unconverged flag, and pending action flag. Fields include convergence reason code, summary of incomplete condition list, suggested action, and timestamp; the event payload structure of the external alarm event object repeatedly applies the pending action mark object, and adds fields such as event channel identifier, delivery status, and retry count to distinguish alarm delivery from session internal status records; restricted convergence branches can seal downgrade evidence packages, and write downgrade reason and downgrade scope summary into the evidence package. Downgrade reason can be verification failure, missing long-tail fragments, off-site pending matching, insufficient resources leading to planned downgrade, etc., and write down the downgrade fragment set summary and open gate exclusion set summary, so that subsequent sessions can select a more conservative plan caliber according to the evidence package integrity level; Sealing new evidence packages and new baseline packages involves post-write read verification during the versioning process. This versioning process includes a sealing batch number and an object version number. The sealing batch number is unique within the session and maintains consistency with the anchor sequence number. The sealing batch number is written to the session directory index and simultaneously to the new evidence package and new baseline package. The object version number includes at least the sealing batch number, object type code, and an incrementing sequence number. The incrementing sequence number monotonically increases within the same sealing batch to distinguish between resealing and updating within the same batch. The output structure of the new evidence package includes at least the following fields: session identifier, sealing batch number, object version number, anchor sequence number, anchor time, evidence package index pointer, evidence package entry summary, confidence record pointer, plan package summary, parent plan pointer, update reason code summary, execution trajectory summary, gate point pass record summary, exception and adjudication record index, rollback and downgrade record summary, final open mode, timestamp, parent evidence package pointer, parent anchor sequence number, and sealing status field. The plan package summary should include at least the plan header summary, task sequence summary, gating point table summary, resource quota table summary, rollback rule table summary, and convergence condition table summary; the execution trajectory summary should include at least the resource usage peak summary, anomaly category count summary, trigger action count summary, and key task completion summary, supporting rapid location of large objects without expansion; the new baseline package output should include at least the topology baseline list, shard priority list, degradable shard set, routing version list, configuration version list, permission version list, key reference version list, associated evidence package pointer, associated evidence package summary, sealing batch number, and object version number; the new evidence package should be synchronously written to the associated baseline package pointer and associated baseline package summary to ensure bidirectional traceability between the evidence package and the baseline package and reduce the risk of mismatch; the sealing status field can select "sealed" or "to be resealed" so that subsequent sessions can determine the integrity of the sealing and correspond to the plan caliber; The write-read verification is performed on both the new evidence package and the new baseline package. The verification items include at least object existence verification, digest consistency verification, and directory index consistency verification. Object existence verification includes ensuring that the archived directory object pointer is resolvable and that the object version number matches the object archive batch number. Digest consistency verification includes ensuring that the object content digest matches the directory digest field. Directory index consistency verification includes verifying that the index object pointer is resolvable and that the index archive batch number matches the object archive batch number, the index object version number matches the object version number, and the index digest matches the object digest. The write-after-read verification timeout threshold ranges from 30 seconds to 10 minutes, for example, 2 minutes. The value is determined based on the consistency level declared in the disaster recovery storage policy and the observable write-after-visibility latency percentile, combined with the object storage request limit and the maximum backoff window of the backoff policy. The retry limit ranges from 1 to 3, for example, 2. The value is determined based on the common windows of short-term object storage invisibility and rate-limited recovery, and to avoid prolonged blocking during retrying. The write-after-read verification timeout threshold field, the retry limit field, and the switchover selection rule field reference the threshold table object field, and a field name summary and value summary are written into the retry record. Verification failure triggers a retry; exceeding the retry limit... If the rate limiting still fails, the sealed status is written to the pending sealed mark, and the package content is written to the backup location entry in the alternative storage location list; the backup location entry selection is performed according to the switching selection rule, which prioritizes locations with different regions and readability marked as readable. If there are multiple optional locations, they are selected from low to high rate limiting level; the backup location pointer, failure reason code, and retry count are written to the sealed verification record and session record. The failure reason code can be of type such as object not visible, digest inconsistent, index not writable, etc.; the pending sealed mark is synchronously written to the sealed status field, so that subsequent sessions can identify the integrity level and select a more conservative plan generation caliber when referencing this evidence package; Session traces, adjudication records, and parameter candidates are written to disaster recovery storage for write-back updates and are traceable to the sealed objects. Session traces are organized by trace index objects and trace segment objects. The trace index object contains at least segment object pointers, time ranges, event type indexes, and key event offsets. The event type index is the same as the event type enumeration of the execution trace. Key event offsets are used to locate anchor point rollback, gating point triggers, open mode switching, and sealing completion times. Adjudication records are organized by adjudication entry tables. The adjudication entry tables contain at least conflict types, trigger condition summaries, adjudication actions, adjudication times, impact scope summaries, reference entry pointers, and mapping summaries. Conflict types are generated by mapping evidence package entry categories to execution exception categories. The mapping summary is written to the new evidence package. Conflict types include at least backup chain conflicts, log segment conflicts, transaction boundary conflicts, metadata drift, insufficient link freshness, and insufficient resources, which facilitates subsequent retrieval based on conflict type. Parameter candidates are organized using a candidate entry table, which includes at least the following fields: parameter name, original value, suggested value, summary of triggering basis, applicable scenario, associated anomaly category, associated gating point, candidate number, status flag, and reference pointer. The candidate generation rule references the candidate trigger count threshold field in the threshold table object. A candidate is generated when the number of occurrences of the same type of anomaly within the same session reaches this threshold. The candidate trigger count threshold ranges from 2 to 5, for example, 3. The value is determined by the frequency of observable anomaly repetitions to distinguish between occasional jitter and stable mismatch. Candidates do not take effect immediately after being written; the status flag is set to "to be tested and verified." A candidate index object is created in the session directory, including at least the following fields: candidate number, associated anomaly category, associated gating point, suggested verification scenario, suggested verification window, and reference pointer. This index object is used for subsequent testing and verification to determine whether to upgrade to a new parameter version. During write-back, boundary and completion markers are written as preliminary checks for subsequent sessions. If degraded fragments exist, a summary of the degraded fragment set and the reason for the degrade are written. The new baseline packet writes completion markers to the degraded fragments. These completion markers must include at least the completion target, completion trigger condition, allowed time window field name summary, and value summary. Completion trigger conditions can be selected from external completion trigger events or the next exercise session. Allowed time windows reference the completion time window field of the threshold table object. If there are off-site replay pending completion markers, a completion task requirement record is written. This record must include at least... The system includes information such as shard identifier, starting position for catching up, target position for catching up, allowable time window field name summary and value summary, reference anchor number, channel identifier, and requirement status. The allowable time window value range is from 1 hour to 72 hours, for example, 12 hours, and the value is based on the off-site replication and replenishment cycle within the acceptable window after recovery. A bidirectional reference is established between the catching up task requirement record and the new evidence package. The new evidence package is written into the catching up requirement summary, and the catching up task requirement record is written into the evidence package summary, so as to support the scheduling and verification of catching up tasks without accessing the original cluster runtime state.

[0023] In this embodiment, the distributed database cluster employs a multi-layered disaster recovery system, including synchronous replication within the same city, asynchronous replay in different locations, and object storage backup. A failure in the main center activates a recovery event. The disaster recovery control terminal creates a recovery session and locks the policy and parameter versions. The recovery time target (e.g., 60 minutes) and recovery point target (e.g., 300 seconds) are normalized into the session index object. Baseline packets and evidence packets are read, and self-consistent verification of the topology list, routing and configuration versions, and permission and key reference versions is performed. A resource budget table is generated based on target environment resource detection. Then, within an observation window (e.g., 90 seconds) and a window sliding step size (e.g., 15 seconds), the same-city confirmation location, the remote replay location, the backup endpoint location, and cross-shard transaction boundary markers are collected. Global consistency anchor point candidates are generated based on hard constraints, and admission is determined according to a threshold table, where the threshold is, for example, the link... Freshness 15 seconds, position difference 120 seconds, boundary marker integrity 98%, and 3 rollbacks allowed; when the admission criteria are not met, the observation window is rolled back and the failed shard group is resampled, and marked as a low-confidence candidate if necessary; a proof package is generated for the anchor candidates that pass the admission criteria and the items are checked in an itemized manner, including backup chain, log segment, transaction boundary, metadata version, and replication confirmation, and outputs a 4-level confidence level and a set of allowed actions; then, a recovery plan package is generated based on the confidence level and resource budget, and metadata recovery, core shard priority loading, incremental loading, and log replay are performed in stages, and verification and opening are promoted at the gating point; when the rollback condition is triggered, the previous anchor point is switched, and the number of rollbacks does not exceed 2, for example; after the convergence criteria are completed, the new evidence package and the new baseline package are sealed, and the session trajectory, adjudication record, and parameter candidates are written back.

[0024] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-level disaster recovery backup and rapid recovery method for database clusters, characterized in that, include: S1. Trigger recovery session, lock policy version and parameter version, read baseline package and evidence package, complete self-consistency verification and determine resource budget; S2. Within the observation window, obtain the same-city confirmation location, remote playback location, backup chain end location, and transaction boundary marker, generate global consistency anchor point candidates, and determine the admission conditions. S3. Generate a proof package for anchor point candidates, and verify the consistency of backup chain, log segment, transaction boundary and metadata version in sequence to determine the confidence level; S4. Generate recovery plan packages according to confidence levels, and execute metadata recovery, core fragment priority loading, incremental loading and log replay according to the plan. Advance segmented verification and opening according to gating points, and switch to the previous anchor point when the rollback conditions are met. S5. After convergence is complete, the new evidence package and baseline package are sealed, and the session trace, adjudication record and parameter candidate are written to the disaster recovery storage.

2. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, Trigger the recovery session, lock the policy and parameter versions, read the baseline and evidence packages, complete self-consistency verification, and determine the resource budget, including: After triggering a session recovery, a session identifier is generated and an index conflict retry is performed, along with the locking policy version, parameter version, and threshold table object. The baseline package and evidence package are read and digests are verified in two stages: catalog index and object content. The decision items are written based on the self-consistent verification of the fixed sequence, and a resource budget table is generated based on the target environment detection.

3. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, Within the observation window, obtain the same-city confirmation location, off-site playback location, backup chain end location, and transaction boundary markers, including: When obtaining the same-city confirmation location, remote playback location, backup chain end location and transaction boundary marker within the observation window, a convergence condition table is formed based on the write-back rule table to determine convergence. If the convergence condition is not met and the site is in a restricted open state, the downgrade evidence is sealed and the reason for the downgrade is recorded.

4. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, Generate global consistency anchor point candidates and determine admission criteria, including: When generating globally consistent anchor point candidates and determining admission conditions, versioning is written into the new evidence package and the new baseline package, and read verification is performed after writing. If the verification fails, switch to the backup storage within the retry limit to rewrite, write back the session trace, decision entries and parameter candidates, and mark the parameter candidates as pending exercise verification status.

5. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, The proof package for anchor point candidates includes: When generating a proof package for anchor point candidates, the backup artifact directory list, log segment directory list, transaction evidence list, metadata version list, and replication confirmation list are read based on the session directory locking baseline package pointer and locking evidence package pointer, and a summary and threshold table version summary are written to each list. When the inventory index is missing, the inventory object is unreadable, or the summary verification fails, switch to the stable inventory pointer. If the switch fails, the verification path is executed using the default threshold parameter of the policy snapshot.

6. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, The backup chain, log segments, transaction boundaries, and metadata version consistency are checked sequentially to determine the confidence level, including: Verify in sequence whether the backup chain, log segment, transaction boundary, and metadata version are consistent; Calculate the confidence level, set the threshold table to generate five types of entries: backup chain, log segment, transaction boundary, metadata version, and replication confirmation, and write the reason code and judgment basis summary respectively. Item disposal suggestions and dependency suggestions are converted into a set of allowed actions. A fixed set of levels and a fixed decision order are set to generate confidence records. The confidence records and item index objects are then written to the session directory.

7. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, Generate recovery plan packages based on confidence levels, including: When generating a recovery plan package according to the confidence level, the input pointer of the plan package is the session directory, and the plan header contains a lock version pointer and a threshold table summary; Based on the confidence level, the task quota and gate point are linked, and the failure handling actions are set as rollback anchor point, downgrade opening, pause and wait, or switch to alternative recovery source.

8. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, The system executes metadata recovery, core shard priority loading, incremental loading, and log replay as planned. It advances segmented verification and opening based on gating points, and switches to the previous anchor point when rollback conditions are met, including: Perform metadata recovery, core shard priority loading, incremental loading and log replay as planned, and promote verification and opening at the gating point; When a rollback is triggered, switch to the previous anchor point within the rollback limit and generate a planned update version, while keeping the version pointer unchanged; Write the degraded fragments into the open exclusion set, and write the rollback and degrade information into the execution trajectory.

9. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, After convergence is complete, it includes: After convergence is completed, convergence is determined according to the convergence condition table and stage termination time window fixed in the plan package, and a convergence status record is generated. The convergence status record includes a summary of the condition table and a summary of the field names. When the open mode is set to restricted open, write the reason for the downgrade. If the convergence condition is not met, write a non-convergence flag and generate an alarm object to be processed.

10. The multi-level disaster recovery backup and rapid recovery method for database clusters according to claim 1, characterized in that, The new evidence package and baseline package are sealed, and the session trace, adjudication record, and parameter candidates are written to the disaster recovery storage, including: When sealing new evidence packages and baseline packages, versioning is performed using the sealing batch number and object version number, and a read-after-write check is performed to verify the existence of objects, the consistency of summaries, and the consistency of indexes. If the verification fails, retry according to the threshold, and write to the backup location according to the switching rules, while marking the sealed status as pending resealing; Write back the session trajectory index, adjudication entries, parameter candidate entries and their indexes to the disaster recovery storage, and set the parameter candidate status flag value to be verified in the exercise; Write completion markers to downgraded fragments, write catch-up requirement records to off-site playback fragments to be caught up, and establish bidirectional references with the evidence package.

Images