Data page recovery method and device, electronic equipment and storage medium

Abstract

The application discloses a data page recovery method and device, electronic equipment and a storage medium. The data page recovery method comprises the following steps: determining a data page cache of a first data page to which a target waiting event is directed, the target waiting event is a waiting event waiting for a target node in a database cluster to respond, and the target node comprises a fault node and / or an active node; releasing other data page caches in the active node except the data page cache of the first data page; and recovering a data page cache of a second data page according to a first redo log of the second data page, the second data page being a data page taking the active node as a recovery node, and the first redo log being recorded in a first log file in a disk. According to the method, other data page caches except the data page cache of the first data page are released, and then data page recovery is performed according to the first redo log of the second data page, so that the recovery efficiency of the data page in the shared storage database cluster is improved.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, apparatus, electronic device, and storage medium for recovering data pages. Background Technology

[0002] A shared storage database cluster (DM Data Shared Cluster, DMDSC) is a multi-instance, single-database system. The cluster allows multiple database instances to access and operate the same database simultaneously. If one node in the cluster fails, the database service will not be unavailable.

[0003] In a shared storage database cluster environment, when a node fails, the remaining active nodes handle the failure. The key to this failure handling is the redo log. The redo log records operations that modify data pages. When a node modifies a data page, a corresponding redo log is generated simultaneously. After the data page is modified, it's not necessary to immediately flush the data page to disk; only the redo log needs to be flushed. If the node fails at this point, after restarting, the redo log content can be used to restore all data pages to their latest state.

[0004] However, in existing technologies, data page recovery requires frequently reading the log sequence number (LSN) from the disk to determine the logs that need to be redone. Data pages are then recovered by redoing the logs. When there are a large number of invalid data pages in the cache, frequently reading the LSN value from the disk will generate a large number of disk reads / writes, resulting in low efficiency of the overall data page recovery. Summary of the Invention

[0005] This invention provides a method, apparatus, electronic device, and storage medium for recovering data pages, in order to solve the problem of low data page recovery efficiency.

[0006] In a first aspect, embodiments of the present invention provide a method for recovering data pages, comprising:

[0007] The data page cache of the first data page to which the target wait event is targeted is determined, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a faulty node and / or an active node;

[0008] Release the cached data pages in this active node, excluding the cached data page of the first data page.

[0009] Based on the first redo log of the second data page, restore the data page cache of the second data page, wherein the second data page is the data page with this active node as the recovery node, and the first redo log is recorded in the first log file on the disk.

[0010] Secondly, embodiments of the present invention provide a data page recovery device, comprising:

[0011] A data page cache determination module is used to determine the data page cache of the first data page targeted by the target wait event, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a faulty node and / or an active node;

[0012] The data page cache release module is used to release the data page cache of other data pages in this active node, except for the data page cache of the first data page.

[0013] The data page cache recovery module is used to recover the data page cache of the second data page based on the first redo log of the second data page, wherein the second data page is the data page with the current active node as the recovery node, and the first redo log is recorded in the first log file on the disk.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data page recovery method as described in the first aspect.

[0018] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a processor to execute and implement the data page recovery method as described in the first aspect.

[0019] The technical solution of this invention first determines the data page cache of the first data page targeted by the target wait event, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a failed node and / or an active node; then, it releases the data page caches of the active node other than the data page cache of the first data page; finally, it restores the data page cache of the second data page according to the first redo log of the second data page, wherein the second data page is the data page with the active node as the recovery node, and the first redo log is recorded in a first log file on the disk. In the event of node failure, by releasing the data page caches other than the data page cache of the first data page, and then restoring the data page according to the first redo log of the second data page, frequent disk reads / writes are avoided, improving the recovery efficiency of data pages in the shared storage database cluster.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of a data page recovery method according to Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart of a data page recovery method according to Embodiment 2 of the present invention;

[0024] Figure 3 This is a schematic diagram of a data page recovery device according to Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of an electronic device that implements the data page recovery method of this invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0029] Example 1

[0030] Figure 1 This is a flowchart of a data page recovery method according to Embodiment 1 of the present invention. This embodiment is applicable to the recovery of data pages when a node fails in a shared storage database cluster. The method can be executed by a data page recovery device, which can be implemented in software and / or hardware and integrated into an electronic device. Further, the electronic device includes, but is not limited to, computers, laptops, smartphones, servers, etc. Figure 1 As shown, the method includes:

[0031] S110. Determine the data page cache of the first data page to which the target wait event is directed, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a faulty node and / or an active node.

[0032] In this context, a data page refers to the basic unit of data storage in a database management system, serving as the fundamental unit for data access, modification, and I / O. A faulty node refers to a node in a shared storage database cluster that fails. A failure can be understood as a node's inability to perform its intended function; the type of failure is not limited, and could include transaction failures, system failures, or media failures. In a shared storage database cluster, when a node fails, the remaining active nodes enter the fault handling process. Active nodes can be any node in the shared storage database cluster that is functioning normally, and the number of active nodes is unlimited.

[0033] The method for determining node failure is not limited. For example, a separate control node can be set up in the shared storage database cluster. The control node can monitor the running status of each node in the cluster. When a node fails, the control node controls other active nodes to handle the failure, or sends the information of the failed node to other active nodes so that they can handle the failure. Alternatively, when a node fails, one or more other active nodes report to the control node, and the control node controls other active nodes to handle the failure, or sends the information of the failed node to other active nodes so that they can handle the failure.

[0034] A target wait event can refer to a wait event that waits for a response from a target node in the database cluster. The target node includes a faulty node and / or an active node. In this case, the wait event can refer to an event that is paused and in a waiting state.

[0035] In one embodiment, the target node includes an active node. When a faulty node exists in the cluster, the active node suspends its worker threads and / or session threads and enters a fault handling process. In this case, the target waiting event may include a waiting event for the active node to respond.

[0036] In one embodiment, the target node includes the faulty node EP2. The session SESS1 of node EP1 needs to modify data pages P1 and P2 in sequence. P1 has been modified and SESS1 also has W permission for data page P2. The Global Buffer Server (GBS) information of P2 is on the EP2 node. EP1 requests X blocking permission for data page P2 from EP2. SESS1 waits for a response message from EP2. Then the target wait event can include a wait event for the faulty node EP2 to respond.

[0037] The first data page targeted by the target wait event can be the data page that the target wait event needs to access or modify, such as the data pages P1 and P2 that need to be modified in node EP1 in the example above.

[0038] Generally, a database allocates a contiguous block of memory for data page caching to improve data access performance. All data access and modification are performed on the cached data pages. The same data page may be distributed across the caches of different nodes. That is, the same data page may exist in the data page caches of multiple nodes, and it is not guaranteed that the content of the data page in the caches of different nodes is exactly the same. The latest data page content is only stored in the caches of some nodes, while the caches of other nodes store a historical version of the data page.

[0039] Determining the data page cache of the first data page for which the target wait event is pending can be understood as determining the data page cache of the first data page within this active node. The data page cache of the first data page within this active node can be the latest data page cache of the first data page, or it can be a data page cache of a historical version of the first data page.

[0040] The method for determining the data page cache of the first data page targeted by the target wait event is not limited, as long as the data page cache of the first data page targeted by the target wait event can be determined. For example, the control node can monitor the running status of each node in the cluster, and when a fault occurs, the control node can determine the node involved in the fault and the first data page corresponding to the node, and then determine the data page cache of the first data page targeted by the target wait event.

[0041] Furthermore, target wait events include wait events for the target node in the database cluster to grant data page authorization, and / or wait events for the target node in the database cluster to return the targeted data page.

[0042] Target wait events include wait events for the target node in the database cluster to grant data page authorization. Waiting for the target node to grant data page authorization can be understood as waiting for the target node to grant the active node S or X blocking permissions for the data page, so that the active node can perform corresponding read or modify operations on the data page.

[0043] The target wait event includes wait events for the target node in the database cluster to return the targeted data page. Waiting for the target node to return the targeted data page can be understood as waiting for the target node to return the latest data page of the targeted data page to the active node, so that the active node can obtain the latest data page. The data page targeted by the target wait event in the active node can be the same version as the data page returned by the target node, or it can be a different version, depending on the data page returned by the target node. Preferably, the data page targeted by the target wait event in the active node can be a different version than the data page returned by the target node. That is, the active node can obtain the latest version of the data page from the target node only if the data page stored in its cache is not the latest version.

[0044] S120. Release the data page caches in this active node, except for the data page cache of the first data page.

[0045] This active node can be any active node in the shared storage database cluster. This active node can have a data page cache for the first data page, as well as caches for other data pages besides the first data page. Releasing the caches for other data pages besides the first data page in this active node ensures that there are no invalid data page caches in the active node's cache during fault handling, thus preventing a large number of disk reads / writes due to frequent readings of LSN values ​​from the disk.

[0046] For example, all data page caches in this active node can be searched. For each data page cache, it can be determined whether the data page cache is the data page cache of the first data page. If it is, the data page cache is retained; otherwise, the data page cache is released.

[0047] S130. Based on the first redo log of the second data page, restore the data page cache of the second data page, wherein the second data page is the data page with this active node as the recovery node, and the first redo log is recorded in the first log file on the disk.

[0048] When a fault occurs, multiple active nodes can simultaneously enter the fault handling process. Each active node restores the data page for which it has recovery authority. The recovery authority of an active node for a data page can be pre-defined according to actual needs. For example, different active nodes can have recovery authority for the same data page; alternatively, each active node can only have recovery authority for one or more data pages. That is, each data page can have only one active node with recovery authority, or multiple active nodes can have recovery authority for it. This invention does not limit the recovery authority of an active node for a data page.

[0049] The second data page can refer to the data page that is restored using this active node as the recovery node. That is, this active node has the right to restore the second data page and can restore the second data page using this active node as the recovery node.

[0050] The first log file can refer to a log file stored on disk, and the first redo log can be recorded in the first log file. The first redo log can record operations performed on the database, such as adding, deleting, modifying objects, or altering data.

[0051] Each time the first redo log is modified, a new LSN value is automatically generated. The LSN can be an integer value starting from zero, and its maximum value is determined by the number of bytes it corresponds to. This invention does not impose any restrictions on this. Each LSN value represents a physical transaction generated within the cluster system. A physical transaction can refer to a set of operations that modify physical data pages within the database. Each first redo log record corresponds to an LSN value. When modifying data, the LSN value is recorded in the header of the data page at the same time as generating the first redo log.

[0052] In a DMDSC cluster system, modifications to the same data page generate globally incrementing LSN values. The active node can restore the data page cache of the second data page based on the first redo log of that data page. The method for restoring the data page cache based on the first redo log of the second data page is not limited; for example, it can be done by redoing the first redo log of the second data page corresponding to the LSN values ​​in ascending order, thereby restoring the data page cache.

[0053] The technical solution of this invention first determines the data page cache of the first data page targeted by the target wait event. The target wait event is a wait event awaiting a response from a target node in the database cluster, including a failed node and / or an active node. Then, it releases the data page caches of the active node other than the data page cache of the first data page. Finally, it restores the data page cache of the second data page according to the first redo log of the second data page, where the second data page is the data page for which the active node is the recovery node, and the first redo log is recorded in a first log file on the disk. In the event of node failure, by releasing the data page caches other than the data page cache of the first data page and then restoring the data page according to the first redo log of the data page for which the active node is the recovery node, frequent disk reads / writes are avoided, improving the recovery efficiency of data pages in a shared storage database cluster.

[0054] Example 2

[0055] Figure 2This is a flowchart of a data page recovery method according to Embodiment 2 of the present invention, which is an optimization based on Embodiment 1 described above. In this embodiment, the situations before determining the data page cache of the first data page targeted by the target wait event, and after recovering the data page cache of the second data page according to the first redo log of the second data page, are specified.

[0056] In this embodiment, before determining the data page cache of the first data page targeted by the target wait event, the method may further include: determining the first target wait event in the active node; after determining the first target wait event in the active node, the method may further include: determining the second target wait event in the active node; before determining the second target wait event in the active node, the method may further include: recording the modification of the target first data page by the first target wait event to the second log file, and releasing the read and write permissions of the first target wait event for the target first data page; before recording the modification of the target first data page by the first target wait event to the second log file through the worker thread of the first target wait event, and releasing the read and write permissions of the first target wait event for the target first data page, the method may further include: waking up the first target wait event.

[0057] In this embodiment, before determining the data page cache of the first data page to which the target waiting event is targeted, the method further includes: pausing each target thread in this active node.

[0058] In this embodiment, after restoring the data page cache of the second data page according to the first redo log of the second data page, the method further includes: waking up the second target wait event; and re-executing the second target wait event through the worker thread of the second target wait event according to the second redo log of the second target wait event, wherein the second redo log is recorded in the second log file.

[0059] In this embodiment, after restoring the data page cache of the second data page according to the first redo log of the second data page, the method further includes: adjusting the target thread in the current active node that is in a paused state to a running state.

[0060] For details not covered in this embodiment, please refer to Embodiment 1.

[0061] like Figure 2 As shown, the data page recovery method provided in Embodiment 2 of the present invention includes:

[0062] S201. Pause all target threads in this activity node.

[0063] The target threads include worker threads and / or session threads. Worker threads can refer to the core threads in the DMDSC cluster system. Worker threads retrieve tasks from the task queue and process them according to their type, handling all related operations on the actual data. Session threads can refer to the threads in the DMDSC cluster system responsible for establishing sessions.

[0064] Pausing all target threads in this active node will stop all target threads in this active node from working, thus allowing this active node to enter the fault handling process.

[0065] S202. Determine the first target waiting event in this activity node.

[0066] The first target waiting event includes events awaiting a response from the target node in the current database cluster. The method for determining the first target waiting event in this active node is not limited, as long as the first target waiting event in this active node can be determined. For example, the control node can monitor the operating status of each node in the cluster, and when a fault occurs, the control node can determine the nodes involved in the fault, thereby determining the target node in the cluster that this active node needs to wait for a response from, and thus determining the first target waiting event in this active node. Alternatively, this active node can determine the first target waiting event in this active node based on the processing progress of each waiting event in this active node.

[0067] In one embodiment, the target node includes the faulty node EP2. The session SESS1 of node EP1 needs to modify data pages P1 and P2 in sequence. P1 has been modified and SESS1 also has W permission for data page P2. The global latch service (GBS) information of P2 is on the EP2 node. EP1 requests X blocking permission for data page P2 from EP2. SESS1 waits for the response message from EP2. Therefore, the waiting event of the active node waiting for the faulty node EP2 to respond can be regarded as a first target waiting event in the active node.

[0068] S203, Awaken the first target waiting event.

[0069] In this context, "wake-up" can refer to terminating the waiting for an event, allowing the thread to continue running. Waking up the thread waiting for the first target event allows the thread corresponding to that first target event to continue running.

[0070] S204. Record the modification of the target's first data page by the first target wait event to the second log file, and release the read and write permissions of the first target wait event for the target's first data page.

[0071] The second log file is stored in the cache. This second log file can be used to record modifications made to the corresponding data page by events such as the first target wait event before writing to disk. The target first data page is the data page targeted by the first target wait event.

[0072] The method of recording the modifications made by the first target wait event to the first target first data page to the second log file and releasing the read and write permissions of the first target wait event to the first target first data page is not limited. For example, the worker thread of the first target wait event can record the modifications made by the first target wait event to the first target first data page to the second log file and release the read and write permissions of the first target wait event to the first target first data page.

[0073] In a DMDSC cluster system, when multiple sessions (SESS) within a node access or modify a data page, they need to acquire not only the LBS permissions for that data page but also read (R) / write (W) permissions. Assuming session SESS1 has read (R) permissions for data page P1, if session SESS2 requests read (R) permissions for data page P1, the request will succeed immediately. However, if session SESS1 has read (R) permissions for data page P1, and session SESS2 requests write (W) permissions for data page P1, it must wait for session SESS1 to release its read (R) permissions before successfully requesting them. Similarly, if session SESS1 has write (W) permissions for data page P1, and session SESS2 requests either read (R) or write (W) permissions for data page P1, it must wait for session SESS1 to release its write (W) permissions before successfully requesting them. Therefore, releasing the read / write permissions for the target first data page during the first target wait event allows other sessions within the currently operating node to request read / write permissions for the target first data page.

[0074] In one embodiment, the target node includes a faulty node EP2. Session SESS1 of node EP1 needs to modify data pages P1 and P2 sequentially. P1 has already been modified, and SESS1 also has write permissions for data page P2. The Global Latch Service (GBS) information for P2 is on node EP2. EP1 requests write permissions for data page P2 from EP2, and SESS1 waits for a response message from EP2. The first target waiting event, the modification of the target's first data page, can be the modification operation of session SESS1 of node EP1 on P1. The modification operation of session SESS1 of node EP1 on P1 is recorded in a second log file. Session SESS1 releases write permissions for P1 and P2, allowing other sessions within the node to request read and write permissions for data pages P1 and P2.

[0075] Furthermore, the modifications made to the first data page of the target by the first target wait event are recorded in the second log file, and the read and write permissions of the first target wait event for the first data page of the target are released, including:

[0076] The worker thread of the first target wait event records the modifications made by the first target wait event to the first target first data page to the second log file, and releases the read and write permissions of the first target wait event to the first target first data page.

[0077] Among them, the worker thread of the first target waiting event is responsible for the relevant operations of the first target waiting event. The worker thread of the first target waiting event records the modification of the first target first data page of the target to the second log file and releases the read and write permissions of the first target waiting event for the first target first data page of the target, so as to facilitate the subsequent fault handling process.

[0078] S205. Determine the second target waiting event in this activity node.

[0079] The second target wait event includes the event that waits for the first target wait event to grant read / write permissions to the target first data page, where the target first data page is the data page targeted by the first target wait event.

[0080] In one embodiment, the target node includes the faulty node EP2. Session SESS1 of node EP1 needs to modify data pages P1 and P2 sequentially. P1 has already been modified, and SESS1 also has W permissions for data page P2. The Global Latch Service (GBS) information for P2 is on node EP2. EP1 requests X blocking permissions for data page P2 from EP2, and SESS1 waits for a response message from EP2. Based on this, SESS2 of node EP1 also needs to modify data page P1. SESS2 needs to wait for SESS1 to complete the modifications to data pages P1 and P2 and release W permissions for P1 and P2. At this time, the second target wait event can include the event waiting for the first target wait event regarding W permissions for data pages P1 and P2.

[0081] S206. Determine the data page cache of the first data page to which the target wait event is located.

[0082] S207. Release the data page caches in this active node, except for the data page cache of the first data page.

[0083] S208. Based on the first redo log of the second data page, restore the data page cache of the second data page.

[0084] S209. Wake up the second target wait event; re-execute the second target wait event through the worker thread of the second target wait event according to the second redo log of the second target wait event, wherein the second redo log is recorded in the second log file.

[0085] Waking up the second target waiting event can be understood as terminating the waiting event, allowing the thread corresponding to the second target waiting event to continue running.

[0086] The second redo log for the second target wait event refers to the modification records made by the current operation corresponding to the second target wait event. The second redo log is recorded in the second log file. By having the worker thread for the second target wait event re-execute the second target wait event based on the second redo log, it can be understood as having the worker thread for the second target wait event re-request read / write permissions for the target's first data page.

[0087] Furthermore, the second target wait event is re-executed based on the second redo log of the second target wait event, including:

[0088] If the second redo log of the second target wait event has not yet been written to the first log file, the second target wait event is re-executed based on the second redo log of the second target wait event.

[0089] The second redo log of the second target wait event has not yet been written to the first log file. This can be understood as the second redo log of the second target wait event not being flushed to disk. Therefore, the second target wait event can be re-executed based on the second redo log of the second target wait event, so that the cluster system can continue the operations before the failure occurred and complete the failure handling.

[0090] S210. Adjust the target thread in this activity node that is in a paused state to a running state.

[0091] Adjusting a target thread that is paused in this active node to a running state can be understood as resuming the execution of a target thread that was paused due to fault handling, indicating that the fault handling of this active node has been completed. This target thread can include worker threads and / or session threads.

[0092] The technical solution of this invention, taking data page recovery of any active node in a shared storage database cluster as an example, specifies the situation before the data page cache of the first data page targeted by the target waiting event is determined, and after the data page cache of the second data page is recovered according to the first redo log of the second data page, making the data page recovery process clearer and improving the data page recovery efficiency in the shared storage database cluster.

[0093] The present invention will be described by way of example below:

[0094] This invention provides a method for recovering data pages during fault handling, the specific process of which is as follows:

[0095] 1. In a DSC database cluster (i.e., shared storage database cluster) environment, after a node failure, the remaining active nodes enter the fault handling process.

[0096] 2. All remaining active nodes suspend their worker threads and session threads (i.e., target threads). Due to the node failure, based on the data page locking logic, there may be multiple wait events in the database at this time. Among them, all wait events waiting for the response from the failed node are called wait event 1 (i.e., the first target wait event), and wait event 1 is registered in the global cache.

[0097] For example, assuming the EP2 node fails, the following waiting events may occur (this invention is not limited to these waiting events, they are just examples):

[0098] a. SESS1 on EP1 node needs to modify data pages P1 and P2 sequentially. P1 has already been modified, and SESS1 also has W permission for data page P2. The GBS information of P2 is on EP2 node. EP1 requests X blocking permission for data page P2 from EP2. SESS1 waits for a response message from EP2, which is called wait event 1. Wait event 1 is registered in the global cache.

[0099] b. In scenario a, SESS2 of EP1 node also needs to modify data page P1. SESS2 needs to wait for SESS1 to release the W permission for data page P1 (SESS1 will release the W permission for P1 and P2 only after it has modified P1 and P2). Since SESS2 does not directly wait for EP2's response message, this wait event is not included in wait event 1, and there is no need to register this wait event in the global cache.

[0100] 3. Wake up the wait event in the global cache, i.e., wait event 1. After wait event 1 is woken up, register the information of the data page currently being used by the operation (i.e., the target first data page) (e.g., data pages P1 and P2 in scenario a). Record the modifications made by the current operation in the REDO log file (e.g., record the modifications made by the SESS1 session to data page P1 in the REDO log file), and then release the R / W permissions of the current operation on the data page (e.g., the SESS1 session releases the W permissions on data pages P1 and P2), i.e., step S204, and then continue to wait for the subsequent process. In addition to wait event 1, other wait events in the cluster that are naturally woken up also need to continue to wait for the subsequent process. All wait events at this time are called wait event 2 (i.e., the second target wait event), and wait event 2 is registered in the global cache.

[0101] For example, in this step, since the SESS1 session released the W permission for data pages P1 and P2, SESS2 is naturally awakened and continues to wait for subsequent processes. This wait event is included in wait event 2 and registered in the global cache.

[0102] 4. Scan all data page caches in the system, retain the data page caches registered in step 3 (such as P1 and P2 in step 3), and directly release the data page caches that have not been registered (i.e., steps S206 and S207).

[0103] 5. Unregistered data page caches may have been modified previously but not yet flushed to disk. In this case, the data page modification operation (i.e., the first redo log) has already been recorded in the online REDO log file (i.e., the first log file) (the online REDO log file is the REDO log file that has already been flushed to disk; this is the normal data modification process). Redo the online REDO logs of all nodes to restore this type of data page cache (i.e., step S208). After the redo is completed, wake up all waiting events 2. After waiting events 2 are woken up, if there are REDO logs that have not yet been flushed to disk (i.e., the second redo log), redo the REDO log first. After the redo is completed, continue with the subsequent event process (i.e., step S209).

[0104] For example, when SESS1 and SESS2 are woken up, SESS1 redoes the REDO log of the current operation (which has not yet been flushed to disk). During this process, it restores write permissions to data pages P1 and P2 and re-initiates an X block request for P2. When SESS2 is woken up, it re-requests write permissions to P1, but still needs to wait for SESS1 to release write permissions to P1.

[0105] The method for recovering data pages during fault handling provided by this invention discards all cached data pages except those currently in use, then redoes the REDO logs of all nodes, thereby recovering the data pages. This method avoids frequent disk reads / writes and can achieve higher fault handling efficiency when there are a large number of invalid data pages.

[0106] Example 3

[0107] Figure 3 This is a schematic diagram of a data page recovery device according to Embodiment 3 of the present invention. This embodiment is applicable to the recovery of data pages when a node fails in a shared storage database cluster. Figure 3 As shown, the specific structure of the device includes:

[0108] The data page cache determination module 21 is used to determine the data page cache of the first data page targeted by the target wait event, wherein the target wait event is a wait event waiting for a target node in the database cluster to respond, and the target node includes a faulty node and / or an active node.

[0109] Data page cache release module 22 is used to release the data page cache of other data pages in this active node except for the data page cache of the first data page;

[0110] The data page cache recovery module 23 is used to recover the data page cache of the second data page according to the first redo log of the second data page, wherein the second data page is the data page with the current active node as the recovery node, and the first redo log is recorded in the first log file on the disk.

[0111] The data page recovery device provided in this embodiment first determines the data page cache of the first data page targeted by the target wait event through the data page cache determination module 21. The target wait event is a wait event awaiting a response from a target node in the database cluster, including a failed node and / or an active node. Then, the data page cache release module 22 releases the data page caches of the active node other than the data page cache of the first data page. Finally, the data page cache recovery module 23 recovers the data page cache of the second data page according to the first redo log of the second data page. The second data page is the data page for which the active node is the recovery node, and the first redo log is recorded in a first log file on the disk. In the event of node failure, by releasing the data page caches other than the data page cache of the first data page and then recovering the data page according to the first redo log of the data page for which the active node is the recovery node, frequent disk reads / writes are avoided, improving the recovery efficiency of data pages in the shared storage database cluster.

[0112] Furthermore, the target wait events in the data page cache determination module 21 include wait events for the target node in the database cluster to grant data page authorization, and / or wait events for the target node in the database cluster to return the target data page.

[0113] Furthermore, the target waiting event includes a first target waiting event, and the device also includes:

[0114] The first target wait event determination module is used to determine the first target wait event in the active node before determining the data page cache of the first data page to which the target wait event is targeted. The first target wait event includes the event that the target node in the current waiting database cluster will respond.

[0115] Furthermore, the target waiting event also includes a second target waiting event, and the device further includes:

[0116] The second target waiting event determination module is used to determine the second target waiting event in the current activity node after determining the first target waiting event in the current activity node. The second target waiting event includes the event of waiting for the first target waiting event to grant read / write permissions to the target first data page, where the target first data page is the data page targeted by the first target waiting event.

[0117] Furthermore, the device also includes:

[0118] The read / write permission release module is used to record the modification of the target first data page by the first target waiting event to the target first data page in the second log file before determining the second target waiting event in this activity node, and to release the read / write permission of the first target waiting event for the target first data page. The second log file is stored in the cache.

[0119] Furthermore, the read / write permission release module is specifically used for:

[0120] The worker thread of the first target wait event records the modifications made by the first target wait event to the first target first data page to the second log file, and releases the read and write permissions of the first target wait event to the first target first data page.

[0121] Furthermore, before the worker thread of the first target wait event records the modification of the target first data page by the first target wait event to the second log file, and releases the read and write permissions of the first target wait event for the target first data page, the device further includes:

[0122] The first target waiting event wake-up module is used to wake up the first target waiting event.

[0123] Furthermore, the device also includes:

[0124] The second target wait event wake-up module is used to wake up the second target wait event after the data page cache of the second data page is restored according to the first redo log of the second data page.

[0125] The second target wait event execution module is used to re-execute the second target wait event according to the second redo log of the second target wait event through the worker thread of the second target wait event. The second redo log is recorded in the second log file.

[0126] Furthermore, the second target waiting event execution module is specifically used for:

[0127] If the second redo log of the second target wait event has not yet been written to the first log file, the second target wait event is re-executed based on the second redo log of the second target wait event.

[0128] Furthermore, the device also includes:

[0129] The target thread pause module is used to pause each target thread in this active node before determining the data page cache of the first data page to which the target wait event is targeted. The target threads include worker threads and / or session threads.

[0130] Furthermore, the device also includes:

[0131] The adjustment module is used to adjust the target thread in the current active node from a paused state to a running state after restoring the data page cache of the second data page based on the first redo log of the second data page.

[0132] The data page recovery device provided in this embodiment of the invention can execute the data page recovery method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0133] Example 4

[0134] Figure 4 This is a schematic diagram of an electronic device implementing the data page recovery method of an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0135] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0136] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0137] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as data page recovery methods.

[0138] In some embodiments, the data page recovery method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data page recovery method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the data page recovery method by any other suitable means (e.g., by means of firmware).

[0139] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0140] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0141] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0142] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0143] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0144] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0145] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0146] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for recovering data pages, characterized in that, The method is executed by an active node in the database cluster, and the method includes: The data page cache of the first data page to which the target wait event is targeted is determined, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a faulty node and / or an active node; Release the cached data pages in this active node, excluding the cached data page of the first data page. Based on the first redo log of the second data page, restore the data page cache of the second data page, wherein the second data page is the data page with this active node as the recovery node, and the first redo log is recorded in the first log file on the disk; The target wait events include wait events for the target node in the database cluster to authorize data pages, and / or wait events for the target node in the database cluster to return the target data page.

2. The method according to claim 1, characterized in that, The target wait event includes a first target wait event, and before determining the data page cache of the first data page to which the target wait event is targeted, it further includes: Identify the first target waiting event in this active node, wherein the first target waiting event includes the event that is currently waiting for a response from the target node in the database cluster.

3. The method according to claim 2, characterized in that, The target waiting event also includes a second target waiting event, and after determining the first target waiting event in this active node, it further includes: Determine the second target waiting event in this activity node, wherein the second target waiting event includes an event that waits for the first target waiting event to grant read / write permissions for the target first data page, and the target first data page is the data page targeted by the first target waiting event.

4. The method according to claim 3, characterized in that, Before determining the second target waiting event in this activity node, the following is also included: The modification of the target first data page by the first target wait event is recorded in the second log file, and the read and write permissions of the first target wait event for the target first data page are released. The second log file is stored in the cache.

5. The method according to claim 4, characterized in that, The step of recording the modification of the target first data page by the first target wait event to the second log file and releasing the read and write permissions of the first target wait event for the target first data page includes: The worker thread of the first target wait event records the modification of the target first data page by the first target wait event to the second log file, and releases the read and write permissions of the first target wait event for the target first data page.

6. The method according to claim 5, characterized in that, Before the worker thread of the first target wait event records the modification of the target first data page by the first target wait event to the second log file and releases the read and write permissions of the first target wait event for the target first data page, the method further includes: The first target is awakened to await the event.

7. The method according to claim 3, characterized in that, After restoring the data page cache of the second data page based on the first redo log of the second data page, the method further includes: Awaken the second target waiting event; The worker thread of the second target wait event re-executes the second target wait event according to the second redo log of the second target wait event, wherein the second redo log is recorded in the second log file.

8. The method according to claim 7, characterized in that, The step of re-executing the second target wait event according to the second redo log of the second target wait event includes: If the second redo log of the second target wait event has not yet been written to the first log file, then the second target wait event is re-executed according to the second redo log of the second target wait event.

9. The method according to any one of claims 1-8, characterized in that, Before determining the data page cache of the first data page to which the target wait event is targeted, the method further includes: Pause all target threads in this activity node, where the target threads include worker threads and / or session threads.

10. The method according to claim 9, characterized in that, After restoring the data page cache of the second data page based on the first redo log of the second data page, the method further includes: Adjust the target thread that is in a paused state in this activity node to a running state.

11. A data page recovery device, characterized in that, include: A data page cache determination module is used to determine the data page cache of the first data page targeted by the target wait event, wherein the target wait event is a wait event waiting for a response from a target node in the database cluster, and the target node includes a faulty node and / or an active node; The data page cache release module is used to release the data page cache of other data pages in this active node, except for the data page cache of the first data page. The data page cache recovery module is used to recover the data page cache of the second data page according to the first redo log of the second data page, wherein the second data page is the data page with the current active node as the recovery node, and the first redo log is recorded in the first log file on the disk; The target wait events in the data page cache determination module include wait events for the target node in the database cluster to grant data page authorization, and / or wait events for the target node in the database cluster to return the target data page.

12. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the data page recovery method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the data page recovery method according to any one of claims 1-10.

Images