Real-time disaster recovery backup method for communication database in hybrid deployment environment

Abstract

The application discloses a real-time disaster recovery backup method for a communication database in a mixed deployment environment and particularly relates to the technical field of communication database disaster recovery, which is used to solve the problems of difficult guarantee of session-level consistency of the communication database in the mixed deployment environment and easy omission or repetition of billing records caused by master-backup switching. The application introduces session domain modeling indexed by a session identifier in the mixed deployment environment, combines session idempotent keys, session fingerprints and double-anchor time base record writing processes, and utilizes session consistency fields, session consistency scores and node disaster recovery health degree evaluation to drive the new master node to remove, sequentially rearrange and compensate missing data according to the session idempotent keys in the switching stage, so that session granularity unified sorting and accurate water level locking are realized under the link and clock fluctuation conditions of the local node, the edge node and the cloud node, billing record repetition or omission is avoided, and the continuous consistency of key signaling and billing sessions under failure is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of communication database disaster recovery technology, specifically a method for real-time disaster recovery and backup of communication databases in a hybrid deployment environment. Background Technology

[0002] Current disaster recovery solutions for communication databases mostly employ methods such as master-slave replication, log archiving and replay, or storage layer mirroring. These solutions achieve master-slave switching between a single data center or a few data centers via heartbeat detection and failover scripts. Such solutions typically maintain consistency at the database instance or storage volume level, focusing primarily on table-level data integrity and overall RPO / RTO metrics. They often lack fine-grained modeling of "session-level" behavior in telecommunications services such as voice, SMS, and data sessions. Especially in scenarios with a hybrid deployment of local data centers, edge nodes, and cloud nodes, network latency fluctuations, packet loss, and clock skew coexist among nodes. Existing technologies often rely on single heartbeats or coarse-grained replication progress assessments, making it difficult to accurately depict the actual write order and completion level of different nodes within the same session.

[0003] To mitigate the risk of business interruption, existing systems typically make trade-offs between replication latency and consistency: one approach improves consistency by extending the confirmation window and sacrificing timeliness, but during failover, it can only promote the standby node as a whole based on the latest visible state of the instance or database table, failing to clearly define the "safety level" for each billing session, which can easily lead to overcharging, undercharging, or status rollback for some sessions; another approach, in pursuit of rapid recovery, uses only simple transaction numbers and log positions as criteria to determine whether a standby node can replace the primary node, lacking a unified identifier and comparable summary for cross-node session contexts, making it difficult to trace the evolution trajectory of a specific session across nodes after failover, and also lacking quantitative methods for assessing session consistency and node disaster recovery health.

[0004] In operational environments characterized by hybrid deployments, fluctuating link and clock states, and high consistency requirements for billing and critical signaling, existing technologies struggle to uniformly characterize session write order, replication progress, and consistency status at the session granularity. They also struggle to pinpoint appropriate switchover boundaries and guide the new master node to restore session state during master-slave failover based on verifiable evidence chains. Consequently, the issue of "inability to achieve measurable and traceable session-level consistency control and disaster recovery failover at the session granularity under collaborative deployment of local, edge, and cloud nodes" remains, requiring further improvement. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a real-time disaster recovery backup method for communication databases in a hybrid deployment environment, thereby solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for real-time disaster recovery backup of a communication database in a hybrid deployment environment, comprising: S1. Obtain node and link information in the hybrid deployment environment, establish a session domain, and generate session identifiers, session idempotent keys, and session fingerprints for the sessions; S2. At each node, physical time anchors and session sequence anchors are attached to the session writes to form a dual-anchor time base. The out-of-order window and water level are configured according to the link delay statistics. S3. Collect and write session replication packets by session domain, generate and send them to the backup node, and sort them by dual anchor time base and out-of-order window in the backup node's session buffer queue and mark missing events. S4. Periodically summarize the session fingerprints, water level lines and missing events of each node to form a session consistency field, calculate the node disaster recovery health and session consistency score and generate a consistency evidence chain. S5. When the primary node meets the fault conditions and the disaster recovery health meets the switching conditions, a backup node is selected from the session consistency field, the switching water level is locked for the specified session and a switching token containing the backup node and the switching water level set is generated. After confirmation by the node set that meets the preset confirmation rules, the backup node is promoted to the primary node. S6. On the new master node, the session state is reconstructed in the session buffer queue according to the switching water level. Deduplication and reordering are performed according to the session idempotent key. Missing events are compensated and the session fingerprint and session consistency field are updated.

[0007] Furthermore, S1 includes: The operation and maintenance platform registers the local nodes, edge nodes, and cloud nodes that carry the communication database, assigns node identifiers to each node, and establishes corresponding link information records. The access layer generates a session identifier and classifies the service into the session domain. When the session is created, a session idempotent key and a session fingerprint are generated, and the session identifier, session idempotent key sequence number and session fingerprint value are recorded in the session configuration table. The node reports the session registration status to the disaster recovery control module through the session registration call. The disaster recovery control module generates a parameter version number and writes the parameter version number into the consistency evidence chain.

[0008] Furthermore, S2 includes: Set up a time synchronization component on each node to align the local clock with the reference clock and record the time deviation range; When a database write occurs within the session domain, physical time is collected from the local clock to generate a physical time anchor, and an incrementing session sequence anchor is maintained within the session. The physical time anchor and the session sequence anchor are combined to form a dual-anchor time base, and the dual-anchor time base and session identifier are registered in the session configuration table and local log.

[0009] Furthermore, in the disaster recovery control module, observation window parameters and out-of-order window parameters are set, and high quantile values ​​and average values ​​are calculated based on the link round-trip delay samples within the observation window; The upper limit of the disordered window is determined based on the high quantile value, and the water level advancement rhythm is determined based on the average value. The parameter record is composed of the out-of-order window limit, water level advancement rhythm, link identifier, and session priority. The parameter record has a parameter version number and is distributed to each node by the configuration management system. Each node references the current parameter version number during dual-anchor time base sorting and water level advancement, and the disaster recovery control module writes the current parameter version number into the consistency evidence chain.

[0010] Furthermore, S3 includes: The master node sets up a session domain management module, and writes records in the observation window according to the session identifier to generate a session replication package carrying the session identifier, dual anchor time base range information, session idempotent key set and session fingerprint increment; The backup node establishes a session buffer queue for each session identifier, sorts the session replication packets according to the session sequence anchor and physical time anchor based on the out-of-order window, marks the continuous interval of the session idempotent key as a candidate set, marks the session idempotent key corresponding to the gap as a missing event, and writes the session status into the consistency evidence chain entry by the disaster recovery control module when periodically reporting the session status.

[0011] Furthermore, S4 includes: The disaster recovery control module receives session fingerprints, water level positions, and missing event counts reported by each node at a fixed rhythm. Establish a session consistency field based on session identifier and node identifier; For each session, the water level lag is obtained based on the difference in the water level positions of each node in the session consistency field. The session consistency score is calculated according to the preset scoring rules based on the session fingerprint consistency of each node. Sessions with session consistency scores lower than the preset consistency security threshold are marked as consistency abnormal sessions.

[0012] Furthermore, the disaster recovery control module calculates the disaster recovery health of nodes for the high-priority session set in the session consistency field based on the water level lag, missing event ratio, and historical reconstruction performance indicators of each node in that set. If no node session status update is received within a preset number of consecutive aggregation periods, the node will be marked as an incomplete node and deducted from the node's disaster recovery health. At the end of each aggregation period, the session consistency field section, node disaster recovery health, session consistency score, and the currently used parameter version number are written into the consistency evidence chain entry.

[0013] Furthermore, S5 includes: The monitoring module reads the master node status and node disaster recovery health from the consistent evidence chain, and initiates the switchover process after determining that the master node meets the failure conditions. The disaster recovery control module selects backup nodes based on the node's disaster recovery health in the session consistency field, determines the switching water level according to the specified session, and generates a switching token containing the backup node identifier and the switching water level set. The switching token is issued to the node set and the confirmation results from each node are received based on the water level and session fingerprint. When the confirmation rules are met, the backup node is set as the new master node through the configuration management system, and the original master node is set to an unwritable state.

[0014] Furthermore, S6 includes: After being set as the master node, the new master node will allocate session replication packets that are not higher than the switching watermark in the session buffer queue to the frozen segment based on the switching token, and will use the session idempotent keys in the frozen segment as the final confirmation range and merge them with the local records. For session replication packets that are above the switching water level, deduplication is performed using the session idempotency key and rearranged according to the dual-anchor time base order. For events marked as missing, replication packets are queried from other backup nodes for compensation. After compensation, the session fingerprint and watermark are updated and written into the session consistency field and consistency evidence chain. Sessions corresponding to uncompensated missing events are added to the scope of manual verification and their state changes are restricted.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By introducing session domain modeling indexed by session identifiers in a hybrid deployment environment, and generating session idempotent keys, session fingerprints, and dual-anchor time bases composed of physical time anchors and session sequence anchors simultaneously with each write, and combined with quantitative evaluation mechanisms for session consistency fields, session consistency scores, and node disaster recovery health, the switchover phase utilizes switchover water level sets and switchover tokens to drive the new master node to perform deduplication, reordering, and missing compensation according to the session idempotent key. This achieves unified sorting, precise water level locking, and traceable master-slave switchover at the session granularity even when local nodes, edge nodes, and cloud nodes are deployed in a hybrid manner and link quality and clock status fluctuate. This avoids duplicate or missing billing records and ensures the continuity and consistency of critical signaling and billing sessions in fault scenarios.

[0016] 2. By continuously probing the link latency, jitter, and packet loss between nodes on the operations and maintenance side and configuring the out-of-order window upper limit and water level advancement rhythm accordingly, a structured intermediate view is formed on the backup node side using session buffer queues, candidate sets, and missing event markers. All process information such as link anomalies, missing events, retransmission failures, and reconstruction results are written into the consistency evidence chain. This achieves the goal of automatically absorbing the impact of network jitter and node time deviation on the replication order without relying on a specific database or middleware. It also enables timely identification and demotion of abnormal links or nodes with incomplete states, reducing the frequency of manual intervention and improving the robustness, observability, and large-scale engineering feasibility of real-time disaster recovery backup of the communication database in a hybrid deployment environment. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the real-time disaster recovery and backup method for communication databases in a hybrid deployment environment according to the present invention. Detailed Implementation

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

[0019] Example: Figure 1 A flowchart illustrating the real-time disaster recovery backup method for communication databases in a hybrid deployment environment is provided. The method includes: S1. Obtain node and link information in the hybrid deployment environment, establish a session domain, and generate session identifiers, session idempotent keys, and session fingerprints for the sessions. The specific implementation is as follows: In a hybrid deployment environment, the first step is to uniformly register all types of nodes participating in the communication database operation through the operations and maintenance platform. A node refers to a computing unit that carries a communication database instance. Based on their deployment location and responsibilities, nodes can be categorized as local nodes, edge nodes, and cloud nodes. Each node is assigned a unique node identifier during registration. Preferably, the node identifier uses a non-repeating, fixed-length code to reliably distinguish different nodes across the entire network. The operations and maintenance platform also needs to establish link information records between any two nodes. Link information refers to a set of measurements describing the network connectivity quality between nodes, including at least three metrics: round-trip time, jitter, and packet loss rate.

[0020] To obtain reliable link information, the system can be configured to perform probes at a fixed rhythm of several to tens of seconds. The rhythm refers to the time interval that remains constant between two adjacent measurements, preferably between five and twenty seconds. The operation and maintenance platform or a designated probe agent sends probe messages to the target node and records the time difference from sending to receiving when a response message is received. This time difference is regarded as a round-trip delay measurement. A series of consecutive measurements constitute an observation window, which is a time period containing several measurement results. Within this time period, the average, maximum, and high-quantile values ​​of the round-trip delay are calculated to characterize the link latency level. The high-quantile value is preferably the delay value at the 95th percentile. For jitter, it can be set to the maximum value minus the minimum value of the round-trip delay within the same observation window. For packet loss ratio, it can be set to the difference between the number of probe message transmissions and the number of successfully received response messages divided by the number of transmissions.

[0021] In real-world scenarios, to avoid interference from occasional network fluctuations on link information, it is preferable to determine that a link is abnormal if three or five consecutive measurements fail. The corresponding measurement results are then removed from the statistics, and the abnormal time period of the link is recorded on the operation and maintenance platform. Subsequent steps can omit the data from this time period when calculating the out-of-order window and water level, thereby ensuring that the link information is consistent with the actual transmission capacity under stable operating conditions.

[0022] After completing the registration of node and link information, the access layer uniformly manages voice services, short message services, and Internet session services entering the system using a session-based approach. Whenever a terminal or upstream system initiates a new communication service, the access layer generates a unique session identifier based on factors such as service type, call number, service entry node, and current time. The session identifier preferably uses a fixed-length encoding structure to facilitate direct comparison between different nodes. The system groups all service operations with the same session identifier into the same session domain. A session domain refers to a set of service contexts and database operations indexed by the session identifier, used for replication and reconstruction at the session level in a hybrid deployment environment.

[0023] When a session is created, the system initializes a session idempotent key sequence and a session fingerprint record for that session domain. The session idempotent key is used to identify each database write operation within the session domain and can be set to a combination of a session identifier, a business step number, and an internally incrementing sequence number. The internally incrementing sequence number is set to an initial value of one when the session is created, and is incremented by one for each write operation, thereby ensuring that the session idempotent key corresponding to different write operations within the same session domain is not duplicated. The session fingerprint is used to describe the amount of confirmed write results in the session domain at a certain moment. Preferably, it can be set as a triple consisting of the number of records, the cumulative amount, and a hash part. The number of records represents the number of confirmed write records in the current session domain, the cumulative amount represents the cumulative value of billing-related fields, and the hash part is used to comprehensively reflect changes in key fields.

[0024] When a session is created, the number of records in the session fingerprint is set to zero, the cumulative amount is set to zero, and the hash part is set to zero. After each database write is completed, the system increments the number of records by one. If the current write includes an amount field, the amount field is converted to an integer in a preset unit and added to the cumulative amount. At the same time, key fields in the current write record, such as the primary key value, status code, and integer part of the amount, are extracted. These key fields are concatenated into a string in a predetermined order, converted into an integer value through a fixed encoding rule, and then normalized within a preset upper limit. Preferably, the integer is modulo a certain upper limit to obtain a bounded integer. This integer is then added to the current hash part. When the added result exceeds the upper limit, the upper limit is subtracted, so that the hash part always falls between zero and the upper limit. Thus, without exposing specific business fields, the comparability of the session fingerprint is maintained with a fixed operation order.

[0025] Those skilled in the art can directly write programs based on this to update the session fingerprint after each write operation, and ensure that when the same key field selection rules, encoding rules, and upper limit parameters are used on different nodes, repeatedly executing the same write sequence on the same session domain will yield consistent session fingerprint results. To support disaster recovery control based on session domains in subsequent steps, each node maintains a local session configuration table. The session configuration table records fields such as the session identifier that has appeared on the node, the current sequence number of the corresponding session idempotent key, the current value of the session fingerprint, and the node identifier to which the session domain belongs in this node. When a session is created or first arrives at a node, the system writes the correspondence between the session identifier and the node identifier into the session configuration table, and updates the session idempotent key sequence number and session fingerprint value after each subsequent write operation.

[0026] To ensure that the session configuration status on the node side is consistent with the global view of the operation and maintenance platform, the system sets up a type of call for managing session registration status. Session registration call refers to the status notification behavior initiated by the node to the disaster recovery control module. When a node finds that a certain session identifier has not been registered in the session configuration table, or finds that its own node identifier is inconsistent with the record of the operation and maintenance platform, or finds that the frequency of its own session status reporting behavior exceeds the preset threshold, it can report the above situation together with its own node identifier and the current time to the disaster recovery control module through session registration call. The reporting frequency is preferably limited to no more than a certain number of times per second, for example, it can be set to less than ten times per second to avoid excessive occupation of the control channel.

[0027] The disaster recovery control module is a control unit responsible for comprehensively maintaining node status, link status, and session consistency information in a hybrid deployment environment. It can run on a standalone server or be integrated with an operations and maintenance platform. Upon receiving a session registration call, the disaster recovery control module returns different processing results based on the call content, such as session not registered, invalid node identity, or reporting frequency exceeding limits. Internally, it assigns or updates parameter version numbers for the current configuration and rules, and writes the parameter version number, along with the current processing result, relevant node identifiers, and session identifiers, into a consistency evidence chain. The consistency evidence chain is a logical chain that records various events, parameter versions, and operation results related to session consistency in chronological order. It is preferably written to persistent storage in an append-only manner for easy subsequent querying and tracing.

[0028] Through the above steps, without limiting specific database brands and network device models, a unified session granularity and key-value system covering local nodes, edge nodes, and cloud nodes is formed. This lays the foundation for using session domains, session idempotent keys, and session fingerprints as unified references in subsequent steps such as replication, reconstruction, and switching. Preferably, in large-scale operational networks, the link detection rhythm can be set to ten seconds, the number of consecutive link failures can be set to three, and the high quantile value can be determined as the 95th percentile of the round-trip latency. Under a set of representative operating conditions, the average round-trip latency between the local data center, edge nodes, and cloud nodes can be set to twenty milliseconds, the high quantile value can be around fifty milliseconds, the jitter amplitude can be within ten milliseconds, and the packet loss ratio can be less than one in a thousand. Under these conditions, through the above session domain creation and session configuration table initialization, it has been tested that it can support the creation and maintenance of tens of thousands of sessions per second. Each node maintains consistency in the session identifier, session idempotent key, and session fingerprint for the same session, enabling those skilled in the art to directly reproduce the above registration method and session organization method, and further implement real-time disaster recovery backup functions for hybrid deployment environments.

[0029] S2. At each node, physical time anchors and session sequence anchors are used to form a dual-anchor time base for session writes. Out-of-order windows and watermarks are configured based on link latency statistics. The specific implementation is as follows: On each node side, to ensure the time signature of session writes is comparable across the entire network, the physical time of the local node is first aligned with a unified reference clock using a time synchronization component. The time synchronization component is a software or hardware module deployed on the node. It periodically sends time query messages to the reference clock service and receives responses containing the standard time. In each interaction, it records the difference between the local time and the reference time, treating this difference as the node's current time offset. Over several consecutive periods, it calculates the maximum, minimum, and average values ​​of the offset to obtain the node's time deviation range. The reference clock refers to a time source providing a unified standard time across the operational network. It can be configured as a clock service cluster deployed in the core data center or as a time service system jointly maintained by multiple data centers. The local clock refers to the time counting mechanism provided by the node's operating system, used to provide timestamps for database writes and log recordings. The time synchronization component is preferably aligned with the reference clock at a rhythm of tens of seconds to several minutes. At the end of each rhythm cycle, it updates the locally recorded time deviation range. When the current offset is found to exceed the preset allowable deviation boundary, it can be set to immediately trigger an additional time synchronization operation to reduce time drift between nodes.

[0030] Based on time synchronization and deviation range recording, whenever a database write operation occurs within the session domain, the node collects the current physical time from the local clock before committing the local transaction. This time value, after the aforementioned deviation compensation, is used as the physical time anchor for this write operation. Simultaneously, a session sequence anchor is maintained within the session domain. The session sequence anchor is a monotonically increasing integer maintained for a single session, initialized to one when the session is created, and incremented by one after each write operation. The system combines the currently written physical time anchor with the updated session sequence anchor to form a dual-anchor time base for this write operation. This dual-anchor time base is used to simultaneously reflect the write's position in global time and its order within the current session during subsequent replication, sorting, and watermark control.

[0031] To reduce the impact of time drift on sequence determination, it is preferable to collect the local clock data before and after each write operation and compare it with the estimated value of the reference clock. If the deviations between the physical time collected in both instances and the estimated value of the reference clock fall within the time deviation range, the write operation is considered a reliable clock write. If either deviation exceeds a preset limit, the write operation can be marked as pending verification. This pending verification mark indicates that a more conservative strategy needs to be adopted in subsequent sorting and water level advancement, such as temporarily refraining from using it as a candidate upper bound for the water level line, or marking it separately in the session consistency field, thereby avoiding incorrect sequence decisions due to local time anomalies. Regarding the aforementioned dual-anchor time base, in order to uniformly constrain the out-of-order tolerance and water level advancement speed across the entire network, the disaster recovery control module needs to statistically analyze the round-trip delay distribution of each link within different observation windows.

[0032] The observation window refers to the time interval within which link round-trip delay measurements are collected over a certain period of time. Preferably, it can be set as a combination of long and short windows to take into account both stable characteristics and instantaneous fluctuations. The long window is used to reflect the typical delay level over a longer time scale, and the short window is used to reflect the instantaneous delay level near the current moment. The round-trip delay measurement can follow the aforementioned link detection mechanism, collecting multiple round-trip delay samples within each observation window. After arranging them in ascending order, the high quantile value and the average value are determined. The high quantile value is preferably the sample value at the 95th percentile position.

[0033] The disaster recovery control module determines the upper limit of the out-of-order window based on the high quantile value in the long window. The out-of-order window refers to the time range or sequence range within which slight out-of-order events are allowed during transmission and writing of the dual-anchor time base, used to absorb network jitter without sacrificing sequential consistency. For example, it can be set to multiply the high quantile delay of the long window by a preset safety factor to obtain a time upper limit. Within the dual-anchor range corresponding to this time upper limit, the backup node buffer allows a certain degree of overlap between write events; late events exceeding this upper limit are no longer included in the normal out-of-order window, but are instead transferred to the compensation path according to rules.

[0034] The average round-trip delay within the short window is used to determine the waterline advancement rhythm. The waterline describes the dual-anchor time base position of a replication link or session that has been safely confirmed on each node. The waterline advancement rhythm refers to the step size by which the system can advance the waterline each time without affecting consistency. It can be set as the sum of the average short window delay and the reserved redundancy time. By controlling the waterline advancement rhythm, the waterline is always kept within the time range where most replication events have been reliably arrived. The disaster recovery control module organizes the out-of-order window parameters and waterline advancement parameters calculated for each pair of nodes and different session priorities into a parameter record. The parameter record includes the link identifier, session priority, out-of-order window upper limit, waterline advancement rhythm, and effective timestamp, and is assigned a unique parameter version number.

[0035] The parameter version number is used to identify the specific configuration adopted by the current disaster recovery strategy. When the operation and maintenance personnel or the adaptive adjustment logic updates the out-of-order window or water level advancement strategy, the parameter version change registration call registers the new parameter record in the configuration management system. The configuration management system is a management service used to centrally store and distribute configuration parameters to each node. It can be deployed as a centralized configuration library or redundantly in a multi-machine room.

[0036] After the parameter version change registration is completed, the configuration management system distributes the latest version of the out-of-order window and waterline parameters to the corresponding nodes according to the link identifier. The nodes cache these parameters and their version numbers locally. When each node writes the dual-anchor time base flag to the session and applies the out-of-order window constraint in the buffer queue, it references the currently valid version number in the local cache and records this version number, along with the session identifier and dual-anchor time base, in the local log and session configuration table for subsequent traceability.

[0037] When a node periodically reports its session status to the disaster recovery control module, the session status report message also carries the currently used parameter version number. After receiving the report, the disaster recovery control module writes the session status information and parameter version number together into the consistency evidence chain and compares whether the versions used by each node are consistent. When it is found that the version number used by a certain node is behind the latest version recorded in the configuration management system, it can be set to issue a configuration update reminder to the node or temporarily reduce the weight of the node in the consistency judgment.

[0038] Through this complete mechanism of time synchronization, dual-anchor time base marking, and distribution of out-of-order windows and waterline parameters, time and order constraints are kept consistent across nodes in a hybrid deployment environment. This ensures that even with network jitter, link latency variations, and individual node clock skew, session writes can still be ordered and waterline advanced according to unified rules. Preferably, in an operational network consisting of local nodes, edge nodes, and cloud nodes, the rhythm of the time synchronization component aligning with the reference clock can be set to 30 seconds, the allowable time deviation range to ±5 milliseconds, the long window length to 5 minutes, the short window length to 30 seconds, and the average round-trip latency sample collected within the long window can be set to 20 milliseconds, with the 95th percentile sample set to 50 milliseconds. In this case, the disaster recovery control module can set the out-of-order window upper limit to 80 milliseconds and the waterline advancement rhythm to 40 milliseconds. Under these conditions, even if short-term link jitter occurs, most replication events... The components can still be rearranged within the out-of-order window, and the water level is always kept within the range where most events have already arrived. Writes with a time deviation exceeding five milliseconds are marked as pending verification. When calculating the session consistency score and advancing the water level in the future, writes with normal clocks can be given priority. This improves the tolerance for network and clock anomalies while ensuring sequential consistency. Those skilled in the art can directly implement the node-side time synchronization logic, the dual-anchor time base generation process, and the statistical and distribution process of out-of-order window and water level parameters based on this, reproduce the same sorting behavior and water level advancement behavior, and obtain the same technical effect as in this embodiment.

[0039] S3. Collect and write session replication packets by session domain, generating packets carrying dual-anchor time bases and session idempotent keys, and send them to the standby node. In the standby node's session buffer queue, sort the packets by dual-anchor time bases and out-of-order window, and mark missing events. Specifically, the implementation is as follows: On the master node side, to ensure stable replication at the session level in a hybrid deployment environment, a dedicated session domain management module is preferred. This module is a logical unit deployed on the master node, used to aggregate database write records by session identifier and organize them into session replication packages within a defined observation window. The defined observation window is a sliding time period based on time, during which multiple write records belonging to the same session domain are collected. The length of the observation window can be set from several milliseconds to several hundred milliseconds, accumulating sufficient write events while ensuring real-time performance.

[0040] Within each observation window, the session domain management module collects and sorts the write records under the same session identifier according to the aforementioned dual-anchor time base. The write events are arranged from early to late with the session sequence anchor as the primary order and the physical time anchor as the secondary order. Then, several writes that are within the range of adjacent dual-anchor time bases, have consecutive session sequence anchors, and have consecutive session idempotent keys are merged and packaged into a session replication package.

[0041] A session replication packet is a transmission unit used to transfer session write content between nodes. It preferably includes a session identifier, the start and end positions of the dual-anchor time base covered by this encapsulation, the set of session idempotent keys included in the write, and the session fingerprint increment calculated based on these writes. The session fingerprint increment can be set as the number of new records added in this encapsulation, the cumulative amount increment, and the hash part increment, which is used to quickly update the local session fingerprint on the backup node side.

[0042] After generating the session replication packet, the master node selects an appropriate replication channel based on the session priority and link quality and sends it to the corresponding backup node. The replication channel refers to the network transmission path specifically configured between the master node and the backup node for session replication. It can correspond to different links and queues. The link quality can be graded based on the aforementioned round-trip delay, high quantile value and packet loss ratio. When the session priority is high or the link quality is poor, a replication channel with higher redundancy and more bandwidth can be selected to reduce the risk of critical session replication failure.

[0043] On the standby node side, a session buffer queue is established for each session identifier. This session buffer queue is an ordered list in memory used to temporarily store session replication packets that have not yet been fully confirmed, along with their write records. Whenever the standby node receives a session replication packet from the master node, it first places the packet into the corresponding session buffer queue based on the session identifier. Then, based on the currently active out-of-order window of the link and the dual-anchor time base carried in the replication packet, the replication packets in the buffer queue are rearranged. The rearrangement process preferably prioritizes the continuity of the session idempotent key sequence number and the order of the session sequence anchors. Within the same session buffer queue, replication packets are arranged in ascending order of session sequence anchors. For writes with the same session sequence anchor, the physical time anchors are compared to determine a finer order, thus obtaining a queue view that is as close as possible to the actual write order within the out-of-order window.

[0044] For a consecutive range of session idempotent keys in the buffer queue, the standby node marks this range as an enterable candidate set. The candidate set refers to the set of writes that already satisfy the order constraints and no longer depend on future late events. These writes can be used as the basis for waterline advancement and session state reconstruction in subsequent steps. For gaps in the session idempotent key sequence—that is, when checking by ascending sequence number and finding that a corresponding replication packet or write record has not yet been received at a certain expected sequence number, and this gap remains unfilled within the time allowed by the out-of-order window—the standby node marks the corresponding session idempotent key as a missing event. A missing event refers to a write that should exist in the session but has not yet been received at the current time. While recording missing events, the standby node restricts the advancement of the corresponding session's waterline. The upper bound of the waterline for that session does not exceed the last consecutive session idempotent key before the missing event, to avoid incorrectly assuming that the session has been fully replicated during global consistency checks.

[0045] If a session replication packet in the buffer queue fails to be transmitted through the master node or replication channel within a preset time, the system can be set to retransmit within a limited number of times. The retransmission interval can be associated with the link round-trip time and out-of-order window parameters. When multiple retransmissions of the same session replication packet occur within an observation window and still fail, the backup node or master node will generate a link quality degradation record locally, send the record to the disaster recovery control module through the session status reporting call, and record the replication failure of the node and the link in the consistency evidence chain within the corresponding time period.

[0046] The role of the session state reporting call in this step is for the backup node to send the current session buffer queue status to the disaster recovery control module at a fixed rhythm. This includes the maximum double-anchor position in the current candidate set for each session, the cumulative count of missing events, and the current value of the local session fingerprint. The maximum double-anchor position can be defined as the upper bound of the double-anchor time base in the candidate set of the session, that is, the writes where neither the session sequence anchor nor the physical time anchor exceeds this value have been sequentially ready on this node. This position provides a quantitative basis for subsequent construction of the session consistency field and calculation of the waterline.

[0047] After receiving these reported information, the disaster recovery control module writes the node identifier, session identifier, maximum dual anchor position, missing event count, local session fingerprint, and the version number of the currently used out-of-order window and water level parameters into the consistency evidence chain entry, which serves as the basis for subsequent calculation of node disaster recovery health and session consistency score.

[0048] Through the series of actions described above, including session replication packet generation, replication channel selection, buffer queue rearrangement, candidate set marking, missing event recording, and session status reporting, the write behavior on the master node side and the queue status on the backup node side form a clearly structured intermediate layer view in the hybrid deployment environment. This supports subsequent fine-grained water level control and disaster recovery switching judgment in the session consistency field. Preferably, in a typical deployment consisting of local nodes, edge nodes, and cloud nodes, the observation window length for generating session replication packets can be set to approximately 50 milliseconds. During this period, an average of several write records for a single high-priority session can be collected. These records are then used to generate one or more session replication packets in dual-anchor time base order. For links with an average round-trip latency of approximately 20 milliseconds and a high quantile of approximately 50 milliseconds, the upper limit of the out-of-order window can be set to 80 milliseconds, the upper limit of the number of retransmissions for that link can be set to three, and the waiting time for a single retransmission can be set to the sum of the average round-trip latency of the long window and a certain amount of redundancy. Under this configuration, when the master node writes multiple records for a session in a short period of time, the session domain management module can form a stable replication packet sequence within an observation window. The backup node's session buffer queue sorts the packets within the out-of-order window and identifies continuous session idempotent key intervals. The corresponding dual-anchor positions are marked as candidate sets and reported to the disaster recovery control module. In the event of a short-term drop in the quality of a few links leading to retransmission failures, a corresponding link quality drop record will be formed in the consistency evidence chain, providing a basis for subsequently including the link in the de-weighting or adjusting the out-of-order window.

[0049] Those skilled in the art can implement the master node session domain management module, session replication package encapsulation logic, backup node session buffer queue management, candidate set and missing event marking rules, and session status reporting and evidence chain recording process in a specific system based on the above definitions and order. This allows them to reproduce the replication and sorting behaviors described in this embodiment without relying on a specific database brand and middleware implementation, and achieve the same technical effects as this method.

[0050] S4. Periodically summarize the session fingerprints, watermarks, and missing events of each node to form a session consistency field, calculate the node disaster recovery health and session consistency score, and generate a consistency evidence chain. The specific implementation is as follows: On the disaster recovery control module side, in order to form a global view that can be used for switching decisions in a hybrid deployment environment, the system can be configured to collect session state information from each node under a fixed rhythm and perform centralized aggregation. A fixed rhythm refers to a periodic action triggered at a uniform time interval, which is preferably on the order of several seconds, so that state changes can be detected in a timely manner without putting too much pressure on the control channel.

[0051] Each node, in accordance with the aforementioned convention for reporting session status, reports to the disaster recovery control module the session fingerprint, watermark position, and missing event count currently maintained by the node within each rhythmic cycle. The session fingerprint represents the amount of digest that the node has confirmed writing in a certain session domain. The watermark position represents the maximum dual-anchor time base position that the node can consider to be replicated and with stable order in the session. The missing event count represents the number of session idempotent keys that have been marked as missing events in the session.

[0052] After receiving reports from different nodes, the disaster recovery control module categorizes the information based on session identifiers and node identifiers. It organizes the session fingerprints, watermark positions, and missing event counts from each node under the same session identifier into a multi-dimensional state view. This view is indexed according to combinations of session identifiers and node identifiers, with each combination corresponding to a set of current state values. This view is the session consistency field. The session consistency field is used to centrally reflect the progress and consistency of different nodes across various sessions at the current aggregation time. Those skilled in the art will understand that the session consistency field does not necessarily need to adopt a specific storage format; as long as it supports querying the watermark and fingerprint status of a session across all nodes by session identifier, and querying the overall performance of a node across various sessions by node identifier, it meets the requirements of this method.

[0053] After constructing the session consistency field, the disaster recovery control module performs a consistency assessment on each session within each aggregation period. The session consistency assessment results in a session consistency score, which is a quantitative score reflecting whether the state of the session is consistent across different nodes. During the scoring process, the disaster recovery control module first extracts the water level positions and session fingerprints corresponding to each node for a given session identifier from the session consistency field. It then calculates the difference between the maximum and minimum values ​​of the water level, considering this difference as the water level lag between different nodes. Next, it compares the session fingerprints between nodes. If all nodes have identical session fingerprints and the water level lag is below a preset water level difference threshold, the session is considered to have reached a high consistency state within this period, and the session consistency score can be set to a high value. If some nodes have different session fingerprints, or the water level lag exceeds the water level difference threshold, the consistency score of the session is reduced according to the degree of deviation. For example, the scoring rules can be set to deduct a portion of the score when the water level lag exceeds a certain level, and deduct another portion of the score when the session fingerprints differ, until it falls below a preset consistency security threshold, at which point the session is marked as an abnormal consistency session. The scoring rules can be pre-configured and version-managed via parameter version numbers, allowing adjustments to be made based on the latency and consistency tolerance of different deployment environments.

[0054] After completing the consistency score for a single session, the disaster recovery control module also needs to provide a comprehensive assessment from the node's perspective to form the node's disaster recovery health. Node disaster recovery health is a quantitative indicator reflecting the disaster recovery capability of a node at the current stage. During calculation, the system prioritizes high-priority sessions because these sessions typically carry services such as voice, billing, or critical signaling. The disaster recovery control module can select all high-priority sessions in the session consistency field and calculate the node's water level lag and missing event ratio for these sessions. The water level lag can be set as the average or maximum difference between the node's water level position and the maximum water level position among all nodes. The missing event ratio can be set as the number of high-priority sessions with missing events divided by the total number of high-priority sessions. To reflect the stability of a node during historical reconstruction processes, past reconstruction performance can be considered. For example, the number of times the node participated in session reconstruction tasks, the reconstruction success rate, and the time required for session fingerprints to become consistent after reconstruction can be statistically analyzed over several past aggregation periods. These historical performance metrics are weighted and converted into a deduction or addition factor, which, along with the current period's water level lag and missing event ratio, forms the node's disaster recovery health score. Preferably, the node's disaster recovery health score is expressed as a score; a higher score indicates that the node's replication progress in high-priority sessions is closer to that of other nodes, it has fewer missing events, and its reconstruction performance is more stable.

[0055] At the end of each aggregation cycle, the disaster recovery control module combines a snapshot of the current session consistency field, the node disaster recovery health of all nodes, the consistency score of all sessions, and the version numbers of the out-of-order window parameters and waterline advancement parameters used in this cycle into a consistency evidence chain entry. The consistency evidence chain is a chronologically linked record structure used to store the global consistency state and related parameter configurations for each aggregation cycle, facilitating the tracing of objective evidence in case of subsequent master-slave switchover, session reconstruction, or disputes. The consistency evidence chain entry preferably records the aggregation time, the set of participating nodes, the parameter version numbers used by each node in this cycle, a list of sessions with consistency anomalies, and information on sessions marked as having severe missing events, ensuring that each state assessment has a clear temporal and parameter context.

[0056] During the aggregation process, the disaster recovery control module also monitors whether the reporting behavior of each node conforms to the expected rhythm. If it is found that the session status reporting information of a certain node does not arrive at a fixed rhythm in one or more consecutive aggregation operations, or if the session information of the node is not updated in multiple observation windows (i.e., the water level position and session fingerprint in the reported content remain unchanged for a long time), it can be inferred that the node is in an incomplete state or potentially disconnected. In such cases, when generating a consistency evidence chain entry, the disaster recovery control module marks the node as an incomplete state node and deducts accordingly from the node's disaster recovery health. At the same time, it provides constraints for subsequent switchover decisions, ensuring that incomplete state nodes are not prioritized as switchover targets when selecting target nodes in the session consistency field. This avoids mistakenly selecting a node as a new master node when its information is unreliable or its reporting is untimely, thus reducing the switchover risk. Preferably, in a typical operational scenario, the disaster recovery control module can set the aggregation rhythm to five seconds, the water level difference threshold to three hundred milliseconds, and the node status incomplete judgment condition to be set to not receiving a session status update from a certain node for three consecutive aggregation cycles or the water level position of all sessions of that node has not changed. Under this setting, the system can detect nodes that report anomalies within tens of seconds and form a clear mark in the consistency evidence chain.

[0057] For example, in a series of experiments involving local data centers, edge nodes, and cloud nodes, when the edge node experienced a session status reporting delay exceeding three cycles due to local network fluctuations, the disaster recovery control module observed in the session consistency field that the edge node's waterline position lagged behind other nodes by more than 300 milliseconds across multiple sessions. Furthermore, the count of missing events increased within multiple observation windows, resulting in a significant drop in the corresponding session consistency score and a decrease in the node's disaster recovery health below the preset safety threshold. Simultaneously, the edge node was marked as an incomplete state node in the consistency evidence chain. Subsequently, when the master node failed and required switching, the switching decision logic, based on the health and status markings provided by the consistency evidence chain, no longer prioritized the edge node, but instead selected a cloud node with higher health as the switching candidate. This comprehensive quantitative evaluation and auditing mechanism, based on session consistency field, consistency score, and node disaster recovery health, ensures that subsequent switching decisions no longer rely on a single heartbeat or simple delay judgment, but are based on complete evidence. This guarantees that the goal of "ensuring session-level consistency and disaster recovery reliability in a hybrid deployment environment" proposed in the technical issue can be reproduced by those skilled in the art and achieved in engineering practice.

[0058] S5. When the primary node meets the fault conditions and the disaster recovery health meets the switching conditions, a backup node is selected from the session consistency field. A switching watermark is locked for a specified session, and a switching token containing the backup node and the switching watermark set is generated. After confirmation by a set of nodes that meet the preset confirmation rules, the backup node is promoted to the primary node. The specific implementation is as follows: During long-term system operation, the monitoring module continuously reads the master node's running status and disaster recovery health from the consistency evidence chain for each period. When it detects that the master node cannot provide write services, critical processes exit abnormally, underlying storage reports continuous errors, or heartbeat detection exceeds the allowed time limit in several recent summary periods, and the master node's disaster recovery health recorded in the consistency evidence chain has fallen below a preset threshold, the master node is deemed to meet the failure conditions, and a switchover process is triggered. The failure conditions refer to a set of rules used to determine that the master node is no longer suitable as the current write entry point. These conditions can include hardware failure, software anomalies, severe performance degradation, and prolonged incomplete state. The preset threshold is a safety lower limit set for the node's disaster recovery health, preferably determined by combining the water level lag of high-priority sessions and the proportion of missing events.

[0059] Once the triggering conditions are met, the disaster recovery control module sorts the backup nodes in the current session consistency field according to their node disaster recovery health in high-priority sessions. It selects several backup nodes with low water level lag, low missing event ratios, and stable historical reconstruction performance in high-priority sessions as a candidate node set. Candidate nodes are backup nodes qualified to take over the responsibilities of the primary node in this switchover. Each candidate node needs to reach a water level close to that of other nodes and maintain a high consistency score in a majority of high-priority sessions. After determining the candidate nodes, the disaster recovery control module needs to determine the switchover water level for the specified sessions involved in this switchover. The specified sessions can be determined by policy configuration and typically cover critical business sessions such as voice billing and SMS billing. The switchover water level refers to the upper limit of the dual-anchor time base position that the system allows the new primary node to reconstruct the state of a session during primary-backup switchover. This position must be a high-water level position where a majority of nodes have reliably covered the system.

[0060] To address this, the disaster recovery control module, within the session consistency field, reads the water level positions of candidate nodes and other backup nodes with good disaster recovery health for each specified session. It calculates the smaller value among these water level positions and checks if this smaller value is still not lower than a preset minimum safe water level threshold. Simultaneously, it checks if the session fingerprint corresponding to this water level is consistent across multiple nodes. When the smaller value satisfies the condition of being covered by a majority of nodes and having consistent session fingerprints, this value is used as the candidate switchover water level for that session. Here, "majority of nodes" can be set to more than half of the nodes participating in the evaluation. For example, when three nodes participate in the evaluation, at least two nodes need to complete replication and achieve fingerprint consistency before reaching this water level position. If a session cannot find a water level position that meets the conditions at the current moment, it can be temporarily excluded from the set of specified sessions for this switchover, or its priority can be reduced to avoid excessively high overall switchover risk due to lagging replication in individual sessions.

[0061] After selecting the switchover water level for all specified sessions, the disaster recovery control module encapsulates the candidate backup node identifier, the switchover water level set corresponding to each specified session, and the currently used out-of-order window and water level parameter version number into a switchover token. The switchover token is a unified instruction carrier for a switchover operation, used to reach consensus within the node set. The node set refers to a group of members participating in the confirmation and execution of this switchover, typically including all nodes with disaster recovery capabilities. The switchover token is distributed to the node set through a control channel. This control channel can be configured as a reliable message channel independent of the business data channel, such as a notification mechanism based on an internal message queue or configuration management system.

[0062] Upon receiving the switching token, each node performs local verification according to preset confirmation rules. The confirmation rules include two core aspects: First, it searches for records in the local consistency evidence chain that match the switching water level of each session in the switching token, and verifies whether the water level of the node in the corresponding session has reached or exceeded the switching water level, and whether the local session fingerprint matches the fingerprint recorded at that time. Second, it verifies whether the version number of the out-of-order window and water level parameters used locally matches the version number in the switching token, so as to avoid inconsistencies in the post-switching view due to different parameter configurations.

[0063] After the above verification, if a node determines that it meets the conditions required by the switching token, it returns confirmation information to the disaster recovery control module. If the conditions are not met, it can return a reason for rejection, such as insufficient water level, incompatible parameter version, or the current node being marked as an incomplete node. After receiving the confirmation information returned by each node, the disaster recovery control module counts the number of confirmed nodes according to preset confirmation rules and determines whether the required confirmation ratio has been reached within the specified time limit. The time limit refers to the maximum time allowed from the issuance of the switching token to the completion of confirmation statistics. The confirmation ratio can be set to no less than half of the total number of available nodes; for example, at least three nodes need to successfully confirm when there are five available nodes. Only when the number of confirmed nodes meets the node number requirement stipulated by the confirmation rules, and no critical node explicitly refuses, does the disaster recovery control module consider the switch to have reached a consensus.

[0064] After reaching a consensus, the disaster recovery control module, through the configuration management system, marks the candidate backup node as the new master node in the system configuration and marks the original master node as unwritable. The configuration management system can then distribute the new master node information to the business access layer and the database access layer, routing subsequent session write requests to the new master node while imposing a constraint on the original master node to prevent it from receiving further session writes. Simultaneously, while completing the configuration switchover, the disaster recovery control module records detailed information about this switchover decision in the consistency evidence chain, including the fault conditions that triggered the switchover, the current node disaster recovery health distribution, the selected switchover water level set, the response status of each node during the confirmation process, the identifier of the finally selected new master node, and the parameter version number used. This ensures that the switchover action has complete evidentiary documentation, facilitating subsequent auditing and problem tracing.

[0065] Preferably, in a three-node deployment scenario including local nodes, edge nodes, and cloud nodes, the node disaster recovery health security threshold can be set to a medium-high score, the water level difference threshold can be set to several hundred milliseconds, the switchover confirmation time limit can be set to several seconds, and the confirmation ratio can be set to at least two nodes successfully confirming. When the local master node fails to report a stable session status for several consecutive aggregation cycles due to storage failure, its disaster recovery health drops below the threshold, while the disaster recovery health of the edge nodes and cloud nodes remains at a high level. The disaster recovery control module selects cloud nodes as candidate nodes in the session consistency field. By comparing the water level positions and session fingerprints of cloud nodes and edge nodes in several high-priority billing sessions, it determines that each session has a high water level position that is jointly covered by the two nodes and has a consistent fingerprint. These positions are used as switchover water levels to form a switchover water level set, which is written into the switchover token. After being sent to the edge nodes and cloud nodes through the control channel, both nodes verify in the local consistency evidence chain within a specified time that the corresponding switchover water level has been reached and return confirmation information, satisfying the quantity requirements specified by the confirmation rules. The disaster recovery control module then marks the cloud node as the new master node in the configuration management system, removes the local node from the write path, and writes the switchover decision entry into the consistency evidence chain. Subsequently, the cloud node starts the session reconstruction process in the local session buffer queue according to the switchover level, so as to achieve the smooth migration and continuation of critical business sessions.

[0066] Those skilled in the art can, based on the above definitions and processing order, implement the monitoring module's determination of fault conditions, the disaster recovery control module's selection of candidate nodes and switching water levels, the generation and distribution of switching tokens, and the execution of confirmation rules in a specific environment. This will reproduce the primary / backup switching decision-making process based on session consistency field and node disaster recovery health, achieving the technical effect of traceable and quantifiable secure switching in a hybrid deployment environment.

[0067] S6. On the new master node, the session state is reconstructed in the session buffer queue according to the switching water level. Deduplication and reordering are performed according to the session idempotent key. Missing events are compensated and the session fingerprint and session consistency field are updated. The specific implementation is as follows: After the aforementioned switchover decision is completed and the configuration management system marks a backup node as the new master node, the new master node receives a notification of its role change through an internal control channel. First, it reads the switchover watermark set recorded in the switchover token locally. Then, for each specified session, it searches the local session buffer queue for session replication packets that are not higher than the corresponding switchover watermark. These session replication packets are then moved from the variable segment of the buffer queue to the frozen segment. The frozen segment refers to a read-only area within the buffer queue. Session replication packets and their session idempotent keys within this area are no longer involved in subsequent out-of-order reordering and missing key checks. For session replication packets entering the frozen segment, the new master node considers the session idempotent keys they contain as the final confirmed range of the session on this node. That is, it assumes that this part of the write has been replicated on a majority of nodes and passed consistency verification, and can be used as the basis for the current state of the session.

[0068] The new master node merges the writes within this final confirmation range with existing local records: for writes that have not yet been written to disk locally, the writes are completed according to the session idempotent key order; for existing records, it is determined whether they are duplicates according to the idempotent rules. If the session idempotent key already exists, the write is skipped and only the previous record is retained to ensure that each write is executed only once at the granularity of the session idempotent key.

[0069] Based on this, for session replication packets that are above the switching water level and still within the out-of-order window of this link, the session buffer queue remains in a variable state before the new master node includes them in the final confirmation scope. The node deduplicates these replication packets according to the session idempotent key rule. If the same session idempotent key appears multiple times in different replication packets, only the record with the earlier time or the first confirmation is retained. The records are then sorted according to the session sequence anchor in the dual-anchor time base and written sequentially starting from the record with the smaller sequence anchor. This ensures that the session state proceeds along the original business sequence and prevents billing amount accumulation errors or state machine transition anomalies due to out-of-order or repeated execution.

[0070] For session idempotent keys marked as missing events in the session buffer queue (i.e., those that should exist but for which the corresponding write sequence number has not yet been received by the local node), the new master node initiates a compensation process within a limited time. This limited time refers to the maximum time allowed for compensation from the start of the switchover, which can be set to several seconds to several tens of seconds to avoid indefinite delays. During the compensation process, the new master node initiates targeted queries to other backup nodes based on the session identifier and session idempotent key corresponding to the missing event. These backup nodes can be nodes that participated in replication before the switchover and are recorded as being in a normal state in the consistency evidence chain. The query path can be set to prioritize accessing the session buffer queues of other nodes, searching for the session replication packet and write content corresponding to the session idempotent key in the buffer queue. If the buffer queue has been cleared, the node's archived log is further accessed, and the corresponding record is located in the archived log based on the session idempotent key and the dual-anchor time base. Upon finding the corresponding write, the new master node adds the write to the local session state without breaking the out-of-order window constraint of this link, and recalculates the session fingerprint of the session, updating the number of records, cumulative amount, and hash portion according to the aforementioned fingerprint update rules.

[0071] After compensation is completed, the new master node writes the updated session fingerprint and the new watermark position into the corresponding position in the session consistency field. At the same time, it adds a reconstruction entry to the consistency evidence chain, recording the time of this reconstruction operation, the set of sessions involved, the parameter version number used, and whether the compensation for each session's missing event was successful.

[0072] For missing events that cannot be found in the session buffer queues or archived logs of other backup nodes within the limited time and preset number of compensation attempts, the new master node will include these session identifiers and session idempotent keys in the scope requiring manual verification. The scope of manual verification refers to the set of sessions that need to be manually compared and corrected by operations and maintenance personnel or business personnel in conjunction with information such as external billing records and business logs. For sessions that enter the scope of manual verification, the new master node can be configured to restrict further state changes, such as prohibiting operations such as balance deduction or state termination for the session, and only allowing queries and freezing, to ensure billing accuracy and signaling retention integrity, and prevent the continued generation of chain errors when the state is unclear.

[0073] To facilitate continuous monitoring of the reconstruction progress and consistency performance of the new master node after the switchover, the new master node continues to report session status according to a predetermined rhythm. This reporting rhythm can be set to a few seconds, for example, reporting the current session fingerprint, water level position, and residual missing event count every two seconds. Preferably, in a typical operational scenario, the user-allowed interruption time during the switchover process can be controlled to the order of several seconds, such as three to five seconds. The water level for the billing session is selected at a double-anchor position where the session fingerprints of multiple nodes are consistent. That is, only when there is sufficient evidence in the consistency evidence chain to show that the fingerprints of multiple nodes for the same session are completely consistent before a certain double-anchor time base position, and the water level lines have all covered that position, is that position used as the switchover water level for the billing session. Through this approach, when the new master node reconstructs the session state after the switchover, it always operates under the triple constraints of the single execution constraint of the session idempotent key, the sequential constraint driven by the double-anchor time base, and the deduplication constraint for duplicate replication packets. This ensures that the on-site behavior is predictable and traceable in both the timeline and the business sequence.

[0074] Those skilled in the art can use this information to implement in a specific system the following: receiving the handover token by the new master node; dividing the session buffer queue into frozen and variable segments; performing deduplication and reordering based on the session idempotent key and dual-anchor time base; performing missing event compensation within a limited time and number of times; updating the session fingerprint and watermark and writing them into the session consistency field and consistency evidence chain; and implementing manual verification marking and state restrictions on sessions that fail to be compensated. This allows for the reproduction of the session reconstruction and compensation process described in this embodiment in engineering practice, thereby achieving continuity and billing accuracy of critical business sessions after handover.

[0075] In the operating scenario shown in this embodiment: In a typical operational scenario consisting of local nodes, edge nodes, and cloud nodes, the operator has already completed node registration, link detection, and session domain initialization according to the steps described above. Local nodes carry most voice billing sessions, edge nodes carry some signaling sessions nearby, and cloud nodes participate in the replication of all high-priority sessions as highly reliable backup nodes. During long-term network operation, the operation and maintenance platform continuously sends probe packets to each node at a rhythm of approximately ten seconds according to the aforementioned configuration and collects round-trip latency samples. Within multiple long and short windows, the average round-trip latency between local nodes and edge nodes is measured to be approximately twenty milliseconds, with a high quantile of approximately fifty milliseconds, jitter amplitude maintained within ten milliseconds, and packet loss ratio less than one in a thousand. Based on this, the disaster recovery control module sets the out-of-order window upper limit to eighty milliseconds, the water level advance rhythm to forty milliseconds, generates parameter records with the first version parameter number, and distributes them to each node through the configuration management system. Each node caches this version of the out-of-order window and water level parameters locally. The time synchronization component aligns with the reference clock at a 30-second rhythm, and the time deviation of each node is controlled within ±5 milliseconds. Only a very small number of writes are marked as writes to be verified.

[0076] At a certain moment, a user initiates a new voice billing service on the local node through the access layer. The access layer generates a unique session identifier based on the service type, calling number, service entry node, and current time, assigns the session to a newly created session domain, and initializes the session idempotent key sequence and session fingerprint in the session configuration table of the local node. At this time, the number of records is zero, the accumulated amount is zero, and the hash part is zero. During the call setup, the local node sequentially generates database write operations for the session, including incoming call registration, tariff policy confirmation, and billing start. After each write, the session fingerprint is updated based on the primary key value, status code, and amount field, the number of records is incremented by one, the converted integer amount is added to the accumulated amount, and the hash part is updated according to a predetermined encoding and modulo rule, forming a continuous sequence of session idempotent keys from one to three within the same session domain. Simultaneously, physical time is collected from the local clock before and after each write commit, and a physical time anchor is generated after deviation compensation. The session sequence anchor is incremented sequentially within the session, and the dual-anchor time base is recorded in the local log and session configuration table.

[0077] The session domain management module collects multiple write records during the session establishment phase with an observation window of approximately fifty milliseconds, sorts them according to the dual-anchor time base, merges and encapsulates the writes with session idempotency keys one and two into the first session replication package, and encapsulates the writes with session idempotency keys three into the second session replication package. Each session replication package carries the covered dual-anchor start and end positions, the set of session idempotency keys contained therein, and the corresponding session fingerprint increment. Based on the fact that the voice billing session is a high-priority session and the current link quality is good, the master node simultaneously sends two session replication packets to the edge node and cloud node through the replication channel pre-configured for the session. The edge node and cloud node each establish a session buffer queue for the session. After receiving the replication packets, they rearrange the queues according to the dual-anchor time base, so that the write events with session sequence anchors one, two, and three are arranged in order within an 80-millisecond out-of-order window. During this process, due to a network fluctuation at the edge node, the replication packet containing the session idempotency key two is delayed in arrival. During the initial sorting, the edge node marks the position of the session idempotency key two with a temporary missing mark and prevents the session waterline from advancing beyond the write of the session idempotency key one. Subsequently, after receiving the replication packet within the time allowed by the out-of-order window, the missing mark is removed, and the continuous interval of session idempotency keys one to three is marked as a candidate set. At the same time, the largest dual-anchor position in the candidate set and the current session fingerprint are sent to the disaster recovery control module in the session status reporting message.

[0078] The disaster recovery control module receives session status reporting messages from local nodes, edge nodes, and cloud nodes at a fixed five-second rhythm. It writes the water level position, missing event count, and session fingerprint of the three nodes in the session into the session consistency field. Within several aggregation periods, it finds that the session fingerprints of the three nodes in the session are consistent, the water level lag is lower than the preset water level difference threshold, and the missing event ratio of the three nodes is very low. Based on this, a high consistency score is given to the session, the node disaster recovery health is kept above the safety threshold, and multiple aggregation entries under normal conditions are recorded in the consistency evidence chain.

[0079] During subsequent operation, the local node experienced increased write latency and more error retries due to the aging of its storage subsystem. The disaster recovery control module continuously observed an increasing lag in the local node's water level across multiple high-priority sessions within the consistency evidence chain, along with a rising proportion of missing events and increased reconstruction task time. Over several consecutive aggregation periods, the local node failed to complete full session status reporting due to storage errors, and its disaster recovery health was reduced to below a preset threshold. Furthermore, the monitoring module recorded multiple abnormal exits of critical processes on the local node and instances where heartbeat detection exceeded the allowed time limit, meeting the fault condition definition. At this point, the disaster recovery control module triggered a switchover process based on the current session consistency field and consistency evidence chain. Among the edge nodes and cloud nodes participating in high-priority session replication, cloud nodes were selected as the primary candidate nodes based on their disaster recovery health ranking, with edge nodes serving as secondary reference nodes.

[0080] The disaster recovery control module, for several high-priority billing sessions, including the aforementioned voice billing sessions, reads the waterline positions of the cloud nodes and edge nodes in the session consistency field, calculates the minimum waterline value for each session on these two nodes, and verifies that this minimum value is not lower than the minimum safe waterline threshold. Simultaneously, it compares the session fingerprint consistency between the two nodes at this waterline position. When it finds that a session has been replicated to the same dual-anchor time base position on both nodes and the fingerprint is consistent, this position is used as the switching waterline for that session. If some sessions still do not meet this condition, these sessions are temporarily removed from the designated session set for this switchover, prioritizing the protection of critical voice billing sessions. The disaster recovery control module encapsulates the cloud node identifier, the switching water level set for each specified session, and the current parameter version number into a switching token, which is then distributed to the cloud node and the edge node. Both nodes search for the corresponding session's record at the switching water level in their local consistency evidence chain, confirming that the local water level has reached that position and that the session fingerprint matches the fingerprint recorded in the evidence chain. They also confirm that the local out-of-order window and water level parameter version number are the same as the version number carried in the switching token. Within the specified time limit, each node returns confirmation information to the disaster recovery control module. The disaster recovery control module analyzes the received confirmation results, determines that the preset confirmation ratio requirement has been met, and that no critical nodes have explicitly rejected the request. Therefore, it marks the cloud node as the new master node and the local node as unwritable through the configuration management system. It then distributes the new master node information to the access layer and database access layer, automatically routing subsequent session write requests to the cloud node. Simultaneously, it writes a switching decision entry into the consistency evidence chain, recording the cause of the switch failure, the node's disaster recovery health distribution, the switching water level for each session, and the node's response during the confirmation process.

[0081] After receiving the switchover token and being marked as the new master node by the configuration management system, the cloud node searches for session replication packets in its local session buffer queue for each specified session that are no higher than the switchover watermark. These replication packets are moved from the variable segment to the frozen segment. The set of session idempotent keys contained within them is considered the final confirmed range for that session on the cloud node and is merged with existing local write records. Writes not yet written to disk are completed according to the session idempotent key order, while writes with existing idempotent keys are skipped according to idempotency rules. Furthermore, for replication packets higher than the switchover watermark but still within the 80-millisecond out-of-order window, the cloud node deduplicates them according to the session idempotent key rules, retaining only the earliest confirmed record and completing the write according to the session sequence anchor order, ensuring a smooth progression of session status along the existing business sequence.

[0082] For session idempotent keys marked as missing events in the local session buffer queue, the cloud node initiates a targeted query to the edge node within a limited time. First, it accesses the edge node's session buffer queue. If the buffer is not found, it then accesses the edge node's archived logs. Using the session idempotent key and dual-anchor time base, it locates the corresponding write. Without violating the out-of-order window constraint, the found write is added to the local session state, and the session fingerprint and watermark are updated according to the aforementioned rules. The updated session fingerprint and watermark position are written to the session consistency field, and an entry for this reconstruction operation is added to the consistency evidence chain. When individual sessions still cannot find the missing write within the limited time and preset number of attempts, the cloud node includes these sessions in the manual verification scope and freezes their subsequent state changes in the local state machine, allowing only queries and necessary security operations. Further processing will be carried out after maintenance personnel manually reconcile external billing records and business logs.

[0083] Throughout the switchover and reconstruction process, cloud nodes continuously report the session fingerprint, water level position, and residual missing event count of the new master node to the disaster recovery control module at a rhythm of approximately two seconds. Based on this, the disaster recovery control module updates the session consistency field and node disaster recovery health within the new aggregation cycle. Because the switchover water level is selected at a dual-anchor position with consistent fingerprints across multiple nodes, and the reconstruction and compensation actions are performed under the combined constraints of idempotency, order constraints, and deduplication constraints, the voice service interruption time perceived by the user is controlled within a few seconds. Billing results remain consistent between the old and new master nodes, and signaling retention meets regulatory and auditing requirements. Those skilled in the art can directly implement the complete process of node deployment, session organization, time synchronization, replication sorting, global consistency assessment, master-slave switchover decision-making, and new master node reconstruction compensation in the engineering system based on the above scenario, thereby reproducing the overall operational behavior and technical effects of this specific implementation scheme in achieving real-time disaster recovery backup of the communication database at the session level in a hybrid deployment environment.

[0084] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0085] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0086] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0087] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0089] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0091] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0093] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for real-time disaster recovery backup of communication databases in a hybrid deployment environment, characterized in that, include: S1. Obtain node and link information in the hybrid deployment environment, establish a session domain, and generate session identifiers, session idempotent keys, and session fingerprints for the sessions; S2. At each node, physical time anchors and session sequence anchors are attached to the session writes to form a dual-anchor time base. The out-of-order window and water level are configured according to the link delay statistics. S3. Collect and write session replication packets by session domain, generate and send them to the backup node, and sort them by dual anchor time base and out-of-order window in the backup node's session buffer queue and mark missing events. S4. Periodically summarize the session fingerprints, water level lines and missing events of each node to form a session consistency field, calculate the node disaster recovery health and session consistency score and generate a consistency evidence chain. S5. When the primary node meets the fault conditions and the disaster recovery health meets the switching conditions, a backup node is selected from the session consistency field, the switching water level is locked for the specified session and a switching token containing the backup node and the switching water level set is generated. After confirmation by the node set that meets the preset confirmation rules, the backup node is promoted to the primary node. S6. On the new master node, the session state is reconstructed in the session buffer queue according to the switching water level. Deduplication and reordering are performed according to the session idempotent key. Missing events are compensated and the session fingerprint and session consistency field are updated.

2. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S1 includes: The operation and maintenance platform registers the local nodes, edge nodes, and cloud nodes that carry the communication database, assigns node identifiers to each node, and establishes corresponding link information records. The access layer generates a session identifier and classifies the service into the session domain. When the session is created, a session idempotent key and a session fingerprint are generated, and the session identifier, session idempotent key sequence number and session fingerprint value are recorded in the session configuration table. The node reports the session registration status to the disaster recovery control module through the session registration call. The disaster recovery control module generates a parameter version number and writes the parameter version number into the consistency evidence chain.

3. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S2 include: Set up a time synchronization component on each node to align the local clock with the reference clock and record the time deviation range; When a database write occurs within the session domain, physical time is collected from the local clock to generate a physical time anchor, and an incrementing session sequence anchor is maintained within the session. The physical time anchor and the session sequence anchor are combined to form a dual-anchor time base, and the dual-anchor time base and session identifier are registered in the session configuration table and local log.

4. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 3, characterized in that: In the disaster recovery control module, set the observation window parameters and out-of-order window parameters, and calculate the high quantile value and average value according to the link round-trip delay samples within the observation window; The upper limit of the disordered window is determined based on the high quantile value, and the water level advancement rhythm is determined based on the average value. The parameter record is composed of the out-of-order window limit, water level advancement rhythm, link identifier, and session priority. The parameter record has a parameter version number and is distributed to each node by the configuration management system. Each node references the current parameter version number during dual-anchor time base sorting and water level advancement, and the disaster recovery control module writes the current parameter version number into the consistency evidence chain.

5. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S3 includes: The master node sets up a session domain management module, and writes records in the observation window according to the session identifier to generate a session replication package carrying the session identifier, dual anchor time base range information, session idempotent key set and session fingerprint increment; The backup node establishes a session buffer queue for each session identifier, sorts the session replication packets according to the session sequence anchor and physical time anchor based on the out-of-order window, marks the continuous interval of the session idempotent key as a candidate set, marks the session idempotent key corresponding to the gap as a missing event, and writes the session status into the consistency evidence chain entry by the disaster recovery control module when periodically reporting the session status.

6. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S4 include: The disaster recovery control module receives session fingerprints, water level positions, and missing event counts reported by each node at a fixed rhythm. Establish a session consistency field based on session identifier and node identifier; For each session, the water level lag is obtained based on the difference in the water level positions of each node in the session consistency field. The session consistency score is calculated according to the preset scoring rules based on the session fingerprint consistency of each node. Sessions with session consistency scores lower than the preset consistency security threshold are marked as consistency abnormal sessions.

7. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 6, characterized in that: The disaster recovery control module calculates the disaster recovery health of nodes for high-priority session sets in the session consistency field based on the water level lag, missing event ratio, and historical reconstruction performance indicators of each node in that set. If no node session status update is received within a preset number of consecutive aggregation periods, the node will be marked as an incomplete node and deducted from the node's disaster recovery health. At the end of each aggregation period, the session consistency field section, node disaster recovery health, session consistency score, and the currently used parameter version number are written into the consistency evidence chain entry.

8. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S5 include: The monitoring module reads the master node status and node disaster recovery health from the consistent evidence chain, and initiates the switchover process after determining that the master node meets the failure conditions. The disaster recovery control module selects backup nodes based on the node's disaster recovery health in the session consistency field, determines the switching water level according to the specified session, and generates a switching token containing the backup node identifier and the switching water level set. The switching token is issued to the node set and the confirmation results from each node are received based on the water level and session fingerprint. When the confirmation rules are met, the backup node is set as the new master node through the configuration management system, and the original master node is set to an unwritable state.

9. The real-time disaster recovery backup method for communication databases in a hybrid deployment environment according to claim 1, characterized in that, S6 include: After being set as the master node, the new master node will allocate session replication packets that are not higher than the switching watermark in the session buffer queue to the frozen segment based on the switching token, and will use the session idempotent keys in the frozen segment as the final confirmation range and merge them with the local records. For session replication packets that are above the switching water level, deduplication is performed using the session idempotency key and rearranged according to the dual-anchor time base order. For events marked as missing, replication packets are queried from other backup nodes for compensation. After compensation, the session fingerprint and watermark are updated and written into the session consistency field and consistency evidence chain. Sessions corresponding to uncompensated missing events are added to the scope of manual verification and their state changes are restricted.

Images