CN117130871B

CN117130871B - Parallel playback method and device for database logs and nonvolatile storage medium

Info

Publication number: CN117130871B
Application number: CN202311399369.XA
Authority: CN
Inventors: 李传成
Original assignee: Primitive Data Beijing Information Technology Co ltd
Current assignee: Primitive Data Beijing Information Technology Co ltd
Priority date: 2023-10-26
Filing date: 2023-10-26
Publication date: 2024-04-05
Anticipated expiration: 2043-10-26
Also published as: CN117130871A

Abstract

The application discloses a parallel playback method and device of database logs and a nonvolatile storage medium. Wherein the method comprises the following steps: receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; and executing parallel playback operation on the log sequence according to the waiting strategy. The method solves the technical problem that a user needs to wait for a long time when carrying out query operation because the snapshot is destroyed in the parallel playback method of WAL logs in the related technology.

Description

Parallel playback method and device for database logs and nonvolatile storage medium

Technical Field

The application relates to the technical field of databases, in particular to a parallel playback method and device for database logs and a nonvolatile storage medium.

Background

In the related art, the speed of the Write-Ahead log (WAL) recording of the standby library is increased by a multithreaded parallel playback (redox) method. Since the task busyness and the execution efficiency of each thread in the process of multithreading parallel redox are different, the situation exists: the multiple threads execute the redox of a section of WAL log in parallel, wherein one thread redox to a first position of the WAL log and the other thread has executed the redox of a second position of the WAL log, and in the section of WAL log, the first position is positioned before the second position, a redox operation of 'establishing snapshot' is executed in the first position, and a redox operation of 'cleaning up data storage space' type log is executed in the second position; in this case, when a query thread is connected to the standby library to perform a query, a snapshot is first attempted, and since the redox operation at the second location precedes the redox operation at the second location, the snapshot established at the first location is destroyed, and the query thread needs to wait for a point where a consistent snapshot can be obtained to obtain the snapshot, thereby completing the query operation. Therefore, the parallel playback method of the WAL log in the related art has the problem of influencing the capability of the database backup to process the client connection, resulting in the reduction of the query performance of the database backup.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the application provides a parallel playback method and device of database logs and a nonvolatile storage medium, which at least solve the technical problem that a user needs to wait for a long time when carrying out query operation because of the condition of destroying snapshots in the parallel playback method of WAL logs in the related technology.

According to an aspect of the embodiments of the present application, there is provided a parallel playback method of database logs, including: receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; and executing parallel playback operation on the log sequence according to the waiting strategy.

Optionally, before performing the parallel playback operation on the log sequence according to the waiting policy, the method includes: reading a log sequence, and distributing a plurality of pre-written logs in the log sequence to a plurality of playback threads, wherein the playback threads are used for executing playback operations; detecting a playback progress of each playback thread of the plurality of playback threads, wherein the playback progress is used for indicating a type of pre-written log that each playback thread is currently executing a playback operation; a wait policy corresponding to the type of the pre-write log is determined.

Optionally, distributing the plurality of pre-written logs in the log sequence to a plurality of playback threads, comprising: acquiring an identifier of each of a plurality of pre-written logs, wherein the identifier of each pre-written log is used for indicating a database transaction to which each pre-written log belongs; the remainder of the hash value of the identifier of each pre-written log relative to the number of playback threads is determined as the target identification.

Optionally, distributing the plurality of pre-written logs in the log sequence to the plurality of playback threads further comprises: the pre-written log without the identifier is distributed to a target thread, wherein the target thread is a thread executed by a database management system.

Optionally, the types of pre-written logs include: the method comprises the steps of generating a first type log when a database executes a data insertion operation, generating a second type log when the database executes a deletion operation, generating a third type log when the database executes an operation for cleaning a data storage space, generating a fourth type log when the database executes an update operation, and generating a fifth type log corresponding to a transaction commit operation.

Optionally, the waiting policy corresponding to the type of the pre-write log includes: if the pre-written log of the playback operation to be executed is any one of the first type log, the second type log, the fourth type log and the fifth type log, determining that the waiting strategy is not needed to wait, and continuing to execute the playback operation; if the pre-written log of the playback operation to be executed is a third type log, acquiring a first identifier and a second identifier, wherein the first identifier is the serial number of a database transaction currently executed by the database, the second identifier is the serial number of a target transaction, and the target transaction is the database transaction with the largest serial number in a plurality of database transactions executed by the database; and determining a waiting strategy corresponding to the third type log according to the first identifier and the second identifier.

Optionally, determining a waiting policy corresponding to the third type log according to the first identifier and the second identifier includes: if the value of the first identifier is larger than that of the second identifier, the waiting strategy corresponding to the third type log is that waiting is not needed, and playback operation is continuously executed; if the value of the first identifier is smaller than that of the second identifier, acquiring a first log sequence number and a second log sequence number, wherein the first log sequence number is the sequence number of a third type log of the current playback operation to be executed, the first log sequence number is used for indicating the position of the third type log of the current playback operation to be executed in the log sequence, the second log sequence number is the log sequence number of a fifth type log of the current playback operation to be executed, and the second log sequence number is used for indicating the position of the fifth type log of the current playback operation to be executed in the log sequence; and determining a waiting strategy corresponding to the third type log according to the first log serial number and the second log serial number.

Optionally, determining a waiting policy corresponding to the third type log according to the first log serial number and the second log serial number includes: if the first log sequence number is smaller than the second log sequence number, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation; if the first log serial number is larger than the second log serial number, determining that the waiting strategy corresponding to the third type log is to pause the execution of the playback operation; if the second log serial number does not exist, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation.

Optionally, after the parallel playback operation is suspended, performing the playback operation on the plurality of fifth type logs until any one of the preset conditions is satisfied, and continuing to perform the playback operation of the third type log; the preset conditions comprise: the first log sequence number is less than the second log sequence number, the fifth type log in the log sequence has performed a playback operation, and the value of the first identifier is greater than the value of the second identifier.

According to another aspect of the embodiments of the present application, there is also provided a parallel playback apparatus for database logs, including: the receiving module is used for receiving a log sequence sent by the database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database of the database host according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; the system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; and the execution module is used for executing parallel playback operation on the log sequence according to the waiting strategy.

According to another aspect of the embodiments of the present application, there is further provided a nonvolatile storage medium, in which a computer program is stored, where a device in which the nonvolatile storage medium is located executes the above-described parallel playback method of the database log by running the computer program.

According to another aspect of the embodiments of the present application, there is also provided an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described parallel playback method of the database log by the computer program.

In the embodiment of the application, a log sequence sent by a database host is received, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; according to the method for executing parallel playback operation on the log sequence by the waiting strategy, the problem of snapshot invalidation is introduced into the playback (redox) operation of the database backup library, and in the redox operation process, the redox operation is caused to push a fast thread to wait for other threads to execute the redox operation of the snapshot, so that the database backup library cannot generate snapshot invalidation, the purpose of avoiding the 'empty window' of the query service is achieved, the technical effect of improving the query performance of the database backup library is achieved, and the technical problem that a user needs to wait for a long time when the user performs the query operation because the snapshot is destroyed in the parallel playback method of WAL logs in the related technology is solved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a schematic diagram of a log sequence according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a multi-threaded parallel playback according to an embodiment of the present application;

FIG. 3 is a block diagram of the hardware architecture of a computer terminal (or mobile device) for implementing a parallel playback method of database logs according to an embodiment of the present application;

FIG. 4 is a flow chart of steps of a method for parallel playback of database logs according to an embodiment of the present application;

FIG. 5 is a block diagram of a parallel playback apparatus of database logs according to an embodiment of the present application;

fig. 6 is a workflow diagram of a database log parallel playback apparatus according to an embodiment of the present application.

Detailed Description

In order to make the present application solution better understood by those skilled in the art, the following description will be made in detail and with reference to the accompanying drawings in the embodiments of the present application, it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

For better understanding of the embodiments of the present application, technical terms related in the embodiments of the present application are explained below:

database snapshot: the snapshot referred to in this embodiment is a database snapshot, which is a backup mode of a database, and is a static copy of the database at a specific point in time. A snapshot may contain all the data and state of the database, including tables, indexes, views, stored procedures, and the like.

Playback (redox) operation: the redox operations mentioned in the embodiment of the application are all implemented in a database, and the redox operation of the database refers to that the modification operation made by the submitted transaction is re-executed once so as to ensure the consistency and the durability of the data; non-persisted modification operations may be reapplied to the database through a redox operation, which is typically accomplished by applying records in the pre-written log to the database one by one.

Parallel: in the embodiment of the application, one WAL log can be divided into a plurality of sections of logs, and the redox operation is performed on WAL logs of different sections in a multithreaded parallel mode.

Transaction/database transaction: refers to an execution unit of a series of database operations that includes a set of database operations (e.g., insert, update, delete).

Transaction commit operations: the database permanently stores all modification operations (insert, delete, update, etc.) into the database.

In the related art, the WAL log generated by the database is usually used for synchronizing the primary and secondary data, and the database secondary database redos/plays back the WAL record generated by the database primary database (database host) in a specific manner, thereby achieving the purpose of data synchronization; single-threaded redox WAL logs suffer from redox performance problems, and therefore multithreading parallel redox is typically employed to speed up the synchronization of WAL records by the standby. FIG. 1 is a schematic diagram of a log sequence, as shown in FIG. 1, consisting of 32 pre-written logs (WALs) with log sequence numbers (Log Sequence Number, LSNs) of 1-32, wherein each pre-written log (WAL) records an operation occurring in a database, the pre-written logs (WALs) are combined into the WAL log sequence shown in FIG. 1 according to a generated time sequence, so that 32 files to be subjected to a redox operation exist in the WAL log sequence, FIG. 2 is a schematic diagram of multi-thread parallel playback, as shown in FIG. 2, a redox operation is performed on the pre-written logs shown in FIG. 1 through 4 playback threads and a target thread (xactrworks) executed by a database management system, wherein a first playback thread (redox 1), a second playback thread (redox 2), a third playback thread (redox 3) and a fourth playback thread (redox 4) perform a redox operation recorded in the WAL log in association with modification of a data page; operations recorded in the WAL log associated with modification of the data page include: INSERT (INSERT) operations, DELETE (DELETE) operations, clear data storage operations (VACUUM), and UPDATE (UPDATE) operations. Each time the above-described modification operation is performed, a corresponding type of WAL log is generated in the database, for example, an I-type WAL log (i.e., a first type log) is generated when the database performs an INSERT (INSERT) operation, a D-type WAL log (i.e., a second type log) is generated when the database performs a DELETE (DELETE) operation, a V-type WAL log (i.e., a third type log) is generated when the database performs an operation (VACUUM) to clean up the data storage space, and a U-type WAL log (i.e., a fourth type log) is generated when the database performs an UPDATE (UPDATE) operation. The xactrworks thread is responsible for reading and distributing (dispatch) WAL records and performing redox operations (xactredo) on WAL logs associated with database transactions. As shown in fig. 2, the xactrum thread distributes each pre-written log (WAL) (LSN 1-LSN 32) in the log sequence shown in fig. 1 to four redox threads, i.e., redox 1-redox 4, and xactrum threads according to a distribution principle (dispatch), wherein each of the redox 1-redox 4 and xactrum threads is capable of executing a redox operation on the WAL log distributed to its thread, i.e., each of the redox 1-redox 4 and xactrum threads reads an operation recorded in each of the WAL logs distributed to its thread, and then repeatedly executes the operation recorded in the WAL log once. For example, as shown in fig. 2, the WAL logs with log serial numbers 12, 22 and 32 (i.e., LSN12, LSN22 and LSN 32) are logs of a transaction type (i.e., xid type log) generated after a database performs a transaction, where LSN12 is a WAL log (xid 1) generated after a transaction 1 is performed, LSN22 is a WAL log (xid 2) generated after a transaction 2 is performed, and LSN32 is a WAL log (xid 3) generated after a transaction 3 is performed, so that a target thread (xactwork) performed by the database management system distributes WAL logs with log serial numbers 12, 22 and 32 (i.e., LSN12, LSN22 and LSN 32) to xactwork threads; and distributes the WAL logs with log sequence numbers 5 and 30 (i.e., LSN5, LSN 30) to redox thread 2 (i.e., redox 2); the WAL logs with log sequence numbers 3 and 20 (namely LSN3 and LSN 20) are distributed to a redox thread 3 (namely redox 3); the WAL log indicated by the remaining log sequence numbers (i.e., the log sequence numbers other than LSN3, LSN5, LSN12, LSN20, LSN22, LSN30, LSN 32) is dispatched to the redox thread 1 (i.e., redox 1), and the redox thread 4 (i.e., redox 4) is not dispatched the WAL log, and therefore, the WAL log to be executed by the redox thread 4 is "NULL". When the database runs, the xactrum thread waits for the execution progress of all the redox threads (redox 1-redox 4) to exceed the progress of the xactrum thread itself, for example, when the minimum log serial number corresponding to the WAL log to be redox in the xactrum thread shown in fig. 2 is LSN12, the database management system waits for the redox operation to be executed in the redox 1-redox 4 when the log serial number of the WAL log is greater than 12, and then executes the redox of the WAL log with the log serial number of LSN 12. Therefore, when parallel playback in the scene shown in fig. 2 is performed according to the method in the related art, there may be the following cases: the minimum log sequence number in the xactwork thread is 12, the minimum log sequence number greater than the LSN12 in the redox work1 is 13, the minimum log sequence number greater than the LSN12 in the redox work2 is 30, and the minimum log sequence number greater than the LSN12 in the redox work2 is 20, because the xactwork thread needs to wait until the playback progress of other threads is greater than the execution progress of the xactwork thread itself, when the xactwork thread starts executing the redox of the log of the LSN12, the thread redox work2 has already executed the redox of the log of the LSN30, as shown in fig. 2, the log of the LSN30 is a V-type log, that is, the redox operation of the log of the LSN30 executed by the redox work2 breaks the snapshot of the thread generated when the xactwork is executed by the LSN 12; if the database backup receives the query instruction for obtaining the snapshot at this time, the database backup needs to wait for the xactwork thread to execute until the next time point for establishing the snapshot, in the scenario shown in fig. 2, needs to wait for the xactwork thread to execute the redox of the log of the LSN22, and other threads (redox 1-redox 4) do not execute the redox of the V-type log, so in the related art, there is a problem that when a user sends a query instruction to the database backup to obtain the snapshot through the client, the user needs to wait for a long time, and cannot immediately obtain the snapshot, and further, there is a problem that the query performance of the database backup is reduced due to the need to wait until a point for obtaining the consistent snapshot. To address this problem, a related solution is provided in embodiments of the present application.

According to embodiments of the present application, there is provided a method embodiment of a parallel playback method of database logs, it being noted that the steps illustrated in the flowchart of the figures may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is illustrated in the flowchart, in some cases the steps illustrated or described may be performed in an order other than that illustrated herein.

The method embodiments provided by the embodiments of the present application may be performed in a mobile terminal, a computer terminal, or similar computing device. Fig. 3 shows a hardware block diagram of a computer terminal (or mobile device) for implementing a parallel playback method of database logs. As shown in fig. 3, the computer terminal 30 (or mobile device 30) may include one or more (shown as 302a, 302b, … …,302 n) processors 302 (the processors 302 may include, but are not limited to, a microprocessor MCU, a programmable logic device FPGA, etc. processing means), a memory 304 for storing data, and a transmission means 306 for communication functions. In addition, the method may further include: a display, an input/output interface (I/O interface), a Universal Serial BUS (USB) port (which may be included as one of the ports of the BUS), a network interface, a power supply, and/or a camera. It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 3 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, the computer terminal 30 may also include more or fewer components than shown in FIG. 3, or have a different configuration than shown in FIG. 3.

It should be noted that the one or more processors 302 and/or other data processing circuits described above may be referred to generally herein as "data processing circuits. The data processing circuit may be embodied in whole or in part in software, hardware, firmware, or any other combination. Furthermore, the data processing circuitry may be a single stand-alone processing module, or incorporated in whole or in part into any of the other elements in the computer terminal 3 (or mobile device). As referred to in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of the path of the variable resistor termination to interface).

The memory 304 may be used to store software programs and modules of application software, such as program instructions/data storage devices corresponding to the parallel playback method of the database log in the embodiment of the present application, and the processor 302 executes the software programs and modules stored in the memory 304, thereby executing various functional applications and data processing, that is, implementing the parallel playback method of the database log. Memory 304 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 304 may further include memory remotely located relative to the processor 302, which may be connected to the computer terminal 30 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission means 306 is used for receiving or transmitting data via a network. The specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 30. In one example, the transmission means 306 comprises a network adapter (Network Interface Controller, NIC) that can be connected to other network devices via a base station to communicate with the internet. In one example, the transmission device 306 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.

The display may be, for example, a touch screen type Liquid Crystal Display (LCD) that may enable a user to interact with a user interface of the computer terminal 30 (or mobile device).

In the above-mentioned operating environment, the embodiment of the present application provides a parallel playback method of a database log, and fig. 4 is a step flowchart of the parallel playback method of a database log provided according to the embodiment of the present application, as shown in fig. 4, where the method includes the following steps:

step S402, receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information.

In step S402, when the database starts running, the database backup/standby machine checks whether or not there is a WAL log that does not perform a playback/rewrite operation (redox) itself, if so, the database backup/standby machine directly performs the playback/rewrite operation (redox), and if not, the database backup/standby machine starts performing the parallel playback operation on the log sequence after receiving the log sequence sent by the database host. The log sequence is used to record all modification operations that occur in the database system, such as insert, update, and delete operations; a record for persisting operations occurring in the database prior to the data being stored on the disk; wherein each pre-written log (WAL log) records an operation in the database, a plurality of pre-written logs (WAL logs) are stored in a log sequence according to occurrence time of the operation recorded by the pre-written logs (WAL logs), for example, the database performs a delete operation and then performs an insert operation, and in the log sequence, the position of the WAL log recording the delete operation is before the position of the WAL log recording the insert operation. It should be noted that, the log sequence may include only one WAL log, and one WAL log may also record a plurality of operations occurring in the database.

In step S404, a waiting policy is obtained, where the waiting policy is used to indicate whether to wait for executing the playback operation, and different types of pre-write logs correspond to different waiting policies.

In step S404, the database backup/backup determines a waiting policy when the playback thread (including threads redox 1-4 and xactwork) performs a playback operation on the pre-written log (WAL) of the type to be subjected to the redox operation, where the waiting policy is used to indicate whether the playback thread needs to wait when performing redox on the WAL log of the type.

It should be noted that, the waiting policy in the embodiment of the present application is applied in a process of executing a redox operation, rather than after receiving a query instruction for obtaining a snapshot, so that the waiting policy provided in the embodiment of the present application can ensure that multiple threads executing a redox operation in a database standby library/standby machine can always maintain a consistent state in a process of executing a redox operation, so that after receiving a query instruction, the snapshot can be returned immediately, thereby achieving a technical effect of improving query performance of the database.

In the step S404, the corresponding waiting policy is determined according to the type of the pre-written log, where the type of the pre-written log is determined according to the operations recorded in the log, for example, if the database performs the insert operation, a log (i.e., a first type log, an I type log) recording the insert operation is generated; the database executes the deleting operation, and a log (namely a second type log and a D type log) for recording the deleting operation is generated; the database executes the operation of cleaning the storage space, and then a log (namely a third type log and a V type log) for recording the operation of cleaning the storage space is generated; the database executes the update operation, and a log (namely a fourth type log and a U type log) for recording the update operation is generated; when a transaction commit operation is performed in the database, a log (i.e., a fifth type log, xid type log) is generated that records the transaction commit operation, wherein a thread (xactwork) executed by the database management system performs a redox operation on the xid type log (i.e., the fifth type log).

Step S406, executing parallel playback operation to the log sequence according to the waiting strategy.

In step S406, according to the waiting policy corresponding to the type of the pre-write log (WAL) determined in step S404, different waiting policies to be followed by each thread when performing the playback/rewrite (redox) operation of the WAL log of a different type are determined, and a plurality of threads are simultaneously run according to the respective corresponding waiting policies, so as to implement the parallel playback operation of the pre-write log (WAL).

According to an optional embodiment of the present application, the waiting policy corresponding to the type of the pre-write log includes: if the pre-written log of the playback operation to be executed is any one of the first type log, the second type log, the fourth type log and the fifth type log, determining that the waiting strategy is not needed to wait, and continuing to execute the playback operation; if the pre-written log of the playback operation to be executed is a third type log, acquiring a first identifier and a second identifier, wherein the first identifier is the serial number of a database transaction currently executed by the database, the second identifier is the serial number of a target transaction, and the target transaction is the database transaction with the largest serial number in a plurality of database transactions executed by the database; and determining a waiting strategy corresponding to the third type log according to the first identifier and the second identifier.

In this embodiment, as mentioned in the previous embodiment, the operations in the database include inserting, deleting, cleaning up the storage space, updating, and saving transaction commit of the above types of operations, where performing redox on the inserting, deleting, updating, and transaction commit operations does not affect the generation of the snapshot; only the operation of cleaning the storage space is carried out, so that the generation of the snapshot is affected, and particularly, the generated snapshot is cleaned. Since the operations that do not affect snapshot generation, such as the insert operation, the delete operation, and the update operation, need only be re-performed when the pre-write log (WAL) is the I-type log (i.e., the first type log), the D-type log (i.e., the second type log), or the U-type log (i.e., the fourth type log), and the insert operation, the delete operation, and the update operation need only be performed again when the pre-write log (WAL) is the xid-type log (i.e., the fifth type log), the corresponding wait policy is no need to wait when the pre-write log is the I-type log (i.e., the first type log), the D-type log (i.e., the second type log), the U-type log (i.e., the fourth type log), or the xid-type log (i.e., the fifth type log), and the playback operation is continued. Since the operation of clearing the storage space once is required for the redox operation of the V-type log (i.e., the third-type log), when a certain thread performs the redox operation to the V-type log (i.e., the third-type log), it is determined whether the redox operation of the V-type log (i.e., the third-type log) needs to be suspended by determining the relationship between the redox process of the xid-type log (i.e., the fifth-type log) and the redox process of the V-type log (i.e., the third-type log), or by determining the relationship between the serial number (i.e., the first identifier) of the database transaction currently being executed by the database and the serial number (i.e., the second identifier) of the database transaction (i.e., the target transaction) having the largest serial number among the database transactions that have been executed by the database. Specifically, when the WAL log of the redox operation to be executed is determined to be a V-type log (i.e., a third-type log), determining a database transaction to which the V-type log to be executed (i.e., the third-type log) belongs, acquiring a serial number (i.e., a first identifier) of the database transaction to which the V-type log (i.e., the third-type log) belongs, and simultaneously acquiring serial numbers of all database transactions executed by the database before the current moment, and determining a maximum serial number (i.e., a second identifier) from the serial numbers; determining whether to suspend the redox operation (i.e. waiting strategy) of the current V-type log (i.e. the third-type log) according to the size relation between the serial number (i.e. the first identifier) of the database transaction to which the V-type log (i.e. the third-type log) belongs and the largest serial number (i.e. the second identifier) of all the database transactions executed by the database before the current moment.

In this embodiment, if the serial number (i.e., the first identifier) of the database transaction to which the V-type log (i.e., the third-type log) to be executed at the current time belongs is greater than the largest serial number (i.e., the second identifier) of all the database transactions executed before the current time, it is indicated that the operation currently executed to clean the data storage space (i.e., the redox operation of the V-type log) does not affect the generation of the snapshot, and at this time, the redox operation of the direct V-type log (i.e., the third-type log) is allowed. If the sequence number (i.e., the first identifier) of the database transaction to which the V-type log (i.e., the third-type log) to be executed at the current time belongs is smaller than the largest sequence number (i.e., the second identifier) of all database transactions executed before the current time, it is stated that the operation of currently executing the cleanup data storage space (i.e., the redox operation of the V-type log) affects the generation of the snapshot, at this time, whether the redox operation (i.e., the waiting strategy) of the current V-type log (i.e., the third-type log) needs to be suspended is determined according to the size relationship between the log sequence number (i.e., the first log sequence number) of the V-type log (i.e., the third-type log) to be executed at the current time and the log sequence number (i.e., the second log sequence number) of the xid-type log (i.e., the fifth-type log) to be executed by the xactrum thread at the current time.

According to an optional embodiment of the present application, determining a waiting policy corresponding to the third type of log according to the first log sequence number and the second log sequence number includes: if the first log sequence number is smaller than the second log sequence number, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation; if the first log serial number is larger than the second log serial number, determining that the waiting strategy corresponding to the third type log is to pause the execution of the playback operation; if the second log serial number does not exist, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation.

In this embodiment, when determining whether or not to suspend execution of a redox operation (i.e., a waiting policy) of a current V-type log (i.e., a third-type log) according to a size relationship between a log sequence number (i.e., a first log sequence number) of the V-type log (i.e., a third-type log) to be executed at a current time and a log sequence number (i.e., a second log sequence number) of a xid-type log (i.e., a fifth-type log) to be executed by a xactwork thread at the current time, there are the following three cases; 1) The log sequence number (i.e., the first log sequence number) of the V-type log (i.e., the third-type log) to be executed at the current time is smaller than the log sequence number (i.e., the second log sequence number) of the xid-type log (i.e., the fifth-type log) to be executed by the xactwork thread at the current time: illustrating that executing the redox operation of the V-type log (i.e., the third type log) does not affect the database backup to generate a snapshot, and thus, does not require waiting, allowing the operation of the V-type log (i.e., the third type log) redox to be directly performed. 2) The log sequence number (i.e., the first log sequence number) of the V-type log (i.e., the third-type log) to be executed at the current time is greater than the log sequence number (i.e., the second log sequence number) of the xid-type log (i.e., the fifth-type log) to be executed by the xactwork thread at the current time: it is illustrated that executing a redox operation of a V-type log (i.e., a third-type log) may delete a previously generated snapshot, at which time execution of the redox operation of the V-type log (i.e., the third-type log) is suspended. 3) The log sequence number (i.e., the second log sequence number) of the xid type log (i.e., the fifth type log) to be executed by the xactwork thread at the current time is not acquired: it is explained that all logs distributed to the xactrworks thread have performed the redox operation, so that performing the redox operation of the V-type log (i.e., the third-type log) does not affect the database backup to generate the snapshot, and at this time, it is allowed to allow the operation of the V-type log (i.e., the third-type log) to be directly performed without waiting.

According to another optional embodiment of the present application, after suspending the execution of the parallel playback operation, the parallel playback method of the database log further includes: performing playback operation on the plurality of fifth type logs until any one preset condition is met, and continuing to perform playback operation of the third type logs; the preset conditions comprise: the first log sequence number is less than the second log sequence number, the fifth type log in the log sequence has performed a playback operation, and the value of the first identifier is greater than the value of the second identifier.

In this embodiment, after determining that the log sequence number (i.e., the first log sequence number) of the V-type log (i.e., the third type log) to be executed at the current time is greater than the log sequence number (i.e., the second log sequence number) of the xid-type log (i.e., the fifth type log) to be executed at the current time by the xactwork thread, stopping executing the redox operation of the V-type log (i.e., the third type log), other threads in the database backup will continue executing the redox operation of the other types of logs, for example, the xactwork thread will continue executing the redox operation on the xid-type log (i.e., the fifth type log) distributed to the threads thereof, and the database will also continue executing the database transaction; detecting in real time a log sequence number (i.e., a second log sequence number) of a next xid type log (i.e., a fifth type log) to be subjected to a redox operation and a sequence number (i.e., a second identifier) of a next database transaction to be performed by the database during continued operation of the database; restarting the redox operation of the V-type log (i.e., the third-type log) in case that the sequence number (i.e., the second identifier) of the next database transaction to be executed by the database is greater than the sequence number (i.e., the first identifier) of the transaction to which the V-type log (i.e., the third-type log) to be suspended belongs; when the sequence number (i.e., the second identifier) of the next database transaction to be executed is smaller than the sequence number (i.e., the first identifier) of the transaction to which the V-type log (i.e., the third-type log) to be suspended belongs, but the log sequence number (i.e., the first sequence number) of the V-type log to be suspended is smaller than the log sequence number (i.e., the second log sequence number) of the next xid-type log (i.e., the fifth-type log) to be subjected to the redox operation, or the xid-type log (i.e., the fifth-type log) of the xactrk thread has all performed the redox operation, the redox operation of the V-type log (i.e., the third-type log) is restarted. In addition, the database may also determine in parallel a size relationship between a sequence number (i.e., the second identifier) of a next database transaction to be executed and a sequence number (i.e., the first identifier) of a transaction to which a V-type log (i.e., the third-type log) that suspends execution belongs; the size relationship of the log sequence number (i.e., the second log sequence number) of the next xid type log (i.e., the fifth type log) to be subjected to the redox operation and the log sequence number (i.e., the first sequence number) of the V type log to be suspended from execution, and the xactwork thread execution progress until any condition for restarting the redox operation of the V type log (i.e., the third type log) is satisfied, and the redox operation of the V type log (i.e., the third type log) is started.

According to an alternative embodiment of the present application, before performing parallel playback operations on a log sequence according to a waiting policy, the method includes: reading a log sequence, and distributing a plurality of pre-written logs in the log sequence to a plurality of playback threads, wherein the playback threads are used for executing playback operations; detecting a playback progress of each playback thread of the plurality of playback threads, wherein the playback progress is used for indicating a type of pre-written log that each playback thread is currently executing a playback operation; a wait policy corresponding to the type of the pre-write log is determined.

In this embodiment, before a plurality of threads run simultaneously according to respective corresponding waiting policies to implement parallel playback operations of pre-written logs (WALs), a log sequence as shown in fig. 1 sent by a database host is first read, and a plurality of WAL logs in the log sequence are distributed to a plurality of playback threads executing a redox operation; when a plurality of playback threads execute playback operations in parallel, detecting the type (i.e., playback progress) of a pre-written log (WAL) currently carrying out redox in each playback thread, and determining a waiting policy corresponding to the type (i.e., playback progress) of the pre-written log (WAL) as the current waiting policy of the playback thread executing the pre-written log (WAL).

An object identifier (Object Identifier, OID) is included in a write-ahead log (WAL) generated by performing specific operations (such as insertion, deletion, update) on the database to indicate which database transaction the write-ahead log (WAL) belongs to, and in this embodiment, it is determined to which thread the write-ahead log (WAL) is distributed according to the object identifier included in each write-ahead log (WAL); specifically, the number of playback threads for executing the redox operation by the database backup/backup machine is obtained, the hash value of the object identifier OID (i.e. identifier) of each pre-written log (WAL) is respectively determined, the hash value of the object identifier OID (i.e. identifier) of each pre-written log (WAL) is used for taking the remainder of the number of playback threads for executing the redox operation by the database backup/backup machine, and the obtained remainder is the playback thread to which the pre-written log (WAL) is distributed; for example, when the hash value of the object identifier OID (i.e., identifier) of the pre-written log with the object identifier OID (i.e., identifier) being a takes a remainder for the number of playback threads, and the obtained remainder is 2, the pre-written log with the object identifier OID (i.e., identifier) being a is distributed to the second playback thread redox 2.

According to further alternative embodiments of the present application, distributing the plurality of pre-written logs in the log sequence to the plurality of playback threads further comprises: the pre-written log without the identifier is distributed to a target thread, wherein the target thread is a thread executed by a database management system.

The object identifier OID (i.e., identifier) is not present in the xid type log (i.e., fifth type log) generated by the database executing transaction commit operation, because the redox operation of the xid type log (i.e., fifth type log) is performed by the xactwork thread (i.e., target thread), when the pre-write log (WAL) distribution is performed, the pre-write log (WAL) that does not include the object identifier OID (i.e., identifier) is directly distributed to the xactwork thread (i.e., target thread), wherein the xactwork thread (i.e., target thread) is performed by the database management system.

Through the steps, the waiting strategy can be applied to the parallel playback process of the database backup/backup machine, so that a plurality of playback threads of the database backup/backup machine are always kept at a consistent point (namely a consistent snapshot point), further, the database backup/backup machine can return to the database snapshot immediately after receiving the query instruction, the condition that a user needs to wait is avoided, and the query performance of the database backup/backup machine is improved.

Fig. 5 is a block diagram of a parallel playback apparatus for database logs according to an embodiment of the present application, and as shown in fig. 5, the parallel playback apparatus for logs includes: the receiving module 50 is configured to receive a log sequence sent by the database host, where the log sequence includes a plurality of pre-written logs, and the log sequence is configured to record operation information of a database to which the database host belongs according to a time sequence, where different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to an occurrence time of an operation corresponding to the operation information; an obtaining module 52, configured to obtain a waiting policy, where the waiting policy is used to indicate whether to wait for a playback operation to be performed, and different types of pre-write logs correspond to different waiting policies; and an execution module 54, configured to execute parallel playback operation on the log sequence according to the waiting policy.

Fig. 6 is a workflow diagram of a parallel playback apparatus for database logs, as shown in fig. 6, after the parallel playback apparatus for logs receives, through a receiving module 50, a log sequence sent by a database master/host, as shown in fig. 1, and performs parallel playback operation on the log sequence according to a method provided in an embodiment of the present application, where the log sequence shown in fig. 1 includes 32 WAL logs, and the 32 WAL logs are arranged into a log sequence according to a generation time, where a generation time of a WAL log with a log sequence number of 1 (LSN 1) is earliest, and a generation time of a WAL log with a log sequence number of 32 (LSN 32) is latest; in addition, different types of WAL logs are used to record different operational information; for example, the type I log (i.e., a first type log) records information related to an insert operation occurring in the database, and the type U log (i.e., a fourth type log) records information related to an update operation occurring in the database; when the parallel playback device of the log performs parallel playback operation on the received log sequence through a plurality of playback threads, the acquisition module 52 determines the type of the WAL log currently processed by each playback thread, acquires a waiting strategy corresponding to the type of the WAL log, and issues the waiting strategy to the corresponding playback thread; wherein the waiting policy indicates that the current WAL log is replayed, or pauses the current WAL log; the execution module 54 controls each playback thread to execute playback operation according to the issued waiting policy; for example, as shown in fig. 6, when the playback thread 2 (request 2) performs a redox operation on the V-type WAL log with a log sequence number of 30 (LSN 30), the obtaining module 52 obtains that the waiting policy of the V-type WAL log is determined according to the sequence number of the database transaction currently executed by the database (i.e., the first identifier standbyXmin) and the largest sequence number (i.e., the second identifier latestremoved xid) corresponding to the database transaction executed by the database before the current time, and as shown in fig. 6, if the sequence number (standbyXmin) of the database transaction currently executed by the database is greater than the largest sequence number (latestremoved xid) corresponding to the database transaction executed by the database before the current time, the waiting policy of the log n30 is that no waiting is needed, the executing module 54 continues to perform the playback (redox) operation; if the serial number (standby Xmin) of the database transaction currently executed by the database is smaller than the maximum serial number (latestRemovedXid) in a plurality of serial numbers corresponding to the database transaction executed by the database before the current moment, determining the waiting strategy of the log LSN30 according to the execution progress of the current xactwork thread (namely the target thread); if the xid type logs (i.e., the fifth type log) distributed for the xactwork thread have all performed playback (redox) operations; without waiting, the execution module 54 directly performs a playback (redox) operation of the log LSN 30; if the xid type log (i.e., the fifth type log) of the playback (redox) operation still exists in the xactwork thread, acquiring a log sequence number (i.e., a second log sequence number) of the xid type log (i.e., the fifth type log) to be executed in the xactwork thread and a log sequence number (i.e., a first log sequence number, 30) of the log LSN 30; when the log sequence number (i.e., the second log sequence number) of the xid type log (i.e., the fifth type log) to be executed is greater than the log sequence number of the log LSN30, the direct execution module 54 performs a playback (redox) operation of the log LSN30 without waiting; when the log sequence number (i.e., the second log sequence number) of the xid type log (i.e., the fifth type log) to be executed is smaller than the log sequence number of the log LSN30, the execution module 54 pauses execution of the replay (redox) operation of the log LSN30, other threads in the database backup continue to execute the redox operation of the log on the threads thereof, and the database continues to execute the database transaction until the largest sequence number (lastremovexid) of a plurality of sequence numbers corresponding to the database transactions after the database execution is smaller than the sequence number (standbyXmin) of the database transaction to which the log LSN30 belongs; if the largest sequence number (lastremovedxid) of the sequence numbers corresponding to the database transactions after the database execution is greater than the sequence number (standbyXmin) of the database transaction to which the log LSN30 belongs, but the log sequence number (i.e., the second log sequence number) of the xid type log (i.e., the fifth type log) to be executed in the xactwork thread is greater than the log sequence number of the log LSN30, or all xid type logs (i.e., the fifth type log) in the xactwork thread execute the redox operation, and restarting the redox operation of the log LSN 30.

It should be noted that, the preferred implementation manner of the embodiment shown in fig. 5 may refer to the related description of the embodiment shown in fig. 4, which is not repeated herein.

The embodiment of the application also provides a nonvolatile storage medium, wherein the nonvolatile storage medium stores a computer program, and the device in which the nonvolatile storage medium is arranged executes the parallel playback method of the database log by running the computer program.

The above-described nonvolatile storage medium is used to store a program that performs the following functions: receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; and executing parallel playback operation on the log sequence according to the waiting strategy.

The embodiment of the application also provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the parallel playback method of the database log by the computer program.

The processor in the electronic device is configured to execute a program that performs the following functions: receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, and the time sequence is determined according to the occurrence time of an operation corresponding to the operation information; obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and different types of pre-write logs correspond to different waiting strategies; and executing parallel playback operation on the log sequence according to the waiting strategy.

Note that each module in the parallel playback apparatus of the log may be a program module (for example, a set of program instructions for implementing a specific function), or may be a hardware module, and for the latter, it may be represented by the following form, but is not limited thereto: the expression forms of the modules are all a processor, or the functions of the modules are realized by one processor.

The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed technology content may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, for example, may be a logic function division, and may be implemented in another manner, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be essentially or a part contributing to the related art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application and are intended to be comprehended within the scope of the present application.

Claims

1. A method for parallel playback of database logs, comprising:

receiving a log sequence sent by a database host, wherein the log sequence comprises a plurality of pre-written logs, the log sequence is used for recording operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, the time sequence is determined according to the occurrence time of an operation corresponding to the operation information, and the types of the pre-written logs comprise: a first type log generated when a database executes a data insertion operation, a second type log generated when the database executes a deletion operation, a third type log generated when the database executes an operation for cleaning a data storage space, a fourth type log generated when the database executes an update operation, and a fifth type log corresponding to a transaction commit operation;

Obtaining a waiting strategy, wherein the waiting strategy is used for indicating whether to wait for executing playback operation, and the different types of pre-write logs correspond to different waiting strategies;

and executing parallel playback operation on the log sequence according to the waiting strategy, wherein the parallel playback operation comprises the following steps: if the pre-written log of the playback operation to be executed is the third type log, a first identifier and a second identifier are obtained, wherein the first identifier is the serial number of a database transaction currently executed by the database, the second identifier is the serial number of a target transaction, and the target transaction is the database transaction with the largest serial number in a plurality of database transactions executed by the database; and determining a waiting strategy corresponding to the third type log according to the first identifier and the second identifier.

2. The method of claim 1, comprising, prior to performing parallel playback operations on the log sequence in accordance with the wait policy:

reading the log sequence, and distributing a plurality of pre-written logs in the log sequence to a plurality of playback threads, wherein the playback threads are used for executing the playback operation;

Detecting a playback progress of each playback thread of the plurality of playback threads, wherein the playback progress is used for indicating a type of a pre-written log of the playback operation currently being executed by each playback thread;

and determining a waiting strategy corresponding to the type of the pre-write log.

3. The method of claim 2, wherein distributing the plurality of pre-written logs in the log sequence to a plurality of playback threads comprises:

acquiring an identifier of each of a plurality of pre-written logs, wherein the identifier of each pre-written log is used for indicating a database transaction to which each pre-written log belongs;

and determining the remainder of the hash value of the identifier of each pre-written log relative to the number of the playback threads as a target identification.

4. The method of claim 3, wherein distributing the plurality of pre-written logs in the log sequence to a plurality of playback threads further comprises:

and distributing the pre-written log without the identifier to a target thread, wherein the target thread is a thread executed by a database management system.

5. The method of claim 1, wherein the waiting policy corresponding to the type of the pre-write log further comprises:

And if the pre-written log of the playback operation to be executed is any one of the first type log, the second type log, the fourth type log and the fifth type log, determining that the waiting strategy is free from waiting, and continuing to execute the playback operation.

6. The method of claim 1, wherein determining a wait policy for the third type log based on the first identifier and the second identifier comprises:

if the value of the first identifier is greater than the value of the second identifier, the waiting strategy corresponding to the third type log is that waiting is not needed, and the playback operation is continuously executed;

if the value of the first identifier is smaller than that of the second identifier, a first log sequence number and a second log sequence number are obtained, wherein the first log sequence number is a sequence number of a third type log of the playback operation to be currently executed, the first log sequence number is used for indicating the position of the third type log of the playback operation to be currently executed in the log sequence, the second log sequence number is a log sequence number of a fifth type log of the playback operation to be currently executed, and the second log sequence number is used for indicating the position of the fifth type log of the playback operation to be currently executed in the log sequence;

And determining a waiting strategy corresponding to the third type log according to the first log serial number and the second log serial number.

7. The method of claim 6, wherein determining a wait policy for the third type of log based on the first log sequence number and the second log sequence number comprises:

if the first log sequence number is smaller than the second log sequence number, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation;

if the first log sequence number is larger than the second log sequence number, determining that the waiting strategy corresponding to the third type log is to pause execution of the playback operation;

and if the second log serial number does not exist, determining that the waiting strategy corresponding to the third type log is not needed to wait, and continuing to execute the playback operation.

8. The method of claim 7, wherein after suspending execution of the parallel playback operation, the method further comprises:

executing the playback operation on the fifth type logs until any one preset condition is met, and continuing to execute the playback operation of the third type log; the preset conditions include:

The first log sequence number is less than the second log sequence number, a fifth type log in the log sequence has performed the playback operation, and the first identifier has a value greater than the second identifier.

9. A parallel playback apparatus for database logs, comprising:

the receiving module is configured to receive a log sequence sent by a database host, where the log sequence includes a plurality of pre-written logs, the log sequence is configured to record operation information of a database to which the database host belongs according to a time sequence, different operation information corresponds to different types of pre-written logs, the time sequence is determined according to occurrence time of an operation corresponding to the operation information, and the types of the pre-written logs include: a first type log generated when a database executes a data insertion operation, a second type log generated when the database executes a deletion operation, a third type log generated when the database executes an operation for cleaning a data storage space, a fourth type log generated when the database executes an update operation, and a fifth type log corresponding to a transaction commit operation;

The system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring a waiting strategy, the waiting strategy is used for indicating whether playback operation is to be executed or not, and the different types of pre-written logs correspond to different waiting strategies;

the execution module is used for executing parallel playback operation on the log sequence according to the waiting strategy, and comprises the following steps: if the pre-written log of the playback operation to be executed is the third type log, a first identifier and a second identifier are obtained, wherein the first identifier is the serial number of a database transaction currently executed by the database, the second identifier is the serial number of a target transaction, and the target transaction is the database transaction with the largest serial number in a plurality of database transactions executed by the database; and determining a waiting strategy corresponding to the third type log according to the first identifier and the second identifier.

10. A nonvolatile storage medium, wherein a computer program is stored in the nonvolatile storage medium, and wherein a device in which the nonvolatile storage medium resides performs the parallel playback method of the database log according to any one of claims 1 to 8 by running the computer program.

11. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, the processor being arranged to perform the method of parallel playback of database logs according to any one of claims 1 to 8 by means of the computer program.