Fault processing method and device, computer equipment, storage medium and program product
By acquiring and storing session identifiers during primary-standby failover and utilizing the standby replica to perform data processing tasks, the problem of data interruption during primary-standby failover is solved, thus improving the database's data processing efficiency.
Patent Information
- Application Number
- CN202511775122.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-03-03
AI Technical Summary
In the traditional primary-backup failover mechanism, when the primary and backup replicas switch, the current data read and write requests are forced to be interrupted, resulting in low data processing efficiency.
By obtaining the session identifier of the primary replica and storing it in an independent memory pool service, the backup replica can determine the target status information and execute data processing tasks based on the session identifier when the primary replica fails, thus achieving primary-backup failover.
It reduces database access latency in fault scenarios, improves the processing efficiency of data read and write requests, and avoids the need for the application to re-initiate requests.
Smart Images
Figure CN121597467A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database management technology, and in particular to a fault handling method, apparatus, computer equipment, storage medium, and program product. Background Technology
[0002] With the rapid development of cloud computing technology, databases, as the core component of data storage and management, have become crucial for ensuring high availability and reliability for applications. Currently, a primary-backup replica architecture is commonly used for fault recovery: when the primary replica fails, it automatically switches to the backup replica to maintain service continuity.
[0003] However, in the traditional master-slave failover mechanism, when the master and slave replicas switch, the currently ongoing data read and write requests will be forced to be interrupted, and the application must resend requests to the database, resulting in low processing efficiency of data read and write requests. Summary of the Invention
[0004] Therefore, it is necessary to provide a fault handling method, apparatus, computer equipment, storage medium, and program product to address the aforementioned technical problems.
[0005] Firstly, this application provides a fault handling method. The method includes:
[0006] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database to the application.
[0007] The target state information is determined by using a backup copy based on the session identifier;
[0008] The backup copy is used to perform the data processing task based on the target status information.
[0009] In one embodiment, the method further includes:
[0010] Before the primary replica fails, during the execution of data processing tasks on the primary replica, the session context information corresponding to the data processing task and the session identifier are stored through the primary replica.
[0011] In one embodiment, determining the target state information based on the session identifier via the backup copy includes:
[0012] The session context information stored corresponding to the session identifier is determined as the target state information.
[0013] In one embodiment, the method further includes:
[0014] Based on the session context information, determine the liveness status of the session corresponding to the session context information;
[0015] The session's lifetime is determined based on its liveness status.
[0016] In one embodiment, determining whether to update the session's lifetime based on the liveness status includes:
[0017] If the session is alive in the current state, update the session's lifespan in the session context information according to the current time and the preset lifespan duration.
[0018] If the session's lifespan status indicates that the session has expired, stop updating the session's lifespan in the session context information.
[0019] In one embodiment, determining the liveness status of the session corresponding to the session context information based on the session context information includes:
[0020] If the current time exceeds the time-to-live information in the session context, the session's liveness status is determined to be expired.
[0021] If the current time does not exceed the timeout specified in the session context information, the session's liveness status is determined to be live.
[0022] Secondly, this application also provides a fault handling apparatus. The apparatus includes:
[0023] The acquisition module is used to obtain the session identifier of the data processing task being executed by the primary replica of the database in the event of a failure of the primary replica of the database, through the database driver used to connect the database to the application.
[0024] The first determination module is used to determine the target state information based on the session identifier using the backup copy;
[0025] The execution module is used to perform the data processing task based on the target status information using the backup copy.
[0026] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:
[0027] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database to the application.
[0028] The target state information is determined by using a backup copy based on the session identifier;
[0029] The backup copy is used to perform the data processing task based on the target status information.
[0030] Fourthly, this application also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:
[0031] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database to the application.
[0032] The target state information is determined by using a backup copy based on the session identifier;
[0033] The backup copy is used to perform the data processing task based on the target status information.
[0034] Fifthly, this application also provides a computer program product. This computer program product includes a computer program that, when executed by a processor, performs the following steps:
[0035] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database to the application.
[0036] The target state information is determined by using a backup copy based on the session identifier;
[0037] The backup copy is used to perform the data processing task based on the target status information.
[0038] The aforementioned fault handling methods, apparatus, computer equipment, storage media, and program products, when the primary copy of the database fails, obtain the session identifier of the session of the data processing task being executed by the primary copy through the database driver used to connect the database and the application; determine the target status information through the backup copy based on the session identifier; and execute the data processing task through the backup copy based on the target status information. Thus, the database driver detects the database fault and realizes the primary / backup switch of the database. The application will not be aware of the database fault, so there is no need to re-initiate requests to the database, reducing the database access latency in fault scenarios and improving the processing efficiency of data read and write requests. Attached Figure Description
[0039] Figure 1 This is an internal structural diagram of a computer device provided in an embodiment of this application;
[0040] Figure 2This is a flowchart illustrating a fault handling method provided in an embodiment of this application;
[0041] Figure 3 This is a flowchart illustrating a lifespan update method provided in an embodiment of this application;
[0042] Figure 4 This is a flowchart illustrating a method for maintaining database connections based on an independent memory pool service, as provided in an embodiment of this application.
[0043] Figure 5 This is a structural block diagram of a fault handling device provided in an embodiment of this application. Detailed Implementation
[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0045] With the rapid development of cloud computing technology, databases, as the core component of data storage and management, have become crucial for ensuring high availability and reliability for applications. Currently, a primary-backup replica architecture is commonly used for fault recovery: when the primary replica fails, it automatically switches to the backup replica to maintain service continuity.
[0046] However, in the traditional master-slave failover mechanism, when the master and slave replicas switch, the currently ongoing data read and write requests will be forced to be interrupted, and the application must resend requests to the database, resulting in low processing efficiency of data read and write requests.
[0047] The fault handling method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown. Figure 1 This is an internal structure diagram of a computer device provided in an embodiment of this application. The computer device may be a server, and its internal structure diagram may be as follows: Figure 1 As shown, this computer device is equipped with an application program, a database driver, a primary database copy, a backup database copy, and an independent memory pool service. The application program connects to the database via the database driver, and the independent memory pool service stores session context information generated during the interaction between the database and the application program.
[0048] Those skilled in the art will understand that Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0049] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a fault handling method provided in an embodiment of this application. This method can be applied to... Figure 1 The method, using a computer device, includes the following steps:
[0050] S201, In the event of a failure of the primary replica of the database, obtain the session identifier of the session of the data processing task being executed by the primary replica through the database driver used to connect the database and the application.
[0051] In this embodiment of the application, the application can access the database for reading and writing through the database driver. After the database driver establishes a connection with the database, the database will create a session for this connection and use a session identifier (session ID) to uniquely identify this session.
[0052] For example, if the database driver detects a failure in the primary replica of the database, it can disconnect from the primary replica and establish a connection with the backup replica, sending a session identifier to the backup replica so that the backup replica can take over the work of the primary replica based on the session identifier. In other words, the backup replica is used as the new primary replica to continue performing data processing tasks.
[0053] Optionally, the database driver can perform access switching by changing the target access address. That is, when the primary replica fails, the target access address is changed to the access address of the backup replica in order to establish a connection with the backup replica.
[0054] S202, determine the target state information based on the session identifier using the backup copy.
[0055] S203, executes data processing tasks based on target status information using a backup copy.
[0056] In one possible implementation, the server is also equipped with an independent memory pool service. Before the primary replica fails, that is, during the process of the primary replica normally executing data processing tasks, the status information and session identifiers corresponding to the data processing tasks can be stored in the independent memory pool service.
[0057] Optionally, after the backup replica obtains the session identifier, it can query the status information stored in the independent memory pool service based on the session identifier, and use the status information stored corresponding to the session identifier as the target status information, so that the backup replica can continue to perform data processing tasks according to the target status information.
[0058] In this embodiment, when the primary replica of the database fails, the database driver used to connect the database and the application obtains the session identifier of the session of the data processing task being executed by the primary replica; the backup replica determines the target state information based on the session identifier; and the backup replica executes the data processing task based on the target state information. Thus, the database driver detects the database failure and realizes the primary / backup switch of the database. The application will not be aware of the database failure, so there is no need to re-initiate a request to the database, reducing the database access latency in failure scenarios and improving the processing efficiency of data read and write requests.
[0059] Based on the above embodiments, the method further includes the following steps:
[0060] Before the primary replica fails, during the execution of data processing tasks on the primary replica, the session context information and session identifier corresponding to the data processing tasks are stored through the primary replica.
[0061] For example, session context information may include connection / session-specific parameters, access identity and permission information, description information of read / write tasks, execution status information of read / write tasks, result cache, and transaction information. Connection / session-specific parameters may include whether transactions are configured for autocommit; access identity and permission information may include username / role name, accessed database name, and current default namespace information; description information of read / write tasks may include currently active SQL statements, syntax trees, execution plans, and execution plan caches; execution status information of read / write tasks may include execution plan status, current access position of each operator, and intermediate execution results; result cache may include read / write request results not yet returned to the database driver; and transaction information may include the current transaction status and locks held by the transaction.
[0062] For example, the server also has an independent memory pool service. Before the primary replica fails, that is, during the process of the primary replica normally executing data processing tasks, the session context information and session identifier corresponding to the data processing tasks can be stored in the independent memory pool service.
[0063] It should be noted that after the primary and backup replicas are switched over, the backup replica can be regarded as the new primary replica. At this time, the session context information and session identifier generated by its data processing tasks will also be stored in the independent memory pool service.
[0064] In this embodiment, before the primary replica fails, during the execution of data processing tasks by the primary replica, the session context information corresponding to the data processing task is stored in the primary replica along with the session identifier. This allows the session context information stored in the primary replica to be queried through the session identifier, which facilitates the rapid determination of the session context information when the primary replica fails, thereby enabling rapid switching between primary and backup replicas. This further reduces the database access latency in failure scenarios and improves the processing efficiency of data read and write requests.
[0065] Based on the above embodiments, S202 can be implemented in the following ways:
[0066] The session context information stored corresponding to the session identifier is determined as the target state information.
[0067] In this embodiment of the application, after the backup copy obtains the session identifier, it can query the session context information stored in the independent memory pool service based on the session identifier, and use the session context information stored corresponding to the session identifier as the target state information, so that the backup copy can continue to perform data processing tasks according to the target state information.
[0068] Reference Figure 3 , Figure 3 This is a flowchart illustrating a lifespan update method provided in an embodiment of this application. Based on the above embodiment, the method further includes the following steps:
[0069] S301, Determine the liveness status of the session corresponding to the session context information based on the session context information.
[0070] S302, determine whether to update the session's lifespan based on its liveness status.
[0071] In this embodiment of the application, the session's liveness status can be determined based on a heartbeat and timeout mechanism, and the session's liveness time can be updated.
[0072] For example, after a database creates a session for a connection, a time-to-live (TTL) can be set, and session context information containing that TTL can be stored in a separate memory pool service. The TTL is a timestamp that can be determined based on the current time and a preset TTL duration.
[0073] Optionally, if the current time exceeds the time-to-live in the session context information, the session's liveness status can be determined as "session expired." Alternatively, if the current time does not exceed the time-to-live in the session context information, the session's liveness status can be determined as "session alive."
[0074] For example, the preset lifespan can be set to 300 seconds. The lifespan is the current time + 300 seconds. In other words, the lifespan of the session will remain for 300 seconds without being updated. If the lifespan of the session is not updated within 300 seconds, that is, if the current time exceeds the lifespan, the lifespan of the session is determined to be expired. If the lifespan of the session is updated within 300 seconds, the current time will not exceed the above lifespan, and the session will still be alive.
[0075] In one embodiment, the database periodically updates the lifespan of surviving sessions. That is, when the session is alive, the lifespan of the session in the session context information is updated according to the current time and the preset lifespan duration.
[0076] For example, the lifespan update cycle can be set to 30 seconds, then the session lifespan will be updated every 30 seconds, and the updated lifespan = current time + preset lifespan duration.
[0077] Optionally, if the session's lifespan status is expired, there is no need to update the session's lifespan. Instead, the session context information of the session marked as expired is removed from the memory pool, releasing all memory resources it occupies.
[0078] It should be noted that the update cycle for the survival time should be shorter than the preset survival time.
[0079] In this embodiment, the survival status of the session corresponding to the session context information is determined based on the session context information; the survival time of the session is updated based on the survival status, thereby realizing the determination of the survival status of the session and the update of the survival time of the session based on the heartbeat and timeout mechanism, thereby avoiding the permanent residue of session information in abnormal scenarios and improving the stability and resource utilization efficiency of the system in long-term operation.
[0080] Reference Figure 4 , Figure 4 This is a flowchart illustrating a method for maintaining database connections based on an independent memory pool service, as provided in an embodiment of this application. The method includes the following steps:
[0081] S401: In the event of a failure in the primary replica of the database, the session identifier of the session for the data processing task being executed by the primary replica is obtained through the database driver used to connect the database and the application.
[0082] S402, determine the session context information stored in the independent memory pool service corresponding to the session identifier as the target state information.
[0083] S403, continue to execute data processing tasks based on the target status information using a backup copy.
[0084] S404 uses heartbeat and timeout mechanisms to prevent the permanent persistence of session context information in the independent memory pool service under abnormal scenarios.
[0085] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0086] Based on the same inventive concept, this application also provides a fault handling apparatus for implementing the fault handling method described above. The solution provided by this apparatus is similar to the solution described in the above method; therefore, the specific limitations in one or more fault handling apparatus embodiments provided below can be found in the limitations of the fault handling method described above, and will not be repeated here.
[0087] In one embodiment, such as Figure 5 As shown, Figure 5 This is a structural block diagram of a fault handling device provided in an embodiment of this application. The device 500 includes:
[0088] The acquisition module 501 is used to obtain the session identifier of the data processing task being executed by the primary replica of the database in the event of a failure of the primary replica of the database, through the database driver used to connect the database and the application.
[0089] The first determination module 502 is used to determine the target state information based on the session identifier through the backup copy.
[0090] Execution module 503 is used to perform data processing tasks based on target status information using a backup copy.
[0091] In one embodiment, the device 500 further includes:
[0092] The storage module is used to store the session context information and session identifier corresponding to the data processing task through the primary replica during the execution of the data processing task in order to prevent the primary replica from failing.
[0093] In one embodiment, the first determining module 502 includes:
[0094] The determining unit is used to determine the session context information stored corresponding to the session identifier as the target state information.
[0095] In one embodiment, the device 500 further includes:
[0096] The second determination module is used to determine the liveness status of the session corresponding to the session context information based on the session context information.
[0097] The update module is used to determine whether to update the session's lifespan based on its liveness status.
[0098] In one embodiment, the update module is specifically used to update the session's lifespan in the session context information according to the current time and a preset lifespan duration when the session's lifespan status is "session alive"; the second update unit is used to stop updating the session's lifespan in the session context information when the session's lifespan status is "session expired".
[0099] In one embodiment, the second determining module is specifically configured to determine the session's survival status as expired if the current time exceeds the survival time in the session context information, and to determine the session's survival status as alive if the current time does not exceed the survival time in the session context information.
[0100] Each module in the aforementioned fault handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0101] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0102] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database and the application.
[0103] The target state information is determined by using a backup copy based on the session identifier;
[0104] Data processing tasks are performed based on the target status information by using a backup copy.
[0105] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0106] Before the primary replica fails, during the execution of data processing tasks on the primary replica, the session context information and session identifier corresponding to the data processing tasks are stored through the primary replica.
[0107] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0108] The session context information stored corresponding to the session identifier is determined as the target state information.
[0109] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0110] Based on the session context information, determine the liveness status of the session corresponding to the session context information;
[0111] Determine whether to update the session's lifetime based on its liveness status.
[0112] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0113] If the session is alive, update the session's lifespan in the session context information according to the current time and the preset lifespan duration.
[0114] If the session's liveness status is expired, stop updating the session's liveness time in the session context information.
[0115] In one embodiment, the processor, when executing a computer program, also performs the following steps:
[0116] If the current time exceeds the time-to-live information in the session context, the session's liveness status is determined to be that the session has expired;
[0117] If the current time has not exceeded the timeout specified in the session context information, the session's liveness status is determined to be session live.
[0118] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:
[0119] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database and the application.
[0120] The target state information is determined by using a backup copy based on the session identifier;
[0121] Data processing tasks are performed based on the target status information by using a backup copy.
[0122] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0123] Before the primary replica fails, during the execution of data processing tasks on the primary replica, the session context information and session identifier corresponding to the data processing tasks are stored through the primary replica.
[0124] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0125] The session context information stored corresponding to the session identifier is determined as the target state information.
[0126] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0127] Based on the session context information, determine the liveness status of the session corresponding to the session context information;
[0128] Determine whether to update the session's lifetime based on its liveness status.
[0129] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0130] If the session is alive, update the session's lifespan in the session context information according to the current time and the preset lifespan duration.
[0131] If the session's liveness status is expired, stop updating the session's liveness time in the session context information.
[0132] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0133] If the current time exceeds the time-to-live information in the session context, the session's liveness status is determined to be that the session has expired;
[0134] If the current time has not exceeded the timeout specified in the session context information, the session's liveness status is determined to be session live.
[0135] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:
[0136] In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database and the application.
[0137] The target state information is determined by using a backup copy based on the session identifier;
[0138] Data processing tasks are performed based on the target status information by using a backup copy.
[0139] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0140] Before the primary replica fails, during the execution of data processing tasks on the primary replica, the session context information and session identifier corresponding to the data processing tasks are stored through the primary replica.
[0141] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0142] The session context information stored corresponding to the session identifier is determined as the target state information.
[0143] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0144] Based on the session context information, determine the liveness status of the session corresponding to the session context information;
[0145] Determine whether to update the session's lifetime based on its liveness status.
[0146] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0147] If the session is alive, update the session's lifespan in the session context information according to the current time and the preset lifespan duration.
[0148] If the session's liveness status is expired, stop updating the session's liveness time in the session context information.
[0149] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:
[0150] If the current time exceeds the time-to-live information in the session context, the session's liveness status is determined to be that the session has expired;
[0151] If the current time has not exceeded the timeout specified in the session context information, the session's liveness status is determined to be session live.
[0152] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0153] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0154] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A fault handling method, characterized in that, The method includes: In the event of a failure of the primary replica of the database, the session identifier of the session in which the primary replica is performing a data processing task is obtained through the database driver used to connect the database to the application. The target state information is determined by using a backup copy based on the session identifier; The data processing task is executed using the backup copy based on the target status information.
2. The method according to claim 1, characterized in that, The method further includes: Before the primary replica fails, during the execution of data processing tasks by the primary replica, the session context information corresponding to the data processing task and the session identifier are stored by the primary replica.
3. The method according to claim 2, characterized in that, The step of determining the target state information based on the session identifier using a backup copy includes: The session context information stored corresponding to the session identifier is determined as the target state information.
4. The method according to claim 2, characterized in that, The method further includes: Based on the session context information, determine the liveness status of the session corresponding to the session context information; Whether to update the session's lifetime is determined based on the session's liveness status.
5. The method according to claim 4, characterized in that, The step of determining whether to update the session's lifetime based on the liveness status includes: If the survival status is that the session is alive, update the session survival time in the session context information according to the current time and the preset survival time. If the session's liveness status is that it has expired, stop updating the session's liveness time in the session context information.
6. The method according to claim 4, characterized in that, Determining the liveness status of the session corresponding to the session context information based on the session context information includes: If the current time exceeds the time-to-live information in the session context, the session's liveness status is determined to be that the session has expired. If the current time does not exceed the lifespan in the session context information, the session's lifespan status is determined to be "session alive".
7. A fault handling device, characterized in that, The device includes: The acquisition module is used to acquire the session identifier of the data processing task being executed by the primary replica of the database in the event of a failure of the primary replica of the database, through a database driver used to connect the database and the application. The first determining module is used to determine the target state information based on the session identifier using a backup copy; An execution module is used to execute the data processing task based on the target status information using the backup copy.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.