Log backup method and device, database system and computing equipment

Abstract

The embodiment of the invention provides a log backup method and device, a database system and computing device.The log backup method is applied to the database system and comprises the steps that a logic log, generated through triggering, of a first data operation instruction in a target transaction is obtained, and the target transaction comprises multiple data operation instructions; the first data operation instruction is any one of a plurality of data operation instructions, and the logic log is generated by executing the first data operation instruction to complete modification operation on main library data; copying the logic log in real time and sending the logic log to the standby library, and returning to execute the step of obtaining the logic log of the first data operation instruction generated by triggering in the target transaction; and under the condition that the standby library receives the logic logs of the data operation instructions of the target transaction, submitting the logic logs of the data operation instructions. Through real-time transmission of the logic log, the risk of degradation to asynchronous replication caused by timeout is reduced, and the stability, availability and response speed of a database system are enhanced.

Description

Technical Field

[0001] The embodiments of this specification relate to the technical field of databases, and more particularly to a log backup method, device, database system, and computing equipment. Background Art

[0002] With the development of database technology, in order to cope with the continuous growth of data volume and the complexity of project requirements, log backup is needed to ensure the security and recoverability of data. Log backup is an important disaster recovery method, which can provide a basis for data recovery when system failure or unexpected events occur.

[0003] At present, in order to improve the reliability and consistency of log backup, semi-synchronous replication can be considered. Semi-synchronous replication stipulates that before the logical log of a transaction is submitted to the primary database, it is necessary to wait for its logical log to be transmitted to the standby database and confirm that the standby database has successfully received the logical log before the submission of the logical log can be completed in the primary database, thereby reducing the risk of data loss and ensuring data reliability.

[0004] However, the master database generally needs to execute multiple transactions. Once the process of transferring the logical log of a transaction to the standby database takes too long, the master database will degenerate into asynchronous replication and immediately submit the logical log of this transaction, which may cause inconsistent data on the master database, reduce the integrity and consistency of the data on the database system, and further reduce the availability and stability of the database system. Therefore, a log backup method that maintains high availability and high stability of the database system is urgently needed. Summary of the invention

[0005] In view of this, an embodiment of this specification provides a log backup method. One or more embodiments of this specification also relate to a log backup device, a database system, a computing device, a computer-readable storage medium and a computer program product to solve the technical defects existing in the prior art.

[0006] According to a first aspect of an embodiment of this specification, a log backup method is provided, which is applied to a database system, and includes: Acquire a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered and generated by executing the first data operation instruction to complete a modification operation on the primary database data; The logical log is copied in real time and sent to the standby database, and the step of returning to execute the step of obtaining the logical log of the first data operation instruction in the target transaction generated by the trigger is executed; When the standby database receives the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is submitted.

[0007] According to a second aspect of an embodiment of this specification, a log backup device is provided, which is applied to a database system, including: an acquisition module, configured to acquire a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered and generated by executing the first data operation instruction to complete a modification operation on the primary database data; The backup module is configured to copy the logical log in real time and send it to the standby database, and return to execute the step of obtaining the logical log of the first data operation instruction in the target transaction generated by the trigger; The commit module is configured to commit the logical log of each data operation instruction when the standby database receives the logical log of each data operation instruction of the target transaction.

[0008] According to a third aspect of an embodiment of this specification, a database system is provided, including a primary database and a backup database; The primary database is used to obtain a logic log of a first data operation instruction in a target transaction that is triggered and generated, copy the logic log in real time and send it to the standby database, and return to execute the step of obtaining a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is generated by executing the first data operation instruction to complete the modification operation on the primary database data; The standby database is used to receive the logical log sent by the primary database, and when receiving the logical log of the last data operation instruction, generates and sends a receipt confirmation message of the logical log of the last data operation instruction to the primary database; The primary database is further used to submit the logical logs of each data operation instruction of the target transaction when receiving the reception confirmation message of the logical log of the last data operation instruction fed back by the standby database.

[0009] According to a fourth aspect of an embodiment of this specification, a computing device is provided, including: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the log backup method are implemented.

[0010] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the above-mentioned log backup method are implemented.

[0011] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instruction, which implements the steps of the above-mentioned log backup method when executed by a processor.

[0012] An embodiment of the present specification provides a log backup method, which is applied to a database system, including: obtaining a logic log of a first data operation instruction in a target transaction that is triggered, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered to execute the first data operation instruction to complete the modification operation on the main database data; copying the logic log in real time and sending it to a standby database, returning to the step of obtaining the logic log of the first data operation instruction in the target transaction that is triggered; and submitting the logic log of each data operation instruction when the standby database receives the logic log of each data operation instruction of the target transaction.

[0013] By transmitting logical logs in real time, the generated logical logs are pre-transmitted to the standby database during the transaction execution process, rather than waiting until the transaction is committed. This ensures that a high level of consistency can be maintained even in the case of network delays or other abnormalities between the primary and standby databases, reducing the risk of degenerating to asynchronous replication due to timeouts. The transmission of logical logs is completed during transaction processing, which greatly reduces the transmission time during the transaction submission phase, avoids performance jitter caused by long waits for confirmation from the standby database, and thus enhances the stability and response speed of the database system. By synchronously backing up log backups, the risk of data asynchrony between the primary and standby databases is reduced, ensuring data integrity and consistency and improving the availability of the database system. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 It is a flow chart of a log backup method; Figure 2 is a flow chart of a log backup method provided by an embodiment of this specification; Figure 3 It is a flow chart of a log backup method provided by an embodiment of this specification; Figure 4 It is a process flow chart of a log backup method applied to a MySQL database provided by an embodiment of this specification; Figure 5 It is a structural diagram of a log backup device provided by an embodiment of this specification; Figure 6 It is a schematic diagram of the structure of a database system provided by an embodiment of this specification; Figure 7 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0015] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0016] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0017] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0018] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0019] First, the terms involved in one or more embodiments of this specification are explained.

[0020] Binary log (binlog for short): A logical log file in a MySQL database that uses binary numbers to record data operation instructions (SQL statements) that change the database. It is used for data recovery and master-slave replication. It is essential to ensure data consistency and persistence.

[0021] Binary log cache: A cache area that temporarily stores uncommitted logical logs during transaction processing. When a transaction is committed, these logical logs will be written to a permanent binary log file. It is suitable for long transactions to reduce disk I / O.

[0022] Relay log: The slave database is used to store binary log copies transmitted by the master database. Relay logs can be replayed to synchronize data operation instructions that modify the master database data.

[0023] Relay log cache: A cache area that temporarily stores relay logs until they are written to the local relay log files of the standby database. This improves replication efficiency and reduces disk I / O.

[0024] Transaction commit: In a database management system, when all data operation instructions in a transaction are successfully executed, the changes are formally saved permanently to the database. Transaction commit marks the end of the transaction and ensures that all changes in the transaction become part of the database state, while satisfying the ACID properties of the transaction: Atomicity, Consistency, Isolation, and Durability.

[0025] Semi-synchronous replication: A MySQL replication mode that requires at least one standby database to confirm receipt and record the logical log before the primary database can complete the transaction commit, thereby improving data consistency.

[0026] Semi-synchronous replication timeout: A delay is set. If no standby database confirms receipt of the logical log within this time, the primary database will fall back to asynchronous replication mode to ensure that the overall performance of the database system is not greatly affected.

[0027] MySQL: An open source relational database system that supports multiple storage engines and is widely used in Web applications and other applications.

[0028] Data operation instructions: Program statements that perform operations such as inserting, updating, or deleting in the database. They are the main way for users to interact with the database system and are used to manage and modify data in the database. Taking SQL statements as an example, they include but are not limited to: INSERT: Adds a new record to a database table.

[0029] UPDATE: Modify the data of an existing record.

[0030] DELETE: Removes records from a database table.

[0031] SELECT: Query and retrieve data from the database.

[0032] Batch insert (INSERT ... SELECT): Select data from one table and insert into another table.

[0033] Conditional update (UPDATE with JOIN): Use the JOIN statement to update information from multiple tables.

[0034] Conditional deletion (DELETE with JOIN): Delete records based on data in other tables.

[0035] Relational Database Service (RDS): A managed database service provided by the cloud platform that simplifies the process of database deployment, management, and expansion, and provides functions such as high availability and automatic backup.

[0036] High Availability (HA): describes the ability of a system design to provide continuous and stable service and keep running even in the event of component failure. For databases, it means minimizing downtime and data loss risks.

[0037] High availability switch (HA switch): When the primary database fails, the process of automatically or manually transferring traffic to the backup database to ensure service continuity and data availability. This process is as transparent as possible to the end user and does not affect project operations.

[0038] Currently, if there is an interruption or failure in the transmission of the logical log of a large transaction, the standby database may lose part of the logical log, thereby destroying the consistency of the data. Therefore, for the processing of large-scale transactions, it is necessary to consider optimizing the semi-synchronous replication mechanism to reduce the impact of large transactions on the overall system performance while maintaining high availability and consistency of data. Semi-synchronous replication stipulates that before the logical log of a transaction is committed in the primary database, it must wait for its logical log to be transmitted to the standby database and confirm that the standby database has successfully received the logical log before the submission of the logical log can be completed in the primary database.

[0039] However, semi-synchronous replication limits the transaction's logical log to be transmitted to the standby database before it is committed in the primary database. The standby database must confirm that it has successfully received the logical log before the logical log can be committed in the primary database, thereby reducing the risk of data loss and ensuring data reliability. Figure 1 As shown, Figure 1 A flow chart of a log backup method is shown below: In the database management system (DBMS), the main database executes transaction 1, which is a large transaction. The logical log .000001 of this transaction needs to be transferred from the main database to the standby database. During the transmission process, since there is only one transmission channel between the main and standby databases, other transactions (transactions 2 and 3) need to wait for the logical log transmission and submission of transaction 1 to be completed before they can use this transmission channel to complete the log backup. Among them, each transaction includes multiple data operation instructions. As an indivisible work unit, the transaction-level logical log needs to be semi-synchronously replicated. When the order of magnitude of transactions is large, there are many logical logs. After waiting for the logical log transmission of transaction 1, a large transaction, to be completed, the logical logs of other transactions can be transferred to the standby database for backup. The entire instance will be in a non-writable state and blocked. Once the log backup process of transaction 1 takes too long, in order to maintain the performance and response speed of the database system, the primary database will degenerate to asynchronous replication and immediately commit the logical log of transaction 1 without waiting for the backup to be completed, until the backup progress of the logical log catches up with the generation progress of the logical log. During this period, the data reliability of the primary database instance will be greatly reduced. If an HA switching operation occurs, data loss may occur.

[0040] In this case, not only will the submission of the logical log of subsequent transactions be delayed, but it may also cause the performance of the primary database to degrade. In extreme cases, it may even cause the primary database to respond slowly or be unable to process new requests in a timely manner, resulting in data loss, causing data to be out of sync between the primary and standby databases, and reducing the availability and stability of the database system.

[0041] In response to the above problems, a log backup method is provided in this specification. This specification also involves a log backup device, a database system, a computing device, a computer-readable storage medium and a computer program product, which are described in detail one by one in the following embodiments.

[0042] See also Figure 2 , Figure 2 A flow chart of a log backup method provided by an embodiment of the present specification is shown. The method is applied to a database system and includes the following specific steps: Step 202: Obtain a logic log triggered by a first data operation instruction in a target transaction, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered by executing the first data operation instruction to complete a modification operation on the primary database data.

[0043] The database system is a software system that stores and manages data in the database, and generally runs on one or more servers. The database system not only provides persistent storage of data, but also supports efficient access, update, query and management of data. The database system includes a primary database and a backup database, which completes the functions of storage, replication, synchronization, backup and recovery of data in the database to ensure high availability, consistency and persistence of data. For example, MySQL, Oracle database system, and PostgreSQL. The database system can be applied to a variety of project scenarios, such as online retail, inventory management, social media user data storage, logistics distribution, intelligent traffic flow analysis, e-commerce, Enterprise Resource Planning (ERP), energy monitoring, production control, archive management, smart cities, environmental monitoring and other big data scenarios.

[0044] The master database is a database instance in the database system that is used to modify data and generate logical logs. The standby database is a database instance in the database system that is used to receive logical logs from the master database and complete log backups. The master database and the standby database can run on different servers to form distributed storage, or they can run on the same server to form a single-machine multi-instance deployment. Generally, the master database directly connects to users or applications, while the standby database does not directly connect to users or applications. For example, MySQL can run on a Linux server in Master-Slave mode or Master-Master mode, where the master database and the standby database can be on different physical servers or on the same server through different ports and service instances.

[0045] The main database data is the project data stored on the main database, including table structure, index, view and other database objects. The modification operation (such as insert, update and delete) of the main database data is completed through data operation instructions, ensuring the implementation of project logic and consistent and complete storage of data. For example, the order table data of the e-commerce project is stored on the MySQL main database, including: 1. order_id (INT, primary key): order unique identifier; 2. customer_id (INT): unique identifier associated with the customer; 3. order_date (DATETIME): timestamp of order creation; status (VARCHAR): order status (such as pending, shipped, completed, etc.); 4. total_amount (DECIMAL): total amount of the order.

[0046] A transaction is a specific set of data operation instructions that are executed as a whole and are either completed or not completed. A transaction is the basic unit for modifying the data in the main database in a database system. The target transaction is the transaction being executed. The target transaction includes multiple data operation instructions. After the data operation instructions complete the modification operation on the main database data, the logical log of the data operation instructions is triggered. The logical log records the modification operation on the main database data to ensure data persistence and consistency and support subsequent log backup and recovery operations. Once all data operation instructions in the target transaction are successfully executed and the logical log is committed, the logical log will be written to persistent storage. For example, when a user places an order, a target transaction will be triggered, which contains multiple data operation instructions, such as inserting a new order record, updating inventory quantity, and recording payment information. These operations must be completed as an atomic unit to ensure the integrity and consistency of the order table data of the e-commerce project. If any step fails, the entire transaction will be rolled back, undoing all changes made, and ensuring that the state of the order table data of the e-commerce project stored in the main database remains unchanged. After each data operation instruction is executed, the system will generate a corresponding logical log to record the completed modification operation.

[0047] Data operation instructions are specific code language commands issued by users or applications to the main database, which are used to perform operations such as create (Create), read (Read), update (Update) and delete (Delete). Data operation instructions are the main way for users to interact with the database system and are used to manage and modify data in the database. For example, SQL statements in MySQL: 1. Insert (INSERT): Add a new record to the database table. In MySQL, INSERT INTO orders (customer_id, order_date, status, total_amount) VALUES (12345, NOW(), 'pending', 299.99); insert a new order record into the order table; 2. Update (UPDATE): Modify the data of an existing record. UPDATE orders SETstatus = 'shipped' WHERE order_id = 12345; Update the order status to "shipped"; 3. Delete (DELETE): Remove records from the database table. DELETE FROM orders WHERE order_id = 12345 ANDstatus = 'canceled'; delete a canceled order; 4. SELECT: query and retrieve data from the database. SELECT * FROM customers WHERE city = 'A'; retrieve all customer information from city A.

[0048] The logical log of data operation instructions is a serialized entry that records the changes made to the main database data through data operation instructions. It is used to ensure data persistence and consistency and support subsequent log backup and recovery operations. The logical log of data operation instructions is triggered when the data operation instructions are executed to complete the modification operation on the main database data. Generally, the logical logs of multiple data operation instructions constitute a logical log file in the form of serialized entries. For example, in MySQL, the binary log (binlog) file of SQL statements, such as mysql-bin.000001, where: mysql-bin.000001 means that this is a binary log file numbered 000001. MySQL numbers these files in sequence. Whenever a log file reaches a certain size or meets other conditions, the system will create a new log file and continue recording. The log file contains all the operation instructions (SQL statements) that modify the database, stored in binary format. Each log entry records a specific database operation, including but not limited to: 1. Event type: Identifies whether this is a start, commit, rollback, or specific data change event; 2. Timestamp: Records the time when the operation occurred; 3. Transaction ID: If transactions are enabled, it contains the unique identifier of the transaction; 4. Table information: The database name and table name involved; 5. Row-level changes: For each row change, the values ​​before and after the modification are recorded in detail; 6. SQL statement: In statement-based replication mode, the executed SQL statement is directly recorded; in row-based replication mode, the specific changes of the affected rows are recorded.

[0049] The first data operation instruction is the latest data operation instruction executed in the target transaction, and is executed according to the transaction logic sequence of the target transaction. The logic log of the first data operation instruction is the logic log record generated when the modification operation of the master database data is completed by executing the first data operation instruction.

[0050] For example, the database of the e-commerce project is stored and managed using the MySQL database system (database management system) of the relational database service (RDS). The MySQL database system runs on a distributed server cluster, and a master server and multiple standby servers are configured for MySQL. The transaction queue of the master instance includes three transactions: transaction 1, transaction 2, and transaction 3. The target transaction currently being executed is transaction 1, which is a transaction triggered by a user's order. The transaction contains three SQL statements: SQL statement 1. Insert a new order record: "INSERT INTO orders (customer_id, order_date, status, total_amount) VALUES (12345, NOW(), 'pending', 299.99)"; SQL statement 2, update inventory information: "UPDATE products SET stock_quantity = stock_quantity - 1 WHERE product_id = 56789;" SQL statement 3, record payment information: "INSERT INTO payments (order_id, payment_method, amount_paid, payment_date) VALUES (12345, 'credit card', 299.99, NOW());".

[0051] SQL statement 1 has just been executed, triggering the generation of the entry binlog event sql_1 in the binary log file mysql-bin.000001 for the SQL statement.

[0052] The logical log of the first data operation instruction in the target transaction is obtained and triggered, laying a data foundation for the logical log for subsequent backup transmission.

[0053] Step 204: Copy the logical log in real time and send it to the standby database, and return to execute the step of obtaining the logical log of the first data operation instruction in the target transaction that is triggered and generated.

[0054] The logical log is copied in real time and sent to the standby database. The specific method is: the logical log is copied in real time, a copy of the logical log is obtained, and the copy of the logical log is sent to the standby database.

[0055] Among them, the logical log is copied in real time to obtain a logical log copy. One optional way is: through a caching mechanism, the logical log is copied in real time to obtain a logical log copy. Another optional way is: through a file system snapshot, the logical log is copied in real time to obtain a logical log copy. Another optional way is: using a network stream data format, the logical log is copied in real time to obtain a logical log copy, which is not limited here.

[0056] Among them, sending the logical log copy to the standby database, one optional way is: sending the logical log copy to the standby database through a reliable data transmission protocol, for example, the TCP protocol uses a three-way handshake method, and after completing the sending, it is necessary to receive the reception confirmation message fed back by the standby database to confirm the successful sending. Another optional way is: sending the logical log copy to the standby database through a message queue, for example, using Kafka or RabbitMQ to asynchronously transfer the logical log copy to the standby database. Increase the flexibility and fault tolerance of the system, which is not limited here.

[0057] It should be noted that in step 102 and step 104, the acquisition of logical logs, the replication and transmission of logical logs, and the execution of data operation instructions and the triggering of the generation of logical logs are two processes that are executed in isolation and can be executed separately by configuring isolated threads.

[0058] Exemplarily, through the cache mechanism, the logical log entry binlog event sql_1 is copied to the memory cache area to obtain the logical log copy binlog event sql_1.entry. The logical log copy binlog event sql_1.entry is sent to the standby server through the TCP protocol, and after receiving the ACK confirmation message returned by the standby server, it is confirmed that the sending is successful, and the binary log entry binlog event sql_2 of the SQL statement 2 generated by the new trigger is returned for execution.

[0059] The logical log is copied and sent to the standby database in real time, and the step of obtaining the logical log of the first data operation instruction in the target transaction is returned and executed. By transmitting the logical log in real time, it is pre-transmitted to the standby database during the transaction execution process, reducing the risk of degenerating to asynchronous replication due to timeout, avoiding performance jitter caused by long waiting for confirmation from the standby database, thereby enhancing the stability and response speed of the database system, reducing the risk of data asynchrony between the primary and standby databases, and ensuring data integrity and consistency.

[0060] Step 206: When the standby database receives the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is submitted.

[0061] The standby database receives the logical log of each data operation instruction of the target transaction. One optional way is that the primary database receives the receipt confirmation message of the logical log of each data operation instruction fed back by the standby database. Another optional judgment method is that the primary database receives the receipt confirmation message of the logical log of the last data operation instruction fed back by the standby database. Another optional judgment method is that the standby database stores the logical log of each data operation instruction that completes the target transaction, which is not limited here.

[0062] It should be noted that only after the target transaction's logical logs for each data operation instruction are committed, can the target transaction be considered to have been successfully replicated to the standby database, thus ensuring that even if the primary database fails, the standby database can take over the service without losing any committed transaction information. Optionally, the standby database may also set a checkpoint to check the received logical logs to further consolidate the security and durability of the data.

[0063] For example, after the standby server receives the logical log entries binlogevent sql_1, binlog event sql_2 and binlog event sql_3 corresponding to SQL statements 1, 2 and 3, it parses these entries one by one and replays the corresponding SQL statements. Once all relevant logical log entries are successfully processed, the standby server confirms these changes and sends an ACK confirmation message to the master server, confirming that the target transaction has been successfully copied to the standby server, committing the binary log file mysql-bin.000001 of transaction 1, and continuing to execute transaction 2.

[0064] In the embodiments of this specification, by transmitting the logical log in real time, the generated logical log is pre-transmitted to the standby database during the transaction execution process, rather than waiting until the transaction is committed to transmit it, ensuring that even in the case of network delays or other abnormal conditions between the primary and standby databases, a high level of consistency can be maintained, reducing the risk of degenerating to asynchronous replication due to timeouts. The transmission of the logical log is completed during transaction processing, which greatly reduces the transmission time during the transaction submission phase, avoids performance jitters caused by long waits for confirmation from the standby database, and thus enhances the stability and response speed of the database system. By synchronously backing up the log backup, the risk of data asynchronism between the primary and standby databases is reduced, ensuring data integrity and consistency, and improving the availability of the database system.

[0065] In an optional embodiment of the present specification, after step 202, the following specific steps are also included: Cache the logical logs in the logical log cache of the primary database; In step 204, the logical log is copied in real time and sent to the standby database, including the following specific steps: When the preset sending conditions are met, the logical logs cached in the logical log cache are copied in real time and sent to the standby database; Step 206 includes the following specific steps: When the standby database receives the logical log of each data operation instruction of the target transaction, it takes out the logical log of each data operation instruction from the logical log cache and submits it.

[0066] The logical log cache is a cache area that temporarily stores uncommitted logical logs. After being committed, the logical logs will be written to persistent storage. For example, the binary log cache (binlog cache).

[0067] Preset sending conditions are pre-set trigger conditions that trigger the real-time replication of logical logs in the primary database and send them to the standby database. Preset sending conditions can trigger the backup transmission process of logical logs based on different factors such as time, data volume or system performance to ensure efficient and real-time data synchronization. Preset sending conditions may include but are not limited to preset cycles, preset data volume thresholds of logical logs, and preset performance indicator thresholds of the primary database.

[0068] In an optional embodiment of the present specification, the preset sending condition is any one of a preset period, a preset data volume threshold of the logical log, and a preset performance indicator threshold of the main database.

[0069] The preset cycle is a pre-set time interval that serves as a timer to trigger the logical log backup transmission. Setting a preset cycle can help to regularly transmit logical logs to maintain the timeliness of log backup transmission. For example, if the preset cycle is once every 5 minutes, the logical log is copied in real time and sent to the standby database once every 5 minutes.

[0070] The preset data volume threshold of the logical log is the preset logical log accumulation volume. Once this volume is exceeded, the transmission of the logical log to the standby database will be triggered. By setting the data volume threshold, batch transmission can be performed when the logical log accumulates to a certain extent, optimizing the use of network resources and reducing the overhead caused by frequent small-scale transmission. For example, if the preset data volume threshold is 1MB, then when the data in the logical log cache accumulates to 1MB or more, the system will trigger the backup transmission of the logical log.

[0071] The preset performance index threshold of the main database is the expected performance index restriction of the main database, such as CPU utilization, memory usage, disk I / O delay, etc. When the performance index reaches the preset threshold, insisting on the backup transmission of the logical log may affect the normal operation and service quality of the main database. You can adjust the transmission strategy of the logical log by monitoring these performance indicators to avoid large amounts of data transmission when the main database load is too high. For example, if the CPU utilization of the main database exceeds 80%, it is necessary to postpone the transmission of non-logical logs to give priority to ensuring the response speed and service stability of the main database.

[0072] The logical log cached in the logical log cache is copied in real time. Specifically, the logical log cached in the logical log cache is copied in real time to obtain a logical log copy, and the logical log copy is sent to the standby database.

[0073] Among them, the logical log is copied in real time to obtain a logical log copy. One optional way is: through a caching mechanism, the logical log cached in the logical log cache is copied in real time to obtain a logical log copy. Another optional way is: through a file system snapshot, the logical log cached in the logical log cache is copied in real time to obtain a logical log copy. Another optional way is: using a network stream data format, the logical log cached in the logical log cache is copied in real time to obtain a logical log copy, which is not limited here.

[0074] The optional method of sending the logical log copy to the standby database is described in the above step 104 and will not be described again here.

[0075] Exemplarily, the entry binlogevent sql_1 in the binary log file mysql-bin.000001 of the SQL statement is cached in the logical log cache binlog cache of the master library. When the preset period (5 minutes) is reached, the copy of the cached logical log entry in the logical log cache binlog cache is sent to the standby library server through the TCP protocol, and after receiving the ACK confirmation message returned by the standby library, it is confirmed that the sending is successful, and the execution is returned to obtain the binary log entry binlog event sql_2 of the SQL statement 2 generated by the new trigger. When the standby library receives the logical log of each SQL statement of transaction 1, the logical log of each SQL statement is taken out from the logical log cache binlog cache, the binary log file mysql-bin.000001 of transaction 1 is committed, and transaction 2 is continued to be executed.

[0076] In the embodiments of this specification, logical log caching and preset sending conditions are used in combination. Logical log caching reduces frequent disk read and write operations, while the preset sending conditions ensure that logical logs are transferred to the backup database in batches at the appropriate time point, which not only maintains the timeliness of data synchronization, but also avoids data transmission interference when the main database is under high load, thereby improving the system's response speed and service quality, and enhancing data integrity and consistency assurance.

[0077] In an optional embodiment of the present specification, the target transaction is a transaction being executed in a transaction queue; Cache the logical logs in the logical log cache of the master database, including the following specific steps: Within the preset time window, the logical log is cached in the logical log cache of the main database, the target transaction is updated to other transactions in the transaction queue, and the step of obtaining the logical log of the first data operation instruction in the target transaction generated by the trigger is returned.

[0078] The preset time window is a pre-set execution window for the logical log cache of the target transaction. By using the preset time window, the log backup is sharded, and the logical log backup transmission of the target transaction is prevented from completely blocking the execution of other transactions. However, this method will modify the format of the logical log, which is somewhat invasive to the database system.

[0079] Exemplarily, the preset time window is 1 second, that is, within each second, the master database will cache the binary logs of all completed first data operation instructions in the currently executing target transaction into the binary log cache (binlogcache), and try to copy and send these binary logs to the standby database in real time according to the preset sending conditions. If the target transaction has not been completed at the end of this 1-second time window, the system will update the target transaction to the next transaction in the transaction queue, even if the previous target transaction has not yet fully committed all its binary logs: When the master database is processing transaction 1 triggered by a user's order, it will cache and transmit as many binary logs generated by the transaction as possible within each 1-second time window. Once 1 second has passed, even if transaction 1 has not been completed, the system will start executing the next transaction in the transaction queue: transaction 2, allowing the binary log of transaction 2 to also be cached and backed up and transmitted.

[0080] In the embodiments of this specification, by performing sharding, caching, and backup transmission operations, resources are avoided from being occupied for a long time on a transaction, the efficiency of parallel processing of multiple transactions is ensured, and the response speed of the system is improved.

[0081] In an optional embodiment of the present specification, after the logical log is copied in real time and sent to the standby database in step 204, the following specific steps are also included: Cache the logical logs in the relay log cache of the standby database.

[0082] The relay log is used to store a copy of the logical log transmitted by the primary database on the standby database. The relay log can be replayed to synchronize the modification operations of data operation instructions on the primary database data. The standby database updates the standby database data by reading and applying events in the relay log, thereby maintaining consistency with the primary database data, ensuring that even if the primary database fails, the standby database can take over the service and provide the latest data.

[0083] The relay log cache is a cache area that temporarily stores relay logs until they are executed and stored persistently. It allows the slave database to accumulate a certain amount of log data in memory before writing it to persistent storage in batches. To speed up the replication process, the slave database may first store the received binary log content in the relay log cache. This can reduce frequent small-scale disk write operations, because writing directly to disk is usually slower than writing to memory. When the cache reaches a certain size or a certain time interval has passed, the log data in the cache will be flushed to disk to complete persistent storage. The relay log cache effectively improves replication efficiency and reduces disk I / O.

[0084] For example, after receiving the data, the standby database stores it in the relay log cache. Then, the standby database re-executes SQL statement 1: "INSERT INTOorders (customer_id, order_date, status, total_amount) VALUES (12345, NOW(), 'pending', 299.99)" on the standby database based on the relay log entry in the relay log cache to insert a new order record, ensuring that the standby database data is consistent with the primary database data.

[0085] In the embodiments of this specification, frequent disk read and write operations are effectively reduced. By accumulating relay logs in the cache, the replication efficiency is improved and the frequency of disk writes is reduced, allowing the standby database to process logical logs in batches, optimizing resource usage and speeding up the response speed of the standby database.

[0086] In an optional embodiment of the present specification, after caching the logical log in the relay log cache of the standby database, the following specific steps are also included: In the case where the relay log cache has cached the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is taken out from the relay log cache, and a relay log file is generated based on the logical log of each data operation instruction.

[0087] The relay log file is a log file of the relay log that is persistently stored on the standby database. It saves a copy of the logical log received from the primary database and is used to replay these log events on the standby database to synchronize the data changes of the primary database. In the case where the relay log cache caches the logical logs of each data operation instruction of the target transaction, the relay log will be flushed to the relay log file on the disk. This ensures that even if the system crashes, the unfinished log application process can be restored through the relay log file. Generally, the relay log files are renamed in sequence.

[0088] Exemplarily, when the relay log cache caches the binary logs of 3 SQL statements of transaction 1, the binary logs of the 3 SQL statements are taken out from the relay log cache, and a relay log file is generated based on the binary logs of each SQL statement, thereby quickly completing the backup transmission.

[0089] In the embodiments of the present specification, by temporarily storing the logical log in the relay log cache, and in the case where the relay log cache has the logical log of each data operation instruction of the target transaction, the relay log file is persistently stored, thereby effectively reducing frequent disk read and write operations, improving the processing efficiency and response speed of the backup database, and ensuring that even if the system fails, the unfinished log application can be restored from the relay log file, thereby ensuring the consistency and persistence of the data and enhancing the stability and availability of the database system.

[0090] In an optional embodiment of the present specification, before generating a relay log file based on the logical log of each data operation instruction, the following specific steps are also included: Get the logical log of the triggered and related transactions; Copy the logical logs of related transactions in real time and send them to the standby database; Generate a relay log file based on the logical log of each data operation instruction, including the following specific steps: Integrate the logical logs of related transactions and the logical logs of each data operation instruction in the target transaction to generate a relay log file.

[0091] Related transactions are other transactions related to the target transaction, generally other transactions in the same batch. In the process of database replication and backup, in order to ensure data consistency and integrity, the logical logs of one or more related transactions are usually processed together with the logical logs of each data operation instruction in the target transaction to ensure that the logical logs of these transactions are backed up to the standby database as a whole. For example, in an e-commerce project, there are two transactions that occur almost at the same time: Transaction A: The user places an order to purchase a product. Transaction B: The administrator adjusts the inventory quantity of the product. Although the two transactions are triggered by different users, they are operations on the same product and may affect the same database records. Therefore, they are considered "related transactions" and need to be processed in the same batch. When performing log backup, it should be ensured that the logs of these two transactions are processed together to maintain data consistency. Related transactions and target transactions can be distinguished based on at least one of the number of instructions of data operation instructions, the number of logical log entries, timestamp, transaction identifier, the amount of data in the primary database operated, and row-level changes.

[0092] The logical log of a related transaction is a serialized entry that records changes to the master database data. The logical log of a related transaction contains all changes to the database during the execution of the related transaction, including but not limited to changes in table structure, indexes, views, and other database objects. The logical log of a related transaction is triggered when the modification operation on the master database data is completed during the execution of the entire related transaction.

[0093] The logical log of the relevant transaction is copied in real time and sent to the standby database. The specific method is: the logical log of the relevant transaction is copied in real time, a copy of the logical log of the relevant transaction is obtained, and the copy of the logical log of the relevant transaction is sent to the standby database.

[0094] Among them, the logical log of the relevant transaction is copied in real time to obtain a copy of the logical log of the relevant transaction. One optional way is: through a caching mechanism, the logical log of the relevant transaction is copied in real time to obtain a copy of the logical log of the relevant transaction. Another optional way is: through a file system snapshot, the logical log of the relevant transaction is copied in real time to obtain a copy of the logical log of the relevant transaction. Another optional way is: using a network stream data format, the logical log of the relevant transaction is copied in real time to obtain a copy of the logical log of the relevant transaction, which is not limited here.

[0095] Among them, the logical log copy of the relevant transaction is sent to the standby database. An optional way is to send the logical log copy of the relevant transaction to the standby database through a reliable data transmission protocol. For example, the TCP protocol uses a three-way handshake method. After the sending is completed, it is necessary to receive the reception confirmation message fed back by the standby database to confirm the successful sending. Another optional way is to send the logical log copy of the relevant transaction to the standby database through a message queue. For example, Kafka or RabbitMQ is used to asynchronously transfer the logical log copy of the relevant transaction to the standby database. The flexibility and fault tolerance of the system are increased, which is not limited here.

[0096] It should be noted that the two processes of obtaining the logical log of related transactions, copying and sending the logical log of related transactions, and executing data operation instructions and triggering the generation of the logical log of related transactions are executed in isolation and can be executed separately by configuring isolated threads.

[0097] For example, after the main database completes the execution of SQL statement 1 in transaction A, the entry binlog event sql_1 in the binary log file mysql-bin.000001 of the SQL statement is triggered. Obtain and copy binlogevent sql_1 to the standby database in real time, send it to the standby database server through the TCP protocol, and confirm the successful sending after receiving the ACK confirmation message returned by the standby database. For the related transaction B, which contains 10 SQL statements for updating inventory information, the 10 SQL statements are executed, which will also trigger the generation of the corresponding binary log file mysql-bin.000002. Copy it as a copy and then send it to the standby database through a reliable data transmission protocol (such as TCP). Integrate the binary log files of transaction A and transaction B to obtain the relay log file.

[0098] In the embodiments of this specification, by processing the logical logs of the target transaction and related transactions together, frequent disk read and write operations are effectively reduced, the processing efficiency and response speed of the standby database are improved, and even if a system failure occurs, the unfinished log application can be restored from the relay log file, ensuring the consistency and persistence of the data and enhancing the stability and availability of the database system. In addition, this method also ensures that even in complex project scenarios, different but related transactions can be correctly reflected in the standby database, avoiding possible data inconsistency problems.

[0099] In an optional embodiment of the present specification, step 206 includes the following specific steps: When the primary database receives the reception confirmation message of the logical log of the last data operation instruction fed back by the standby database, the logical log of each data operation instruction is submitted.

[0100] The last data operation instruction is the last data operation instruction executed in the target transaction, which means that all previous operations must be successful to execute this final command, otherwise the entire transaction will be rolled back.

[0101] The logical log of the last data operation instruction is a serialized entry that records the changes made to the main database data through the last data operation instruction. It is used to ensure data persistence and consistency and support subsequent log backup and recovery operations. The logical log of the last data operation instruction is triggered when the last data operation instruction completes the modification operation on the main database data.

[0102] The reception confirmation message is a signal or notification sent from the standby database to the master database, indicating that the standby database has successfully received the logical log of the last data operation instruction. This confirmation mechanism is used in a semi-synchronous replication environment to ensure that the master database will commit the transaction only after confirming that the standby database has safely received the logical log. It will not happen that the standby database has not received the logical log of the last data operation instruction, but the master database has committed the transaction. When the standby database asks the master database to retransmit, the master database needs to "find" the logical log of the last data operation instruction from the submitted logical log file to retransmit. This helps reduce the risk of data loss and improves the reliability and consistency of the system.

[0103] For example, the SQL statement of "record payment information" is the last data operation instruction in the transaction. Only when the primary database server receives the ACK confirmation message of the binary log of the last data operation instruction sent by the standby database server, can it be determined that transaction 1 has been successfully processed by both database instances, thereby completing the submission process of the entire transaction.

[0104] In the embodiment of this specification, by ensuring that the primary database is submitted only after receiving the receipt confirmation message of the logical log of the last data operation instruction from the standby database, the risk of data asynchrony is effectively avoided. This method not only reduces the possibility of data loss and enhances the reliability and consistency of the system, but also prevents unnecessary retransmission operations, improves replication efficiency and system response speed, and thus improves the overall performance and stability of the database system.

[0105] Corresponding to the above-mentioned multiple method embodiments, Figure 3 A flow chart of a log backup method provided by an embodiment of this specification is shown. Figure 3 As shown: On the main database, a task manager and a logical log cache for global logical log real-time backup are set. The task manager is used to manage and schedule the real-time backup tasks of the global logical log. A global logical log real-time backup list is set in the task manager to record all logical log entries that need to be backed up and their status. The logical log cache is used to cache the logical logs generated by the trigger. User threads and backup threads run on the main database.

[0106] A relay log cache is set on the standby database, which is used to cache received logical logs. Read and write threads are running on the standby database.

[0107] Execute the user thread, modify the main database data to trigger the generation of logical logs, and after completing the backup and transmission of all logical logs, submit the logical log files to complete persistent storage.

[0108] The backup thread is executed to send the real-time backup entries of the logical logs of each data operation instruction in the target transaction and the real-time backup entries of the logical logs of the related transactions to the standby database.

[0109] Execute the read-write thread, cache the received logical log real-time backup entries of each data operation instruction in the target transaction and the logical log real-time backup entries of the related transactions through the relay log cache, add the logical log real-time backup entries of the related transactions directly to the relay log file, and when the relay log cache has the logical log real-time backup entries of each data operation instruction in the target transaction, take out the logical log real-time backup entries of each data operation instruction from the relay log cache, rename them and add them to the relay log file.

[0110] The following combination Figure 4 , taking the application of the log backup method provided in this specification in the MySQL database as an example, the log backup method is further described. Figure 4 A flowchart of a log backup method applied to a MySQL database provided in an embodiment of the present specification is shown. The method is applied to an RDS MySQL database and includes the following specific steps: Step 402: Obtain the binary log binlog of the SQL statement in the ETL (Extract, Transform, Load) transaction that is triggered and generated, wherein the ETL transaction includes multiple SQL statements, and the binary log binlog is triggered and generated by executing the SQL statement to complete the modification operation on the main database data.

[0111] Step 404: cache the binary log binlog cache to the binary log cache binlogcache of the master library.

[0112] Step 406: When the preset period is reached, the binary logs cached in the binary log cache are copied in real time and sent to the standby database.

[0113] Step 408: Cache the binary log binlog cache to the relay log cache relay logcache of the standby database, and return to execute step 402.

[0114] Step 410: When the relay log cache has the binary log binlog of each SQL statement of the ETL transaction cached, the binary log binlog of each SQL statement is retrieved from the relay log cache, a relay log file is generated based on the binary log binlog of each SQL statement, and a reception confirmation message is sent to the master database.

[0115] Step 412: When the master database receives the reception confirmation message of the binary log binlog of each SQL statement fed back by the standby database, the binary log binlog of each SQL statement is retrieved from the binary log cache binlog cache for submission.

[0116] In the embodiments of this specification, the binary log binlog of the large transaction is pre-transmitted to the standby database during the transaction execution process through real-time transmission. When the large transaction is committed, only further file conversion needs to be performed in the standby database, which greatly reduces the time consumption of transmitting the binary log binlog in the submission phase of the large transaction. The semi-synchronous replication will not degenerate and will not cause the instance to be unwritable, effectively avoiding the timeout rollback and performance jitter of the semi-synchronous replication, and there is no need to change the format of the binary log binlog file, and there is no invasion of the ecology of the MySQL database.

[0117] Corresponding to the above method embodiment, this specification also provides a log backup device embodiment, Figure 5 FIG. 1 shows a schematic diagram of a log backup device provided by an embodiment of the present specification. Figure 5 As shown, the device is applied to a database system and includes: The acquisition module 502 is configured to acquire a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered and generated by executing the first data operation instruction to complete the modification operation on the primary database data; The backup module 504 is configured to copy the logical log in real time and send it to the standby database, and return to execute the step of obtaining the logical log of the first data operation instruction in the target transaction generated by the trigger; The commit module 506 is configured to commit the logical log of each data operation instruction when the standby database receives the logical log of each data operation instruction of the target transaction.

[0118] Optionally, the device further comprises: a first cache module configured to cache the logical log into a logical log cache of the master library; The backup module 504 is further configured to: when a preset sending condition is met, copy the logical log cached in the logical log cache in real time and send it to the standby database; The commit module 506 is further configured to: when the standby database receives the logical log of each data operation instruction of the target transaction, fetch the logical log of each data operation instruction from the logical log cache for committing.

[0119] Optionally, the preset sending condition is any one of a preset period, a preset data volume threshold of the logical log, and a preset performance indicator threshold of the main database.

[0120] Optionally, the target transaction is a transaction being executed in the transaction queue; The first cache module is further configured to: cache the logical log into the logical log cache of the main library within a preset time window, update the target transaction to other transactions in the transaction queue, and return to execute the step of obtaining the logical log of the first data operation instruction in the target transaction that is triggered and generated.

[0121] Optionally, the device further comprises: The second cache module is configured to cache the logical logs into the relay log cache of the standby database.

[0122] Optionally, the device further comprises: The file generation module is configured to fetch the logical log of each data operation instruction from the relay log cache when the relay log cache has the logical log of each data operation instruction of the target transaction, and generate a relay log file based on the logical log of each data operation instruction.

[0123] Optionally, the device further comprises: The relevant backup module is configured to obtain the logical log of the relevant transaction generated by the trigger; copy the logical log of the relevant transaction in real time and send it to the standby database; Correspondingly, the file generation module is further configured as follows: Integrate the logical logs of related transactions and the logical logs of each data operation instruction in the target transaction to generate a relay log file.

[0124] Optionally, the submit module 506 is further configured to submit the logical logs of each data operation instruction when the primary database receives a reception confirmation message of the logical log of the last data operation instruction fed back by the standby database.

[0125] In the embodiments of this specification, by transmitting the logical log in real time, the generated logical log is pre-transmitted to the standby database during the transaction execution process, rather than waiting until the transaction is committed to transmit it, ensuring that even in the case of network delays or other abnormal conditions between the primary and standby databases, a high level of consistency can be maintained, reducing the risk of degenerating to asynchronous replication due to timeouts. The transmission of the logical log is completed during transaction processing, which greatly reduces the transmission time during the transaction submission phase, avoids performance jitters caused by long waits for confirmation from the standby database, and thus enhances the stability and response speed of the database system. By synchronously backing up the log backup, the risk of data asynchronism between the primary and standby databases is reduced, ensuring data integrity and consistency, and improving the availability of the database system.

[0126] The above is a schematic scheme of a log backup device of this embodiment. It should be noted that the technical scheme of the log backup device and the technical scheme of the log backup method described above are of the same concept, and the details not described in detail in the technical scheme of the log backup device can be found in the description of the technical scheme of the log backup method described above.

[0127] Corresponding to the above method embodiment, this specification also provides a database system embodiment. Figure 6 FIG. 1 shows a schematic diagram of a database system provided by an embodiment of the present specification. Figure 6 As shown, the database system 600 includes a main database 602 and a backup database 604; The primary database 602 is used to obtain the logic log of the first data operation instruction in the target transaction generated by the trigger, copy the logic log in real time and send it to the standby database 604, and return to the step of executing the logic log of the first data operation instruction in the target transaction generated by the trigger, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is generated by executing the first data operation instruction to complete the modification operation on the data of the primary database 602; The standby database 604 is used to receive the logical log sent by the main database 602, and when receiving the logical log of the last data operation instruction, generate and send a reception confirmation message of the logical log of the last data operation instruction to the main database 602; The primary database 602 is further configured to submit the logical logs of the data operation instructions of the target transaction upon receiving a reception confirmation message of the logical log of the last data operation instruction fed back by the standby database 604 .

[0128] Optionally, the main library 602 is also used to cache the logical log in the logical log cache of the main library 602. When the preset sending conditions are met, the logical log cached in the logical log cache is copied in real time and sent to the standby library 604. When the reception confirmation message of the logical log of the last data operation instruction fed back by the standby library 604 is received, the logical log of each data operation instruction is taken out from the logical log cache for submission.

[0129] Optionally, the standby database 604 is also used to cache the logical log in the relay log cache of the standby database 604. When receiving the receipt confirmation message of the logical log of the last data operation instruction fed back by the standby database 604, the logical log of each data operation instruction is taken out from the relay log cache, and a relay log file is generated based on the logical log of each data operation instruction.

[0130] In the embodiments of this specification, in the database system, by transmitting the logical log in real time, the generated logical log is pre-transmitted to the standby database during the transaction execution process, rather than waiting until the transaction is committed to transmit, ensuring that even in the case of network delays or other abnormal conditions between the main database and the standby database, a high level of consistency can be maintained, reducing the risk of degenerating to asynchronous replication due to timeout. The transmission of the logical log is completed during transaction processing, which greatly reduces the transmission time of the transaction submission stage, avoids performance jitter caused by long waits for confirmation from the standby database, and thus enhances the stability and response speed of the database system. Through synchronous backup of log backup, the risk of data asynchronism between the main database and the standby database is reduced, the integrity and consistency of the data are guaranteed, and the availability of the database system is improved.

[0131] The above is a schematic solution of a database system of this embodiment. It should be noted that the technical solution of the database system and the technical solution of the log backup method described above are of the same concept, and the details not described in detail in the technical solution of the database system can be found in the description of the technical solution of the log backup method described above.

[0132] Figure 7 The block diagram of a computing device provided by an embodiment of the present specification is shown. The components of the computing device 700 include but are not limited to a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and the database 750 is used to store data.

[0133] The computing device 700 also includes an access device 740 that enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of network interface (e.g., a Network Interface Controller (NIC)) of wired or wireless type, such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, and a Near Field Communication (NFC).

[0134] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 7 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0135] The computing device 700 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 700 may also be a mobile or stationary server.

[0136] The processor 720 is used to execute the following computer program / instruction, which implements the steps of the above-mentioned log backup method when executed by the processor.

[0137] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the log backup method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the log backup method described above.

[0138] An embodiment of the present specification further provides a computer-readable storage medium storing a computer program / instruction, which implements the steps of the above-mentioned log backup method when the computer program / instruction is executed by a processor.

[0139] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the log backup method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the log backup method described above.

[0140] An embodiment of the present specification also provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned log backup method when executed by a processor.

[0141] The above is a schematic scheme of a computer program product of this embodiment. It should be noted that the technical scheme of the computer program product and the technical scheme of the log backup method described above are of the same concept, and the details not described in detail in the technical scheme of the computer program product can be found in the description of the technical scheme of the log backup method described above.

[0142] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0143] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the contents contained in the computer readable medium may be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer readable media do not include electric carrier signals and telecommunication signals.

[0144] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0145] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0146] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A log backup method, applied to a database system, comprising: Acquire a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered and generated by executing the first data operation instruction to complete a modification operation on the primary database data; The logical log is copied in real time and sent to the standby database, and the step of returning to execute the logical log of the first data operation instruction in the target transaction generated by the acquisition trigger is performed; When the standby database receives the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is submitted.

2. The method according to claim 1, after obtaining the logical log of the first data operation instruction in the target transaction, further comprising: Cache the logical log into the logical log cache of the master library; The real-time copying of the logical log and sending the same to the standby database includes: When a preset sending condition is met, the logical log cached in the logical log cache is copied in real time and sent to the standby database; When the standby database receives the logical log of each data operation instruction of the target transaction, submitting the logical log of each data operation instruction includes: When the standby database receives the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is retrieved from the logical log cache for submission.

3. According to the method of claim 2, the preset sending condition is any one of a preset cycle, a preset data volume threshold of the logical log, and a preset performance indicator threshold of the main library.

4. The method according to claim 2, wherein the target transaction is a transaction being executed in a transaction queue; The step of caching the logical log into the logical log cache of the master library includes: Within a preset time window, the logical log is cached in the logical log cache of the master database, the target transaction is updated to other transactions in the transaction queue, and the step of returning to execute the logical log of the first data operation instruction in the target transaction generated by the acquisition trigger is returned.

5. The method according to any one of claims 1 to 4, after the logical log is copied in real time and sent to the standby database, further comprising: The logical log is cached in the relay log cache of the standby database.

6. The method according to claim 5, after the step of caching the logical log in the relay log cache of the standby database, further comprises: In the case where the relay log cache has cached the logical log of each data operation instruction of the target transaction, the logical log of each data operation instruction is taken out from the relay log cache, and a relay log file is generated based on the logical log of each data operation instruction.

7. The method according to claim 6, before generating a relay log file based on the logical log of each data operation instruction, further comprises: Get the logical log of the triggered and related transactions; Copy the logical log of the relevant transaction in real time and send it to the standby database; The generating of the relay log file based on the logical log of each data operation instruction includes: The logical logs of the related transactions and the logical logs of the data operation instructions in the target transaction are integrated to generate a relay log file.

8. The method according to claim 1, when the standby database receives the logical log of each data operation instruction of the target transaction, submitting the logical log of each data operation instruction comprises: When the primary database receives a reception confirmation message of the last logical log of the data operation instruction fed back by the standby database, the logical logs of each data operation instruction are submitted.

9. A log backup device, applied to a database system, comprising: an acquisition module, configured to acquire a logic log of a first data operation instruction in a target transaction that is triggered and generated, wherein the target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logic log is triggered and generated by executing the first data operation instruction to complete a modification operation on the primary database data; A backup module is configured to copy the logical log in real time and send it to a standby database, and return to the step of executing the logical log of the first data operation instruction in the target transaction generated by the acquisition trigger; The commit module is configured to commit the logical log of each data operation instruction of the target transaction when the standby database receives the logical log of each data operation instruction.

10. A database system, comprising a main database and a backup database; The master database is used to obtain the logic log of the first data operation instruction in the target transaction generated by the trigger, copy the logic log in real time and send it to the standby database, and return to execute the step of obtaining the logic log of the first data operation instruction in the target transaction generated by the trigger, wherein: The target transaction includes multiple data operation instructions, the first data operation instruction is any one of the multiple data operation instructions, and the logical log is generated by triggering the execution of the first data operation instruction to complete the modification operation on the main database data; The standby database is used to receive the logical log sent by the primary database, and upon receiving the logical log of the last data operation instruction, generate and send a reception confirmation message of the logical log of the last data operation instruction to the primary database; The master database is further configured to submit the logical logs of the data operation instructions of the target transaction upon receiving a reception confirmation message of the logical log of the last data operation instruction fed back by the standby database.

11. According to the database system of claim 10, the main database is also used to cache the logical log in the logical log cache of the main database, and when the preset sending conditions are met, the logical log cached in the logical log cache is copied in real time and sent to the standby database, and when the reception confirmation message of the logical log of the last data operation instruction fed back by the standby database is received, the logical log of each data operation instruction is taken out from the logical log cache for submission.

12. According to the database system of claim 10 or 11, the standby database is further used to cache the logical log in the relay log cache of the standby database, and when receiving the reception confirmation message of the logical log of the last data operation instruction fed back by the standby database, the logical log of each data operation instruction is taken out from the relay log cache, and a relay log file is generated based on the logical log of each data operation instruction.

13. A computing device comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer program / instructions are executed by the processor, the steps of the method according to any one of claims 1 to 8 are implemented.

14. A computer-readable storage medium storing a computer program / instruction, wherein the computer program / instruction, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

15. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

Images