CN106815094B

CN106815094B - Method and equipment for realizing transaction submission in master-slave synchronization mode

Info

Publication number: CN106815094B
Application number: CN201510875827.1A
Authority: CN
Inventors: 张广舟; 林晓斌; 范孝剑; 周正中; 张文杰
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-12-02
Filing date: 2015-12-02
Publication date: 2020-12-11
Anticipated expiration: 2035-12-02
Also published as: CN106815094A

Abstract

The application aims to provide a method and equipment for realizing transaction submission in a master-slave synchronization mode. Specifically, when a main database receives a transaction submitting request of a user, a transaction number corresponding to a transaction and a log number before the transaction submitting request are sent to a standby database; executing a transaction commit operation; detecting whether the standby database receives prior log information corresponding to the transaction; and if the transaction is accepted, sending a transaction submission completion notification to the user. Compared with the prior art, the method and the device have the advantages that the main database receives a transaction submission request of a user, namely, the transaction number of a corresponding transaction and the log number before the transaction submission request are sent to the corresponding standby database, the transaction submission operation is executed, whether the transmitted prior log information is received by the standby database or not is detected, if the transmitted prior log information is received by the standby database, a completion notification of the transaction submission request is sent to the user, the transaction submission speed of the database and the performance of the database are improved, and user experience is optimized.

Description

Method and equipment for realizing transaction submission in master-slave synchronization mode

Technical Field

The present application relates to the field of computers, and in particular, to a technique for implementing transaction commit in a master-slave synchronization mode.

Background

With the advent of the big data era, the rapid increase of data processing capacity drives the development of databases, generally, a main database and a standby database are adopted to jointly guarantee the high reliability of the databases, and in order to guarantee the safety of data without loss, a synchronization mode is often adopted between the main database and the standby database of the databases to perform data backup, wherein, in the prior art, when database transactions are submitted, the main database server needs to send all logs of the transactions to the standby database server, and the standby database server feeds back the received logs to complete the submission of the database transactions and inform users.

However, in the prior art, when a database transaction is submitted in a master-slave synchronization mode, network delay often exists between the master database server and the slave database, so that it takes a long time for the master database server to submit the database transaction, and further, the completion time of the database transaction is too long, the throughput of the database transaction is reduced, and the performance of the database is greatly reduced.

Disclosure of Invention

The application aims to provide a method and equipment for realizing transaction submission in a primary and standby synchronization mode, which are used for solving the problem that the transaction submission completion time in the conventional primary and standby synchronization mode is too long.

To achieve the above object, according to an aspect of the present application, there is provided a method for a primary database server to implement transaction submission in a primary/secondary synchronization mode, the method solving a problem of an excessively long transaction submission completion time in the existing primary/secondary synchronization mode, the method including:

when a main database receives a transaction submission request of a user, sending a transaction number corresponding to a transaction and a log number of a latest log of the transaction before the transaction submission request is received to a corresponding standby database;

performing a transaction commit operation of the transaction in the master database;

detecting whether the standby database receives prior log information corresponding to the transaction;

and when the standby database receives the prior log information corresponding to the transaction, sending a transaction submission completion notification corresponding to the transaction submission request to the user.

According to another aspect of the present application, the present application provides a method for a standby database server to implement transaction submission in a primary/standby synchronization mode, which solves the problem of an excessively long transaction submission completion time in the existing primary/standby synchronization mode, and includes:

receiving a transaction number of a transaction sent by a main database and a log number of a latest log of the transaction before receiving the transaction submission request;

when detecting the corresponding main database is abnormal, switching the standby database to a new main database, and before providing service, executing the following operations:

for the transaction to be complemented in the new main database, regenerating a corresponding transaction commit request and executing a transaction commit operation to obtain complemented log information;

and performing playback operation on the new master database according to the completed log information so as to restore the database to be consistent.

According to another aspect of the present application, a primary database server device for implementing transaction submission in a primary/secondary synchronization mode is provided, which solves the problem of an excessively long transaction submission completion time in the existing primary/secondary synchronization mode, and includes:

the sending device is used for sending the transaction number of the corresponding transaction and the log number of the latest log of the transaction before the transaction submitting request is received to the corresponding standby database when the main database receives the transaction submitting request of a user;

executing means for executing a transaction commit operation of the transaction in the master database;

the detection device is used for detecting whether the standby database receives the prior log information corresponding to the transaction;

and the notification device is used for sending a transaction submission completion notification corresponding to the transaction submission request to the user when the standby database receives the prior log information corresponding to the transaction.

According to another aspect of the present application, there is provided a backup database server device for implementing transaction commit in a primary and backup synchronization mode, the device solving the problem of an excessively long transaction commit completion time in the existing primary and backup synchronization mode, the device comprising:

the receiving device is used for receiving the transaction number of the transaction sent by the main database and the log number of the latest log of the transaction before the transaction submitting request is received;

the main/standby switching device is used for switching the standby database into a new main database when detecting that the corresponding main database is abnormal, and executing the following operations before providing service:

the log completion device is used for regenerating a corresponding transaction submission request and executing transaction submission operation for the transaction to be completed in the new main database so as to obtain completed log information;

and the data recovery device is used for executing playback operation on the new master database according to the completed log information so as to ensure that the databases are recovered to be consistent.

According to another aspect of the present invention, a system for implementing transaction submission in a primary/secondary synchronization mode is further provided, so as to solve the problem of too long transaction submission completion time in the existing primary/secondary synchronization mode, where the system includes a primary database server device according to one aspect of the present invention as described above for implementing transaction submission in the primary/secondary synchronization mode, and a backup database server device according to another aspect of the present invention as described above for implementing transaction submission in the primary/secondary synchronization mode.

Compared with the prior art, the method and the device have the advantages that the main database receives the transaction submission request of the user, namely the transaction number of the corresponding transaction and the log number before the transaction submission request are sent to the corresponding standby database, the transaction submission operation is executed, whether the standby database receives the sent prior log information or not is detected, if the standby database receives the prior log information, the completion notification of the transaction submission request is sent to the user, so that the user can be notified of the completion of the submission without waiting for the standby database to synchronously complete the log of the transaction submission request, the problem that the transaction submission completion time is too long in the existing main and standby synchronous mode is solved, the transaction submission speed of the database is increased, the throughput of the database transaction is increased, the database performance is improved, and the user experience is optimized.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 is a flow chart illustrating a method implemented by a primary database and a backup database for transaction commit in a primary/backup synchronization mode according to an aspect of the present application;

FIG. 2 is a flow chart illustrating step S23 of a method for implementing transaction commit in active-standby synchronous mode according to another preferred embodiment of the present application;

FIG. 3 is a schematic diagram of an apparatus for implementing transaction commit in a master-slave synchronization mode implemented by a primary database and a backup database according to another aspect of the present disclosure;

FIG. 4 is a schematic diagram of a log completion apparatus in a device for implementing transaction commit in a primary/standby synchronization mode according to another preferred embodiment of the present application;

FIG. 5 is a diagram illustrating transaction commit in primary/standby synchronization mode according to another preferred embodiment of the present application.

The same or similar reference numbers in the drawings identify the same or similar elements.

Detailed Description

The present application is described in further detail below with reference to the attached figures.

In a typical configuration of the present application, the terminal, the device serving the network, and the trusted party each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.

Fig. 1 is a flowchart illustrating a method for implementing transaction commit in a master-slave synchronization mode implemented by a primary database and a backup database according to an aspect of the present application. Wherein the master database terminal device includes step S11, step S12, step S13, and step S14; the backup database terminal includes step S21, step S22, step S23, and step S24.

In step S11, when the master database receives a transaction commit request from a user, the master database device sends a transaction number corresponding to the transaction and a log number of a latest log of the transaction before receiving the transaction commit request to a corresponding backup database; in step S21, the standby database side device receives the transaction number of the transaction sent by the primary database and the log number of the latest log of the transaction before receiving the transaction commit request; the master database end device performs a transaction commit operation of the transaction in the master database in step S12; in step S13, the primary database device detects whether the standby database has received previous log information corresponding to the transaction; in step S14, when the standby database has received the prior log information corresponding to the transaction, the primary database device sends a transaction commit completion notification corresponding to the transaction commit request to the user; when detecting the corresponding primary database abnormality, the backup database side device switches the backup database to a new primary database in step S22, and performs the following operations before providing the service: in step S23, the standby database side device regenerates a corresponding transaction commit request for the to-be-complemented transaction in the new primary database and performs a transaction commit operation to obtain complemented log information; in step S24, the standby database side device performs a playback operation on the new master database according to the completed log information, so as to restore the consistency of the database.

Specifically, in step S11, when the master database receives a transaction commit request from a user, the master database device sends a transaction number corresponding to the transaction and a log number of a latest log of the transaction before receiving the transaction commit request to the corresponding backup database. The transaction commit request of the user refers to an operation of committing the database transaction after the database transaction is executed, and is a commit statement in most databases, for example, a commit command is received by the transaction T1 in fig. 5. For example, as shown in fig. 5, after receiving the commit command, the transaction T1 sends the transaction number corresponding to the transaction T1 to the backup database corresponding to the primary database, where the primary database server in fig. 5 corresponds to the primary database and the secondary database server corresponds to the backup database. The log number of the latest log before the transaction commit request refers to the log number of the latest log before the user transaction commit request is received, and does not include the log number corresponding to the user transaction commit request, for example, as shown in fig. 5, the transaction T1 sends the latest log number except for the commit command. Here, the corresponding backup database refers to a backup database in the same master/backup synchronization mode as the primary database. The transaction number of the corresponding transaction sent to the corresponding standby database and the log number of the latest log of the transaction before receiving the transaction commit request may be sent asynchronously by using a single connection, where the sending mode includes a normal sending mode in a master-standby synchronous mode of the database, or asynchronous sending by using a single data connection, but is not limited thereto. The master database still normally transmits the log before the transaction commit request of the user to the standby database at the same time or before the transaction number of the corresponding transaction transmitted to the standby database and the log number of the latest log before the transaction commits the request, for example, as shown in fig. 5, the master database normally transmits the logs of the transaction T1 except for the commit command, and here, the logs except for the commit command do not necessarily have a mutual dependency relationship with the transaction number and the last log number except for the commit command, that is, the logs and the last log number may be transmitted asynchronously. When a main database receives a transaction submission request of a user, a transaction number corresponding to the transaction and a log number of a latest log of the transaction before the transaction submission request is received are sent to a corresponding standby database, so that the standby database preferentially ensures the backup of a main log of the transaction and related information, and the transaction data can be supplemented and played back in time after the main database fails.

It should be understood by those skilled in the art that the above-mentioned manner of sending the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request is merely an example, and other existing or future manners of sending the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request may be applicable to the present application, and shall be included in the scope of the present application, and is herein incorporated by reference.

Next, in step S21, the standby database side device receives the transaction number of the transaction sent by the primary database and the log number of the latest log of the transaction before receiving the transaction commit request. That is, the standby data receives the transaction number of the transaction sent by the primary database and the log number of the latest log of the transaction before receiving the transaction commit request, for example, as shown in fig. 5, the direction of the arrow pointing to the standby database indicates that the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request are received by the standby database. Herein, the receiving the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request includes, but is not limited to, receiving asynchronously by using a separate connection, where the receiving includes a normal receiving manner in a master/slave synchronization mode of the database, or receiving asynchronously by using a separate data connection. And the standby database still normally receives the log before the user's transaction commit request, for example, as shown in fig. 5, the standby database normally receives the log of the transaction T1 except for the commit command, and here, the log of the transaction T1 except for the commit command does not necessarily have a mutual dependency relationship with the log of the transaction number and the log of the last log of the transaction number except for the commit command, that is, the log of the transaction T and the log of the last log of the transaction T except for the commit command may be received asynchronously. The standby database receives the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request, so that the standby database preferentially ensures the backup of the main log of the transaction and the related information, and the transaction data can be supplemented and played back in time after the main database fails.

It should be understood by those skilled in the art that the above-mentioned manner of receiving the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request is merely an example, and other existing or later-occurring manners of receiving the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request may be applicable to the present application, and shall be included in the scope of protection of the present application, and are incorporated herein by reference.

Next, the master database end device performs a transaction commit operation of the transaction in the master database in step S12. The transaction commit operation of the transaction refers to a related operation corresponding to the transaction commit request of the user, for example, the transaction commit operation corresponding to the commit command in fig. 5, and operations of generating a log corresponding to the commit statement and writing the log into a disk, but not limited thereto, include all related operations corresponding to the transaction commit request of the user. And sending a corresponding log for executing the transaction commit operation to a standby database after executing the transaction commit operation of the transaction, wherein the sending of the log and the sending of the log information are parallel. And the transaction commit operation of the transaction performed by the database is parallel to the aforementioned sending of the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the corresponding standby database and the sending of the log before the transaction commit request of the user, that is, the commit information does not necessarily need to wait for the completion of the commit of the main database to occur to the standby database, for example, in fig. 5, the commit statement is performed while sending the other logs except the commit command and the sending of the transaction number and the sending of the latest log number except the commit command. Because the transaction commit operation for executing the transaction and the aforementioned operations of sending the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the corresponding backup database and sending the log of the transaction before sending the transaction commit request of the user all cause time consumption due to network delay during writing data, operating a disk and sending, the parallel operation can greatly improve the speed of the operation corresponding to the transaction commit request of the user.

It should be understood by those skilled in the art that the above-described manner of performing the transaction commit operation of the transaction is merely exemplary, and other existing or future possible manners of performing the transaction commit operation of the transaction, such as may be applicable to the present application, are also included within the scope of the present application and are hereby incorporated by reference.

Preferably, in step S12, the generating, by the master database device, log information corresponding to the transaction commit operation, and storing the log information refers to executing the transaction commit operation of the transaction according to the transaction commit request of the user, where the generating includes generating log information corresponding to a commit statement of the transaction commit operation, such as a commit command, and storing the log information in a storage device, such as a disk. Therefore, relatively time-consuming operations of writing data, operating a disk and the like are parallel to the operation that the main database sends the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request to the corresponding standby database, and the submission efficiency of database transactions is improved.

Next, in step S13, the primary database device detects whether the standby database has received the previous log information corresponding to the transaction. The method refers to the steps that the main database detects the transaction number of the corresponding transaction sent to the standby database, the log number of the latest log of the transaction before receiving the transaction submission request, and whether the latest log of the transaction before receiving the transaction submission request and related log information are received and completed by the standby database. The prior log information includes a transaction number of a corresponding transaction sent to the standby database, a log number of a latest log of the transaction before receiving the transaction commit request, and a latest log of the transaction before receiving the transaction commit request and related log information, as shown in fig. 5 by way of example, that is, the master database detects whether the standby test has received logs other than the commit command, whether the transaction number of the transaction in which the commit command is received, and whether the last log number other than the commit command has been received. The detection operation includes, but is not limited to, periodically detecting whether the standby database has been accepted by the primary database, or feeding back the transmission completion to the primary database when the transmission of the primary database is completed, or feeding back the transmission completion to the primary database when the reception of the standby database is completed, and the feedback reception completion can confirm whether the user can be notified that the transaction commit request is completed by the detection operation.

It should be understood by those skilled in the art that the above-mentioned manner for detecting whether the backup database has received the prior log information corresponding to the transaction is only an example, and other existing or later-occurring manners for detecting whether the backup database has received the prior log information corresponding to the transaction are also included in the scope of protection of the present application, and are hereby incorporated by reference.

Here, the prior log information corresponding to the transaction includes: the transaction number and the log number; log information of the transaction prior to the log number. The transaction number and the log number refer to a transaction number of a corresponding transaction and a log number of a latest log of the transaction before the transaction submitting request is received, that is, the transaction number of the transaction where the commit command is located and the last log number except for the commit command in the example shown in fig. 5. The log information of the transaction before the log number refers to the latest log and related log information of the transaction before the transaction receives the transaction commit request, and the log information refers to the latest log and related log information of the transaction which needs to be backed up before the transaction commit request is received.

Preferably, in step S13, the primary database device receives feedback information sent by the standby database, where the feedback information indicates that the standby database has received previous log information corresponding to the transaction. The method for detecting whether the standby database has received the previous log information corresponding to the transaction is to receive feedback information sent by the standby database, where the feedback information includes whether the standby database has received the previous log information corresponding to the transaction, for example, as shown in fig. 5, the master database receives the log number and receives the feedback. The feedback information includes, but is not limited to, periodic feedback, or feedback sent after completion according to a certain condition, for example, the feedback information is used to help the primary database to timely obtain the receiving condition of the backup database for the previous log information corresponding to the transaction, so as to determine whether the user can be notified that the transaction commit request is completed.

Further, the method includes step S25 (not shown), in which the standby database side device sends feedback information confirming that the previous log information corresponding to the transaction has been received to the primary database in step S25. The method refers to a situation that the backup database sends feedback information to the main database so that the main database obtains whether the backup database has received the prior log information corresponding to the transaction, wherein the feedback information comprises whether the backup database has received the prior log information corresponding to the transaction. The feedback information includes, but is not limited to, periodic feedback, or feedback sent after completion according to a certain condition, for example, the feedback information is used to help the primary database to timely obtain the receiving condition of the backup database for the previous log information corresponding to the transaction, so as to determine whether the user can be notified that the transaction commit request is completed.

Next, in step S14, the primary database device sends a transaction commit completion notification corresponding to the transaction commit request to the user when the backup database has received the previous log information corresponding to the transaction. Namely confirming that the standby database has received the transaction number of the transaction corresponding to the transaction and the log number of the latest log of the transaction before receiving the transaction submission request at the primary database, and the latest log and related log information of the transaction before the transaction commit request is received, at this time, the transaction commit operation of the transaction to which the transaction commit request corresponds is not necessarily performed to completion, all information before the transaction commit request, including the transaction number, the log number, and the log, can wait for completion and then notify the user that the transaction commit request operation is completed if the information is not backed up by the backup database, the method and the device have the advantages that the last transaction submitting operation and the corresponding log backup are not required to be waited for to be completed, so that the time for waiting for the log submission corresponding to the last transaction submitting operation is saved, and the speed of the database transaction submitting operation is increased.

Next, in step S22, the backup database side device switches the backup database to a new primary database when detecting an abnormality in the corresponding primary database. In the primary and standby synchronous mode of the database, for example, the primary database is connected to update the heartbeat table after the primary and standby switching conditions are met, if the primary database is judged to be abnormal due to timeout, the situation that the primary database fails or is down to provide services normally is not limited to the situation, and the switching mode includes but is not limited to disconnecting the service of the primary database and establishing connection between the primary database and related applications or services by using the standby database instead of the primary database. In the switching process, the standby database can traverse all the logs which are not applied yet for return visit, and if some transactions lack a commit operation, the transactions are in an uncommitted state in the return visit process. After the return visit is completed, the state of all the transactions is checked, and the uncommitted transaction is the transaction which may need to be completed with the commit operation.

After the standby database is switched to the new primary database, before providing the service, the standby database side device performs the following operations in steps S23 and S24:

in step S23, the standby database device regenerates the corresponding transaction commit request for the to-be-complemented transaction in the new primary database and performs a transaction commit operation to obtain completed log information. Because the transaction submitting operation of the transaction corresponding to the transaction submitting request is executed and completed by the master database before the master database notifies the user that the operation corresponding to the transaction submitting request is completed, and all information before the transaction submitting request, including the transaction number, the log, and the like, is backed up by the standby database, it is ensured that when the master database notifies the user that the operation corresponding to the transaction submitting request is completed, the master log of the transaction corresponding to the transaction submitting request is sent to the standby database, but the notification can be sent without waiting for the synchronous completion of the operation log corresponding to the transaction submitting request, so that the operation log corresponding to the transaction submitting request may not be received by the standby database, and at this time, the standby database is switched to a new master database, and the operation log corresponding to the transaction submitting request is lost compared with the original master database, therefore, after the standby database is switched to a new main database, before providing service, the transaction number of the corresponding transaction, the log number of the latest log of the transaction before receiving the transaction commit request, and all logs corresponding to the transaction need to be detected, and if the log number of the latest log of the transaction before receiving the transaction commit request is detected but the log corresponding to the transaction commit operation is not detected, a transaction commit request is regenerated from the log number and the transaction number and is put into the log corresponding to the transaction to complete the log corresponding to the transaction.

It should be understood by those skilled in the art that the above-mentioned manner of complementing the log according to the log number and the transaction number is only an example, and other manners of complementing the log according to the log number and the transaction number, which may occur now or in the future, are also included in the scope of the present application and are incorporated herein by reference.

Next, in step S24, the standby database side device performs a playback operation on the new master database according to the completed log information, so as to restore the consistency of the database. That is, according to the related operation information in the log information, the part which has not been backed up in the new primary database is played back, so that the part which has been recorded in the log and has been subjected to data change in the primary database and not subjected to synchronous change in the new primary database can be subjected to synchronous change, for example, the log information includes a transaction commit request but has not been submitted in the standby database, and therefore, the same transaction in the new primary database is submitted according to the transaction commit request in the log information, so as to complete the missing data information, and the state of the database data is restored to the previous primary database, which ensures that no data is lost.

Those skilled in the art will appreciate that the foregoing manner of making the database restore consistent is by way of example only, and that other existing or future manners of making the database restore consistent, as applicable to the present application, are intended to be encompassed within the scope of the present application and are hereby incorporated by reference.

Fig. 2 is a flowchart of step S23 in a method for implementing transaction commit in the active-standby synchronous mode according to another preferred embodiment of the present application. The log completion apparatus includes step S231 and step S232.

In step S231, the standby database side device determines a to-be-complemented transaction according to the log number information and the transaction number information in the new master database, where the to-be-complemented transaction is already submitted but a corresponding log is not yet sent to the new master database; in step S232, the standby database device regenerates the corresponding transaction commit request according to the log number of the transaction to be complemented and the transaction number, and executes the transaction commit operation to obtain the completed log information.

Specifically, in step S231, the standby database side device determines a transaction to be complemented according to the log number information and the transaction number information in the new master database, where the transaction to be complemented is already submitted but the corresponding log is not yet sent to the new master database. Namely, whether the new master database has missing log information needing to be replenished is determined according to the log number information and the transaction number information in the new master database. For example, after the standby database is switched to a new master database, the transaction number of the corresponding transaction, the log number of the latest log of the transaction before receiving the transaction commit request, and all logs corresponding to the transaction are detected before providing service, because the previous master database immediately sends the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the standby database, that is, the current new master database, after receiving the transaction commit request of the user, if the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request are detected, it is determined that the previous master database has received the transaction commit request of the user, the log corresponding to the transaction commit operation continues to be detected, and if the transaction number of the corresponding transaction is not detected, it indicates that the transaction to be complemented has been committed but the corresponding log has not yet been sent to the new master database, therefore, the to-be-complemented transaction is determined to avoid data loss caused by inconsistency of the new main database. The method for determining the to-be-complemented transaction also comprises the steps that the standby database traverses all logs which are not applied yet, return visit is carried out, if some transactions lack a commit operation, the transactions are in an uncommitted state in the return visit process, after the return visit is completed, the states of all transactions are checked, and the uncommitted transactions are transactions which possibly need to be complemented with the commit operation.

Next, in step S232, the standby database device regenerates the corresponding transaction commit request according to the log number of the transaction to be complemented and the transaction number, and executes the transaction commit operation to obtain the completed log information. Because the missing is the log corresponding to the last transaction commit request, a transaction commit request is regenerated from the log number and the transaction number, for example, a log corresponding to a commit statement is regenerated and put into the log corresponding to the transaction, i.e., the log corresponding to the transaction can be completed.

It should be understood by those skilled in the art that the above-mentioned manner for determining the pending transactions and completing the log information is only an example, and other manners for determining the pending transactions and completing the log information, which are currently available or may be later appeared, are also included in the scope of the present application, and are hereby incorporated by reference.

Those skilled in the art should appreciate that they may have devised combinations of aspects of this invention and that they may be embodied in many other forms, including embodiments that do not depart from the spirit and scope of the present invention.

Fig. 3 is a schematic diagram of an apparatus for implementing transaction commit in a master-slave synchronization mode, implemented by a primary database side and a backup database side according to another aspect of the present application. The master database terminal device comprises a sending device 111, an executing device 112, a detecting device 113 and a notifying device 114; the backup database includes an accepting device 121, a primary/backup switching device 122, a log completing device 123, and a data restoring device 124.

When the main database receives a transaction submission request from a user, the sending device 111 sends a transaction number corresponding to the transaction and a log number of a latest log of the transaction before receiving the transaction submission request to the corresponding standby database; the accepting device 121 receives a transaction number of a transaction sent by a master database and a log number of a latest log of the transaction before receiving the transaction commit request; the executing device 112 executes the transaction commit operation of the transaction in the master database; the detecting device 113 detects whether the standby database has received the prior log information corresponding to the transaction; when the backup database has received the prior log information corresponding to the transaction, the notification device 114 sends a transaction commit completion notification corresponding to the transaction commit request to the user; when detecting that the corresponding primary database is abnormal, the primary/secondary switching device 122 switches the backup database to a new primary database, and performs the following operations before providing services: the log completion device 123 regenerates the corresponding transaction submission request and executes the transaction submission operation for the transaction to be completed in the new master database, so as to obtain the completed log information; the data recovery device 124 performs a playback operation on the new master database according to the completed log information, so as to restore the database to be consistent.

Specifically, when the master database receives a transaction commit request from a user, the sending device 111 in the master database sends a transaction number corresponding to the transaction and a log number of a latest log of the transaction before receiving the transaction commit request to the corresponding backup database. The transaction commit request of the user refers to an operation of committing the database transaction after the database transaction is executed, and is a commit statement in most databases, for example, a commit command is received by the transaction T1 in fig. 5. For example, as shown in fig. 5, after receiving the commit command, the transaction T1 sends the transaction number corresponding to the transaction T1 to the backup database corresponding to the primary database, where the primary database server in fig. 5 corresponds to the primary database and the secondary database server corresponds to the backup database. The log number of the latest log before the transaction commit request refers to the log number of the latest log before the user transaction commit request is received, and does not include the log number corresponding to the user transaction commit request, for example, as shown in fig. 5, the transaction T1 sends the latest log number except for the commit command. Here, the corresponding backup database refers to a backup database in the same master/backup synchronization mode as the primary database. The transaction number of the corresponding transaction sent to the corresponding standby database and the log number of the latest log of the transaction before receiving the transaction commit request may be sent asynchronously by using a single connection, where the sending mode includes a normal sending mode in a master-standby synchronous mode of the database, or asynchronous sending by using a single data connection, but is not limited thereto. The master database still normally transmits the log before the transaction commit request of the user to the standby database at the same time or before the transaction number of the corresponding transaction transmitted to the standby database and the log number of the latest log before the transaction commits the request, for example, as shown in fig. 5, the master database normally transmits the logs of the transaction T1 except for the commit command, and here, the logs except for the commit command do not necessarily have a mutual dependency relationship with the transaction number and the last log number except for the commit command, that is, the logs and the last log number may be transmitted asynchronously. When a main database receives a transaction submission request of a user, a transaction number corresponding to the transaction and a log number of a latest log of the transaction before the transaction submission request is received are sent to a corresponding standby database, so that the standby database preferentially ensures the backup of a main log of the transaction and related information, and the transaction data can be supplemented and played back in time after the main database fails.

Then, the accepting device 121 in the standby database receives the transaction number of the transaction sent by the primary database and the log number of the latest log of the transaction before receiving the transaction commit request. That is, the standby data receives the transaction number of the transaction sent by the primary database and the log number of the latest log of the transaction before receiving the transaction commit request, for example, as shown in fig. 5, the direction of the arrow pointing to the standby database indicates that the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request are received by the standby database. Herein, the receiving the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request includes, but is not limited to, receiving asynchronously by using a separate connection, where the receiving includes a normal receiving manner in a master/slave synchronization mode of the database, or receiving asynchronously by using a separate data connection. And the standby database still normally receives the log before the user's transaction commit request, for example, as shown in fig. 5, the standby database normally receives the log of the transaction T1 except for the commit command, and here, the log of the transaction T1 except for the commit command does not necessarily have a mutual dependency relationship with the log of the transaction number and the log of the last log of the transaction number except for the commit command, that is, the log of the transaction T and the log of the last log of the transaction T except for the commit command may be received asynchronously. The standby database receives the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request, so that the standby database preferentially ensures the backup of the main log of the transaction and the related information, and the transaction data can be supplemented and played back in time after the main database fails.

Then, the executing device 112 in the master database executes the transaction commit operation of the transaction in the master database. The transaction commit operation of the transaction refers to a related operation corresponding to the transaction commit request of the user, for example, the transaction commit operation corresponding to the commit command in fig. 5, and operations of generating a log corresponding to the commit statement and writing the log into a disk, but not limited thereto, include all related operations corresponding to the transaction commit request of the user. And sending a corresponding log for executing the transaction commit operation to a standby database after executing the transaction commit operation of the transaction, wherein the sending of the log and the sending of the log information are parallel. And the transaction commit operation of the transaction performed by the database is parallel to the aforementioned sending of the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the corresponding standby database and the sending of the log before the transaction commit request of the user, that is, the commit information does not necessarily need to wait for the completion of the commit of the main database to occur to the standby database, for example, in fig. 5, the commit statement is performed while sending the other logs except the commit command and the sending of the transaction number and the sending of the latest log number except the commit command. Because the transaction commit operation for executing the transaction and the aforementioned operations of sending the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the corresponding backup database and sending the log of the transaction before sending the transaction commit request of the user all cause time consumption due to network delay during writing data, operating a disk and sending, the parallel operation can greatly improve the speed of the operation corresponding to the transaction commit request of the user.

Preferably, the executing device 112 generates log information corresponding to the transaction commit operation, and stores the log information refers to executing the transaction commit operation of the transaction according to the transaction commit request of the user, where generating the log information corresponding to the commit statement of the transaction commit operation, such as commit command, and storing the log information in a storage device, such as a disk. Therefore, relatively time-consuming operations of writing data, operating a disk and the like are parallel to the operation that the main database sends the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction submission request to the corresponding standby database, and the submission efficiency of database transactions is improved.

Next, the detection device 113 in the primary database detects whether the backup database has received the previous log information corresponding to the transaction. The method refers to the steps that the main database detects the transaction number of the corresponding transaction sent to the standby database, the log number of the latest log of the transaction before receiving the transaction submission request, and whether the latest log of the transaction before receiving the transaction submission request and related log information are received and completed by the standby database. The prior log information includes a transaction number of a corresponding transaction sent to the standby database, a log number of a latest log of the transaction before receiving the transaction commit request, and a latest log of the transaction before receiving the transaction commit request and related log information, as shown in fig. 5 by way of example, that is, the master database detects whether the standby test has received logs other than the commit command, whether the transaction number of the transaction in which the commit command is received, and whether the last log number other than the commit command has been received. The detection operation includes, but is not limited to, periodically detecting whether the standby database has been accepted by the primary database, or feeding back the transmission completion to the primary database when the transmission of the primary database is completed, or feeding back the transmission completion to the primary database when the reception of the standby database is completed, and the feedback reception completion can confirm whether the user can be notified that the transaction commit request is completed by the detection operation.

Preferably, the detecting device 113 receives feedback information sent by the backup database, where the feedback information indicates that the backup database has received previous log information corresponding to the transaction. The method for detecting whether the standby database has received the previous log information corresponding to the transaction is to receive feedback information sent by the standby database, where the feedback information includes whether the standby database has received the previous log information corresponding to the transaction, for example, as shown in fig. 5, the master database receives the log number and receives the feedback. The feedback information includes, but is not limited to, periodic feedback, or feedback sent after completion according to a certain condition, for example, the feedback information is used to help the primary database to timely obtain the receiving condition of the backup database for the previous log information corresponding to the transaction, so as to determine whether the user can be notified that the transaction commit request is completed.

Further, a feedback device 125 (not shown) is included in the backup database, and the feedback device 125 sends feedback information confirming that the previous log information corresponding to the transaction has been received to the primary database. The method refers to a situation that the backup database sends feedback information to the main database so that the main database obtains whether the backup database has received the prior log information corresponding to the transaction, wherein the feedback information comprises whether the backup database has received the prior log information corresponding to the transaction. The feedback information includes, but is not limited to, periodic feedback, or feedback sent after completion according to a certain condition, for example, the feedback information is used to help the primary database to timely obtain the receiving condition of the backup database for the previous log information corresponding to the transaction, so as to determine whether the user can be notified that the transaction commit request is completed.

Next, the notification device 114 in the primary database sends a transaction commit completion notification corresponding to the transaction commit request to the user when the backup database has received the previous log information corresponding to the transaction. Namely confirming that the standby database has received the transaction number of the transaction corresponding to the transaction and the log number of the latest log of the transaction before receiving the transaction submission request at the primary database, and the latest log and related log information of the transaction before the transaction commit request is received, at this time, the transaction commit operation of the transaction to which the transaction commit request corresponds is not necessarily performed to completion, all information before the transaction commit request, including the transaction number, the log number, and the log, can wait for completion and then notify the user that the transaction commit request operation is completed if the information is not backed up by the backup database, the method and the device have the advantages that the last transaction submitting operation and the corresponding log backup are not required to be waited for to be completed, so that the time for waiting for the log submission corresponding to the last transaction submitting operation is saved, and the speed of the database transaction submitting operation is increased.

Next, when detecting that the corresponding primary database is abnormal, the primary/secondary switching device 122 in the backup database switches the backup database to a new primary database. In the primary and standby synchronous mode of the database, for example, the primary database is connected to update the heartbeat table after the primary and standby switching conditions are met, if the primary database is judged to be abnormal due to timeout, the situation that the primary database fails or is down to provide services normally is not limited to the situation, and the switching mode includes but is not limited to disconnecting the service of the primary database and establishing connection between the primary database and related applications or services by using the standby database instead of the primary database. In the switching process, the standby database can traverse all the logs which are not applied yet for return visit, and if some transactions lack a commit operation, the transactions are in an uncommitted state in the return visit process. After the return visit is completed, the state of all the transactions is checked, and the uncommitted transaction is the transaction which may need to be completed with the commit operation.

After the standby database is switched to a new primary database, and before providing services, the log completion unit 123 and the data recovery unit 124 perform the following operations:

the log completion device 123 regenerates the corresponding transaction commit request and executes the transaction commit operation for the to-be-completed transaction in the new master database, so as to obtain the completed log information. Because the transaction submitting operation of the transaction corresponding to the transaction submitting request is executed and completed by the master database before the master database notifies the user that the operation corresponding to the transaction submitting request is completed, and all information before the transaction submitting request, including the transaction number, the log, and the like, is backed up by the standby database, it is ensured that when the master database notifies the user that the operation corresponding to the transaction submitting request is completed, the master log of the transaction corresponding to the transaction submitting request is sent to the standby database, but the notification can be sent without waiting for the synchronous completion of the operation log corresponding to the transaction submitting request, so that the operation log corresponding to the transaction submitting request may not be received by the standby database, and at this time, the standby database is switched to a new master database, and the operation log corresponding to the transaction submitting request is lost compared with the original master database, therefore, after the standby database is switched to a new main database, before providing service, the transaction number of the corresponding transaction, the log number of the latest log of the transaction before receiving the transaction commit request, and all logs corresponding to the transaction need to be detected, and if the log number of the latest log of the transaction before receiving the transaction commit request is detected but the log corresponding to the transaction commit operation is not detected, a transaction commit request is regenerated from the log number and the transaction number and is put into the log corresponding to the transaction to complete the log corresponding to the transaction.

Then, the data recovery device 124 performs a playback operation on the new master database according to the completed log information, so as to restore the database to be consistent. That is, according to the related operation information in the log information, the part which has not been backed up in the new primary database is played back, so that the part which has been recorded in the log and has been subjected to data change in the primary database and not subjected to synchronous change in the new primary database can be subjected to synchronous change, for example, the log information includes a transaction commit request but has not been submitted in the standby database, and therefore, the same transaction in the new primary database is submitted according to the transaction commit request in the log information, so as to complete the missing data information, and the state of the database data is restored to the previous primary database, which ensures that no data is lost.

Fig. 4 is a schematic diagram of a log completion apparatus in a device for implementing transaction commit in a primary/standby synchronization mode according to another preferred embodiment of the present application. The log completion device comprises a to-be-completed transaction determination unit 1231 and a log completion unit 1232.

The to-be-complemented transaction determining unit 1231 determines a to-be-complemented transaction according to the log number information and the transaction number information in the new master database, where the to-be-complemented transaction is submitted but a corresponding log is not yet sent to the new master database; the log completion unit 1232 regenerates the corresponding transaction commit request according to the log number of the transaction to be completed and the transaction number, and executes the transaction commit operation to obtain the completed log information.

Specifically, the to-be-complemented transaction determining unit 1231 determines a to-be-complemented transaction according to the log number information and the transaction number information in the new master database, where the to-be-complemented transaction is already submitted but a corresponding log is not yet sent to the new master database. Namely, whether the new master database has missing log information needing to be replenished is determined according to the log number information and the transaction number information in the new master database. For example, after the standby database is switched to a new master database, the transaction number of the corresponding transaction, the log number of the latest log of the transaction before receiving the transaction commit request, and all logs corresponding to the transaction are detected before providing service, because the previous master database immediately sends the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request to the standby database, that is, the current new master database, after receiving the transaction commit request of the user, if the transaction number of the corresponding transaction and the log number of the latest log of the transaction before receiving the transaction commit request are detected, it is determined that the previous master database has received the transaction commit request of the user, the log corresponding to the transaction commit operation continues to be detected, and if the transaction number of the corresponding transaction is not detected, it indicates that the transaction to be complemented has been committed but the corresponding log has not yet been sent to the new master database, therefore, the to-be-complemented transaction is determined to avoid data loss caused by inconsistency of the new main database. The method for determining the to-be-complemented transaction also comprises the steps that the standby database traverses all logs which are not applied yet, return visit is carried out, if some transactions lack a commit operation, the transactions are in an uncommitted state in the return visit process, after the return visit is completed, the states of all transactions are checked, and the uncommitted transactions are transactions which possibly need to be complemented with the commit operation.

Then, the log completion unit 1232 regenerates the corresponding transaction commit request according to the log number of the transaction to be completed and the transaction number, and executes the transaction commit operation to obtain the completed log information. Because the missing is the log corresponding to the last transaction commit request, a transaction commit request is regenerated from the log number and the transaction number, for example, a log corresponding to a commit statement is regenerated and put into the log corresponding to the transaction, i.e., the log corresponding to the transaction can be completed.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, implemented using Application Specific Integrated Circuits (ASICs), general purpose computers or any other similar hardware devices. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions described above. Likewise, the software programs (including associated data structures) of the present application may be stored in a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. Additionally, some of the steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

In addition, some of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application through the operation of the computer. Program instructions which invoke the methods of the present application may be stored on a fixed or removable recording medium and/or transmitted via a data stream on a broadcast or other signal-bearing medium and/or stored within a working memory of a computer device operating in accordance with the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform a method and/or a solution according to the aforementioned embodiments of the present application.

It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. A plurality of units or means recited in the apparatus claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.

Claims

1. A method for transaction submission in a master-slave synchronization mode at a master database server side is provided, wherein the method comprises:

2. The method of claim 1, wherein the prior log information corresponding to the transaction comprises:

the transaction number and the log number;

log information of the transaction prior to the log number.

3. The method of claim 1, wherein said performing a transaction commit operation of the transaction in the master database comprises:

and generating log information corresponding to the transaction submitting operation, and storing the log information.

4. The method of any of claims 1 to 3, wherein the detecting whether the standby database has received prior log information corresponding to the transaction comprises:

and receiving feedback information sent by the standby database, wherein the feedback information indicates that the standby database has received prior log information corresponding to the transaction.

5. A method for realizing transaction submission in a master-slave synchronization mode at a standby database server side is disclosed, wherein the method comprises the following steps:

and performing playback operation on the new master database according to the completed log information so as to enable the new master database to be consistent with the master database before switching.

6. The method of claim 5, wherein the method further comprises:

and sending feedback information for confirming that the prior log information corresponding to the transaction is received to the main database.

7. The method of claim 5 or 6, wherein the regenerating a corresponding transaction commit request and performing a transaction commit operation for the to-be-complemented transaction in the new master database to obtain complemented log information comprises:

determining a transaction to be complemented according to the log number information and the transaction number information in the new master database, wherein the transaction to be complemented is submitted but a corresponding log is not sent to the new master database;

and regenerating a corresponding transaction submitting request according to the log number and the transaction number of the transaction to be complemented, and executing transaction submitting operation to obtain complemented log information.

8. A master database server side device for implementing transaction submission in a master-slave synchronization mode, wherein the device comprises:

9. The apparatus of claim 8, wherein the prior log information corresponding to the transaction comprises:

the transaction number and the log number;

log information of the transaction prior to the log number.

10. The apparatus of claim 8, wherein the execution means is to:

11. The apparatus of any of claims 8 to 10, wherein the detection device is to:

12. A backup database server-side device for implementing transaction commit in a master-backup synchronization mode, wherein the device comprises:

and the data recovery device is used for executing playback operation on the new master database according to the completed log information so as to enable the new master database to be consistent with the master database before switching.

13. The apparatus of claim 12, wherein the apparatus further comprises:

and the feedback device is used for sending feedback information for confirming that the prior log information corresponding to the transaction is received to the main database.

14. The apparatus of claim 12 or 13, wherein the log completion means comprises:

a to-be-complemented transaction determining unit, configured to determine a to-be-complemented transaction according to the log number information and the transaction number information in the new master database, where the to-be-complemented transaction is submitted but a corresponding log is not yet sent to the new master database;

and the log completion unit is used for regenerating a corresponding transaction submission request according to the log number of the transaction to be completed and the transaction number, and executing transaction submission operation to obtain the completed log information.

15. A system for implementing transaction commit in a master-slave synchronous mode, wherein the system comprises a primary database server-side device according to any one of claims 8 to 11 and a backup database server-side device according to any one of claims 12 to 14.