Database backup method and device, equipment and medium

Abstract

The invention relates to the technical field of data backup, can be applied to business system platforms of medical health, financial science and technology and the like, and discloses a database backup method which comprises the following steps: acquiring a database to be backed up, detecting whether long transactions exist in the database to be backed up, and when the long transactions do not exist in the database to be backed up, starting the database to be backed up. If yes, a table locking operation instruction is sent to the table locking module; the table locking module executes table locking operation according to the table locking operation instruction and judges whether the table locking operation is overtime or not, and when the table locking operation is not overtime, a snapshot operation instruction is sent to the snapshot module; the snapshot module executes snapshot operation according to the snapshot operation instruction and judges whether the snapshot operation is successful or not, and if the snapshot operation is successful, the lock is actively released, and database backup is completed. Data backup is performed through long transaction detection, table locking timeout control, active lock release and the like, data consistency is ensured, and backup efficiency and database stability are improved.

Description

Technical Field

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

[0002] While block-based snapshot backup solutions offer certain efficiency advantages, they often face challenges in practical applications regarding data consistency. Particularly during snapshotting, if write operations continue, the backup data may be inconsistent, impacting integrity and availability. A common approach is to use table locking mechanisms, locking database tables during backup to prevent data modification. However, table locking significantly impacts database concurrency performance, blocking write operations and affecting business continuity and response speed. In high-concurrency scenarios, prolonged table locking can lead to performance degradation and even deadlocks. Furthermore, existing backup tools typically consume significant time for data recovery, especially with large databases, where the recovery process can take hours or longer, failing to meet enterprise requirements for high availability and rapid recovery. The backup process itself also consumes substantial system resources, including CPU, memory, and disk I / O, further increasing database load and potentially interfering with running business systems. In summary, current backup solutions based on block storage snapshots still face many challenges in terms of consistency assurance, performance impact, and recovery efficiency. More efficient and less intrusive solutions are urgently needed to improve the reliability and availability of database backups.

[0003] In the fintech sector, backup solutions based on block storage snapshots present particularly significant challenges. Financial systems have extremely high requirements for data consistency and business continuity; any data inconsistency can lead to transaction errors, financial losses, or compliance risks. If write operations occur during the snapshot process, the backup data may be in an inconsistent state, failing to meet the stringent data integrity requirements of financial regulations. Table-locking mechanisms used to address this issue can block write operations in the trading system, causing transaction delays or even failures, severely impacting user experience and business continuity. In high-concurrency trading scenarios, excessively long table-locking times can lead to system performance degradation or deadlocks, further exacerbating business risks. Furthermore, financial systems typically handle massive amounts of data, resulting in lengthy backup and recovery times, making it difficult to meet the stringent requirements of high availability and rapid recovery in financial operations. The backup process consumes significant system resources, potentially affecting real-time transaction processing performance and increasing the risk of system failure. Therefore, the fintech sector urgently needs more efficient and less intrusive backup solutions to ensure data consistency, business continuity, and system stability.

[0004] In the healthcare sector, backup solutions based on block storage snapshots also present serious problems. Medical data involves patient privacy and the integrity of medical records; data inconsistencies can lead to misdiagnosis, treatment delays, or medical disputes, severely impacting patient safety and the reputation of medical institutions. If write operations occur during the snapshot process, the backup data may not accurately reflect the patient's latest condition, posing risks to clinical decision-making. While table locking mechanisms can ensure data consistency, they can block write operations in the healthcare information system, affecting critical tasks such as real-time entry of medical records and prescriptions by doctors, reducing the efficiency of medical services. In high-concurrency medical scenarios, table locking can lead to slow system response or even deadlocks, severely impacting the continuity of medical services. Furthermore, the sheer volume and rapid growth of medical data, coupled with long backup and recovery times, makes it difficult to meet the rapid data recovery needs of healthcare operations. The backup process consumes significant system resources, potentially affecting the stable operation of hospital information systems and interfering with normal medical activities. Therefore, the healthcare sector urgently needs more efficient and less intrusive backup solutions to ensure data consistency, business continuity, and patient safety. Summary of the Invention

[0005] The main objective of this invention is to provide a database backup method, apparatus, device, and storage medium, aiming to solve the problems of excessively long table locking time, deadlock, and backup failure in existing backup technologies.

[0006] To achieve the above objectives, the present invention provides a database backup method, comprising: Obtain the database to be backed up, check whether there are long transactions in the database to be backed up, and if there are no long transactions in the database to be backed up, send a table locking operation command to the table locking module; The table locking module executes the table locking operation according to the table locking operation instruction and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module executes a snapshot operation according to the snapshot operation instruction and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

[0007] Furthermore, to achieve the above objectives, the present invention provides a database backup device, comprising: The long transaction module is used to obtain the database to be backed up, detect whether there are long transactions in the database to be backed up, and send a table locking operation command to the table locking module when there are no long transactions in the database to be backed up. The table locking module is used to execute table locking operations according to the table locking operation instructions, and to determine whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module is used to execute snapshot operations according to snapshot operation instructions and determine whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a database backup program stored in the memory and executable on the processor, wherein the database backup program, when executed by the processor, implements the steps of the database backup method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a database backup program, which, when executed by a processor, implements the steps of the database backup method as described above.

[0010] Beneficial Effects: This invention relates to the field of data backup technology and can be applied to business system platforms in communications, healthcare, and fintech. It discloses a database backup method, comprising: acquiring a database to be backed up; detecting whether long transactions exist in the database; if no long transactions exist, sending a table locking operation instruction to a table locking module; the table locking module executing the table locking operation according to the instruction and determining whether the operation has timed out; if the operation has not timed out, sending a snapshot operation instruction to a snapshot module; the snapshot module executing the snapshot operation according to the instruction and determining whether the operation is successful; if the operation is successful, actively releasing the lock to complete the database backup. This invention introduces a preventative long transaction detection mechanism to identify and avoid backup failures or database performance issues caused by long transactions in advance. Simultaneously, a table locking timeout control mechanism ensures that the table locking operation is completed within a reasonable time, avoiding backup blocking due to table locking failure. Furthermore, by actively releasing the table lock after snapshot completion, the impact on database performance is reduced, improving database high availability and significantly enhancing the reliability and efficiency of backup operations. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a database backup method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the database backup method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database backup device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The database backup method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the user terminal communicates with the server via a network. The server can obtain the database to be backed up from the user terminal, detect whether there are long transactions in the database, and if no long transactions exist, send a table locking operation instruction to the table locking module. The table locking module executes the table locking operation according to the instruction and determines whether the operation has timed out. If the operation has not timed out, it sends a snapshot operation instruction to the snapshot module. The snapshot module executes the snapshot operation according to the instruction and determines whether the operation is successful. If the operation is successful, the lock is actively released, and the database backup is completed. This invention introduces a preventative long transaction detection mechanism to identify and avoid backup failures or database performance problems caused by long transactions in advance. Simultaneously, a table locking timeout control mechanism ensures that the table locking operation is completed within a reasonable time, avoiding backup blocking due to table locking failure. Furthermore, by actively releasing the table lock after snapshot completion, the impact on database performance is reduced, improving database high availability and significantly enhancing the reliability and efficiency of backup operations. The user terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the database backup method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the database backup method proposed in this invention includes the following steps: S100. Obtain the database to be backed up, and detect whether there are long transactions in the database to be backed up. If there are no long transactions in the database to be backed up, send a table locking operation instruction to the table locking module. S200: The table locking module executes the table locking operation according to the table locking operation instruction, and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. S300: The snapshot module executes a snapshot operation according to the snapshot operation instruction and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released to complete the database backup.

[0016] In this embodiment, before performing a database backup operation, the system needs to clearly define the database instance to be backed up to ensure that subsequent operations are performed on the correct database. A system may contain multiple database instances, such as a master database, slave databases, or databases for different business modules. By clearly defining the target database, the system can avoid backing up the wrong database instance.

[0017] Long transactions refer to transactions that take a considerable amount of time to execute, typically those that consume database resources for an extended period. Long transactions may cause the database to lock certain tables or rows, thus affecting the execution of backup operations. The system determines the existence of long transactions by querying the database's transaction logs or status information. For example, it can check the transaction's start time, execution time, and compare the transaction's execution time with a preset long transaction threshold (such as a transaction execution time exceeding a certain number of minutes) to determine if the transaction is long. Early detection of long transactions can effectively prevent backup failures or database performance issues caused by them. If long transactions exist, backup operations may fail due to excessive table locking time, and may even lead to deadlocks.

[0018] If no long transactions are detected in the database to be backed up, it indicates that the current transaction state of the database is relatively stable and suitable for backup operations. The system will send a table locking operation command to the table locking module to begin the table locking operation. Table locking is to ensure the consistency of database data during the backup process. By locking tables, new write operations can be prevented from modifying the data during the backup process, thereby ensuring the integrity and consistency of the backup data. After receiving the table locking operation command, the table locking module begins to execute the table locking operation. Typically, a global read lock is implemented by executing a specific SQL command (such as FLUSH TABLES WITH READLOCK), locking all tables in the database to ensure that the backup operation can be performed in a consistent state. While executing the table locking operation, the system will start a timer to record the execution time of the table locking operation. The preset table locking time is a pre-set time threshold used to determine whether the table locking operation has timed out. For example, it can be set to 1 minute. If the table locking operation is completed within the preset time, it means that the table locking operation is successful and the database is in a consistent state. At this time, the system will send a snapshot operation command to the snapshot module to begin the snapshot operation. The purpose of a snapshot operation is to generate a consistent copy of the database at a specific point in time for subsequent backup or recovery operations.

[0019] After receiving the snapshot operation command, the snapshot module begins executing the snapshot operation. Before the snapshot begins, the system re-checks data consistency to ensure that the data has not been modified while the tables are locked. A snapshot copy of the data is generated by calling the snapshot functionality of the underlying storage system or database (such as LVM snapshots, file system snapshots, or the database's built-in snapshot functionality). Snapshot-related information (such as snapshot time and snapshot location) is recorded in the log or metadata for later use. If the snapshot operation completes successfully, it indicates that the backup operation has successfully generated a consistent data copy. The system proactively releases the global read lock previously acquired using the `FLUSH TABLES WITH READ LOCK` command. This step is crucial because it allows the database to resume normal read and write operations, minimizing the impact on business operations. The system marks the backup operation as successfully completed and records backup-related information (such as backup time, backup type, and snapshot location). This information can be used for subsequent backup management, recovery operations, or auditing.

[0020] Through the above process, the system can complete database backup operations efficiently and reliably. By employing key mechanisms such as identifying the target database, detecting long transactions, performing table locking operations, generating snapshots, and releasing table locks, the system ensures the success rate and efficiency of the backup operation.

[0021] For example, in the fintech field, banks' "real-time transfer systems" require a full data backup every morning for disaster recovery and audit traceability. However, during the morning hours, there may still be long transactions such as cross-time zone transactions (e.g., cross-border transfers) or automatic system reconciliations. Direct backups may lead to data inconsistencies, such as "a transfer was only deducted but not credited" or "the reconciliation results are incomplete," which may cause user complaints and financial disputes during subsequent recovery. To avoid these problems, the system predefines a "long transaction threshold" (usually set to 30 seconds, because financial transactions are mostly short processes) and monitors the transaction database to be backed up in real time through database logs. If a transaction exceeding the threshold is detected (e.g., a cross-border transfer is delayed for 5 minutes due to exchange rate synchronization delay), the backup is paused and restarted after the transaction ends, thus avoiding the risk of the backup capturing incomplete transaction data. Once it is confirmed that there are no long transactions, the system sends a command to the table locking module to execute a "read-only lock" on the core transaction tables (such as the user account table and transfer record table). The table lock timeout threshold must be strictly adapted to business characteristics (e.g., set to 10 seconds): if the table lock is completed within 10 seconds, it indicates that there are no high-frequency write operations (such as concentrated user transfers), and the snapshot phase can begin; if the timeout occurs, the table lock is abandoned to avoid user experience issues caused by the "transfer button becoming unresponsive." After a successful table lock, the snapshot module quickly generates a consistent snapshot of the transaction data (e.g., creating a read-only copy based on the database's MVCC mechanism). Since the table lock only lasts for the milliseconds required for the snapshot (far below the timeout threshold), users are almost unaware of it; the lock is released immediately after the snapshot is completed, and the transaction system resumes normal writes, ensuring business continuity (e.g., no delay in user transfers, repayments, etc.).

[0022] In the healthcare field, hospital electronic health record (EHR) systems require real-time backups of patient data (such as outpatient medical records, inpatient records, and medication lists) for cross-departmental access, medical insurance reimbursement, and emergency recovery. If a long transaction occurs during backup, such as a doctor editing a medical record, it may result in issues like missing diagnoses or incorrect medication dosages, impacting subsequent treatment decisions. In the medical context, the definition of a "long transaction" differs from that in the financial sector: a doctor editing a complex medical record might take 30 minutes (a reasonably long transaction), while a nurse entering test results is typically a short transaction (within 5 minutes). Therefore, the system sets differentiated thresholds for different tables (e.g., a 30-minute threshold for medical record tables and a 5-minute threshold for test tables). Backups are only initiated when there are no transactions exceeding the corresponding threshold in the EHR database to be backed up, thus avoiding interruptions to doctors' normal treatment operations. Table locking commands only apply to "non-real-time write tables" (such as historical medical record tables), while "exemption from table locking" rules are set for "real-time treatment tables" (such as emergency resuscitation records). The table locking timeout threshold is set to 30 seconds (to accommodate the intervals between nurses entering test results). If the table locking is completed within 30 seconds, it indicates that there is no high-frequency data writing at that time (such as during non-emergency periods), and a snapshot can be executed. If the timeout occurs (such as during peak emergency periods when nurses are continuously entering data), the backup is delayed to prioritize ensuring uninterrupted treatment processes. The snapshot module generates an encrypted snapshot of the EHR data. Since the table locking only applies to non-real-time tables and the time is extremely short (usually within 10 seconds), doctors editing medical records and nurses entering data are almost unaffected. The lock is released immediately after the snapshot is completed to ensure the real-time nature of medical data (e.g., a diagnosis just saved by a doctor can be immediately accessed by other departments).

[0023] In one embodiment, step S100 includes: S101. Obtain the database to be backed up and check whether there are long transactions in the database to be backed up; S102. If there are no long transactions in the database to be backed up, a table locking operation instruction is sent to the table locking module. S103. If there are long transactions in the database to be backed up, the table locking stage will not be entered for the time being and a long transaction alarm will be triggered.

[0024] In this embodiment, before performing the database backup operation, it is necessary to first identify the database object to be backed up. This step mainly involves determining the target database for backup to ensure that subsequent operations are performed on the correct database. For example, if there are multiple database instances in a system, it is necessary to explicitly specify which database to back up so that subsequent detection and backup operations can be executed accurately.

[0025] Before the backup operation begins, the system proactively checks the database to be backed up for long transactions. Long transactions are those that take a considerable amount of time to run, potentially consuming database resources and impacting the backup process. For example, a long-running transaction might lock certain tables or rows, affecting the backup tool's access and operations. The system determines the presence of long transactions by querying the database's transaction logs or status information. Specifically, it checks the transaction's start time, runtime, and compares this information with a preset long transaction threshold (such as a transaction runtime exceeding a certain number of minutes) to determine if it qualifies as a long transaction. Early detection of long transactions effectively avoids excessive table locking or deadlocks caused by them. Encountering long transactions during the backup process can prevent the backup operation from proceeding smoothly and may even lead to database performance issues or backup failure.

[0026] If no long-running transactions are found in the database to be backed up during the detection process, it indicates that the current transaction state of the database is relatively stable and suitable for backup operations. At this point, the system will send a table-locking operation command to the table-locking module to begin the table-locking operation. The purpose of table-locking is to ensure the consistency of database data during the backup process. By locking tables, new write operations can be prevented from modifying the data during the backup process, thereby ensuring the integrity and consistency of the backup data. Table-locking operations are usually implemented by executing specific SQL statements (such as FLUSH TABLES WITH READ LOCK), which locks the tables in the database, allowing the backup operation to proceed in a consistent state.

[0027] If a long transaction is detected in the database to be backed up, it indicates that the current database state is unsuitable for backup operations. To avoid backup failures or database performance issues caused by long transactions, the system will take the following measures: First, it will temporarily skip the table locking phase. Due to the presence of long transactions, directly entering the table locking phase may lead to excessively long locking times, or even deadlocks. Therefore, the system will temporarily skip the table locking phase to avoid unnecessary impact on the database. Second, it will cancel the snapshot operation. Since the consistency and reliability of the backup data cannot be guaranteed in the current state, the system will cancel the snapshot operation to avoid inconsistent backup data. Finally, it will issue an alert. To alert system administrators or relevant personnel about the current database state, the system will issue an alert. Alerts can be issued in various ways, such as sending emails, SMS notifications, or recording alert information in the system log. The alert content typically includes information such as the existence of long transactions and the reason for canceling the backup operation, so that relevant personnel can take timely measures to resolve the long transaction issue and create conditions for subsequent backup operations.

[0028] This preventative long transaction detection mechanism allows the solution to detect and handle long transactions before the backup operation begins, effectively preventing backup failures, database performance degradation, or deadlocks caused by long transactions. This mechanism not only improves the reliability of backup operations but also ensures the stability and availability of the database during the backup process, meeting the backup requirements of high-concurrency, large-scale database scenarios.

[0029] For example, in the fintech field, data backup technology in real-time payment systems manifests as "risk pre-filtering." For instance, a third-party payment platform's core transaction database needs to generate incremental backups hourly for tracing abnormal transactions. However, if a long transaction (lasting more than 1 minute) exists during backup (where a user scans a code to pay but the merchant hasn't confirmed), direct backup might result in incomplete data ("deduction record exists, but payment record is missing"), leading to disputes like "user complaints about missing funds" during subsequent reconciliation. To avoid this, the application process is as follows: Before backup is triggered, the system automatically scans the active transactions in the transaction database, filtering risks using a preset "long transaction threshold" (typically 30 seconds in payment scenarios). If a transaction exceeding the threshold is detected (e.g., a large payment lasting 2 minutes due to network fluctuations), the system immediately cancels the snapshot operation and simultaneously pushes an alarm message (including transaction ID, involved accounts, and duration) to the operations center. Operations personnel can then determine whether manual intervention is needed (e.g., contacting the merchant to confirm the transaction status) based on the alarm message. After the long transaction is completed, the system will restart the backup process to ensure that the "deduction and receipt records of each payment" in the backup data strictly correspond.

[0030] In the healthcare field, data backup is directly related to patient safety. Incomplete data such as electronic medical records and test results can lead to misdiagnosis or treatment delays. This technology ensures that the backup data accurately reflects the patient's treatment status through strict control of long transactions. In electronic medical record (EMR) systems, the application of this technology focuses on balancing "real-time editing by doctors with backup integrity." For example, the EMR system of a top-tier hospital needs to back up the day's outpatient medical records at 3:00 AM every day for medical insurance reimbursement review. If a long transaction (lasting more than 30 minutes) exists during backup, such as "a doctor is editing a multidisciplinary consultation record for a cancer patient," direct backup may result in invalid data with "missing consultation conclusions," which may lead to reimbursement rejection due to "insufficient diagnostic evidence" during medical insurance review. The implementation logic of this technology is as follows: The system presets a "medical long transaction threshold" (15 minutes for medical record editing scenarios) and scans the active transactions in the EMR database before backup. When a transaction exceeding the threshold is detected (e.g., a doctor editing a complex medical record for 20 minutes), the system immediately cancels the snapshot and sends an alarm to the information technology department (including the medical record ID, patient name, and attending physician). The IT department can notify doctors via the hospital intranet that "the current medical record editing has triggered a backup alert; it is recommended to save and then pause the operation." After the doctor completes the editing and submits the transaction, the system will automatically restart the backup, ultimately ensuring that the backed-up medical record contains the complete chain of "chief complaint, examination results, consultation opinions, and treatment plan."

[0031] In one embodiment, step 103 specifically includes: If a long transaction exists in the database to be backed up, then obtain the completion time of the long transaction; Compare the completion time with the completion time threshold; If the completion time is less than or equal to the completion time threshold, then wait for the long transaction to complete; If the completion time is greater than the completion time threshold, the table locking phase will not be entered and a long transaction alarm will be triggered.

[0032] In this embodiment, before performing data backup, it is necessary to actively detect whether long transactions exist in the database. Long transactions refer to transactions with long execution times, which may adversely affect the efficiency and reliability of the backup operation. To assess whether long transactions will have a significant impact on the backup operation, it is necessary to obtain the estimated completion time of these long transactions. This can be done by querying the database's transaction log or system tables (such as the `INFORMATION_SCHEMA.INNODB_TRX` table in RASESQL) to obtain currently running transactions and their execution times. Then, by combining the transaction execution times, historical database performance data, and other relevant information, the completion time of the transactions can be estimated.

[0033] The completion time threshold is a preset time value used to determine whether long transactions can be completed within an acceptable timeframe. This threshold needs to be determined based on actual business needs and database performance. If the business has high requirements for database availability, the threshold should be set lower to avoid significant impact on business operations during backups. Conversely, if the database performance is good and can process transactions quickly, the threshold can be appropriately relaxed. Furthermore, a reasonable threshold also needs to be set based on the time window of the backup operation. For example, if the backup operation needs to be completed at night, the threshold can be relatively lenient; while if the backup operation needs to be completed quickly during off-peak hours, the threshold should be more stringent.

[0034] If the estimated completion time of a long transaction is less than or equal to the set completion time threshold, it means the transaction can be completed within an acceptable timeframe. In this case, the backup operation can choose to wait for the long transaction to complete to avoid performance issues or backup failures caused by table locking. Waiting for the long transaction to complete ensures that the backup operation is performed when the database state is stable, thereby guaranteeing the logical consistency of the backup data. In this way, the duration of table locking operations can be reduced, minimizing the impact on database performance.

[0035] If the estimated completion time of a long transaction exceeds the completion time threshold, it indicates that the transaction may take a considerable amount of time to complete. Continuing to wait may cause the backup operation to time out or significantly impact database performance. In this situation, the following measures should be taken: First, temporarily suspend the table locking phase to avoid excessively long table locking times or deadlocks caused by the long transaction, ensuring the normal operation of the database; second, cancel the current snapshot operation, as the completion time of the long transaction exceeds the threshold, and the backup operation cannot be completed within the scheduled time; finally, initiate alarm processing, notifying relevant personnel or the system through the alarm mechanism so that timely measures can be taken. The alarm content can include detailed information about the long transaction, the estimated completion time, and the reason for canceling the backup operation.

[0036] By employing the above logic, long transactions can be effectively managed before backup operations, ensuring smooth backup processes while minimizing the impact on database performance and business continuity. This approach demonstrates high practicality and reliability in high-concurrency, large-scale database scenarios.

[0037] For example, in the fintech field, high-frequency trading systems are a typical application scenario. High-frequency trading relies on millisecond-level data updates, and each transaction is linked to fund flows. If long transactions exist during backup, it may lead to data inconsistency, thus affecting subsequent settlement and risk control. To address this, relevant technologies can detect long transactions. For instance, a 30-second threshold can be set for long transactions. When a transaction exceeding this threshold is detected, the system obtains its estimated completion time. If the completion time is within the threshold, the system waits for the transaction to complete before initiating the backup. Taking a securities high-frequency trading system as an example, a large transaction became a long transaction due to system delays. After technical detection, it was determined that the transaction could be completed in 50 seconds, which is within the set 60-second threshold. Therefore, the system waited for the transaction to complete before performing the table locking operation. A 10-second timeout was set during table locking to ensure that the data is frozen within a short period. After generating a snapshot, the lock is released immediately, ensuring the integrity of the transaction data without affecting subsequent transactions. Cross-border payment platforms can also benefit from this technology. Cross-border payments involve multi-node data synchronization, which is prone to long transactions. This technology can prevent backup data errors. When a long transaction is detected and its completion time exceeds a threshold, the system cancels the snapshot and triggers an alarm. For example, a long transaction involving the exchange of multiple currencies on a cross-border payment platform was expected to take 150 seconds to complete. Since this exceeded the 120-second threshold, the system immediately issued an alarm, and staff intervened to handle the situation, thus preventing reconciliation issues caused by incorrect backups.

[0038] In the healthcare field, electronic medical record (EMR) systems are widely used. EMRs require real-time updates, which are crucial for patient safety. If a doctor is editing a long transaction during backup, critical information may be missing from the backup. This technology plays a vital role by detecting long transactions and setting thresholds based on different operations. For example, the threshold for editing complex medical records could be set to 30 minutes. When a long transaction is detected, the system obtains its estimated completion time; if it's within the threshold, it waits. In a hospital's EMR system, a doctor was editing a detailed medical record for a cancer patient. The system detected this long transaction, estimated to take 25 minutes to complete, within the 30-minute threshold. Therefore, the system waited for it to complete and then locked the table. This table locking is for non-real-time operations, with a timeout of 20 seconds to ensure rapid snapshot generation and that releasing the lock does not affect the real-time operations of doctors and nurses. This technology is also applicable to real-time medical monitoring platforms. These platforms collect patients' vital signs data in real time, which needs to be backed up in real-time for doctors' reference. If long transactions exist, the backup data may be inaccurate. When the system detects a long transaction, it will cancel the snapshot and issue an alarm if the completion time exceeds a threshold. For example, if an ICU real-time monitoring platform experiences a long data transmission transaction due to equipment failure, with an estimated completion time of 40 seconds, exceeding the 30-second threshold, the system will immediately issue an alarm. Technicians will promptly repair the issue, ensuring the accuracy of the monitoring data backup and providing reliable information for doctors' diagnoses.

[0039] In one embodiment, step S200 includes: S201. Receive the table lock operation instruction, execute the global-level read lock command, and time the execution time of the table lock operation to obtain the table lock time; S202. If the table locking operation is completed and the table locking time is less than or equal to the preset table locking time, then send a snapshot operation instruction to the snapshot module. S203. If the table locking operation is not completed and the table locking time is greater than the preset table locking time, then exit the table locking operation and trigger a table locking failure alarm.

[0040] In this embodiment, when the system detects that no long-lived transactions exist in the database to be backed up, it sends a table locking operation command to the table locking module. Upon receiving the command, the table locking module executes a global read lock command, such as `FLUSH TABLES WITH READ LOCK`. This command locks all tables in the database, ensuring the backup operation is performed in a consistent state. At this time, tables in the database can only be read, not written, thus guaranteeing the integrity and consistency of the backup data. By executing the `FLUSH TABLES WITH READ LOCK` command, all tables in the database are flushed to disk and read locks are acquired, ensuring that data is not modified during the backup process.

[0041] While performing a table locking operation, the system starts a timer to record the execution time of the operation, known as the table locking time. The purpose of this timer is to monitor whether the table locking operation completes within a reasonable timeframe, thus determining if it has timed out. If the table locking operation takes too long, it may lead to database performance degradation or prevent successful backup operations. The table locking time is the time interval from the execution of the table locking command to the completion of the operation. If the table locking operation completes within a preset timeframe (i.e., the table locking time is less than or equal to the preset time), it indicates that the operation is successful and has not significantly impacted database performance. At this point, the system sends a snapshot operation command to the snapshot module to begin the snapshot backup operation. The preset table locking time is a pre-defined time threshold used to determine if the table locking operation has timed out; for example, it can be set to 1 minute. The snapshot operation command is the instruction from the system to the snapshot module to begin the snapshot backup operation when the table locking operation completes successfully and has not timed out. The snapshot module then generates snapshot data for the database based on the backup requirements.

[0042] If a table locking operation fails to complete within the preset time frame (i.e., the locking time exceeds the preset time), it indicates a potential problem, such as database resource constraints or lock conflicts. To prevent backup operations from waiting excessively for table locking to complete, the system takes the following measures: First, the system proactively exits the table locking operation, releasing the lock command from its impact on the database and preventing performance degradation or backup failures due to incomplete locking. Second, the system triggers a table locking failure alarm, notifying the system administrator or relevant personnel that the operation failed to complete within the preset time. Alarms can be sent in various ways, such as via email, SMS, or logging in the system log. Alarm content typically includes the reason for the locking failure and the locking time, allowing relevant personnel to promptly investigate and address the issue.

[0043] This table-locking timeout control mechanism effectively prevents backup failures or database performance issues caused by table-locking operation timeouts. By setting reasonable table-locking time thresholds and promptly exiting and alerting when a table-locking operation times out, the system ensures the timeliness of backup operations and the high availability of the database. This mechanism has significant application value in high-concurrency, large-scale database scenarios, significantly improving the reliability and efficiency of backup operations.

[0044] For example, in the fintech field, high-frequency trading systems in securities need to back up the day's transaction details (such as order books, transaction records, and fund flows) after the market closes each day for regulatory audits and disaster recovery. During the backup process, the system first sends a global read lock command to the table locking module, imposing read-only restrictions on core tables such as the user account table and the transaction order table, while simultaneously starting a timer. The table locking threshold is usually preset to 5 seconds, which is a "business silence window" calculated based on historical data. If the table locking is completed within 5 seconds, it means that there are no high-frequency write operations at that time (such as user margin calls, order cancellations, etc.), and the system will immediately trigger the snapshot module to generate a consistent copy, and then release the lock. The entire process has no impact on the clearing business before the opening of the next day. However, if the table locking timeout (more than 5 seconds without completion) is caused by a sudden peak (such as a sudden large number of orders for a certain stock before the market closes), the system will immediately exit the table locking operation and trigger a three-level alarm: a pop-up prompt on the operation and maintenance terminal, an SMS notification to the responsible person, and a "abnormal batch" mark in the backup log. This mechanism can avoid the risk of "forced table locking causing transaction blockage". For example, in a 2023 case study by a securities firm, this technology promptly detected table-locking anomalies through timeout alerts. After investigation, it was confirmed that an external interface anomaly caused duplicate order submissions. Emergency measures were taken, and the backup was re-executed, ultimately preventing any impact on the next day's clearing and reconciliation. In cross-border payment platforms, the application of this technology further highlights its "controllable risk" characteristic. Cross-border payments involve multiple currency exchanges, anti-money laundering screening, and other lengthy transactions, requiring backups to ensure the atomicity of "payment instructions and receipt records." When the system executes a global read lock, the threshold is set to 8 seconds (adapting to the message synchronization cycle of international clearing). If the table lock is completed within 8 seconds, the snapshot accurately captures the "complete transaction chain that has been cleared." If a timeout occurs, an alarm mechanism is used to link with the business middleware to suspend non-emergency payments, retrying only after the table-locking environment stabilizes. This design avoids "table-locking timeouts causing payment channel congestion" while ensuring the consistency of backup data with the central bank's clearing system.

[0045] In the healthcare field, taking the electronic medical record database of a top-tier hospital as an example, a full backup of outpatient / inpatient medical records is required every day at 3:00 AM for archiving and evidence collection in medical disputes. At this time, the system needs to perform a global read lock on the patient basic information table, diagnosis record table, and medication list table, with a preset threshold of 10 seconds. This is based on the "low-business period" in clinical practice: few doctors enter new medical records at 3:00 AM, and the 10-second lock window is sufficient to complete the snapshot. If the lock is successful within 10 seconds, the snapshot can completely capture the entire chain of data for a particular surgery, including preoperative examinations, intraoperative records, and postoperative medical orders, ensuring that the backup data can support subsequent medical record backtracking. However, if an emergency (such as a batch of trauma patients admitted to the emergency department and doctors urgently entering resuscitation records) causes the lock to time out, the system will immediately exit the operation and trigger a medical-grade alarm: a pop-up notification in the HIS system, automatic calling of the IT department's on-call phone, and marking the backup task as "pending priority processing." This mechanism avoids the fatal risk of "locking the table and blocking the entry of emergency records." For example, in a practical case at a children's hospital, this technology promptly detected ICU data being entered in the emergency department due to a timeout during table locking. After the emergency treatment was completed, a backup was re-executed, ultimately ensuring the integrity of the "full record of the emergency process" and providing reliable data for subsequent case analysis. This technology also plays a crucial role in regional medical data platform scenarios. The platform needs to aggregate test results and imaging data from multiple hospitals, and backups must ensure the logical continuity of "cross-hospital examination data for the same patient." When the system performs a global read lock, the threshold is set to 15 seconds (adapting to the distributed synchronization cycle of the data platform). If the table locking is completed within 15 seconds, the snapshot can accurately associate "Patient A's CT image at Hospital A + Blood Routine Report at Hospital B"; if a timeout occurs, an alarm is triggered to suspend non-urgent data aggregation tasks in the data platform, and retrying after the table locking environment stabilizes, preventing data upload failures at primary hospitals due to forced table locking.

[0046] In one embodiment, step S203 further includes: S2031. When the meter locking operation is not completed and the meter locking time is greater than the preset meter locking time, the meter locking operation is checked in real time according to the preset time interval. S2032. Compare the timeout duration with the preset timeout duration. S2033. If the time taken for the lock operation is between the preset lock time and the lock duration, then a snapshot operation command is sent to the snapshot module. S2034. If the time taken for the table locking operation is greater than the table locking duration and the table locking operation is not completed, then the lock is forcibly released and the backup task is terminated, and an abnormal table locking duration alarm is triggered.

[0047] In this embodiment, if the table locking operation fails to complete within the preset locking time (e.g., 1 minute), the system will not directly abandon the operation but will instead enter a polling phase. During this phase, the system will check whether the table locking operation has been completed at preset time intervals (e.g., every 10 seconds). The preset time interval is a pre-defined interval used to control the polling frequency; for example, it can be set to check the table locking status every 10 seconds. Through this polling mechanism, the system can dynamically monitor the progress of the table locking operation, rather than simply waiting for a fixed timeout, which allows for more flexible handling of various situations that may arise during the operation.

[0048] During the polling process, the system continuously records the total time of the table locking operation and compares it with the preset table locking duration. The table locking duration is a longer time threshold than the preset duration, defining the maximum allowed time for a table locking operation. The preset table locking duration is a stricter timeout limit, typically longer than the preset duration. For example, the preset duration could be 1 minute, while the table locking duration could be 3 minutes. The system determines whether the table locking operation exceeds the allowed range by comparing the actual execution time and the table locking duration.

[0049] If the table locking operation completes after the preset locking time but still within the lock duration, it means that although the table locking operation was delayed, it was ultimately successful. At this point, the system sends a snapshot operation command to the snapshot module to begin the snapshot backup operation. The snapshot operation command is the instruction from the system to the snapshot module to begin the snapshot backup operation after the table locking operation has successfully completed. This means that even though the table locking operation was delayed, the backup operation can still continue. This design allows the system to still have a chance to complete the backup operation even if the table locking operation is delayed, rather than directly abandoning the backup task.

[0050] If the table locking operation fails to complete after the allowed lock time, it indicates that the operation has exceeded the maximum permitted waiting time. In this case, the system will take the following measures: First, to prevent the table locking operation from continuing to impact the database, the system will forcibly release the lock command to prevent the database from malfunctioning due to prolonged table locking. Second, since the table locking operation failed to complete within the allowed time, the backup task cannot continue, so the system will terminate the backup task. Finally, the system will trigger an abnormal table locking duration alarm, notifying the system administrator or relevant personnel that the table locking operation failed to complete within the allowed time. Alarms can be issued in various ways, such as sending emails, SMS notifications, or recording alarm information in the system log. The alarm content typically includes information such as the reason for the table locking operation failure and the locking time, so that relevant personnel can promptly investigate the problem and take appropriate measures.

[0051] This mechanism ensures that if a table locking operation fails to complete within a preset time, the system will not immediately abandon the backup task. Instead, it will flexibly handle the situation through polling and stricter timeout controls. This design not only improves the reliability of backup operations but also ensures high availability and stability of the database during the backup process. Furthermore, by forcibly releasing locks and triggering alarms, the system can promptly detect and address potential problems, preventing backup operations from having an excessive impact on database performance.

[0052] For example, in the fintech field, high-frequency trading systems in securities are required to back up the day's trading data (including orders, transaction records, and fund flows) 30 minutes after market close each day for regulatory auditing and disaster recovery. The system presets a "lock time" of 8 seconds (based on historical data, locking within 8 seconds can cover 95% of the quiet business periods) and a "lock duration" of 20 seconds (allowing some flexibility to avoid misjudgment due to instantaneous peaks). When a backup is triggered, if the lock operation is not completed within 8 seconds (e.g., a sudden surge in user inquiries about holdings causing lock blockage), the system will immediately initiate a real-time check mechanism, scanning the lock status every 2 seconds. If the lock is completed at the 12th second (still less than the 20-second duration), the system will immediately send a command to the snapshot module to generate backup data containing the "complete transaction chain," and then release the lock. The entire process will not affect the initialization of post-market clearing (clearing must be started after the lock is released). However, if extreme circumstances (such as a sudden delisting announcement for a stock triggering tens of thousands of users to cancel orders) cause the lock to remain locked for more than 22 seconds (exceeding the 20-second duration), the system will perform a "forced lock release + backup termination" operation, triggering a level four alarm: red text flashing on the trading system console, the operations team making phone calls, and the backup log being marked "critical." This mechanism can avoid the catastrophic consequences of "continuous lock blocking the order cancellation channel." For example, in a practical case at a securities firm in 2024, this technology, by forcibly releasing the lock, enabled the order cancellation business to return to normal within 3 seconds, sacrificing only one non-core backup, but avoiding losses exceeding 100 million yuan due to users being unable to cancel orders.

[0053] In the healthcare field, ICU real-time monitoring systems require backing up patients' real-time data, such as heart rate, blood pressure, and ventilator parameters, every 15 minutes for patient review and treatment analysis. The system has a preset "lock time" of 10 seconds (ICU data writes are extremely frequent, necessitating strict limits on the basic lock duration) and a "lock duration" of 25 seconds (allowing for some buffering to avoid frequent trigger failures). If the lock is not completed within 10 seconds (e.g., due to congestion caused by multiple monitors simultaneously uploading data), the system checks every 3 seconds. If the lock is completed within 20 seconds, the snapshot module immediately generates a backup containing a "complete vital signs curve," and releasing the lock does not affect the monitor's real-time writes. If the lock is not completed within 28 seconds (exceeding the 25-second duration), the system forcibly releases the lock and triggers a medical-grade alarm (ICU nurse station audible and visual alarm, IT department on-call mobile phone pop-up). A top-tier hospital's ICU used this mechanism to forcibly release the lock after 30 seconds of timeout, ensuring uninterrupted real-time data recording after defibrillation for myocardial infarction patients, with subsequent data recovery via differential backup.

[0054] In one embodiment, step S300 includes: S301. Receive a snapshot operation instruction and execute the snapshot operation; S302. Determine whether the snapshot operation was successful; S303. If the snapshot operation is successful, the lock is actively released to complete the database backup. S304. If the snapshot operation fails, the lock is forcibly released, the backup task is terminated, and a snapshot failure alarm is triggered.

[0055] In this embodiment, once the table locking operation is successfully completed and preset conditions are met (e.g., the table locking time is within an allowed range), the system sends a snapshot operation instruction to the snapshot module. Upon receiving the instruction, the snapshot module begins executing the snapshot operation. The purpose of the snapshot operation is to generate a consistent data copy of the database at a specific point in time. This copy can be used for subsequent backups, recovery, or other data management operations. Before the snapshot begins, the system checks the data consistency again to ensure that the data has not been modified while the table is locked. A snapshot copy of the data is generated by calling the snapshot function of the underlying storage system or database (e.g., LVM snapshot, file system snapshot, or the database's built-in snapshot function). Simultaneously, relevant snapshot information (such as snapshot time, snapshot location, etc.) is recorded in the log or metadata for later use.

[0056] After a snapshot operation is completed, the system needs to determine whether the snapshot operation was successful. This is typically achieved by checking error messages during the snapshot generation process, returning status codes, or verifying the integrity of the snapshot data. Success conditions include no errors during snapshot generation, complete and consistent snapshot data, and correct recording of snapshot metadata (such as snapshot timestamps and snapshot locations). Failure conditions include storage system failures (such as insufficient disk space or storage device failure), internal database errors (such as snapshot functionality being unavailable or data corruption), and network problems (such as snapshot data transmission failure).

[0057] If the snapshot operation completes successfully, the system will proactively release the lock, that is, actively release the global read lock previously acquired using the `FLUSHTABLES WITH READ LOCK` command. This step is crucial because it allows the database to resume normal read and write operations, minimizing the impact on business operations. Subsequently, the system will mark the backup operation as successfully completed and record relevant backup information (such as backup time, backup type, snapshot location, etc.). This information can be used for subsequent backup management, recovery operations, or auditing.

[0058] If a snapshot operation fails, the system will forcibly release the lock. This is to prevent the database from malfunctioning due to prolonged table locking, and the system will forcibly release the table lock command. This step is necessary to ensure the database can be restored to a normal state as quickly as possible. Simultaneously, since the snapshot operation failed, the backup task cannot continue, so the system will terminate the current backup task. Furthermore, the system will trigger a snapshot failure alarm to notify the system administrator or relevant personnel that the snapshot operation failed to complete successfully. Alarms can be issued in various ways, such as sending emails, SMS notifications, or recording alarm information in the system log. The alarm content typically includes the reason for the snapshot failure (such as insufficient storage space, network problems, etc.), the time of the snapshot operation failure, and relevant logs or error messages, so that relevant personnel can promptly troubleshoot the problem.

[0059] This mechanism allows the system to promptly release locks and complete backup tasks upon successful snapshot operations, ensuring high database availability and business continuity. Conversely, in the event of a snapshot failure, the system can respond quickly, forcibly releasing locks and terminating the backup task to prevent excessive impact on database performance. Furthermore, by triggering alerts, system administrators can promptly identify and address issues, ensuring the reliability of backup operations and data security.

[0060] For example, in fintech operations, financial institutions' systems periodically receive snapshot operation instructions. These instructions may be triggered automatically by the system or manually initiated by operations personnel. For instance, during the clearing phase after the close of daily trading, the system automatically sends a snapshot instruction to back up all transaction records and account balance data for the day. The snapshot operation quickly takes a snapshot of the data in the database, generating a data copy. This process needs to be efficient and low-latency to ensure it doesn't significantly impact normal financial operations. For example, in a banking system, a snapshot operation can complete the backup of massive amounts of transaction data within seconds, ensuring data integrity. The system uses verification algorithms (such as hash verification) to determine if the snapshot operation was successful. If the verification result shows that the data is complete and consistent, the snapshot operation is considered successful. For example, by comparing the hash values ​​of the snapshot data and the source data, it can be quickly determined whether the data has been tampered with or lost during the backup process. If the snapshot operation is successful, the system proactively releases the lock, completing the database backup. This indicates that the backup task has been successfully completed, and the system can continue to operate normally. For example, after completing the snapshot, financial institutions can store the backup data in an off-site data center to prevent data loss in the event of a failure in the local data center. If a snapshot operation fails, the system will forcibly release the lock and terminate the backup task, triggering a snapshot failure alarm. Operations personnel will receive an alarm notification and can promptly investigate the problem. For example, if a network failure prevents complete data transfer, operations personnel can quickly fix the network issue and restart the backup task.

[0061] In healthcare operations, hospital information systems periodically receive snapshot commands to back up electronic medical record (EMR) data. These commands may be triggered automatically, such as during off-peak hours at night when the system automatically backs up the day's medical records. The snapshot operation backs up the EMR database, creating a data copy. This process requires ensuring data integrity and privacy. For example, encryption technology is used to encrypt the backup data to prevent theft during transmission and storage. The system uses a verification algorithm to determine if the snapshot operation was successful. If the verification result shows that the data is complete and consistent, the snapshot operation is considered successful. For example, by comparing the hash values ​​of the backup data and the source data, it can be quickly determined whether the data has been tampered with or lost during the backup process. If the snapshot operation is successful, the system will proactively release the lock, completing the database backup. This indicates that the backup task has been successfully completed, and the system can continue to operate normally. For example, hospitals can store backup data in off-site data centers to prevent data loss in the event of a failure in the local data center. If the snapshot operation fails, the system will forcibly release the lock and terminate the backup task, triggering a snapshot failure alarm. Maintenance personnel will receive an alarm notification and promptly investigate the problem. For example, if a backup fails due to a storage device malfunction, the maintenance personnel can quickly repair the device and restart the backup task.

[0062] In one embodiment, the database backup method includes step S400, specifically including: S401. Perform a snapshot operation and time the snapshot operation to obtain the execution time; S402. Compare the execution time with the preset backup time; S403. If the execution time is less than or equal to the preset backup time, the data backup is determined to have failed, and a backup anomaly alarm is triggered. S404. If the execution time is greater than the preset backup time, the data backup is determined to be successful.

[0063] In this embodiment, after the snapshot module receives the snapshot operation instruction, the system starts a timer to record the execution time of the snapshot operation until it is completed. The purpose of the snapshot operation is to generate a consistent data copy of the database at a specific point in time. This is usually achieved by calling the underlying storage system (such as LVM snapshots) or the database's snapshot function. By timing the snapshot, the system can monitor whether the snapshot operation is completed within a reasonable time range, thereby avoiding the impact on the normal operation of services due to excessively long snapshot operation times.

[0064] After a snapshot operation is completed, the system compares the execution time of the snapshot operation with the preset backup time. The preset backup time is a pre-defined time threshold used to define the maximum allowed time for a snapshot operation, for example, it can be set to 5 minutes. The system will determine whether the execution time of the snapshot operation is less than or equal to the preset backup time.

[0065] If the snapshot operation takes less than or equal to the preset backup time, it means that although the snapshot operation was completed, it did not complete within the expected time. According to the documentation, this situation is considered a data backup failure. Even if the snapshot operation is completed, if the execution time is significantly abnormally long, the backup is considered to have failed. In this case, the system will trigger a backup anomaly alarm, notifying the system administrator or relevant personnel that the backup operation failed to complete within the expected time. Alarms can be issued in various ways, such as sending emails, SMS notifications, or recording alarm information in the system log. The alarm content typically includes the snapshot operation's execution time, the preset backup time, and the reason for the backup failure (e.g., excessively long execution time).

[0066] If the snapshot operation takes longer than the preset backup time, it means the snapshot operation completed within the expected time, and therefore the data backup is considered successful. If the snapshot operation completes within the preset backup time, it means the backup operation met expectations, and therefore the backup is considered successful. After determining that the backup is successful, the system will continue to perform subsequent backup operations, such as storing the snapshot data in the backup storage device and recording relevant backup information (such as backup time, backup location, etc.).

[0067] By comparing time and time thresholds, the system can determine whether a snapshot operation was successful. This mechanism not only ensures that the backup operation can be completed, but also ensures that it is completed within a reasonable timeframe, thus guaranteeing the efficiency and reliability of the backup operation. Simultaneously, by triggering backup anomaly alarms, system administrators can promptly identify and address problems in the backup operation, ensuring the integrity and consistency of the data backup.

[0068] For example, in the fintech field, cryptocurrency trading systems need to perform hourly snapshot backups of transaction data, covering information such as user holdings, transaction records, and fund flows. Based on historical data and peak business activity, the system presets a backup time of 15 minutes. When performing a snapshot operation, if the actual execution time is 10 minutes (less than 15 minutes), the system will determine the backup has failed and trigger an alarm. This is because cryptocurrency transaction data is large and closely interconnected; a normal backup needs to completely capture all information, and too short a time may lead to data omissions. For example, the transaction record of a certain transaction may not be included in the backup. If the system subsequently malfunctions, discrepancies may appear when restoring the data, potentially causing user disputes. However, when the execution time is 18 minutes (greater than 15 minutes), the backup is considered successful. At this time, the backup data can fully reflect all transaction information within that hour, providing a reliable basis for fault recovery and regulatory audits. For example, a cryptocurrency exchange once experienced a snapshot execution time of only 8 minutes. The system promptly issued an alarm, and technical personnel investigated and found that the data synchronization delay of some nodes caused the snapshot to not completely capture information. After repairing and re-running the backup, potential risks caused by incorrect backup data were avoided.

[0069] In the healthcare field, telemedicine platforms need to store patient consultation records, examination reports, prescription information, etc., in real time and perform a full snapshot backup weekly. Based on data growth rate and transmission efficiency, the preset backup time is 30 minutes. When the snapshot execution time is 20 minutes (less than 30 minutes), the system determines the backup has failed and triggers an alarm. This is because telemedicine data contains a large number of multimedia files such as images and videos; a normal backup requires sufficient time for transmission and processing, and too short a time may result in the loss of some examination reports or consultation videos. For example, if a patient's CT images are not backed up, doctors will not be able to view historical images during subsequent follow-up visits, potentially affecting the accuracy of diagnosis. When the execution time is 35 minutes (more than 30 minutes), the backup is considered successful, and the backup data completely covers all patient information, ensuring the continuity of remote diagnosis and treatment. For example, one telemedicine platform triggered an alarm because the snapshot execution time was only 25 minutes. Upon investigation, it was found that network bandwidth fluctuations caused some data transmission interruptions, resulting in the loss of prescription information for several patients. Technicians immediately took measures to restore transmission and re-backup, ensuring the integrity of the medical data.

[0070] In one embodiment, a database backup device is provided, which corresponds one-to-one with the database backup methods described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database backup device of the present invention. The modules include a long transaction module 10, a table locking module 20, and a snapshot module 30. Detailed descriptions of each functional module are as follows: The long transaction module 10 is used to obtain the database to be backed up, detect whether there are long transactions in the database to be backed up, and when there are no long transactions in the database to be backed up, send a table locking operation instruction to the table locking module. The table locking module 20 is used to execute a table locking operation according to the table locking operation instruction, and to determine whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module 30 is used to execute snapshot operations according to snapshot operation instructions and determine whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released to complete the database backup.

[0071] In one embodiment, the long transaction module 10 includes: The long transaction judgment unit is used to obtain the database to be backed up and detect whether there are long transactions in the database to be backed up. The long transaction existence unit is used to send a table locking operation instruction to the table locking module if there is no long transaction in the database to be backed up. The "Long Transaction Does Not Exist" unit is used to temporarily prevent the table locking phase from starting up and to trigger a long transaction alarm if a long transaction exists in the database to be backed up.

[0072] In one embodiment, the long transaction non-existent unit specifically includes: If a long transaction exists in the database to be backed up, then obtain the completion time of the long transaction; Compare the completion time with the completion time threshold; If the completion time is less than or equal to the completion time threshold, then wait for the long transaction to complete; If the completion time is greater than the completion time threshold, the table locking phase will not be entered and a long transaction alarm will be triggered.

[0073] In one embodiment, the watch locking module 20 includes: The table locking execution unit is used to receive table locking operation instructions, execute global-level read lock commands, and time the execution time of the table locking operation to obtain the table locking time. The table locking completion unit is used to send a snapshot operation instruction to the snapshot module if the table locking operation is completed and the table locking time is less than or equal to a preset table locking time. The table locking failure unit is used to exit the table locking operation and trigger a table locking failure alarm if the table locking operation is not completed and the table locking time is greater than a preset table locking time.

[0074] In one embodiment, the table lock failure unit specifically includes: If the table locking operation is not completed and the table locking time is longer than the preset table locking time, then the table locking operation is checked in real time according to the preset time interval to see if it is completed. Compare the timeout duration with the preset timeout duration; If the time taken for the table locking operation is between the preset table locking time and the table locking duration, then a snapshot operation command is sent to the snapshot module. If the time taken by the table locking operation exceeds the table locking duration and the table locking operation is not completed, the lock will be forcibly released and the backup task will be terminated, and an abnormal table locking duration alarm will be triggered.

[0075] In one embodiment, the snapshot module 30 includes: A snapshot operation unit is used to receive snapshot operation instructions and execute the snapshot operation; A snapshot operation determination unit is used to determine whether the snapshot operation is successful; The snapshot operation success unit is used to actively release the lock and complete the database backup if the snapshot operation is successful. The snapshot operation failure unit is used to forcibly release the lock, terminate the backup task, and trigger a snapshot failure alarm if the snapshot operation fails.

[0076] In one embodiment, the verification module 40 includes: The execution time unit is used to perform snapshot operations and time the snapshot operation to obtain the execution time. An execution time determination unit is used to compare the execution time with a preset backup time; The backup exception unit is used to determine that the data backup has failed and trigger a backup exception alarm when the execution time is less than or equal to the preset backup time. The backup success unit is used to determine that the data backup is successful if the execution time is greater than the preset backup time.

[0077] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external user terminals via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a database backup method on the server side.

[0078] In one embodiment, a computer device is provided, which may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps of a database backup method on the user side. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the database to be backed up, check whether there are long transactions in the database to be backed up, and if there are no long transactions in the database to be backed up, send a table locking operation command to the table locking module; The table locking module executes the table locking operation according to the table locking operation instruction and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module executes a snapshot operation according to the snapshot operation instruction and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

[0079] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain the database to be backed up, check whether there are long transactions in the database to be backed up, and if there are no long transactions in the database to be backed up, send a table locking operation command to the table locking module; The table locking module executes the table locking operation according to the table locking operation instruction and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module executes a snapshot operation according to the snapshot operation instruction and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

[0080] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0081] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0082] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0083] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A database backup method, characterized in that, Includes the following steps: Obtain the database to be backed up, check whether there are long transactions in the database to be backed up, and if there are no long transactions in the database to be backed up, send a table locking operation command to the table locking module; The table locking module executes the table locking operation according to the table locking operation instruction and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module executes a snapshot operation according to the snapshot operation instruction and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

2. The database backup method as described in claim 1, characterized in that, The process involves acquiring the database to be backed up, detecting whether long transactions exist in the database, and if no long transactions exist, sending a table locking operation instruction to the table locking module, including: Obtain the database to be backed up and check whether there are long transactions in the database to be backed up; If there are no long transactions in the database to be backed up, a table locking operation command is sent to the table locking module; If a long transaction exists in the database to be backed up, the table locking phase will not be initiated and a long transaction alarm will not be triggered.

3. The database backup method as described in claim 2, characterized in that, If a long transaction exists in the database to be backed up, the table locking phase will not be entered and a long transaction alarm will not be triggered. Specifically, this includes: If a long transaction exists in the database to be backed up, then obtain the completion time of the long transaction; Compare the completion time with the completion time threshold; If the completion time is less than or equal to the completion time threshold, then wait for the long transaction to complete; If the completion time is greater than the completion time threshold, the table locking phase will not be entered and a long transaction alarm will be triggered.

4. The database backup method as described in claim 1, characterized in that, The table locking module executes a table locking operation according to the table locking operation instruction, and determines whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module, including: Receive the table lock operation command, execute the global-level read lock command, and time the execution time of the table lock operation to obtain the table lock time; If the table locking operation is completed and the table locking time is less than or equal to the preset table locking time, then a snapshot operation instruction is sent to the snapshot module. If the table locking operation is not completed and the table locking time is longer than the preset table locking time, the table locking operation will be exited and a table locking failure alarm will be triggered.

5. The database backup method as described in claim 4, characterized in that, The step of exiting the table locking operation and triggering a table locking failure alarm if the table locking operation is not completed and the table locking time is longer than the preset table locking time also includes: If the table locking operation is not completed and the table locking time is longer than the preset table locking time, then the table locking operation is checked in real time according to the preset time interval to see if it is completed. Compare the timeout duration with the preset timeout duration; If the time taken for the table locking operation is between the preset table locking time and the table locking duration, then a snapshot operation command is sent to the snapshot module. If the time taken by the table locking operation exceeds the table locking duration and the table locking operation is not completed, the lock will be forcibly released and the backup task will be terminated, and an abnormal table locking duration alarm will be triggered.

6. The database backup method as described in claim 1, characterized in that, The snapshot module executes a snapshot operation according to the snapshot operation instruction, and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released, and the database backup is completed. This includes: Receive snapshot operation instructions and execute the snapshot operation; Determine whether the snapshot operation was successful; If the snapshot operation is successful, the lock is released proactively, and the database backup is completed. If the snapshot operation fails, the lock will be forcibly released, the backup task will be terminated, and a snapshot failure alarm will be triggered.

7. The database backup method as described in claim 1, characterized in that, The snapshot module executes a snapshot operation according to the snapshot operation instruction, and determines whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released, and after the database backup is completed, the process also includes: Perform a snapshot operation and time the snapshot operation to obtain the execution time; Compare the execution time with the preset backup time; If the execution time is less than or equal to the preset backup time, the data backup is determined to have failed, and a backup anomaly alarm is triggered. If the execution time is greater than the preset backup time, the data backup is considered successful.

8. A database backup device, characterized in that, The database backup device includes: The long transaction module is used to obtain the database to be backed up, detect whether there are long transactions in the database to be backed up, and send a table locking operation command to the table locking module when there are no long transactions in the database to be backed up. The table locking module is used to execute table locking operations according to the table locking operation instructions, and to determine whether the table locking operation has timed out. If the table locking operation has not timed out, a snapshot operation instruction is sent to the snapshot module. The snapshot module is used to execute snapshot operations according to snapshot operation instructions and determine whether the snapshot operation is successful. If the snapshot operation is successful, the lock is actively released and the database backup is completed.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a database backup program stored on the memory and executable on the processor, wherein the database backup program, when executed by the processor, implements the steps of the database backup method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a database backup program, which, when executed by a processor, implements the steps of the database backup method as described in any one of claims 1-7.

Images