A method, medium, and device for obtaining a database recoverable time interval.

Abstract

This invention relates to the field of database management technology, and in particular to a method, medium, and device for obtaining a database recoverable time interval. It determines the start and end sequence numbers by using the current log sequence number and timeline identifier, avoiding calculation errors in the recoverable interval due to incorrect scanning range. Through continuity analysis using file naming sequences and sequence numbers, it automatically identifies log integrity before recovery, preventing recovery failure due to missing logs. By parsing historical timeline files and verifying their validity based on fork points and associated sequence numbers, it automatically identifies legitimate log segments in timeline fork scenarios, preventing recovery failure due to using incorrect timeline logs. By integrating continuity status, time mapping, validity results, and archiving delay thresholds to calculate the recoverable interval, it can generate a clear and effective time range before recovery, avoiding recovery failure due to blind operations, while dynamically adjusting the termination time to ensure synchronization with the master node log status.

Description

Technical Field

[0001] This invention relates to the field of database management technology, and in particular to a method, medium, and device for obtaining the recoverable time interval of a database. Background Technology

[0002] In the field of database management, accurately determining the recoverable time range is crucial for ensuring data security and business continuity. Point-in-time recovery technology allows a database to be restored to a specific point in time, and its reliability directly depends on the integrity and continuity of the write-ahead log and proper timeline management.

[0003] In the prior art, the Chinese invention patent "Database Recovery Method and Apparatus, Storage Medium and Electronic Device" (application number CN202311178386.0, application date September 13, 2023) focuses on determining the recovery order of database objects by evaluating key application indices, aiming to optimize recovery efficiency. However, it does not solve the pre-inspection problem before recovery and cannot ensure that the target recovery time point is within the effective write-ahead log range, which may lead to failure when recovering data due to missing key logs. The Chinese invention patent "A Data Recovery Method and Related Device" (application number CN202311056531.8, application date August 21, 2023) improves the accuracy of data recovery by generating logs that record data page modifications and version identifiers, ensuring data accuracy by comparing version information during recovery. However, its focus is on matching data page versions rather than pre-judging the feasibility of recovery time points. The system only terminates with an error when encountering missing logs or timeline conflicts during the recovery process. Users cannot know whether the specified target time point is feasible before performing recovery. This leads to the inability to automatically and quickly detect the fork point when a timeline fork occurs due to a failure switch of the database master node, thus failing to reset the scan range in time to correctly obtain the recoverable time interval. This can easily cause the recovery operation to fail due to the use of logs from the wrong timeline.

[0004] Therefore, accurately assessing the availability of the recovery window before database recovery is performed and dynamically adjusting the recovery interval has become an urgent problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention provides a method for obtaining a database recoverable time interval, which includes the following steps: S1. Determine the start and end sequence numbers of this scan based on the current log sequence number and current timeline identifier corresponding to the database master node.

[0006] S2, scan the log archive pool according to the start and end sequence numbers, perform continuity analysis based on the file naming sequence and log sequence number range corresponding to the scanned log segment files, obtain continuity status information and sequence number-timestamp mapping relationship, where the continuity status information includes the identification results of missing segments, delayed segments and complete segment sequences.

[0007] S3, based on the timeline bifurcation points and associated log sequence numbers obtained from parsing the historical timeline file corresponding to the current timeline identifier, performs timeline validity verification on the scanned log segment files, and obtains the validity verification result corresponding to each scanned log segment file, wherein the validity verification result is valid or invalid.

[0008] S4. Based on the continuity status information, sequence number-timestamp mapping relationship, legality verification result and preset archiving delay threshold, obtain the recoverable time interval. The start time of the recoverable time interval is determined based on the start timestamp of the earliest complete segment sequence, and the end time is determined based on the end timestamp of the latest legal log segment file.

[0009] The present invention also provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described method for obtaining the database recoverable time interval.

[0010] The present invention also provides an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0011] This invention has at least the following beneficial effects: By determining the start and end sequence numbers using the current log sequence number and timeline identifier, the scanning range is precisely bound to the current state of the database master node, solving the problem of not being able to automatically reset the scanning range after a timeline fork. This ensures that only log segments related to the current master node's log chain are scanned, avoiding calculation deviations in recoverable intervals due to incorrect scanning ranges. Through continuous analysis using the log segment file naming sequence and sequence number range, missing, delayed, and complete log segments can be automatically identified before recovery, solving the problem of not being able to pre-check log integrity before recovery. This allows users to know whether there are complete logs supporting the target time point before performing recovery, avoiding recovery failure due to missing logs. Furthermore, by parsing the timeline history… The system performs validity checks on the files based on fork points and associated sequence numbers, automatically identifying legitimate log segments in timeline fork scenarios. This solves the problem of not being able to detect timeline conflicts before recovery, ensuring that the recoverable time interval only includes logs from the current timeline and legitimate predecessor timelines, avoiding recovery failures due to the use of incorrect timeline logs. By integrating continuity status, time mapping, validity results, and archiving delay thresholds to calculate the recoverable interval, it can generate a clear and valid time range before recovery, solving the problem of not being able to pre-determine the feasibility of the target recovery time point. This allows users to know which time points are safe to recover before performing recovery, avoiding recovery failures caused by blind operations. At the same time, it dynamically adjusts the termination time to ensure matching with the master node log synchronization status. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a method for obtaining a database recoverable time interval provided in Embodiment 1 of the present invention. Detailed Implementation

[0014] 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.

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

[0016] Example 1 This first embodiment provides a method for obtaining the recoverable time interval of a database, such as... Figure 1 As shown, the method for obtaining the recoverable time interval of the database includes the following steps: S1. Determine the start and end sequence numbers of this scan based on the current log sequence number and current timeline identifier corresponding to the database master node.

[0017] Among them, the database master node is the core node in the database cluster that handles business read and write requests and generates write-ahead logging (WAL). It is different from the standby node, which only synchronizes the master node data and does not process write requests. As the sole data source for the current log sequence number and the current timeline identifier, it ensures that the scan range is completely aligned with the latest data status of the business and avoids deviations caused by obtaining data from non-core nodes.

[0018] The current log sequence number (LSN) is a unique numerical identifier (formatted as 0x12345678) that marks the order in which WAL logs are written in databases such as PostgreSQL. It monotonically increments with each data modification by the master node and is used to reflect the latest progress of data modification by the database master node.

[0019] The current timeline identifier is a unique numerical identifier (such as Timeline2) automatically generated after a database master node fails and switches over (e.g., a standby node is promoted to master node). It is used to distinguish log chains under different failure scenarios. For example, after the original master node fails, the log chain generated by the new master node belongs to a different timeline than the log chain of the original master node.

[0020] The current log sequence number and the current timeline identifier represent the progress of data modification on the database's master node and the log chain attribution identifier. On the one hand, the current log sequence number serves as the end point of the scan, ensuring that the scan covers the archived logs corresponding to the latest data on the master node. On the other hand, the current timeline identifier implicitly limits the chain attribution of the scanned logs, that is, only the logs of the current timeline and the valid predecessor timelines. Combined with the end sequence number of the previous scan as the starting point of this scan, the start and end sequence numbers of this scan are finally determined, avoiding scanning redundant logs or missing critical logs.

[0021] Correspondingly, the start and end sequence numbers represent the starting and ending boundaries of the current scan's log archive pool, both expressed as log sequence numbers, such as the start sequence number 0x10000000 and the end sequence number 0x12345678, used to clearly define the precise range of the scan. Specifically, the start sequence number typically reuses the end sequence number from the previous scan to achieve incremental scanning; the end sequence number corresponds to the current log sequence number of the master node, ensuring coverage of the latest logs. The combination of these two can avoid scanning processed historical logs to reduce load, and avoid scanning future logs that have not yet been generated to avoid invalid judgments, while providing a clear range benchmark for subsequent continuous analysis.

[0022] In one specific embodiment, the start and end sequence numbers include a start sequence number and an end sequence number, and S1 includes the following steps: S11. Establish a communication connection with the database master node, call the built-in log sequence number query interface of the database master node to obtain the current log sequence number corresponding to the database master node. The current log sequence number is used to reflect the latest progress of the current data modification of the database master node.

[0023] S12, call the system status query interface of the database master node, read the system control information of the database master node, and extract the current timeline identifier corresponding to the database master node from the system control information. The current timeline identifier is a unique identity identifier generated after the database master node fails and switches over, which is used to distinguish the log chain under different failure scenarios.

[0024] S13, use the termination sequence number recorded during the previous log archive pool scan as the starting sequence number of this scan, and use the current log sequence number as the termination sequence number of this scan.

[0025] The built-in log sequence number query interface of the database master node is a program interface natively provided by the database master node for querying the current LSN, such as the pg_current_wal_lsn() function interface of PostgreSQL. It can directly obtain the real-time current log sequence number from the master node, avoiding data lag or errors caused by indirect querying through third-party tools, and ensuring that the subsequently determined scan termination point can accurately match the latest data modification progress of the master node.

[0026] The system control information of the database master node is a collection of data stored locally in the core configuration and status files (such as the pg_control file in PostgreSQL). It contains key information such as timeline identifiers, checkpoint information, and log configurations. It is used to record the basic operating parameters of the master node and is a reliable data source for extracting the current timeline identifier, ensuring the accuracy of distinguishing log chains under different failure scenarios.

[0027] Correspondingly, the system status query interface of the database master node is a program interface natively provided by the database master node for reading core system control information, such as the pg_control_checkpoint() function interface of PostgreSQL. It can extract system control information containing the current timeline identifier. The returned data comes from the system control file of the master node and has the characteristic of being tamper-proof, ensuring that the obtained current timeline identifier can accurately reflect the current log chain ownership of the master node.

[0028] Therefore, by directly calling the built-in interface of the database master node, it is ensured that the obtained current log sequence number and current timeline identifier have no transmission delay or data deviation. Incremental scanning is achieved by reusing the termination sequence number of the previous log archive pool scan as the starting sequence number of this scan, avoiding the duplication of verified logs. At the same time, the current log sequence number is used as the termination sequence number of this scan to ensure that the scan covers the latest logs of the master node, ultimately forming a precise, efficient, and non-redundant scan range definition logic.

[0029] As described above, by establishing a communication connection with the database master node and calling the built-in log sequence number query interface, the obtained current log sequence number comes directly from the log generation source, avoiding data delays or distortions caused by third-party tools forwarding data. This ensures that the parameter used as the scan termination sequence number can accurately match the latest data modification progress of the master node. By calling the master node system status query interface and extracting the current timeline identifier from the system control information, the obtained current timeline identifier comes from the master node's tamper-proof system control file, rather than manually configured or synchronized data. This avoids timeline identifier errors caused by human error or synchronization deviations, ensuring that the subsequent implicitly limited log chain affiliation is consistent with the actual state of the master node, reducing invalid log scanning, and ultimately forming a precise, efficient, and non-redundant scan range definition logic.

[0030] S2, scan the log archive pool according to the start and end sequence numbers, perform continuity analysis based on the file naming sequence and log sequence number range corresponding to the scanned log segment files, obtain continuity status information and sequence number-timestamp mapping relationship, where the continuity status information includes the identification results of missing segments, delayed segments and complete segment sequences.

[0031] The log segment file is a file entity generated by the database after dividing the WAL log into fixed sizes (such as 16MB by default in PostgreSQL). The file records a continuous data modification operation and the corresponding metadata. Each file has a unique name, such as 0000000200000001000000F0 in PostgreSQL.

[0032] The log archive pool is a dedicated storage area in the database used for persistent storage of log segment files. It is used to store log segment files that have been generated and archived from the master node for a long time.

[0033] The file naming sequence is a set of filenames arranged in the order in which log segment files are generated. For example, 0000000200000001000000F0→0000000200000001000000F1→0000000200000001000000F2. The naming rule implies the order in which log segments are generated and their timeline attribution. It is used to make a preliminary judgment on whether log segments are archived sequentially and is a surface-level judgment basis for continuity analysis.

[0034] The log sequence number range is the interval between the start and end values ​​of the log sequence number corresponding to a single log segment file. For example, the log sequence number range of a certain log segment file is 0x10000000-0x1000FFFF. This log sequence number range is obtained by parsing the metadata in the header of the log segment file. It reflects the logical position of the log segment file in the overall log chain and is used to accurately determine whether the log sequence numbers of adjacent log segments are seamlessly connected. It is an in-depth judgment basis for continuity analysis.

[0035] In one specific embodiment, S2 includes the following steps: S21. Based on the start and end sequence numbers, locate the storage range of log segment files in the log archive pool, and scan all log segment files within the storage range through the file query interface to obtain the actual file name and storage path of each log segment file.

[0036] S22, extract the actual file names of the scanned log segment files, parse the log sequence number corresponding to each scanned log segment file according to the naming rules of the database log segment files, and construct the actual file naming sequence and log sequence number range.

[0037] S23, based on the start and end sequence numbers and the actual file naming sequence, check whether the log sequence number range is seamlessly connected, and obtain the continuity status information based on the check results.

[0038] S24, invoke the database log parsing tool to read the header metadata of each scanned log segment file, and extract the start and end timestamps corresponding to each log segment file.

[0039] S25. Establish a sequence number-timestamp mapping relationship based on the log sequence number, start timestamp, and end timestamp corresponding to each scanned log segment file.

[0040] The storage range of the log archive pool is the range of log segment files stored in the physical storage medium, determined by the log segment file path boundaries corresponding to the start and end sequence numbers. For example, in PostgreSQL, the file corresponding to LSN0x10000000 is stored in the pg_wal / archive / 00000002 / directory. This is used to limit the scan boundary, avoid scanning files in irrelevant storage paths, and improve scan efficiency.

[0041] The file query interface is a program interface used to access the log archive pool storage media. Through the file query interface, a list of log segment files within the storage range can be obtained in batches. It supports filtering by path and sorting by filename, ensuring efficient acquisition of the actual file name and storage path of each log segment file.

[0042] The naming rules for database log segment files follow the database-defined log segment file naming format. For example, in PostgreSQL, log segment files are named as a hexadecimal string of "timeline + high byte of log sequence number + low byte of log sequence number". This string contains encoded information of the timeline identifier and the log sequence number, which is used to parse the corresponding log sequence number from the filename and establish the association between the file and the logical sequence.

[0043] The actual file naming sequence is the set of filenames of the scanned log segment files sorted according to naming rules. For example, sorting by the sequence number in the filename reflects the actual order of the archived log segment files.

[0044] The header metadata of a log segment file is descriptive data stored at the beginning of the log segment file. It contains key information such as the file creation time (start timestamp), write completion time (end timestamp), corresponding log sequence number range, and timeline identifier. Using database log parsing tools provided by the database provider for reading log segment file metadata, such as PostgreSQL's pg_waldump, the timestamp, checksum, and log sequence number range in the file header can be parsed to accurately extract the start and end timestamps corresponding to each log segment file, ensuring the accuracy of the time data. Then, the log sequence number, start timestamp, and end timestamp corresponding to each scanned log segment file are matched to establish a sequence number-timestamp mapping relationship.

[0045] The above achieves full automation from scanning files to generating analysis results, eliminating the need for manual intervention to parse filenames, compare serial numbers, or extract timestamps, thus reducing errors caused by manual operation. At the same time, it forms a complete data chain of files, serial numbers, and timestamps, providing a consistent and reliable data source for subsequent verification and calculation.

[0046] In one specific embodiment, S23 includes the following steps: S231, Based on the naming rules of the log segment files corresponding to the start and end sequence numbers, generate the expected name sequence corresponding to the log sequence number range, wherein the expected name sequence includes the expected file name corresponding to each scan order.

[0047] S232, initialize the scan order i=1.

[0048] S233, the i-th log segment file scanned is identified as the file to be checked corresponding to the scan order i.

[0049] S234, match the expected file name corresponding to the scan order i with the actual file name corresponding to the scanned i-th log segment file, and determine the intermediate type corresponding to the scanned i-th log segment file based on the matching result, wherein the intermediate type is complete or potentially lost.

[0050] S235, if the scanning order i=N, then obtain the intermediate type corresponding to each scanned log segment file and execute step S236; otherwise, update i=i+1 and repeat step S233, where N is the total number of scanned log segment files.

[0051] S236, Based on the intermediate type corresponding to each scanned log segment file, determine the continuity check result corresponding to each scanned log segment file, wherein the continuity check result is complete, missing, or delayed.

[0052] S237. Obtain continuity status information based on the continuity verification results corresponding to each scanned log segment file.

[0053] In one specific embodiment, S236 includes the following steps: For any log segment file detected, if the intermediate type corresponding to the log segment file is complete, then the continuity check result corresponding to the log segment file is determined to be complete.

[0054] If the intermediate type corresponding to the log segment file is potentially lost, and the intermediate type corresponding to the last log segment file scanned is complete, then the continuity check result corresponding to the log segment file is determined to be missing.

[0055] If the intermediate type corresponding to the log segment file is potentially lost, and the intermediate type corresponding to the last log segment file scanned is also potentially lost, then the continuity check result corresponding to the log segment file is determined to be delayed.

[0056] Based on the start and end sequence number range and the database log segment file naming rules, the expected names of the log segment files that should exist are generated, and the expected name sequence is combined to obtain the benchmark template for continuity analysis. This template is then compared with the actual file names of the log segment files that are actually scanned to determine whether there are any missing or abnormal files.

[0057] The scan order is an index assigned to the expected sequence of names and each file actually scanned, establishing a one-to-one correspondence between the expected file names and the actual file names, ensuring the accuracy of successive matching and avoiding mismatches.

[0058] The intermediate type is a preliminary labeling of the actual file status after successive matching. It only includes complete and potentially lost. Complete indicates that the actual file name of the log segment file is consistent with the expected file name, confirming its existence and compliance. Potentially lost indicates that the log segment file with the corresponding expected file name was not scanned. It is not yet possible to determine whether it is a real loss or an archiving delay. It is used to provide a basis for judgment for subsequent final status correction.

[0059] Based on the intermediate types, the final state of each log segment file is corrected by combining the intermediate types of the last log segment file, and the continuity verification result is obtained, which includes three categories: complete, missing, and delayed.

[0060] N is the number of log segment files actually scanned. N is used as the iteration termination condition to ensure that all actually scanned log segment files have completed intermediate type marking. At the same time, the difference between the expected name sequence length and N helps to determine whether there are any unchecked log segment files.

[0061] As described above, by successively comparing the expected file sequence under ideal conditions with the actual scanned file sequence, and combining the file status at the termination point to confirm the true status of the log segment files, the consistency and reliability of the continuity analysis results under different scenarios are ensured without the need for manual intervention to determine whether the files are continuous or whether the unscanned files are missing or delayed.

[0062] S3, parse the historical timeline file corresponding to the current timeline identifier, and perform timeline validity verification on the scanned log segment files based on the parsed timeline bifurcation points and associated log sequence numbers, and obtain the validity verification result corresponding to each scanned log segment file, where the validity verification result is valid or invalid.

[0063] The timeline history file is a metadata file in the database that records timeline fork information. It contains records of fork points generated by each failover, used to trace the origin of the current timeline and the fork positions of all predecessor timelines. For example, in the PostgreSQL file 00000002.history, the 00000002 in the filename corresponds to the current timeline identifier.

[0064] A timeline fork is the point in time when a database master node fails and switches over (e.g., the original master node crashes and the standby node becomes the new master node). Each timeline fork corresponds to a unique associated log sequence number, which indicates the log progress at the time of the fork. For example, the last log sequence number written by the original master node is 0x12345678, which is the associated log sequence number corresponding to the timeline fork, used to define the valid range of logs in different timelines.

[0065] Specifically, when a database master node fails over, a new timeline identifier is generated and recorded in the timeline history file. By parsing this timeline history file, all timeline forks and associated log sequence numbers are obtained. Based on this, the scanned log segment files are checked to see if they belong to the current timeline and its valid predecessor timeline (i.e., the valid previous timeline). If the log sequence number of the log segment file is before the timeline fork and belongs to the predecessor timeline, or after the timeline fork and belongs to the current timeline, it is considered valid; otherwise, it is invalid. This ensures that only valid logs consistent with the current master node's log chain are used when calculating the recoverable interval.

[0066] In one specific embodiment, S3 includes the following steps: S31. Based on the current timeline identifier, locate the timeline history file corresponding to the current timeline identifier in the log archive pool. The timeline history file is used to record the historical records of timeline switching of the database master node, including several timeline forks and corresponding associated log sequence numbers. The associated log sequence number is the log sequence number of the database master node at the time of timeline switching, which is used to determine the valid range of logs for different timelines.

[0067] S32, extract the reference timeline identifier from the header metadata of each scanned log segment file, compare the reference timeline identifier with the current timeline identifier, and obtain the first comparison result corresponding to each scanned log segment file, wherein the first comparison result is either the identifier matches or the identifier does not match.

[0068] S33, based on the first comparison result corresponding to each scanned log segment file, determine the target timeline identifier and target log sequence number corresponding to each scanned log segment file.

[0069] S34, compare the reference timeline identifier corresponding to each scanned log segment file with the corresponding target timeline identifier, and compare the log sequence number corresponding to each scanned log segment file with the corresponding target log sequence number to obtain the second comparison result corresponding to each scanned log segment file.

[0070] S35, based on the second comparison result corresponding to each scanned log segment file, obtain the legality verification result corresponding to each scanned log segment file.

[0071] The reference timeline identifier is a timeline identifier extracted from the header metadata of the scanned log segment file, recording the actual timeline to which the log segment file belongs.

[0072] The reference timeline identifier of the scanned log segment file is directly compared with the current timeline identifier. If the reference timeline identifier matches the current timeline identifier, the first comparison result is determined to be an identifier match; otherwise, it is an identifier mismatch. Log segment files with matching identifiers are considered as log segment files that may belong to the current timeline after initial screening, thus narrowing down the scope of subsequent verification.

[0073] The log segment file undergoes a dual comparison: a comparison between the reference timeline identifier and the target timeline identifier, and between the actual log sequence number and the target log sequence number range. This comprehensive second comparison result determines the validity of the log segment file, ensuring that the verification result considers both timeline attribution and log sequence number validity. Specifically, if the log segment file corresponds to the current timeline, it needs to be verified whether its log sequence number is less than or equal to the target log sequence number, i.e., the associated log sequence number of the latest timeline fork. If the log segment file corresponds to a predecessor timeline (the target timeline identifier is the predecessor timeline, determined by the previous timeline fork), it needs to be verified whether its log sequence number is less than or equal to the target log sequence number, i.e., the associated log sequence number of the previous timeline fork, ensuring that the log segment file belongs to a valid log before the predecessor timeline fork.

[0074] The above-mentioned dual mechanism of timeline identifier comparison and log sequence number range verification accurately filters out legitimate log segments that are consistent with the current master node's log chain, solving the problem of misjudgment that may occur with single identifier comparison; by covering the current and predecessor timelines, the comprehensiveness of the verification is ensured, and the efficiency is improved by reducing invalid calculations through preliminary screening, while also taking accuracy into account, providing a reliable solution for log legitimacy judgment in complex timeline fork scenarios.

[0075] In one specific embodiment, S33 includes the following steps: For any log segment file scanned, if the first comparison result corresponding to the log segment file is that the identifier matches, then the latest timeline bifurcation point is determined as the target timeline identifier corresponding to the log segment file, and the associated log sequence number corresponding to the target timeline identifier is determined as the target log sequence number corresponding to the log segment file.

[0076] If the first comparison result for the log segment file is that the identifiers are inconsistent, then the timeline bifurcation point preceding the latest timeline bifurcation point is determined as the target timeline identifier for the log segment file, and the associated log sequence number corresponding to the target timeline identifier is determined as the target log sequence number for the log segment file.

[0077] The timeline bifurcation points recorded in the timeline history file are arranged in the order of occurrence, such as bifurcation point 1 → bifurcation point 2 → ... → latest bifurcation point. Each timeline bifurcation point corresponds to a timeline identifier and associated log sequence number.

[0078] For log segment files belonging to the current timeline whose identifiers match in the first comparison, their legal range is defined by the latest timeline fork point, requiring only that the log sequence number is after the latest timeline fork point. For log segment files that may belong to a previous timeline with inconsistent identifiers, their legal range is defined by the timeline fork point preceding the latest timeline fork point, requiring the log sequence number to be between the previous timeline fork point and the latest timeline fork point. By using a reverse matching method according to the timeline fork point order, it is ensured that each log segment file can find a corresponding legal timeline benchmark, providing a clear judgment standard for subsequent double comparisons.

[0079] The above approach, by differentiating target benchmarks for scenarios with consistent and inconsistent identifiers, achieves refined timeline legality verification. This avoids misjudging legitimate predecessor logs or missing illegal cross-timeline logs due to using a single benchmark based solely on the current timeline identifier. It ensures that all possible legitimate log segment files in the current timeline and legitimate predecessor timelines can proceed to the next step of verification through benchmark matching, while excluding obviously invalid log segment files, thus balancing the comprehensiveness and efficiency of the verification.

[0080] S4. Based on the continuity status information, sequence number-timestamp mapping relationship, legality verification result and preset archiving delay threshold, obtain the recoverable time interval. The start time of the recoverable time interval is determined based on the start timestamp of the earliest complete segment sequence, and the end time is determined based on the end timestamp of the latest legal log segment file.

[0081] The database master node generates write-ahead logs in real time. However, synchronizing these logs to the archive pool involves inherent asynchronous latency, such as network transmission time and storage write time. A preset archive latency threshold is a pre-configured maximum time difference allowed between the master node logs and the archive logs. This threshold measures the synchronization level between the archive logs and the latest data on the master node, preventing the use of seemingly up-to-date but out-of-sync logs to calculate the termination time due to archive latency (the master node has generated logs but has not completed archiving). This ensures that complete archive logs are available during recovery. The preset archive latency threshold can be set by the implementer based on actual conditions, for example, 300 seconds.

[0082] The recoverable time interval represents the effective time range within which database recovery can be performed. It includes two boundaries: start time and end time. The recovery target time specified by the user must be within this recoverable time interval to ensure successful recovery. This can effectively solve the problem of recovery failure caused by the user manually specifying a time that is outside the effective range.

[0083] The earliest complete segment sequence is generated from the set of continuous and unmissing log segments selected from the continuous state information. Its starting timestamp determines the earliest boundary of the recoverable interval, ensuring that there is corresponding complete log support during recovery.

[0084] The latest valid log segment file is the log segment with the largest log sequence number from the log segments that have passed the validity check, which is also the log segment file with the most recent generation time. Its end timestamp is the basis for calculating the end time of the recoverable interval, ensuring that the recovery can cover the time point corresponding to the latest valid log.

[0085] In one specific embodiment, S4 includes the following steps: S41, based on the continuity status information, select the set of first log segment files marked as complete segments.

[0086] S42, based on the sequence number-timestamp mapping relationship, determine the starting timestamp corresponding to the log sequence number of the earliest complete segment in the first log segment file set as the starting time of the recoverable time interval.

[0087] S43, based on the validity check results, select the set of valid second log segment files.

[0088] S44. Based on the sequence number-timestamp mapping relationship, determine the end timestamp of the log segment file corresponding to the latest log sequence number in the second log segment file set as the reference time.

[0089] S45, calculate the time difference between the reference time and the current system time. If the time difference is less than or equal to the preset archiving delay threshold, the reference time is determined as the end time of the recoverable time interval. If the time difference is greater than the preset archiving delay threshold, the current system time minus the preset archiving delay threshold is determined as the end time of the recoverable time interval.

[0090] The reference time is the end timestamp of the latest valid log segment file in the second log segment file set. It serves as the initial reference value for the termination time of the recoverable interval and reflects the latest time boundary of valid log coverage.

[0091] The current system time is the real-time system time of the database master node, such as the current UTC time of the server. It is used to compare with the reference time to calculate the archiving latency and determine whether the log archiving is lagging behind the data generation progress of the master node.

[0092] If the time difference between the reference time and the current system time is less than or equal to the preset archiving delay threshold, it means that the archived logs have basically caught up with the master node's progress, and the reference time can be safely used as the termination time. If the time difference is greater than the preset archiving delay threshold, it means that the archiving is seriously lagging behind, and some logs generated by the master node have not yet been archived. If the reference time is still used as the termination time, recovery may fail due to missing unarchived logs. Therefore, the termination time needs to be corrected by subtracting the preset archiving delay threshold from the current system time to ensure that the logs corresponding to the termination time have been archived. By sacrificing a small amount of timeliness for recovery integrity, the optimal balance between timeliness and integrity is achieved, ensuring the safe availability of the recoverable time interval.

[0093] The above-mentioned progressive logic, which ensures log availability through integrity filtering, correct attribution through legality filtering, dimension transformation through time mapping, and reliable synchronization through delay threshold correction, transforms abstract log parameters into intuitive and reliable time ranges. From complete segment filtering to legal segment filtering, and then to time mapping and dynamic correction, no manual intervention is needed to determine which time points are recoverable. Especially in complex scenarios such as missing segments, multiple timeline forks, and archiving delays, it can quickly output accurate time ranges.

[0094] In one specific embodiment, the method for obtaining the recoverable time interval of the database further includes the following steps: S5, output the recoverable time interval, and trigger the corresponding alarm when abnormal situations such as missing log segments, illegal timeline forks, or delays exceeding the threshold are detected.

[0095] The calculated recoverable time range, including the start and end times, will be output in an intuitive form (such as text, interface pop-ups, or API return values) for operation and maintenance personnel or business system users to use directly for data recovery operations.

[0096] A missing log segment anomaly refers to a log segment file marked as missing in the continuous status information. This means that the log segment is confirmed to be permanently lost and not due to archiving delay. It will directly cause the start time of the recoverable interval to be shifted backward, making it impossible to cover the time corresponding to the missing segment. If not handled, the recovery time point selected by the user may fail due to missing logs. An alarm needs to be triggered to prompt the operation and maintenance personnel to replenish the missing logs, such as by restoring from backup.

[0097] A timeline fork illegality exception is an invalid log segment file that belongs to another forked timeline. This type of exception indicates that there are redundant logs from unrelated timelines in the log archive pool, which may interfere with the calculation of recoverable intervals. If illegal logs are mistakenly included in the reference time, an alarm should be triggered to prompt the operation and maintenance personnel to clean up the illegal logs to avoid occupying storage resources or causing misjudgment in verification.

[0098] An archive delay exceeding the threshold occurs when the time difference between the reference time and the current system time exceeds the preset archive delay threshold. This type of anomaly indicates that log archiving is severely delayed and the master node logs have not been synchronized to the archive pool in a timely manner. This will cause the end time of the recoverable interval to be corrected (earlier than the reference time). If not handled, users may not be able to recover to a more recent point in time. An alarm should be triggered to prompt the operations and maintenance personnel to investigate the cause of the archive delay, such as network failure, storage performance bottleneck, etc.

[0099] By monitoring and identifying abnormal situations such as missing log segments, illegal timeline forks, or delays exceeding thresholds in real time, corresponding alarms are triggered, such as SMS, email, and monitoring platform alarms. This ensures that abnormal situations are detected and handled in a timely manner, avoiding subsequent recovery failures due to lack of intervention.

[0100] The above-mentioned method determines the start and end sequence numbers by using the current log sequence number and timeline identifier, ensuring that the scan range is precisely bound to the current state of the database master node. This solves the problem of not being able to automatically reset the scan range after a timeline fork, ensuring that only log segments related to the current master node's log chain are scanned, avoiding deviations in the calculation of recoverable intervals due to incorrect scan ranges. By performing continuity analysis using the log segment file naming sequence and sequence number range, missing, delayed, and complete log segments can be automatically identified before recovery, solving the problem of not being able to pre-check log integrity before recovery. This allows users to know whether there are complete logs supporting the target time point before performing recovery, avoiding recovery failure due to missing logs. Furthermore, by parsing the timeline historical files and based on... The system performs validity checks on fork points and associated sequence numbers, automatically identifying legitimate log segments in timeline fork scenarios. This solves the problem of not being able to detect timeline conflicts before recovery, ensuring that the recoverable time interval only includes logs from the current timeline and legitimate predecessor timelines, avoiding recovery failures due to the use of incorrect timeline logs. By integrating continuity status, time mapping, validity results, and archiving delay thresholds to calculate the recoverable interval, a clear and valid time range can be generated before recovery. This solves the problem of not being able to pre-determine the feasibility of the target recovery time point, allowing users to know which time points are safe to recover before performing recovery, avoiding recovery failures caused by blind operations. At the same time, the system dynamically adjusts the termination time to ensure matching with the master node's log synchronization status.

[0101] Example 2 Embodiment 2 of the present invention provides a non-transitory computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiment. The at least one instruction or at least one program is loaded and executed by the processor to implement the method for obtaining the database recoverable time interval provided in the above embodiment.

[0102] Example 3 Embodiment 3 of the present invention provides an electronic device, which includes a processor and the non-transitory computer-readable storage medium of Embodiment 2 of the present invention.

[0103] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for obtaining a database recoverable time interval, characterized in that, The acquisition method includes the following steps: S1. Determine the start and end sequence numbers of this scan based on the current log sequence number and current timeline identifier corresponding to the database master node; S2, Scan the log archive pool according to the start and end sequence numbers, perform continuity analysis according to the file naming sequence and log sequence number range corresponding to the scanned log segment files, obtain continuity status information and sequence number-timestamp mapping relationship, wherein the continuity status information includes the identification results of missing segments, delayed segments and complete segment sequences; S3, parse the timeline history file corresponding to the current timeline identifier, and perform timeline legality verification on the scanned log segment files based on the parsed timeline bifurcation points and associated log sequence numbers, and obtain the legality verification result corresponding to each scanned log segment file, wherein the legality verification result is legal or illegal, and the timeline bifurcation point is the time node when the database master node fails and switches. S4. Based on the continuity status information, the sequence number-timestamp mapping relationship, the legality verification result, and the preset archiving delay threshold, a recoverable time interval is obtained. The start time of the recoverable time interval is determined based on the start timestamp of the earliest complete segment sequence, and the end time is determined based on the end timestamp of the latest legal log segment file.

2. The method for obtaining the database recoverable time interval according to claim 1, characterized in that, The start and end sequence numbers include a start sequence number and an end sequence number. S1 includes the following steps: S11, establish a communication connection with the database master node, call the built-in log sequence number query interface of the database master node to obtain the current log sequence number corresponding to the database master node, wherein the current log sequence number is used to reflect the latest progress of the current data modification of the database master node; S12, call the system status query interface of the database master node, read the system control information of the database master node, and extract the current timeline identifier corresponding to the database master node from the system control information. The current timeline identifier is a unique identifier generated after the database master node fails and switches over, which is used to distinguish log chains under different failure scenarios. S13, use the termination sequence number recorded during the previous log archive pool scan as the starting sequence number of this scan, and use the current log sequence number as the termination sequence number of this scan.

3. The method for obtaining the recoverable time interval of a database according to claim 2, characterized in that, S2 includes the following steps: S21, based on the start and end sequence numbers, locate the storage range of log segment files in the log archive pool, scan all log segment files within the storage range through the file query interface, and obtain the actual file name and storage path of each log segment file; S22, extract the actual file names of the scanned log segment files, parse the log sequence number corresponding to each scanned log segment file according to the naming rules of the database log segment files, and construct the actual file naming sequence and log sequence number range; S23, based on the start and end sequence numbers and the actual file naming sequence, check whether the log sequence number range is seamlessly connected, and obtain the continuity status information based on the check result; S24, call the database log parsing tool to read the header metadata of each scanned log segment file and extract the start and end timestamps corresponding to each log segment file; S25. Establish a sequence number-timestamp mapping relationship based on the log sequence number, start timestamp, and end timestamp corresponding to each scanned log segment file.

4. The method for obtaining the recoverable time interval of a database according to claim 3, characterized in that, S23 includes the following steps: S231, according to the naming rules of the log segment files corresponding to the start and end sequence numbers, generate the expected name sequence corresponding to the log sequence number range, wherein the expected name sequence includes the expected file name corresponding to each scan order; S232, initialize the scan order i=1; S233, the i-th log segment file scanned is identified as the file to be checked corresponding to scan order i; S234, match the expected file name corresponding to the scan order i with the actual file name corresponding to the scanned i-th log segment file, and determine the intermediate type corresponding to the scanned i-th log segment file based on the matching result, wherein the intermediate type is complete or potentially lost. S235, if the scanning order i=N, then obtain the intermediate type corresponding to each scanned log segment file and execute step S236; otherwise, update i=i+1 and repeat step S233, where N is the total number of scanned log segment files. S236, Based on the intermediate type corresponding to each scanned log segment file, determine the continuity check result corresponding to each scanned log segment file, wherein the continuity check result is complete, missing, or delayed; S237, obtain the continuity status information based on the continuity verification result corresponding to each scanned log segment file.

5. The method for obtaining the database recoverable time interval according to claim 4, characterized in that, S236 includes the following steps: For any log segment file scanned, if the intermediate type corresponding to the log segment file is complete, then the continuity check result corresponding to the log segment file is determined to be complete. If the intermediate type corresponding to the log segment file is potentially lost, and the intermediate type corresponding to the last log segment file scanned is complete, then the continuity check result corresponding to the log segment file is determined to be missing. If the intermediate type corresponding to the log segment file is potentially lost, and the intermediate type corresponding to the last log segment file scanned is also potentially lost, then the continuity check result corresponding to the log segment file is determined to be delayed.

6. The method for obtaining the database recoverable time interval according to claim 1, characterized in that, S3 includes the following steps: S31, based on the current timeline identifier, locate the timeline history file corresponding to the current timeline identifier in the log archive pool, wherein the timeline history file is used to record the historical records of the database master node timeline switching, including several timeline forks and corresponding associated log sequence numbers, wherein the associated log sequence number is the log sequence number corresponding to the database master node when the timeline is switched, and is used to determine the effective range of different timeline logs; S32, extract the reference timeline identifier from the header metadata of each scanned log segment file, compare the reference timeline identifier with the current timeline identifier, and obtain the first comparison result corresponding to each scanned log segment file, wherein the first comparison result is either the identifier matches or the identifier does not match; S33, Based on the first comparison result corresponding to each scanned log segment file, determine the target timeline identifier and target log sequence number corresponding to each scanned log segment file; S34, compare the reference timeline identifier corresponding to each scanned log segment file with the corresponding target timeline identifier, and compare the log sequence number corresponding to each scanned log segment file with the corresponding target log sequence number to obtain the second comparison result corresponding to each scanned log segment file; S35, based on the second comparison result corresponding to each scanned log segment file, obtain the legality verification result corresponding to each scanned log segment file.

7. The method for obtaining the database recoverable time interval according to claim 6, characterized in that, S33 includes the following steps: For any log segment file scanned, if the first comparison result corresponding to the log segment file is that the identifier matches, then the latest timeline bifurcation point is determined as the target timeline identifier corresponding to the log segment file, and the associated log sequence number corresponding to the target timeline identifier is determined as the target log sequence number corresponding to the log segment file. If the first comparison result for the log segment file is that the identifiers are inconsistent, then the timeline bifurcation point preceding the latest timeline bifurcation point is determined as the target timeline identifier for the log segment file, and the associated log sequence number corresponding to the target timeline identifier is determined as the target log sequence number for the log segment file.

8. The method for obtaining the recoverable time interval of a database according to claim 1, characterized in that, S4 includes the following steps: S41, based on the continuity status information, select a set of first log segment files marked as complete segments; S42, based on the sequence number-timestamp mapping relationship, determine the starting timestamp corresponding to the log sequence number of the earliest complete segment in the first log segment file set as the starting time of the recoverable time interval; S43, Based on the legality verification results, select a set of legal second log segment files; S44, based on the sequence number-timestamp mapping relationship, determine the end timestamp of the log segment file corresponding to the latest log sequence number in the second log segment file set as the reference time; S45, calculate the time difference between the reference time and the current system time. If the time difference is less than or equal to the preset archiving delay threshold, then the reference time is determined as the end time of the recoverable time interval. If the time difference is greater than the preset archiving delay threshold, then the current system time minus the preset archiving delay threshold is determined as the end time of the recoverable time interval.

9. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the method for obtaining the database recoverable time interval as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images