Data backup method, electronic device, and computer-readable storage medium

Abstract

Disclosed in the embodiments of the present application are a data backup method, an electronic device, and a computer-readable storage medium. The method is applied to an electronic device, which comprises a central processing unit, a memory and a hardware acceleration device, wherein the memory comprises a first buffer area. The method specifically comprises: reading first data from a first data file, and storing the read first data into a first buffer area, wherein the first data file is stored in a data disc corresponding to an original database directory; compressing the first data in the first buffer area by means of the hardware acceleration device, so as to generate backup data corresponding to the first data; and writing the backup data into a data disc corresponding to a backup directory. The embodiments of the present application can improve the efficiency of data backup.

Description

Data backup method, electronic device, and computer-readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on June 19, 2023, with application number 202310729914.0, and invention name “Data backup method, electronic device and computer-readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of databases, and in particular to a data backup method, an electronic device, and a computer-readable storage medium. Background Art

[0003] With the rapid development of network and communication technologies, massive amounts of data are impacting various industries at an unprecedented rate. To effectively manage and maintain this data, users typically use databases for storage. Furthermore, to prevent data loss, users often need to perform physical database backups.

[0004] At the same time, how to improve the efficiency of physical backup of databases is a concern of the industry.

[0005] Summary of the Invention

[0006] The embodiments of the present application disclose a data backup method, an electronic device, and a computer-readable storage medium, which can improve the physical backup efficiency of a database.

[0007] The first aspect discloses a data backup method, which can be applied to electronic devices, modules in electronic devices (for example, chips, central processing units, etc.), and logic modules or software (such as the backup tool described below) that can realize all or part of the functions of electronic devices. The electronic device may include a central processing unit, a memory, and a hardware acceleration device. The memory may include a first buffer zone. The following description is based on the application to the electronic device as an example. The data backup method may include: reading the first data in the first data file and storing the first data in the first buffer zone, wherein the first data file is stored in the data disk corresponding to the original database directory; compressing the first data in the first buffer zone by the hardware acceleration device to generate backup data corresponding to the first data; and writing the backup data to the data disk corresponding to the backup directory.

[0008] In an embodiment of the present application, when performing a physical database backup, the first data can be first stored in a first buffer, and then the hardware acceleration device can be used to compress the data in units of the first buffer. This ensures that the performance of the hardware acceleration device is fully utilized, thereby improving the efficiency of data compression and, in turn, improving the efficiency of the physical database backup. Furthermore, data compression performed by the hardware acceleration device can also reduce the overall power consumption of the electronic device.

[0009] As a possible implementation, reading the first data in the first data file and storing the first data in the first buffer includes: opening the first data file; when the first buffer does not store or is not full of the first data, reading the first data in the first data file and storing the first data in the first buffer.

[0010] In the embodiment of the present application, only when the first buffer is not filled with or does not contain the first data, the first data in the first data file is read and the read first data is stored in the first buffer. In this way, the first data stored in the first buffer is not overwritten, thereby ensuring the integrity of the data and, in turn, the integrity of the backup data.

[0011] As a possible implementation, compressing the first data in the first buffer by the hardware acceleration device includes: compressing the first data in the first buffer by the hardware acceleration device when the first buffer is full of the first data.

[0012] In the embodiment of the present application, after the first buffer is full, the data in the first buffer is compressed, which can maximize the performance of the hardware acceleration device, thereby increasing the speed of physical backup of the database.

[0013] As a possible implementation, the method may further include: after the hardware acceleration device completes compressing the first data in the first buffer, changing the state of the first buffer to an idle state.

[0014] In the embodiment of the present application, a status flag can be set for the first buffer. When the status flag of the first buffer is idle, the first buffer can be used to write the first data into the first buffer. When the status flag of the first buffer is not idle, the first buffer cannot be used. In this way, it can be ensured that the electronic device can fully utilize the first buffer based on the status flag of the first buffer.

[0015] As a possible implementation, there are multiple first buffers, and the method further includes: reading remaining data from the first data file and storing the remaining data in a second buffer, where the second buffer is any other buffer in the first buffer that does not store or is not fully filled with the first data; when the hardware acceleration device completes compressing the first data in a first buffer, compressing the data in the second buffer through the hardware acceleration device.

[0016] In an embodiment of the present application, there can be multiple first buffers. In this way, while the hardware acceleration device is compressing data in one first buffer, the electronic device can write data to other buffers that have not stored or are not full of data. This allows the compression of the buffer and the storage of the buffer to be carried out in parallel, thereby further improving the efficiency of physical backup of the database.

[0017] As a possible implementation, storing the first data in the first buffer includes: verifying the first data; and if the verification is successful, storing the first data page in the first buffer.

[0018] In an embodiment of the present application, before storing the read first data in the first buffer, a verification process can be performed. If the verification process succeeds, the read first data can be stored in the first buffer. This can avoid storing erroneous data and ensure the accuracy of the backup data. Furthermore, data verification can discard erroneous data, reducing the amount of data that needs to be compressed, thereby saving processing resources of the electronic device and reducing the overall power consumption of the electronic device.

[0019] As a possible implementation, the method further includes: reading first data from multiple data files in the original database directory through multiple threads, and storing the first data from the different data files read into multiple buffers that do not store or are not full of the first data in the first buffers; when a third buffer is full, compressing the data in the third buffer through the hardware acceleration device, and the third buffer is any full buffer among the multiple first buffers.

[0020] In an embodiment of the present application, data can be written to multiple buffers through multiple threads. In this way, it can be ensured that the hardware acceleration device of the electronic device always has a full buffer for compression, so that the performance of the hardware acceleration device can be fully utilized, and the efficiency of database physical backup can be further improved.

[0021] As a possible implementation, the electronic device includes multiple hardware acceleration devices, and the method further includes: when there are multiple full buffers in the multiple first buffers, compressing the data in the multiple full buffers in parallel by processing the multiple hardware acceleration devices.

[0022] In an embodiment of the present application, the electronic device may include multiple hardware acceleration devices. In this case, the electronic device may compress data in multiple buffers in parallel through the multiple hardware acceleration devices, which can further improve the efficiency of database physical backup.

[0023] As a possible implementation, the number of threads is determined based on a first time, a second time, and the number of hardware acceleration devices included in the electronic device; the first time is the time required to read the first data from the original database directory and fill a first buffer zone, and the second time is the time required for a hardware acceleration device to complete compression of a full first buffer zone and for the central processor to write the corresponding backup data to the data disk corresponding to the backup directory.

[0024] In the embodiment of the present application, the data of the threads to be started can be determined based on the first time, the second time, and the number of hardware acceleration devices. In this way, the number of threads can be ensured to be compatible with the processing capabilities of the hardware acceleration devices included in the electronic device. While ensuring that the hardware acceleration devices of the electronic device always have a full buffer available for compression, the processor resources of the electronic device will not be excessively occupied.

[0025] As a possible implementation, the number of the buffers is determined based on the first time, the second time, and the number of hardware acceleration devices included in the electronic device; the first time is the time required to read the first data from the original database directory and fill a first buffer, and the second time is the time required for a hardware acceleration device to complete compression of a full first buffer and for the central processor to write the corresponding backup data to the data disk corresponding to the backup directory.

[0026] In an embodiment of the present application, the number of buffers to be set can be determined based on the first time, the second time, and the number of hardware acceleration devices. In this way, the number of buffers can be ensured to be compatible with the number of threads and the processing capabilities of the hardware acceleration devices included in the electronic device, without excessively occupying the memory resources of the electronic device.

[0027] As a possible implementation, the method further includes: during the data backup process, dynamically adjusting the number of threads and / or the number of buffers according to the first time, the second time, and the number of hardware acceleration devices included in the electronic device.

[0028] In the embodiments of the present application, the first time and the second time can be variable. Therefore, the electronic device can dynamically adjust the number of buffers and the number of threads to improve the utilization efficiency of buffer and thread resources. Furthermore, dynamically adjusting the number of buffers and the number of threads can ensure that memory and processor resources are not excessively occupied, nor that the number of buffers and threads is insufficient, thereby preventing the hardware acceleration device from performing at its full potential.

[0029] As a possible implementation, the central processing unit includes the hardware acceleration device.

[0030] In an embodiment of the present application, the hardware acceleration device can be integrated into the central processing unit, so that the communication delay between the hardware acceleration device and the central processing unit can be reduced, thereby further improving the efficiency of database physical backup.

[0031] A second aspect discloses an electronic device, which includes a processor and a memory. The processor calls a computer program stored in the memory to implement the data backup method provided in the first aspect and any possible implementation of the first aspect.

[0032] The third aspect discloses a computer-readable storage medium having a computer program or computer instructions stored thereon. When the computer program or computer instructions are executed, the data backup method disclosed in the above aspects is implemented.

[0033] A fourth aspect discloses a chip, comprising a processor for executing a program stored in a memory. When the program is executed, the chip executes the data backup method disclosed in the above aspects.

[0034] As a possible implementation, the memory is located outside the chip.

[0035] A sixth aspect discloses a computer program product, which includes a computer program code. When the computer program code is run, the data backup method disclosed in the above aspects is executed.

[0036] It should be understood that the implementation and beneficial effects of the above-mentioned multiple aspects or any possible implementation methods of the present application can be referenced to each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] FIG1 is a schematic structural diagram of an electronic device disclosed in an embodiment of the present application;

[0038] FIG2 is a schematic diagram of a scenario of physical backup of a database disclosed in an embodiment of the present application;

[0039] FIG3 is a schematic diagram of the software structure of an electronic device disclosed in an embodiment of the present application;

[0040] FIG4 is a schematic diagram of a scenario in which a backup tool disclosed in an embodiment of the present application performs physical backup of a database;

[0041] FIG5 is a flow chart of a database physical backup method disclosed in an embodiment of the present application;

[0042] FIG6 is a flow chart of another database physical backup method disclosed in an embodiment of the present application;

[0043] FIG7 is a flow chart of another database physical backup method disclosed in an embodiment of the present application;

[0044] FIG8 is a flow chart of another database physical backup method disclosed in an embodiment of the present application;

[0045] FIG9 is a flow chart of another database physical backup method disclosed in an embodiment of the present application;

[0046] FIG10 is a flow chart of another database physical backup method disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0047] The embodiments of the present application disclose a database physical backup method, electronic device, and computer-readable storage medium, which can improve the efficiency of database physical backup and reduce the hard disk space occupied. The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0048] In order to better understand the embodiments of the present application, the relevant terms and related technologies of the embodiments of the present application are described below.

[0049] A database cluster is generally a database system consisting of multiple machines. One or more databases can be created on a database cluster. A machine in a database cluster is called a node.

[0050] Database clusters may include centralized database clusters, distributed database clusters, and the like. Among them, a centralized database cluster may include a host (master node) and multiple backup machines (slave nodes), and the data stored on the master and backup machines may be the same. A distributed database cluster may also include master nodes and slave nodes, each node may store a certain shard of data, and the data shards stored by multiple nodes may be spliced ​​together into a complete set of data. The master node in the database cluster may manage and monitor each slave node, or the database cluster may include a separate management node for the master node or slave node to manage and monitor each slave node. For example, the master node may issue data operation instructions, such as data backup instructions, to each slave node, instructing the slave node to perform data backup.

[0051] Hardware acceleration technology is a technology that uses hardware devices to speed up processing, such as compression, decompression, decryption, encryption, random number generation, digital signatures, video encoding and decoding. Furthermore, for hardware acceleration, dedicated hardware can be designed for specific processing. For example, for compression tasks, dedicated hardware can be designed to handle compression tasks to improve data compression efficiency. In the embodiments of this application, these dedicated hardware for specific processing can be referred to as hardware acceleration devices.

[0052] In practical scenarios, hardware accelerators can be used to assist the central processing unit (CPU) in its work, improving overall processing efficiency. For example, computationally intensive tasks (those requiring large amounts of computation) can be assigned to hardware accelerators to reduce CPU pressure and increase overall processing speed. Furthermore, because hardware accelerators are specialized hardware designed for specific processing, they consume less power than CPUs.

[0053] Among the related technologies, hardware acceleration technology can include QAT (quick assist technology) under the x86 architecture and KAE (Kunpeng accelerator engine) under the ARM (advanced RISC machine) architecture.

[0054] With the rapid development of network and communication technologies, massive amounts of data are impacting various industries at an unprecedented rate of growth. To effectively manage and maintain this data, users typically use databases for data storage. Furthermore, considering the need for data disaster recovery, it is often necessary to perform periodic physical backups of database data files. This allows for the recovery of data files on a standby server using the backup sets generated from the previous physical backups, ensuring business continuity in the event of a disaster (such as a server crash or other failure that results in data loss).

[0055] Among them, a physical backup of a database refers to copying one or more copies of the data files in the original database directory and storing them in other directories. These directories can be called backup directories. A backup set refers to a collection of database backup files, that is, one or more backup files stored in a backup directory. Generally, when performing a physical backup of a database, it is generally necessary to compress the database data files to reduce the hard disk space occupied by the backup set. In other words, each backup file in the backup directory can be a compressed file, and the data files in the original database directory can correspond one-to-one with the backup files in the backup directory. It should be understood that the original database directory can be the directory of the database to be backed up.

[0056] In the related art, the physical backup of a database may include four steps: reading data, verifying, compressing, and writing to disk. Among them, the database usually uses fixed-size data pages (pages) to store data, such as each data page can be 8 kilobytes (KB) in size. Based on this, the backup tool (backup software) can verify and compress each data page in turn, and write the compressed backup page (backup page) into the backup set directory. Specifically, the electronic device can read 8KB data pages in turn from the data file of the database. Afterwards, the electronic device can verify the read 8KB data pages in turn and calculate their checksums. Thereafter, the electronic device can use a compression algorithm implemented by software, such as lz4, zlib, zstd and other software compression algorithms, to compress the 8KB data pages after verification in turn. Finally, the electronic device can write the compressed data pages to the disk in turn and store them in the corresponding backup directory to generate a backup set.

[0057] In the above process, each data page must be verified and compressed page by page. Both verification and compression are computationally intensive tasks, requiring significant CPU resources. Each of these processes can potentially strain the CPU. Therefore, when CPU resources are limited, verification and compression are typically performed serially. Furthermore, compression is a time-consuming process during physical database backups, often accounting for 50% or more of the total physical backup time.

[0058] To improve the efficiency of database physical backups and reduce the overall time consumption, embodiments of the present application employ hardware acceleration technology during database physical backups. Specifically, data page compression can be performed by a hardware acceleration device. Furthermore, one or more buffers can be provided, into which data pages to be compressed can be initially stored. When the buffers are full, the hardware acceleration device can compress data pages in batches, buffer by buffer, thereby ensuring that the performance of the hardware acceleration device is fully utilized.

[0059] In order to better understand the embodiments of the present application, the system architecture of the embodiments of the present application is first described below.

[0060] Please refer to Figure 1, which is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present application. The electronic device 100 may be a mobile phone terminal, a tablet computer, a laptop computer, a desktop computer, a server, etc., and is not limited to this embodiment of the present application. The electronic device 100 may include a central processing unit 101, a hardware acceleration device 102, a memory 103, and a hard disk 104. The central processing unit 101, the hardware acceleration device 102, the memory 103, and the hard disk 104 may be interconnected or connected to each other via a bus 105.

[0061] In an embodiment of the present application, hard disk 104 can be used to store database data files. CPU 101 can be used to read data files in the database from the hard disk and perform operations such as verification. Memory 103 can be used to provide one or more buffers to temporarily store verified data pages. Hardware acceleration device 102 can compress batches of data pages in buffer units to obtain compressed backup data packets. Furthermore, the compressed backup data packets can be stored in hard disk 104.

[0062] In the embodiment of the present application, the hardware acceleration device 102 may be dedicated hardware with a data compression function to assist the central processing unit 101 in improving the efficiency of data compression. For example, the hardware acceleration device 102 may be a QAT accelerator card, a KAE accelerator card, or the like.

[0063] Illustratively, the hard disk 104 may be a hard disk drive (HDD), or a solid state drive (SSD).

[0064] It should be noted that Figure 1 only illustrates one central processing unit, one hardware acceleration device, one memory, and one hard disk. However, in actual situations, the electronic device may include two, three, four, or more central processing units, hardware acceleration devices, memories, and hard disks, and the embodiments of the present application are not limited to this.

[0065] In one possible implementation, the central processing unit 101 and the hardware acceleration device 102 can be independently configured or integrated together, such as integrating the hardware acceleration device 102 into the central processing unit 101. It should be noted that the electronic device 100 can be a node in a centralized database cluster, a node in a distributed database cluster, or other devices that include a database. For centralized database clusters and distributed database clusters, each node (including master nodes and slave nodes) can automatically back up data files in the database, or the master node or management node can uniformly issue a backup command, and each node, after receiving the backup command, can back up the data files in the database.

[0066] It should be noted that the system architecture shown in Figure 1 is merely an example and does not constitute a limitation. In practical applications, the electronic device 100 may also include more or fewer components, or different component configurations, etc., which are not limited here.

[0067] The physical backup process of the present application is exemplarily described below with reference to FIG2 .

[0068] Please refer to Figure 2, which is a schematic diagram of a scenario of physical backup of a database disclosed in an embodiment of the present application. In Figure 2, for the sake of convenience of explanation, it is assumed that the storage space corresponding to the original database directory of the database is the primary data disk, and the storage space corresponding to the backup directory is the backup (copy) data disk. In this case, when performing a physical backup of the database, it is necessary to read out the data files under the original database directory stored in the primary data disk, and store them in the corresponding backup directory after compression. The backup directory can include a corresponding number of backup files for the number of data files included in the original database directory, that is, the data files under the original database directory can correspond one-to-one to the backup files under the backup directory. Moreover, the organization method of the backup files under the backup directory can be the same as the organization method of the data files under the original database directory. Among them, the organization method here may include the adopted data structure, the relationship between the data, etc.

[0069] Specifically, the CPU can read the data pages in the data file under the original database directory from the main data disk in sequence, and can verify the read data pages. When the verification is completed, the CPU can store the verified data pages in an idle buffer. For example, buffer A is currently in an idle state, and the CPU can store the verified data pages in buffer A. When buffer A is full, the CPU can mark buffer A as busy. For example, the CPU can set a status label for the buffer and set the status label to busy. In addition, the CPU can notify the hardware acceleration device to compress the data pages in buffer A, and a compressed backup data packet can be obtained, and the compressed backup data packet can be stored in the storage space corresponding to the backup directory in the backup data disk. Afterwards, the CPU can change the status label of buffer A to an idle state so that the data pages to be backed up can be rewritten.

[0070] That is, the busy state indicates that the buffer is full of data, while the free state indicates that no data is stored in the buffer or that the buffer is not full of data.

[0071] In the above processing flow, when buffer A is full, while the hardware acceleration device compresses the data pages in buffer A, the CPU can continue to read the data pages in the data file under the original database directory from the main data disk, and store the read data pages in buffer B. When buffer B is full, the hardware acceleration device is notified to compress the data pages in buffer B. In other words, buffer A and buffer B can be used to alternately store verified data pages. When buffer A is full, while the hardware acceleration device compresses the data pages in buffer A, the CPU can continue to store verified data pages through buffer B. Afterwards, when buffer B is full and buffer A is free again, data can be stored through buffer A again. In this way, the verification and compression of data pages can be performed in parallel, thereby improving the overall efficiency of database physical backup.

[0072] It should be understood that by continuously reading data pages and storing them in buffer A and buffer B, and alternately compressing the data pages in buffer A and buffer B, compressed backup of all data files can be completed to generate a complete backup set.

[0073] It should be understood that while FIG2 illustrates the process flow for physical database backup using two buffers, the present embodiment does not limit the number of buffers. For example, one buffer, three, four, or more buffers may be provided. It should also be understood that while the above description uses the storage space corresponding to the original database directory as the primary data disk and the storage space corresponding to the backup directory as the backup data disk, this does not constitute a limitation. In actual practice, the storage space corresponding to the original database directory and the backup directory may be on the same hard disk, such as both being the primary data disk. In other words, the data files in the original database directory and the backup files in the backup directory may be stored on the same hard disk.

[0074] It should be noted that the hardware acceleration device implements a very efficient compression algorithm in hardware (including various processing circuits), and its compression performance is far superior to compression algorithms implemented in software (such as lz4, zlib, zstd, etc.). For example, the hardware acceleration device has a faster compression speed and a smaller compression volume. Therefore, in the above-mentioned processing flow, compressing data pages through the hardware acceleration device can shorten the time required for compression. At the same time, considering that compressing data pages through the hardware acceleration device will bring about communication overhead between hardware, such as communication overhead between the CPU and the hardware acceleration device. Therefore, if the hardware acceleration device is notified to perform compression processing every time a data page is verified, it may cause the hardware communication overhead to be too large, and the compression of a single data page cannot effectively utilize the performance of the hardware acceleration device, thereby affecting the overall efficiency of the database physical backup. Based on this, one or more buffers can be set in the embodiment of the present application. When the buffer is full, the hardware acceleration device is notified to perform compression processing on all data pages in the buffer. In this way, the communication overhead between hardware can be reduced and the computing power of the hardware acceleration device can be fully utilized.

[0075] The following is an exemplary description of the software architecture of the embodiment of the present application.

[0076] Please refer to Figure 3, which is a schematic diagram of the software structure of an electronic device disclosed in an embodiment of the present application. The electronic device 100 may include a database 106, and the database 106 may include a backup tool 1061. In other words, the backup tool 1061 may be a subroutine module in the database 106.

[0077] Please refer to Figure 4, which is a schematic diagram of a scenario in which a backup tool disclosed in an embodiment of the present application performs physical backup of a database. As shown in Figure 4, in the embodiment of the present application, the backup tool 1061 can read the data files in the database from the main data disk, and perform operations such as verification, and can store the verified data pages into the buffer in the memory, such as buffer A, buffer B, etc. When the buffer is full, the backup tool 1061 can call the data compression API provided by the hardware acceleration device, and the data compression API will correspondingly call the driver of the hardware acceleration device, and the driver of the hardware acceleration device will drive the hardware acceleration device to compress the data pages in the buffer, and a compressed backup data packet can be obtained. In addition, the backup tool 1061 can store the compressed backup data packet into the backup file under the backup directory to generate a complete backup set.

[0078] For a more detailed description of the backup tool 1061, please refer to the relevant description in the following method embodiment, which will not be repeated here.

[0079] In a possible implementation, the backup tool 1061 may not be a submodule of the database 106 , but may be an independent module.

[0080] It should be noted that the software structure shown in Figure 3 is only an example and does not constitute a limitation. In other embodiments of the present application, the software structure shown in Figure 3 may include more or fewer software modules than shown in the figure.

[0081] Based on the above system architecture, please refer to Figure 5, which is a flow chart of a database physical backup method disclosed in an embodiment of the present application. As shown in Figure 5, it is a processing flow for database physical backup under a single buffer setting. The processing method can be executed by the central processing unit (CPU), specifically, the CPU can call a program in the backup tool to execute. The processing flow may include but is not limited to the following steps:

[0082] 501. The CPU opens the first data file in the original database directory.

[0083] The first data file may be any unbacked-up data file stored in the primary data disk and can be found through the original database directory.

[0084] When performing a physical backup of the database, the CPU can back up the data files in the original database directory in sequence, generate corresponding backup files, and store them in the backup data disk corresponding to the backup directory. For example, the CPU can first open any unbacked up data file in the original database directory to facilitate reading the data pages therein.

[0085] 502. When the first buffer is in an idle state, the CPU reads data pages from the first data file in sequence, and stores the read data pages in the first buffer in sequence.

[0086] To fully utilize the performance of the hardware acceleration device, the hardware acceleration device of the electronic device can compress data pages in batches using buffers as units. Therefore, in the case of a single buffer, the CPU can first determine whether the first buffer is idle. If the first buffer is not idle, that is, busy, the CPU can wait until the first buffer is idle. If the first buffer is idle, the CPU can sequentially read data pages from the first data file and store the read data pages into the first buffer until the first buffer is full. It should be understood that data pages in a data file can be sequentially ordered, and each data page can include an identifier, such as a logical address or a data page number. Therefore, in one possible implementation, sequentially reading data pages from the first data file can be understood as sequentially reading data pages in the order of the data pages, such as reading consecutive data pages in the order of their logical addresses. Initially, the first buffer is in an idle state by default. The size of the first buffer can be N times the data page size, where N is an integer greater than or equal to 2. For example, N can be 8, 16, etc. For example, when the data page size is 8 KB, the size of the first buffer can be 64 KB, 128 KB, etc. It should be understood that the first buffer area may be a storage area opened in the memory of the electronic device, and may be used by the electronic device to temporarily store data pages that need to be compressed during a database physical backup process.

[0087] It should be understood that when the remaining data pages in the first data file are read for the last time, the number of remaining unread data pages in the first data file may be small and insufficient to fill the first buffer. In this case, all the remaining unread data pages in the first data file can be stored in the first buffer, and then the first buffer can be considered full.

[0088] In one possible implementation, the CPU can verify the read data pages before sequentially storing them in the first buffer. Verification can include two scenarios: one is calculating a checksum for each data page. In this case, after the CPU calculates the checksum for each data page, it can store the data page and the corresponding checksum together in the first buffer (e.g., appending the checksum to the end of the corresponding unbacked-up data page), so that the accuracy of the data can be verified when restoring data based on the backup set. Another scenario is calculating a checksum for each data page and comparing it with the previously calculated checksum to determine whether the currently read data page is accurate. In this case, after the CPU calculates the checksum for each data page, it can compare the currently calculated checksum with the previously calculated checksum for the data page (e.g., the checksum calculated when the data page was previously stored on the primary data disk). If they are the same, it indicates that the currently read unbacked-up data page is correct and can be stored in the first buffer. If they are different, it indicates that the currently read unbacked-up data page is incorrect and can be skipped or data recovery can be performed.

[0089] It should be understood that the check code is usually derived from the original data through some kind of operation to verify the correctness of the original data. Common check codes may include parity check code, Hamming check code, Cyclic Redundancy Check (CRC) code, etc.

[0090] 503. When the first buffer is full, the CPU changes the state of the first buffer to a busy state, and compresses multiple data pages in the first buffer through a hardware acceleration device to obtain corresponding backup data packets.

[0091] As the CPU continues to store data pages in the first buffer, the first buffer will become full. At this time, to prevent the CPU from continuing to write data to the first buffer, the CPU can change the state of the first buffer to a busy state. Furthermore, the CPU can notify the hardware acceleration device to compress the data pages in the first buffer. After the hardware acceleration device compresses the data pages in the first buffer, a corresponding backup data packet can be obtained. The backup data packet includes the corresponding backup data packet obtained by the hardware acceleration device compressing the data pages in the first buffer. The backup data packet corresponding to the data page in the first buffer can also be understood as compressed data corresponding to the data page in the first buffer.

[0092] The CPU compressing the multiple data pages in the first buffer using the hardware acceleration device may specifically include: the CPU may call a compression API (application programming interface) provided by the hardware acceleration device, the compression API may correspondingly call a driver of the hardware acceleration device, and the driver of the hardware acceleration device may drive the hardware acceleration device to compress the multiple data pages in the first buffer. When calling the compression API provided by the hardware acceleration device, the CPU may provide corresponding parameters, such as the address of the first buffer, so that the hardware acceleration device can compress the multiple data pages in the first buffer.

[0093] 504. The CPU writes the corresponding backup data packet into the backup data disk corresponding to the backup directory, and changes the state of the first buffer to an idle state.

[0094] After the hardware acceleration device has finished compressing the multiple data pages in the first buffer, it can notify the CPU that compression of the first buffer is complete. The CPU can then write the corresponding backup data packets obtained by compressing the multiple data pages in the first buffer to the backup data disk corresponding to the backup directory. Furthermore, the CPU can change the state of the first buffer to an idle state so that the data pages to be backed up, i.e., the remaining unread data pages, can be rewritten. It should be noted that after the hardware acceleration device has finished compressing the data in the first buffer, the compressed backup data packets can be stored in the first buffer or in another idle buffer. The time it takes for the first buffer to change to an idle state can be different for these two different scenarios. If the compressed backup data packets are stored in the first buffer, it is necessary to wait for the CPU to write the backup data packets to the backup data disk corresponding to the backup directory. After the backup data packets are written to the backup disk corresponding to the backup directory, the state of the first buffer can be changed to an idle state. If the compressed backup data packets are stored in another idle buffer, the state of the first buffer can be changed to an idle state after the hardware acceleration device has finished compressing the data pages in the first buffer, without having to wait for the backup data packets to be written to the backup data disk corresponding to the backup directory.

[0095] It is understandable that since the data files in the original database directory and the backup files in the backup directory are one-to-one corresponding, when the CPU writes the corresponding backup data packet into the backup directory, it actually writes it into the backup file corresponding to the first data file in the backup directory.

[0096] 505. The CPU determines whether the first data file has been backed up. If not, the CPU executes step 502; if the first data file has been backed up, the CPU executes step 506.

[0097] After the CPU writes the backup data packets corresponding to the multiple data pages in the first data file to the backup data disk corresponding to the backup directory, it can determine whether the first data file has been backed up, that is, whether the first data file still includes unbacked up data pages or unread data pages. If the first data file has not been backed up (the first data file still includes unbacked up data pages), the CPU can continue to read the unbacked up data pages in the first data file and execute step 502. If the first data file has been backed up (the first data file does not include unbacked up data pages), the CPU can continue to determine whether the original database directory still includes unbacked up data files and execute step 506.

[0098] 506. The CPU determines whether the original database directory contains any unbacked-up data files. If so, step 501 may be executed; if not, step 507 may be executed. When the first data file is backed up, the CPU determines whether the original database directory contains any unbacked-up data files. If so, the CPU may continue to open any unbacked-up data file in the original database directory and execute step 501. If the original database directory contains no unbacked-up data files, that is, all data files in the original database directory have been backed up, the CPU may execute step 507.

[0099] It should be noted that, due to different business needs, there may be multiple backups for the same first data file. For example, the first data file is first backed up to the first backup data disk, and then the first data file is backed up to the second backup data disk. Therefore, when judging whether a first data file is an unbacked-up data file, or judging whether a data page is an unbacked-up data page, there may be different judgment results due to the above reasons. Based on this, in the embodiment of the present application, for the above steps 502-507, the CPU judges whether the first data file includes unbacked-up data pages. The unbacked-up data pages refer to data pages that have not been backed up during this backup process, such as the process of steps 501-507 executed this time, and the CPU judges whether the original database directory still includes unbacked-up data files, which refers to data files that have not been backed up during this backup process, such as the process of steps 501-507 executed this time.

[0100] It should be noted that the backup data disk and the primary data disk can be the same physical hard disk or different physical hard disks.

[0101] 507. The CPU completes the physical backup of the database and releases related resources.

[0102] When all data files in the original database directory are backed up, the backup directory may include complete backup files, and the CPU may end the physical backup of the database and release related resources, such as memory resources such as the first buffer.

[0103] It should be noted that the order of steps 501 through 507 is not unique. Some steps can be executed in parallel, such as step 504 and step 505. Furthermore, the execution order of the steps can be adjusted based on actual circumstances. For example, in one possible implementation, step 506 can be executed first. When it is determined that the original database directory does not contain any unbacked-up data files, the CPU can execute step 507. When it is determined that the original database directory does contain any unbacked-up data files, the CPU can execute step 501 and subsequent steps 502 through 505. During step 505, if it is determined that the first data file has been backed up, step 506 can be executed again to continue determining whether the original database directory still contains any unbacked-up data files. For another example, steps 501 through 507 can be split into two independent execution flows: one responsible for writing unbacked-up data pages to the first buffer, and the other responsible for compressing data pages in the first buffer. These two processing flows can be executed in parallel and can be linked by the state of the first buffer. As shown in Figure 6, it can be a processing flow for writing data pages to the first buffer. When writing data pages to the first buffer, the CPU can detect whether the first buffer is in an idle state. When the first buffer is in an idle state, the CPU can continuously write unbacked-up data pages to the first buffer. As shown in Figure 7, it can be a processing flow for compressing data pages in the first buffer through a hardware acceleration device. When compressing data pages in the first buffer, the CPU can detect whether the first buffer is in a busy state. When the first buffer is in a busy state, that is, when the first buffer is full, the CPU can compress the data pages in the first buffer through the hardware acceleration device and write the compressed backup data packets to the backup data disk corresponding to the backup directory. The relevant steps in Figures 6 and 7 can refer to the relevant descriptions in the above steps 501 to 507, and will not be repeated here.

[0104] In the above processing flow, when the CPU performs physical backup of the database, it can compress batch data pages in units of buffers through the hardware acceleration device, which can greatly improve the efficiency of data compression and thus increase the speed of physical backup of the database.

[0105] Figure 5 illustrates the database physical backup process under a single buffer. However, in practice, multiple buffers can also be used during database physical backup. This allows data reading and compression to proceed in parallel, or data reading, verification, and compression to proceed in parallel, thereby further improving the speed of database physical backup. The following describes an exemplary database physical backup process under multiple buffer settings, with reference to Figures 8 and 9. Figure 8 illustrates the process of writing unbacked-up data pages to an idle buffer under multiple buffer settings, while Figure 9 illustrates the process of compressing data pages in a busy buffer using a hardware acceleration device under multiple buffer settings.

[0106] The following first introduces the processing flow shown in FIG8 . As shown in FIG8 , the processing flow may be executed by a central processing unit (CPU), specifically, the CPU may call a program in the backup tool to execute the processing flow. The processing flow may include but is not limited to the following steps:

[0107] 801. The CPU opens the first data file in the original database directory.

[0108] The first data file may be any unbacked-up data file that is stored in the primary data disk and can be found through the original database directory.

[0109] Step 801 is similar to step 501 , and reference may be made to the relevant description in the above step 501 .

[0110] 802. When there is an idle buffer in the multiple buffers of the electronic device, the CPU reads data pages from the first data file in sequence, and stores the read data pages in the second buffer in sequence.

[0111] The second buffer may be any buffer in an idle state among the multiple buffers.

[0112] In the case of multiple buffers, the CPU may first determine whether any of the multiple buffers are in an idle state. If no buffer is in an idle state among the multiple buffers, the CPU may wait until the multiple buffers are idle. If any of the multiple buffers are in an idle state, the CPU may sequentially read data pages from the first data file and sequentially store the read data pages in the second buffer until the second buffer is full. In the initial state, the multiple buffers are in an idle state by default. It should be understood that the multiple buffers may be buffers allocated from memory space for storing data pages to be backed up.

[0113] It should be understood that when the remaining data pages in the first data file are read for the last time, the number of remaining unread data pages in the first data file may be small and insufficient to fill the second buffer. In this case, all the remaining unread data pages in the first data file can be stored in the second buffer, and the second buffer can be considered to be full.

[0114] In a possible implementation, the CPU may verify the read data pages that have not been backed up before storing them in the second buffer. For a description of data page verification, please refer to the relevant description in step 501 and will not be repeated here.

[0115] 803. When the second buffer is full, the CPU changes the state of the second buffer to a busy state.

[0116] As the CPU continues to store data pages in the second buffer, the second buffer will be full. At this time, to prevent the CPU from continuing to write data to the second buffer, the CPU can change the state of the second buffer to a busy state. In addition, the CPU can notify the hardware acceleration device to compress the data pages in the second buffer.

[0117] 804. The CPU determines whether the first data file has been backed up. If not, the CPU executes step 802; if the first data file has been backed up, the CPU executes step 805.

[0118] After the CPU has filled the second buffer, it can determine whether the first data file has been backed up, that is, whether the first data file still includes unbacked-up data pages. If the first data file has not been backed up, the CPU can continue to read the unbacked-up data pages in the first data file and execute step 802. If the first data file has been backed up, the CPU can continue to determine whether the original database directory still includes unbacked-up data files and execute step 805.

[0119] 805. The CPU determines whether the original database directory includes any unbacked-up data files. If the original database directory includes any unbacked-up data files, step 801 may be executed. If the original database directory does not include any unbacked-up data files, step 806 may be executed.

[0120] When the first data file is backed up, the CPU may determine whether the original database directory contains any unbacked-up data files. If the original database directory contains any unbacked-up data files, the CPU may continue to open any unbacked-up data file in the original database directory and execute step 801. If the original database directory contains no unbacked-up data files, that is, all data files in the original database directory have been backed up, the CPU may execute step 806.

[0121] 806. The CPU completes the physical backup of the database and releases related resources.

[0122] When all data files in the original database directory are backed up, the backup directory may include complete backup files, and the CPU may end the physical backup of the database and release related resources, such as memory resources such as the second buffer.

[0123] The following describes the processing flow shown in FIG9 . As shown in FIG9 , the processing flow may be executed by a central processing unit (CPU), specifically, the CPU may call a program in the backup tool to execute the processing flow. The processing flow may include but is not limited to the following steps:

[0124] 901. When a buffer in a busy state exists among multiple buffers of the electronic device, the CPU compresses multiple data pages in a third buffer through a hardware acceleration device to obtain a corresponding backup data packet.

[0125] The third buffer may be any buffer in a busy state among the multiple buffers.

[0126] As shown in FIG8 , when all data files of the database have not been backed up, the CPU can continue to write data pages to be backed up into free buffers in the multiple buffers. Furthermore, when a buffer is full, the CPU can notify the hardware acceleration device to compress the data pages in the buffer. Therefore, when a buffer in the multiple buffers of the CPU is busy, the CPU can compress the multiple data pages in the third buffer through the hardware acceleration device to obtain the corresponding backup data packets. For example, assuming that there are three buffers, namely buffer a, buffer b, and buffer c, where buffer a and buffer b are busy, the CPU can compress the multiple data pages in buffer a and then compress the multiple data pages in buffer b through the hardware acceleration device.

[0127] It should be noted that, in one possible implementation, when there are multiple busy buffers, the hardware acceleration device can compress the data pages in these multiple busy buffers in parallel, thereby improving the overall speed of database physical backup. Alternatively, if the CPU includes multiple hardware acceleration devices, in this case, when there are multiple busy buffers, the CPU can use the multiple hardware acceleration devices to compress the data pages in different buffers, thereby improving the overall speed of database physical backup.

[0128] 902. The CPU writes the corresponding backup data packet into the backup data disk corresponding to the backup directory, and changes the state of the third buffer to an idle state.

[0129] After the hardware acceleration device has completed compressing the multiple data pages in the third buffer, it can notify the CPU that the compression of the third buffer is complete. The CPU can then write the corresponding backup data packets obtained by compressing the multiple data pages in the third buffer to the backup data disk corresponding to the backup directory. Furthermore, the CPU can change the state of the third buffer to an idle state so that the data pages to be backed up can be rewritten.

[0130] During the database physical backup process shown in Figures 8 and 9 above, data reading, verification, and compression can be performed in parallel. For example, assume that buffer a, buffer b, and buffer c are included, and that they are all initially in an idle state. During the database physical backup, the CPU can read the unbacked-up data pages from the original database directory and verify them, then store the verified data pages in buffer a. When buffer a is full, the state of buffer a can be changed to "busy," and the hardware acceleration device can be notified to compress the data pages in buffer a. While the hardware acceleration device is compressing the data pages in buffer a, the CPU can continue to read the unbacked-up data pages from the original database directory and verify them, then store the verified data pages in buffer b. When buffer b is full, the state of buffer b can be changed to "busy," and the hardware acceleration device can be notified to compress the data pages in buffer b. In this way, after the hardware acceleration device has finished compressing the data pages in buffer a, it can continue to compress the data in buffer b, eliminating the need to wait, thereby improving the overall efficiency of the database physical backup.

[0131] It is understandable that the time required to read unbacked-up data pages from the original database directory and fill an idle buffer (hereinafter referred to as T1) may be different from the time required for the hardware acceleration device to compress a busy buffer and for the CPU to write the corresponding backup data packets to the data disk corresponding to the backup directory (hereinafter referred to as T2). Therefore, in order to fully utilize the processing power of the hardware acceleration device included in the electronic device, in some cases, the electronic device can start multiple threads to read unbacked-up data pages from the original database directory in parallel (for example, multiple threads can read unbacked-up data pages from different data files in the original database directory respectively) and store the read unbacked-up data pages in the idle buffer.

[0132] In a possible implementation, the number of enabled threads may be determined according to the first time, the second time, and the number of hardware acceleration devices (hereinafter referred to as M).

[0133] For example, the number of threads opened can be Indicates rounding up. This allows the number of full buffers to be greater than the number of compressed buffers at the same time, or the number of full buffers to be equal to the number of compressed buffers (that is, buffer storage and buffer compression are balanced), thereby maximizing the use of the electronic device's hardware acceleration devices and further improving the speed of database physical backup.

[0134] It should be understood that in order to achieve the above-mentioned maximum compression processing effect using the hardware acceleration device of the electronic device, the number of buffers is also required to support it. The number of buffers can be determined based on the number of threads and the number of hardware acceleration devices. For example, the number of buffers can be the number of threads + the number of hardware acceleration devices, that is, This ensures that there are enough buffers, so that multiple threads have corresponding free buffers to write unbacked-up data pages. Furthermore, it ensures that the hardware acceleration device included in the electronic device has busy buffers for compression processing. It should be noted that, with respect to the number of buffers set in this case, each buffer can store the corresponding backup data packet obtained by the hardware acceleration device compressing the data in the buffer. In other words, the data page to be backed up in a buffer and the backup data packet corresponding to the data page to be backed up can be stored in the same buffer.

[0135] For example, let's assume T1 is 4 seconds. This means that it takes 4 seconds for a thread to read unbacked data pages from the original database directory and fill an idle buffer, including time for data page verification. T2 is 2 seconds, meaning it takes 2 seconds for a hardware acceleration device to compress a busy buffer and for the CPU to write the corresponding backup data to the data disk corresponding to the backup directory. There are two hardware acceleration devices: hardware acceleration device 1 and hardware acceleration device 2. At this point, the number of threads can be calculated as 4 / 2*2, or 4 threads: threads 1 through 4. The number of buffers can be 4+2, or 6 buffers: buffer 1 through 6. Initially, all six buffers can be empty. Threads 1 through 4 can then write unbacked data pages to buffers 1 through 4 in parallel. In 4 seconds, buffers 1 through 4 can be filled. Afterwards, between 4 and 6 seconds, hardware acceleration device 1 and hardware acceleration device 2 can compress buffer 1 and buffer 2, respectively. The CPU can write the corresponding backup data packets to the data disk corresponding to the backup directory. Meanwhile, threads 1 and 2 can write the unbacked-up data pages to buffer 5 and buffer 6, respectively. At 6 seconds, hardware acceleration device 1 and hardware acceleration device 2 can complete compressing the data pages in buffer 1 and buffer 2, respectively. Between 6 and 8 seconds, hardware acceleration device 1 and hardware acceleration device 2 can compress buffer 3 and buffer 4, respectively. The CPU can write the corresponding backup data packets to the data disk corresponding to the backup directory. Meanwhile, threads 1 and 2 can continue writing the unbacked-up data pages to buffer 5 and buffer 6, respectively. Threads 3 and 4 can write the unbacked-up data pages to buffer 1 and buffer 2, respectively. At 8 seconds, hardware acceleration device 1 and hardware acceleration device 2 can complete compressing the data pages in buffer 3 and buffer 4, respectively. The CPU can write the corresponding backup data packets to the data disk corresponding to the backup directory. Meanwhile, threads 1 and 2 can fill buffer 5 and buffer 6, respectively. Between 8 and 10 seconds, hardware acceleration device 1 and hardware acceleration device 2 can compress buffer 5 and buffer 6, respectively. The CPU can write the corresponding backup data packets to the data disk corresponding to the backup directory. Meanwhile, threads 3 and 4 can continue writing unbacked-up data pages to buffer 1 and buffer 2, respectively. Threads 1 and 2 can also write unbacked-up data pages to buffer 3 and buffer 4, respectively. At 10 seconds, hardware acceleration device 1 and hardware acceleration device 2 can complete compressing the data pages in buffer 5 and buffer 6, respectively. The CPU can write the corresponding backup data packets to the data disk corresponding to the backup directory, and threads 3 and 4 can fill buffer 1 and buffer 2, respectively.As can be seen, during the database physical backup process, threads 1-4 can concurrently write data pages to four idle buffers, while hardware acceleration device 1 and hardware acceleration device 2 can concurrently compress two busy buffers. Furthermore, once hardware acceleration device 1 or 2 has finished compressing a busy buffer and the CPU has written the corresponding backup data packet to the data disk corresponding to the backup directory, there will always be a busy buffer available for further compression processing. This fully utilizes the processing resources of hardware acceleration device 1 and hardware acceleration device 2.

[0136] It should be understood that the above-mentioned T1 is also related to the size of the buffer, the load of the CPU, etc., and the above-mentioned T2 is also related to the size of the buffer, the load of the hardware acceleration device, the processing power of the hardware acceleration device itself, etc. For example, when the size of the buffer and the processing power of the hardware acceleration device itself are determined, if the more CPU resources are occupied by tasks other than database physical backup, the greater the CPU load may be, which will lead to a reduction in the CPU resources used for database physical backup, and in turn, the above-mentioned T1 will increase accordingly. Similarly, if the hardware acceleration device also needs to process other tasks, T2 will also change accordingly. The more processing resources of the hardware acceleration device are occupied by other tasks, the greater the load on the hardware acceleration device may be, and accordingly, T2 may increase.

[0137] Since T1 and T2 may change during the database physical backup process, the electronic device can dynamically adjust the number of threads and the number of buffers. For example, during the database physical backup process, the electronic device can dynamically monitor or predict the size of T1 and T2, and then dynamically adjust the number of threads and buffers to be opened when T1 or T2 changes. For example, assuming that the number of hardware acceleration devices is 2, the current T1 is 4s, and T2 is 2s. At this time, the electronic device can open 4 threads for buffer storage and can set 6 buffers. Later, if the CPU load is high, T1 can become 2s, and T2 remains unchanged. At this time, the electronic device can determine that it is more appropriate to open 2 threads and 4 buffers. Therefore, the electronic device can close 2 threads and release the resources of 2 buffers. In this way, while ensuring the efficiency of database physical backup, the occupation of CPU resources and memory resources can be reduced.

[0138] As can be seen, during the database physical backup process, the electronic device dynamically adjusts the number of threads and buffers to maintain a balance between buffer storage and buffer compression. That is, in the same period of time, the number of full buffers and compressed buffers is almost equal. This fully utilizes the performance of the hardware acceleration device, and the number of buffers and threads is more appropriate, avoiding excessive CPU and memory resource usage.

[0139] Based on the above system architecture, please refer to Figure 10, which is a flow chart of another database physical backup method disclosed in an embodiment of the present application. The backup method can be executed by a central processing unit (CPU) of an electronic device. The electronic device may include a CPU, a memory, and a hardware acceleration device. The memory may include a first buffer. As shown in Figure 10, the processing flow may include, but is not limited to, the following steps:

[0140] 1001. The CPU reads first data from a first data file and stores the first data into a first buffer.

[0141] The first data file is stored in a data disk corresponding to the original database directory, such as the master data disk. The first data may be an unbacked-up data page in the first data file. Exemplarily, the size of the first buffer may be N times the size of the data page, where N is an integer greater than or equal to 2.

[0142] Exemplarily, the CPU may first open the first data file, and then, if the first buffer does not store or is not full of the first data, in this case, the first buffer may continue to store data, and at this time, the CPU may read the first data in the first data file and store the read first data in the first buffer. It should be understood that the fact that the first buffer does not store or is not full of the first data may be understood as the first buffer being in an idle state, and reference may be made to the relevant description in the embodiment shown in FIG5 above. It should also be noted that when the compression of the first data in the first buffer is completed and the corresponding compressed data is obtained, the corresponding compressed data may also be stored in the first buffer, and then the compressed data stored in the first buffer may be written to the data disk corresponding to the backup directory. Afterwards, when the compressed data stored in the first buffer is successfully written to the data disk corresponding to the backup directory, the first buffer may be regarded as an empty buffer, that is, a buffer in which the first data is not stored.

[0143] In a possible implementation, the CPU may verify the read first data before storing the read first data into the first buffer. Thereafter, if the first data verification succeeds, the CPU stores the first data page into the first buffer.

[0144] 1002. The CPU compresses the first data in the first buffer through a hardware acceleration device to generate backup data corresponding to the first data.

[0145] In a possible implementation, when the first buffer is fully loaded with the first data, the CPU compresses the first data in the first buffer through the hardware acceleration device, thereby ensuring the utilization rate of the buffer space.

[0146] In one possible implementation, there may be multiple first buffers. In this case, the CPU can read the remaining data from the first data file, that is, read the remaining unread data pages or data pages to be backed up in the first data file, and store the remaining read data in the second buffer. The second buffer can be any of the remaining buffers in the multiple first buffers that does not store or is not fully filled with the first data. When the hardware acceleration device completes compressing the first data in a first buffer, the data in the second buffer is compressed by the hardware acceleration device. That is to say, in the case of including multiple buffers, while the hardware acceleration device is compressing the data in a first buffer, the CPU can continue to read the remaining data from the first data file and store the remaining data in another first buffer, which can ensure that the CPU writes data to the buffer in parallel with the hardware acceleration device compressing the data, thereby improving data backup efficiency.

[0147] In one possible implementation, multiple threads can be used to read first data from multiple data files in the original database directory, and the first data from the different data files can be stored in multiple buffers that are not filled or not fully filled with the first data. When a third buffer is full, the data in the third buffer can be compressed by a hardware acceleration device. The third buffer can be any full buffer among the multiple first buffers.

[0148] It should be understood that the first data in the above-mentioned multiple data files may be different data.

[0149] In a possible implementation, when there are multiple full buffers in the multiple first buffers, the CPU may process and compress data in the multiple full buffers in parallel through multiple hardware acceleration devices.

[0150] For example, the number of enabled threads and buffers can be determined based on the first time, the second time, and the number of hardware acceleration devices included in the electronic device. The first time can be the time required to read the first data from the original database directory and fill a first buffer, and the second time can be the time required for a hardware acceleration device to compress a full first buffer and for the CPU to write the corresponding backup data to the data disk corresponding to the backup directory.

[0151] In a possible implementation, the hardware acceleration device of the electronic device is provided in the processor of the electronic device. That is, the hardware acceleration device of the electronic device and the processor of the electronic device may be integrated together.

[0152] It is understandable that during the data backup process, the first time and the second time may change. Therefore, during the data backup process, the CPU can dynamically adjust the number of threads and / or the number of buffers based on the first time, the second time, and the number of hardware acceleration devices included in the electronic device.

[0153] 1003. The CPU writes the corresponding backup data to the data disk corresponding to the backup directory.

[0154] For the above steps 1001 to 1003, reference may be made to the description of the relevant steps in FIG5 , FIG8 and FIG9 , which will not be repeated here.

[0155] It should be noted that the relevant information (ie, the same information or similar information) and related descriptions in the above different embodiments can refer to each other.

[0156] The execution subject in the above steps 501-507, 601-606, 701-702, 801-806, 901-902, and 1001-1003 may be not only the central processing unit (CPU) in the electronic device, but also other controllers or processing chips in the electronic device, such as CPLD, FPGA and other controllers.

[0157] It should be understood that the CPU is used as the execution subject of the interaction diagram in Figures 5, 6, 7, 8, 9, and 10 to illustrate the above processing flow, but this application does not limit the execution subject of the interaction diagram. For example, the CPU in Figures 5, 6, 7, 8, 9, and 10 can also be a chip, chip system, electronic device, etc. that supports the CPU to implement the method, or a logic module or software that can implement all or part of the CPU functions (such as the backup tool mentioned above).

[0158] The present application embodiment also discloses an electronic device, which includes a memory and a processor, the memory being used to store a computer program or computer instruction of the electronic device, and the processor being used to read the program or computer instruction stored in the memory and execute the method in the above method embodiment. The above memory may include but is not limited to random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or portable read-only memory (CD-ROM). The above processor may be a CPU, a complex programmable logic device, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. The processor may also be a combination that implements a computing function, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like.

[0159] An embodiment of the present application further discloses a computer-readable storage medium having instructions stored thereon, which, when executed, execute the method in the above method embodiment.

[0160] The embodiments of the present application further disclose a computer program product comprising instructions, which, when executed, perform the method in the above method embodiments.

[0161] Obviously, the embodiments described above are only some of the embodiments of this application, and not all of them. Reference to "embodiments" herein means that the specific features, structures, or characteristics described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it refer to independent or alternative embodiments that are mutually exclusive with other embodiments. It is understood, both explicitly and implicitly, that the embodiments described herein can be combined with other embodiments. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. In the specification, claims, and accompanying drawings of this application, the terms "first," "second," "third," and so on are used to distinguish between different objects, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a list of steps or elements may be included, or alternatively, steps or elements not listed may be included, or alternatively, other steps or elements inherent to the process, method, product, or device may be included. It can be understood that the equal sign of the above conditional judgment can be greater than one end or less than one end. For example, the above conditional judgment of a threshold being greater than, less than or equal to can also be changed to a conditional judgment of the threshold being greater than, equal to or less than the threshold, which is not limited here.

[0162] It will be appreciated that only the parts relevant to the present application, not all, are shown in the accompanying drawings. It will be appreciated that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the various operations (or steps) as sequential processes, many of the operations therein can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the various operations can be rearranged. When its operation is completed, the process can be terminated, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0163] As used in this specification, the terms "component," "module," "system," "unit," and the like are used to refer to computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a unit can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or distributed between two or more computers. In addition, these units can be executed from various computer-readable media having various data structures stored thereon. Units can communicate, for example, through local and / or remote processes based on signals having one or more data packets (e.g., data from a second unit interacting with another unit in a local system, a distributed system, and / or a network. For example, the Internet interacts with other systems via signals).

[0164] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of this application. It should be understood that the above description is only the specific implementation methods of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of this application should be included in the scope of protection of this application.

Claims

1. A data backup method, characterized in that: The method is applied to an electronic device, the electronic device includes a central processing unit, a memory and a hardware acceleration device, the memory includes a first buffer zone; the method includes: Reading first data from a first data file and storing the first data in the first buffer, wherein the first data file is stored in a data disk corresponding to an original database directory; compressing the first data in the first buffer by the hardware acceleration device to generate backup data corresponding to the first data; The backup data is written into the data disk corresponding to the backup directory.

2. The method according to claim 1, characterized in that The compressing the first data in the first buffer by the hardware acceleration device includes: When the first buffer is fully stored with the first data, the first data in the first buffer is compressed by the hardware acceleration device.

3. The method according to claim 1 or 2, characterized in that: There are multiple first buffers, and the method further includes: Read the remaining data from the first data file, and store the remaining data in the second buffer; the second buffer is any other buffer among the multiple first buffers that does not store or is full of the first data; When the hardware acceleration device completes compressing the first data in the first buffer, the data in the second buffer is compressed by the hardware acceleration device.

4. The method according to claim 3, characterized in that The method further comprises: Reading first data from multiple data files in the original database directory respectively through multiple threads, and storing the read first data from different data files respectively into buffers in which the first buffers are not stored or are not fully stored; When the third buffer is full, the data in the third buffer is compressed by the hardware acceleration device, and the third buffer is any full buffer among the multiple first buffers.

5. The method according to claim 3 or 4, characterized in that: The electronic device includes a plurality of hardware acceleration devices, and the method further includes: When there are multiple full buffers among the multiple first buffers, the multiple hardware acceleration devices process and compress data in the multiple full buffers in parallel.

6. The method according to claim 4 or 5, characterized in that: The number of threads is determined according to the first time, the second time, and the number of hardware acceleration devices included in the electronic device; the first time is the time required to read the first data from the original database directory to fill a first buffer zone, and the second time is the time required for a hardware acceleration device to complete compressing a full first buffer zone, and for the central processing unit to write the corresponding backup data into the data disk corresponding to the backup directory.

7. The method according to any one of claims 3 to 6, characterized in that: The number of the buffers is determined according to the first time, the second time, and the number of hardware acceleration devices included in the electronic device; the first time is the time required to read the first data from the original database directory to fill a first buffer, and the second time is the time required for a hardware acceleration device to complete compressing a full first buffer, and for the central processor to write the corresponding backup data into the data disk corresponding to the backup directory.

8. The method according to any one of claims 3 to 7, characterized in that: The method further comprises: During the data backup process, the number of threads and / or the number of buffers are dynamically adjusted according to the first time, the second time, and the number of hardware acceleration devices included in the electronic device.

9. The method according to any one of claims 1 to 8, characterized in that: The central processing unit includes the hardware acceleration device.

10. An electronic device, characterized in that: The electronic device comprises a processor and a memory, and the processor calls a computer program or a computer instruction stored in the memory to implement the method according to any one of claims 1 to 9.

Images