CN106168919A - A kind of database backup method, Apparatus and system - Google Patents

Abstract

The invention provides a database backup method, device and system, the method comprising: according to the log file of the source database, obtaining the record information corresponding to each write operation; according to the obtained record information corresponding to each write operation , determine at least one type of record information, and each type of record information corresponds to the same type of write operation; according to the type of write operation corresponding to each type of record information, establish a common index for this type of record information, and for this type of record information Perform compression; send the compressed record information of each type to the target database corresponding to the source database. The target database can back up the source database by performing corresponding write operations according to the received record information. Compared with the log file, the occupied space of the compressed record information is significantly reduced, so the sending of the record information can occupy less network resources. Therefore, this solution can reduce the occupation of network resources.

Description

A database backup method, device and system

technical field

The invention relates to the field of computer technology, in particular to a database backup method, device and system.

Background technique

With the deepening of computers in the field of data analysis applications, the scope of database usage requirements has gradually expanded, and the status and role of databases in application systems has become more and more important. Therefore, in the development and use of database-based systems, it is necessary to pay attention to the security of the database. For example, the best solution to ensure database security is to make timely data backups.

Currently, any operation performed in the source database can be recorded in the log file of the source database. By sending the log file to other databases, other databases can perform the same operation and processing according to the log file, so as to maintain consistency with the source database, so as to realize database backup.

Since the space occupied by the log file is generally large, the implementation of directly sending the log file will occupy more network resources.

Contents of the invention

The invention provides a database backup method, device and system, which can reduce the occupation of network resources.

In order to achieve the above object, the present invention is achieved through the following technical solutions:

In a first aspect, the present invention provides a database backup method, comprising:

Obtain the record information corresponding to each write operation in the log file of the source database;

Determine at least one type of record information according to the acquired record information corresponding to each write operation, and each type of record information corresponds to the same type of write operation;

According to the write operation type corresponding to each type of record information, establish a common index of this type of record information, and compress this type of record information;

Send the compressed record information of each type to the target database corresponding to the source database.

Further, the write operation type includes: at least one of insert (insert), update (update), delete (delete), and for update (update).

Further, the compressing this type of record information includes: according to the established common index of this type of record information, deleting the same content as the common index in this type of record information, so as to compress this type of record information .

Further, the sending the compressed record information of each type to the target database corresponding to the source database includes: generating a compressed log file with a fixed format including the compressed record information of each type, and sending the The compressed log file is sent to the target database corresponding to the source database.

In a second aspect, the present invention provides a database backup device, comprising:

The obtaining unit is used to obtain the record information corresponding to each write operation in the log file of the source database;

A determining unit, configured to determine at least one type of record information according to the acquired record information corresponding to each write operation, and each type of record information corresponds to the same type of write operation;

A compression unit, configured to establish a common index for each type of record information according to the type of write operation corresponding to the type of record information, and compress the type of record information;

The sending unit is configured to send the compressed record information of each type to the target database corresponding to the source database.

Further, the write operation type includes: at least one of insert, update, delete, and for update.

Further, the compressing unit is specifically configured to, according to the established common index of this type of record information, delete the same content as the common index in this type of record information, so as to compress this type of record information.

Further, the sending unit is specifically configured to generate a compressed log file with a fixed format including compressed record information of each type, and send the compressed log file to the target database corresponding to the source database.

In a third aspect, the present invention provides a database backup system, comprising:

A source database, a target database corresponding to the source database, and any of the database backup devices described above, wherein,

The target database is configured to receive the compressed record information of each type sent by the database backup device; and perform a corresponding write operation according to the compressed record information of each type.

Further, the target database is also configured to periodically send a heartbeat request to the source database according to a predetermined two-way heartbeat detection mechanism and a heartbeat request time interval; receive a heartbeat packet returned by the source database; determine the Whether the information included in the heartbeat packet is the same as the predetermined information, if not, it is determined that the source database is faulty.

Further, the target database is specifically configured to receive the heartbeat packet returned by the source database, and the heartbeat packet carries the MAC (Media Access Control, Media Access Control) address corresponding to the source database; according to the received The MAC address corresponding to the source database and the MAC address corresponding to itself, execute the hash algorithm to obtain the current hash value; judge whether the current hash value is the same as the predetermined standard value, if not, determine the The source database is down.

Further, the target database is also used to determine the current heartbeat request time interval when it is determined that the heartbeat packet returned by the source database has not been received, and the current heartbeat request time interval is shorter than the corresponding last heartbeat The request time interval, based on the current heartbeat request time interval, sends a heartbeat request to the source database, and loops like this; when it is judged that the heartbeat packet returned by the source database has not been received at least twice in a row, determine the The source database failed.

The present invention provides a database backup method, device and system. According to the log file of the source database, the record information corresponding to each write operation is obtained; according to the obtained record information corresponding to each write operation, the At least one type of record information, and each type of record information corresponds to the same type of write operation; according to the type of write operation corresponding to each type of record information, a common index of this type of record information is established, and the type of record information is compressed; The compressed record information of each type is sent to the target database corresponding to the source database. The target database can back up the source database by performing corresponding write operations according to the received record information. Compared with the log file, the occupied space of the compressed record information is significantly reduced, so the sending of the record information can occupy less network resources. Therefore, the present invention can reduce the occupation of network resources.

Description of drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are For some embodiments of the present invention, those skilled in the art can also obtain other drawings based on these drawings without creative work.

Fig. 1 is a flow chart of a database backup method provided by an embodiment of the present invention;

Fig. 2 is a flowchart of another database backup method provided by an embodiment of the present invention;

Fig. 3 is a schematic diagram of a database backup device provided by an embodiment of the present invention;

Fig. 4 is a schematic diagram of a database backup system provided by an embodiment of the present invention.

detailed description

In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments It is a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the protection of the present invention. scope.

As shown in Figure 1, the embodiment of the present invention provides a database backup method, which may include the following steps:

Step 101: Obtain record information corresponding to each write operation in the log file of the source database.

Step 102: Determine at least one type of record information according to the acquired record information corresponding to each item of write operation, and each type of record information corresponds to the same type of write operation.

Step 103: According to the write operation type corresponding to each type of record information, establish a common index of this type of record information, and compress the type of record information.

Step 104: Send the compressed record information of each type to the target database corresponding to the source database.

An embodiment of the present invention provides a database backup method. According to the log file of the source database, the record information corresponding to each write operation is obtained; according to the obtained record information corresponding to each write operation, at least one of them is determined. Each type of record information corresponds to the same type of write operation; according to the type of write operation corresponding to each type of record information, a common index of this type of record information is established, and this type of record information is compressed; the compressed Each type of record information is sent to the target database corresponding to the source database. The target database can back up the source database by performing corresponding write operations according to the received record information. Compared with the log file, the occupied space of the compressed record information is significantly reduced, so the sending of the record information can occupy less network resources. Therefore, the present invention can reduce the occupation of network resources.

In an embodiment of the present invention, the write operation type includes: at least one of insert, update, delete, and forupdate.

In detail, the SQL (Structured Query Language, Structured Query Language) statement corresponding to the write operation may include at least one keyword among insert, update, delete, and for update, and each keyword corresponds to a write operation Types of.

In an embodiment of the present invention, in order to illustrate a compression method of record information, the compressing this type of record information includes: deleting the The same content as the common index, so as to compress this type of record information.

Specifically, by deleting the same content in the same type of record information as the corresponding common index, the space resources occupied by this part of the content can be released, so that the occupied space of this type of record information can be reduced.

In an embodiment of the present invention, the sending the compressed record information of each type to the target database corresponding to the source database includes: generating a compressed log with a fixed format including the compressed record information of each type file, and send the compressed log file to the target database corresponding to the source database.

In detail, after the compression operation is performed on each type of record information, a compressed log file with a fixed format may be generated, and the compressed log file may include each type of compressed record information. By sending the compressed log file to the target database, the target database can perform every write operation the same as the source database according to the compressed log file, thereby completing the backup from the source database to the target database.

As shown in Fig. 2, an embodiment of the present invention provides another kind of database backup method, and this method takes database backup and fault detection management method based on log as an example, specifically comprises the following steps:

Step 201: Create a resource management group on a unified resource management platform, and the resource management group includes a source database and a target database.

In detail, when the source database needs to be backed up, the source database and the target database to be backed up can be set in the same resource management group on the same resource management platform.

In this embodiment, the source database and the target database may have a one-to-one correspondence.

In addition, in an embodiment of the present invention, a target database can correspond to at least one source database, so as to realize the aggregation of data backup, the target database can be used as a mirror image of each source database; and a source database can correspond to at least one target database to realize the broadcast of data backup, and each target database can be used as a mirror image of the source database.

Step 202: Create a database space corresponding to the source database on the local host, and create a database space corresponding to the target database on the destination host.

To implement backup of the target database to the source database, you can create the dbspaces required by the source database on one host and the dbspaces required by the target database on another host.

In detail, the database space corresponding to the created target database may not be smaller than the database space corresponding to the created source database. Usually, the size of the two database spaces can be set to be equal, and the target database can be a mirror image of the real-time replication of the source database.

As mentioned above, in one embodiment of the present invention, when a target database corresponds to multiple source databases, the database space of the target database should not be less than the sum of the database spaces of the multiple source databases; database, the dbspace of each target database should not be smaller than the dbspace of the source database.

Step 203: Obtain the log file of the source database, and obtain the record information corresponding to each write operation in the log file.

In detail, the write operation type may include: at least one of insert, update, delete, and for update.

Since the log file of the source database occupies a large amount of space, sending the log file directly will occupy more network resources, so only the necessary information in the log file can be extracted, for example, the record information corresponding to the write operation can be intercepted.

Step 204: Determine at least one type of record information according to the acquired record information corresponding to each write operation, and each type of record information corresponds to the same type of write operation.

Since different types of write operations correspond to different execution modes, the acquired record information corresponding to all write operations may be classified.

Step 205: According to the write operation type corresponding to each type of record information, establish a common index of this type of record information, and delete the same content as the common index in this type of record information according to the established common index, so as to Class record information is compressed.

For each type of record information, each item of record information in this type of record information includes the same index content. When there are many items of record information with the same index content, the index content will occupy more log resources. Therefore, according to the index content included in each type of record information, a common index of this type of record information can be established, and the In this type of record information, the same index content as the shared index is screened out, so as to realize the compression of this type of record information.

Step 206: Generate a compressed log file with a fixed format including compressed record information of each type, and send the compressed log file to the target database corresponding to the source database.

In order to facilitate the real-time backup of the source database, a compressed log file can be generated, which includes each type of recorded information after compression, and the compressed log file has a fixed format recognizable by the system.

The resulting compressed log file has a significantly reduced data size compared to the log file originally acquired from the source database. For example, under normal circumstances, the data volume of the compressed log file may be about 1/4 of the original log file. It can be seen that the occupied space of the compressed log file is greatly reduced, and the network transmission of the compressed log file will correspondingly occupy less basic bandwidth and network resources during data backup.

In detail, the sending of compressed log files can be performed on the order of sub-second level.

Step 207: When receiving the compressed log file, the target database executes a corresponding write operation according to the compressed log file.

Specifically, the target database can decompress the received compressed log file, and perform each write operation according to the decompressed log. By performing each write operation, the target database can be modified the same as the source database, so the backup from the source database to the target database can be realized.

In the embodiment of the present invention, the log files of the source database are compressed, and the compressed log files are transmitted to the target database, so as to realize real-time backup from the source database to the target database. This implementation method can consume less database resources and provide convenience for real-time synchronization of the database, so it can be an efficient database backup method.

Step 208: The target database periodically sends a heartbeat request to the source database according to a predetermined two-way heartbeat detection mechanism and a heartbeat request time interval.

In the embodiment of the present invention, an appropriate heartbeat request time interval can be determined according to actual needs, such as 10s, that is, a fault detection is performed every 10s, so that when the source database fails, the fault can be detected in time and corresponding fault handling can be performed.

Step 209: When the heartbeat packet receiving time corresponding to the heartbeat request time interval is reached, the target database judges whether it has received the heartbeat packet returned by the source database, if so, execute step 212, otherwise, execute step 210.

The target database receives the heartbeat packet from the source database every 10s. There are two ways to determine the failure of the source database: one is that the heartbeat packet has not been received for many times in a row, and the other is that the received heartbeat packet is wrong. At an interval of 10s, the target database can first determine whether it has received a heartbeat packet.

In an embodiment of the present invention, at the same time, the source database can send a heartbeat request to the target database to determine whether the target database is faulty. Since the heartbeat request with the target database can be based on the same implementation principle, details are not described here.

In one embodiment of the present invention, when one end detects that the heartbeat packet receiving time has been reached, but does not receive the heartbeat packet sent by the other end, if one end fails to ping the opposite end within 10s, an alarm will be sent and recorded Fault condition at this time.

Step 210: Determine whether the heartbeat packet returned by the source database has not been received for three consecutive times, if yes, determine that the source database is faulty, and end the current process, otherwise, execute step 211.

In this embodiment, it can be set that when the heartbeat packet is not received for three consecutive times, it can be considered that the source database is faulty. Of course, according to different actual needs, it can also be determined as other consecutive times.

When the target database judges that the heartbeat packet has not been received, it can further judge whether it has not received the heartbeat packet for three consecutive times. If the judgment result is yes, it can directly determine that the source database is faulty. If the judgment result is no, it can try to obtain it again. heartbeat packet.

Step 211: Determine the current heartbeat request time interval, and the current heartbeat request time interval is less than the corresponding previous heartbeat request time interval, and based on the determined current heartbeat request time interval, send a heartbeat request to the source database, and execute step 209 .

If the current heartbeat packet is not received for the first time, you can determine that the last heartbeat request interval is 10s, and determine that the current heartbeat request interval is less than 10s, such as 5s, and based on the determined 5s interval, obtain the heartbeat again Bag. Correspondingly, if the heartbeat packet is not received when the time interval of 5s is reached, it is currently the second time that the heartbeat packet has not been received, then it can be determined that the last heartbeat request time interval is 5s, and the current heartbeat request time interval is determined to be less than 5s, For example, it is 2s, and based on the determined 2s interval, the heartbeat packet is obtained again.

Therefore, in this embodiment, the heartbeat request time intervals corresponding to no heartbeat packets being received three times may be set to be 10s, 5s, and 2s in sequence. That is, when the heartbeat packet is not received at the 10s interval, the heartbeat packet is obtained again at the interval of 5s. If the heartbeat packet is not received yet, the heartbeat packet is obtained again at the interval of 2s. If the heartbeat packet is not received three times, then It is straightforward to determine that the source database is down.

Under normal circumstances, you can set a relatively long heartbeat request interval to periodically check whether the source database is in a normal working state. However, when it is detected that the heartbeat packet from the source database has not been received, the heartbeat request time interval can be reduced in order to quickly verify whether the source database is faulty, so that the fault can be found and resolved in time.

Step 212: The target database judges whether the information included in the heartbeat packet is the same as the predetermined information according to the heartbeat packet returned by the source database, and if so, determines that the source database is working normally; otherwise, determines that the source database is faulty.

When the target database receives the heartbeat packet, it can determine whether the heartbeat packet is wrong.

In detail, in the embodiment of the present invention, the heartbeat packet sent by the source database may carry the MAC address corresponding to the source database, and the target database may perform hashing according to the received MAC address corresponding to the source database and its own corresponding MAC address. Algorithm to get the current hash value. Then, it is judged whether the obtained current hash value is the same as the predetermined standard value, if so, it can be determined that the source database is working normally, otherwise, it can be determined that the source database is faulty.

In one embodiment of the present invention, the target database can send a heartbeat packet with fixed content to the source database, and the source database can perform fixed changes to the fixed content according to predetermined data modification rules, and send the changed heartbeat packet to the target database, if the target database determines that the fixed change is correct, it can be determined that the source database is working normally; otherwise, it can be determined that the source database is faulty.

Specifically, data synchronization between databases and database failure detection can be performed based on database logs, bidirectional heartbeat mechanism and network communication between the two ends. In addition, managers can also monitor the entire synchronization process through a unified management platform, and detect and deal with abnormal problems in a timely manner according to the logs of the management platform. This implementation method can realize functions such as mirror replication of local databases, high security and high availability of remote disaster recovery.

Based on the implementation of the embodiment of the present invention, sub-second level real-time replication of a large amount of data can be realized between heterogeneous IT infrastructures, wherein the heterogeneous IT infrastructures can include almost all commonly used operating system platforms and database platforms . Therefore, the embodiments of the present invention can be applied in various scenarios such as emergency systems, online reports, real-time data warehouse supply, transaction tracking, data synchronization, centralization/distribution, disaster recovery, database upgrade and transplantation, and dual business centers. In addition, various flexible topological structures such as one-to-one, one-to-many, many-to-one, two-way, point-to-point, and cascade can be realized.

As shown in Figure 3, an embodiment of the present invention provides a database backup device 30, including:

An acquisition unit 301, configured to acquire record information corresponding to each write operation in the log file of the source database;

A determining unit 302, configured to determine at least one type of record information according to the acquired record information corresponding to each item of write operation, and each type of record information corresponds to the same type of write operation;

The compression unit 303 is configured to, according to the write operation type corresponding to each type of record information, establish a common index of this type of record information, and compress the type of record information;

The sending unit 304 is configured to send the compressed record information of each type to the target database corresponding to the source database.

In an embodiment of the present invention, the write operation type includes: at least one of insert, update, delete, and forupdate.

In an embodiment of the present invention, the compression unit 303 is specifically configured to delete the same content as the common index in this type of record information according to the established common index of this type of record information, so as to to compress.

In an embodiment of the present invention, the sending unit 304 is specifically configured to generate a compressed log file with a fixed format including compressed record information of each type, and send the compressed log file to the source database corresponding to target database.

As shown in Figure 4, the embodiment of the present invention provides a kind of database backup system, comprises:

The source database 40, the target database 50 corresponding to the source database 40, and any of the database backup devices 30 described above, wherein,

The target database 50 is configured to receive the compressed record information of each type sent from the database backup device 30 ; and perform corresponding write operations according to the compressed record information of each type.

In an embodiment of the present invention, one source database 40 may correspond to at least one target database 50 ; and one target database 50 may correspond to at least one source database 40 . In addition, the database backup device 30 may correspond to at least one combination of the source database 40 and the target database 50 .

In one embodiment of the present invention, the target database 50 is further configured to periodically send a heartbeat request to the source database according to a predetermined two-way heartbeat detection mechanism and a heartbeat request time interval; A heartbeat packet: judging whether the information included in the heartbeat packet is the same as predetermined information, and if not, determining that the source database is faulty.

In one embodiment of the present invention, the target database 50 is specifically configured to receive the heartbeat packet returned by the source database, and the heartbeat packet carries the MAC address corresponding to the source database; according to the received The MAC address corresponding to the source database and the MAC address corresponding to itself, execute the hash algorithm to obtain the current hash value; judge whether the current hash value is the same as the predetermined standard value, if not, determine the source database error occured.

In one embodiment of the present invention, the target database 50 is further used to determine the current heartbeat request time interval when it is determined that the heartbeat packet returned by the source database has not been received, and the current heartbeat request time interval is less than the corresponding last heartbeat request time interval, based on the current heartbeat request time interval, send a heartbeat request to the source database, and so on; when it is determined that the heartbeat returned by the source database has not been received at least twice in a row package, it was determined that the source database was down.

The information exchange and execution process among the units in the above-mentioned device are based on the same concept as the method embodiment of the present invention, and the specific content can refer to the description in the method embodiment of the present invention, and will not be repeated here.

In summary, each embodiment of the present invention has at least the following beneficial effects:

1. In the embodiment of the present invention, according to the log file of the source database, the record information corresponding to each write operation is obtained; according to the record information corresponding to each write operation obtained, at least one type of record information is determined, And each type of record information corresponds to the same write operation type; according to the write operation type corresponding to each type of record information, a common index of this type of record information is established, and this type of record information is compressed; each type of compressed The record information is sent to the target database corresponding to the source database. The target database can back up the source database by performing corresponding write operations according to the received record information. Compared with the log file, the occupied space of the compressed record information is significantly reduced, so the sending of the record information can occupy less network resources. Therefore, the present invention can reduce the occupation of network resources.

2. In the embodiment of the present invention, the log files of the source database are compressed, and the compressed log files are transmitted to the target database, so as to realize real-time backup from the source database to the target database. This implementation method can consume less database resources and provide convenience for real-time synchronization of the database, so it can be an efficient database backup method.

3. In the embodiment of the present invention, under normal circumstances, a relatively long time interval for heartbeat requests can be set to periodically check whether the source database is in a normal working state. However, when it is detected that the heartbeat packet from the source database has not been received, the heartbeat request time interval can be reduced in order to quickly verify whether the source database is faulty, so that the fault can be found and resolved in time.

4. In the embodiment of the present invention, based on the implementation of the embodiment of the present invention, sub-second level real-time replication of a large amount of data can be realized between heterogeneous IT infrastructures, wherein the heterogeneous IT infrastructures can include almost All common operating system platforms and database platforms. Therefore, the embodiments of the present invention can be applied in various scenarios such as emergency systems, online reports, real-time data warehouse supply, transaction tracking, data synchronization, centralization/distribution, disaster recovery, database upgrade and transplantation, and dual business centers. In addition, various flexible topological structures such as one-to-one, one-to-many, many-to-one, two-way, point-to-point, and cascade can be realized.

It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is a relationship between these entities or operations. There is no such actual relationship or sequence. Furthermore, the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article or apparatus comprising a set of elements includes not only those elements, but also includes elements not expressly listed. other elements of or also include elements inherent in such a process, method, article, or device. Without further limitations, an element defined by the phrase "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

Those of ordinary skill in the art can understand that all or part of the steps for realizing the above-mentioned method embodiments can be completed by hardware related to program instructions, and the aforementioned programs can be stored in a computer-readable storage medium. When the program is executed, the It includes the steps of the above method embodiments; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other various media that can store program codes.

Finally, it should be noted that: the above descriptions are only preferred embodiments of the present invention, and are only used to illustrate the technical solutions of the present invention, and are not used to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present invention are included in the protection scope of the present invention.

Claims (10)

1. A database backup method, characterized in that, comprising: According to the log file of the source database, obtain the record information corresponding to each write operation; Determine at least one type of record information according to the acquired record information corresponding to each write operation, and each type of record information corresponds to the same type of write operation; According to the write operation type corresponding to each type of record information, establish a common index of this type of record information, and compress this type of record information; Send the compressed record information of each type to the target database corresponding to the source database. 2. The method of claim 1, wherein, The write operation type includes: at least one of insert, update, delete, and update for update; and / or, The compressing the recording information of this type includes: according to the established common index of the recording information of this type, deleting the same content as the common index in the recording information of this type, so as to compress the recording information of this type. 3. The method according to claim 1 or 2, characterized in that, The sending of each type of compressed record information to the target database corresponding to the source database includes: generating a compressed log file with a fixed format that includes each type of compressed record information, and storing the compressed log file Send to the target database corresponding to the source database. 4. A database backup device, characterized in that, comprising: The obtaining unit is used to obtain the record information corresponding to each write operation in the log file of the source database; A determining unit, configured to determine at least one type of record information according to the acquired record information corresponding to each write operation, and each type of record information corresponds to the same type of write operation; A compression unit, configured to establish a common index for each type of record information according to the type of write operation corresponding to the type of record information, and compress the type of record information; The sending unit is configured to send the compressed record information of each type to the target database corresponding to the source database. 5. The database backup device according to claim 4, characterized in that, The write operation type includes: at least one of insert, update, delete, and update for update; and / or, The compressing unit is specifically configured to, according to the established common index of this type of record information, delete the same content as the common index in this type of record information, so as to compress this type of record information. 6. The database backup device according to claim 4 or 5, characterized in that, The sending unit is specifically configured to generate a compressed log file with a fixed format including compressed record information of each type, and send the compressed log file to the target database corresponding to the source database. 7. A database backup system, characterized in that, comprising: A source database, a target database corresponding to the source database, and the database backup device according to any one of claims 4 to 6, wherein, The target database is configured to receive the compressed record information of each type sent by the database backup device; and perform a corresponding write operation according to the compressed record information of each type. 8. database backup system according to claim 7, is characterized in that, The target database is further configured to periodically send a heartbeat request to the source database according to a predetermined two-way heartbeat detection mechanism and a heartbeat request time interval; receive a heartbeat packet returned by the source database; determine whether the heartbeat packet contains Whether the included information is the same as the predetermined information, if not, it is determined that the source database is faulty. 9. database backup system according to claim 8, is characterized in that, The target database is specifically configured to receive a heartbeat packet returned by the source database, and the heartbeat packet carries a media access control MAC address corresponding to the source database; according to the received MAC address corresponding to the source database Executing a hash algorithm for the MAC address corresponding to itself to obtain a current hash value; judging whether the current hash value is the same as a predetermined standard value, and if not, determining that the source database is faulty. 10. The database backup system according to any one of claims 7 to 9, characterized in that, The target database is further configured to determine the current heartbeat request time interval when it is determined that the heartbeat packet returned by the source database has not been received, and the current heartbeat request time interval is less than the corresponding previous heartbeat request time interval , based on the current heartbeat request time interval, send a heartbeat request to the source database, and loop like this; when it is determined that the heartbeat packet returned by the source database has not been received at least twice in a row, it is determined that the source database has Fault.