Database backup method and apparatus, electronic device, and storage medium
By determining a shared log directory in the distributed database for log backup, the problem of redundant log files occupying storage resources is solved, and a more efficient backup process is achieved.
Patent Information
- Application Number
- CN202211235096.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-10-10
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2042-10-10
AI Technical Summary
In distributed databases, existing technologies result in a large number of redundant log files consuming excessive storage resources and having poor backup accuracy.
By obtaining the preset backup strategy of the distributed database, the nodes to be backed up are determined, and the logs to be backed up are backed up according to the shared log directory, reducing redundancy and improving backup accuracy.
It reduces the computational burden and storage resource waste in distributed database backups, and improves backup efficiency.
Smart Images

Figure CN115454725B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a database backup method, apparatus, electronic device, and storage medium. Background Technology
[0002] Database backup and recovery is one of the important functions of a database. During the operation of a database, errors by technicians, bugs in software programs, and failures in hardware devices can occur from time to time. Therefore, it is extremely important to be able to retain accurate backup files.
[0003] In existing technologies, technicians will set the database to back up all log files periodically. However, in distributed databases, a large number of redundant log files are likely to appear, which consume too much storage resources, make database backups chaotic, and result in poor accuracy of log file backups. Summary of the Invention
[0004] This application provides a database backup method, apparatus, electronic device, and storage medium to improve the accuracy of database backup, reduce backup redundancy, and save storage resources.
[0005] According to one aspect of this application, a database backup method is provided, the method comprising:
[0006] Obtain the default backup strategy for the distributed database;
[0007] Based on the preset backup strategy, determine the nodes to be backed up;
[0008] Determine the shared log directory based on the node to be backed up;
[0009] Back up the logs of the distributed database based on the shared log directory.
[0010] According to another aspect of this application, a database backup apparatus is provided, comprising:
[0011] The strategy acquisition module is used to acquire the preset backup strategies of the distributed database.
[0012] The node determination module is used to determine the nodes to be backed up based on a preset backup strategy.
[0013] The directory determination module is used to determine the shared log directory based on the node to be backed up;
[0014] The log backup module is used to back up the logs of the distributed database based on the shared log directory.
[0015] According to another aspect of this application, an electronic device is provided, the electronic device comprising:
[0016] At least one processor; and
[0017] A memory communicatively connected to the at least one processor; wherein,
[0018] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the database backup method described in any embodiment of this application.
[0019] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the database backup method described in any embodiment of this application.
[0020] The technical solution of this application embodiment determines the shared log directory based on the node to be backed up, so as to count the set of log directories of each node, and then back up the logs based on the records in the shared log directory, so as to prevent redundancy in log backup, reduce the backup calculation workload and computing resources of the distributed database, reduce the waste of storage space, and improve the backup efficiency of the distributed database.
[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1A This is a flowchart of a database backup method provided according to Embodiment 1 of this application;
[0024] Figure 1B This is a schematic diagram of a backup log recovery process provided according to Embodiment 1 of this application;
[0025] Figure 2A This is a flowchart of a database backup method according to Embodiment 2 of this application;
[0026] Figure 2B This is a schematic diagram of a log backup process provided according to Embodiment 2 of this application;
[0027] Figure 3This is a schematic diagram of a database backup device according to Embodiment 3 of this application;
[0028] Figure 4 This is a schematic diagram of the structure of an electronic device that implements the database backup method of the embodiments of this application. Detailed Implementation
[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0031] Example 1
[0032] Figure 1A This application provides a flowchart of a database backup method according to Embodiment 1. This embodiment is applicable to log backup in a distributed database. The method can be executed by a database backup device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1A As shown, the method includes:
[0033] S110. Obtain the preset backup strategy for the distributed database.
[0034] The preset backup strategy can be a pre-defined rule for backing up log files in the distributed database. For example, it may include, but is not limited to, time-based strategies and / or node-based strategies. A time-based strategy, as the name suggests, sets the backup of logs generated within a specific time period; a node-based strategy can back up logs from selected storage nodes in the distributed database. Backup strategies are not exhaustive; they can be preset or temporarily modified by relevant technical personnel based on actual conditions or human experience, and this application embodiment does not limit this. The preset backup strategy of the distributed database can be pre-configured in the security group cluster center of the distributed database to facilitate control of subordinate computing and storage nodes through the security group cluster center. When using the preset backup strategy, it can be directly invoked from the security group cluster center of the distributed database, or a backup strategy set by relevant technical personnel in real time can be used as the preset backup strategy.
[0035] S120. Determine the node to be backed up according to the preset backup strategy.
[0036] The node to be backed up can be the target node for log backup. This node can be a compute node or any node in the distributed database. Since the preset backup strategy already determines which nodes will be backed up, the relevant information for the node to be backed up can be directly obtained from the preset backup strategy. The node to be backed up can be determined based on the update status of backup files among nodes. For example, the node with the most (or most recent) log backups can be selected as the node to be backed up. This allows for the synchronous backup of the minimum amount of log content, reducing energy consumption during backup processing, reducing the amount of logs in a single backup, and saving storage space resources.
[0037] S130. Determine the shared log directory based on the node to be backed up.
[0038] The shared log directory can be a directory that needs to be backed up on at least one node; that is, it can be a backup directory shared by different nodes. Directory concatenation is possible; for example, backup can be performed on node A at location X in the shared log directory, and then on node B, the backup can continue at location X. Preferably, the shared log directory can be stored in a shared storage node of the distributed database, and logs that need to be backed up on the compute nodes can be copied to the shared log directory of the shared storage node as backups.
[0039] In one optional implementation, determining the shared log directory based on the node to be backed up may include: determining the shared log directory based on the historical log directory of the node to be backed up and the directory of the logs to be backed up.
[0040] The historical log directory can be a directory containing logs that have already been backed up on the node to be backed up. It's understandable that, since some content in the logs to be backed up may have already been backed up, to reduce the computational load, improve processing speed, and minimize log redundancy, directories that have already been backed up are not re-backed up. Instead, the directories containing the logs to be backed up are compared with the historical log directories to identify those that haven't been backed up and used as shared log directories to support subsequent log backups.
[0041] S140. Back up the logs to be backed up in the distributed database according to the shared log directory.
[0042] Based on the shared log directory determined in the preceding steps, copy the logs that need to be backed up from the node to be backed up to the shared storage node.
[0043] In one optional implementation, after backing up the logs to be backed up in the distributed database according to the shared log directory, the method may further include: obtaining preset backup and recovery conditions; determining at least two log files to be recovered according to the preset backup and recovery conditions; determining whether the at least two log files to be recovered belong to the same computing node; and recovering the log files to be recovered according to the determination result.
[0044] The preset backup and recovery conditions can be pre-defined log recovery conditions stored in the security group cluster center of the distributed database. These conditions can be set by relevant technical personnel based on actual conditions or human experience, such as restoring logs from a specific node within a certain time period. They can be directly retrieved from the security group cluster or retrieved based on recovery conditions input in real time by relevant technical personnel. The log files to be recovered are the log files that require recovery operations. It is understood that since at least two log files to be recovered may belong to the same compute node or different compute nodes, the methods for recovering the log files will differ, and log recovery operations will be performed separately according to the actual situation.
[0045] Furthermore, the step of restoring the log file to be restored based on the judgment result may include: if at least two log files to be restored belong to the same computing node, then the log file to be restored is restored according to the log sequence number of the log file to be restored; if at least two log files to be restored do not belong to the same computing node, then the log file to be restored is restored according to the existence of the log end position of the current log file to be restored in the next log file to be restored.
[0046] The log sequence number of the log file to be recovered can be the transaction number of the log file in the compute node. When at least two log files to be recovered belong to the same compute node, if the transaction numbers are consecutive, the backed-up log files can be retrieved and restored to the compute node according to the order of the transaction numbers; otherwise, if the transaction numbers are not consecutive, the log recovery is deemed to have failed.
[0047] The log cutoff position can be the last record of a log file in the shared log directory on the current compute node. Log files after this position may exist on the next compute node. When at least two log files to be recovered do not belong to the same compute node, the log files stored on the current compute node are traversed to determine the position of the last log entry (e.g., the last entry in chronological order) in the shared log directory, which is then used as the log cutoff position. On the next compute node, it is queried to see if the next log entry corresponding to this cutoff position is in the next log file existing on that node (equivalent to a log integrity verification process). If consecutive log entries can be determined based on their chronological order, then the missing logs can be recovered.
[0048] Based on the above-described embodiments, this application also provides a preferred embodiment for log recovery, such as... Figure 1B As shown, it specifically includes:
[0049] 1) Based on the restore interface in the distributed database, iterate through the selected log files one by one to confirm whether the preset backup and recovery conditions are met;
[0050] 2) Determine whether the current log file and the next log file belong to the same compute node; if they belong to the same compute node, proceed to step 3); if they do not belong to the same compute node, proceed to step 4.
[0051] 3) Determine if the transaction numbers of the current log file and the next log file are consecutive. If they are not consecutive, the recovery is deemed to have failed. If they are consecutive, continue reading the next log file and jump to step 2).
[0052] 4) Use the gdbbinlog command in the distributed database to read the last log entry position in the file and check if the log entry position appears in the next log file; if it exists, proceed to step 2); if it does not exist, remove this file from the file list and return to step 2.
[0053] 5) Continue the log file recovery operation until the file traversal is complete;
[0054] The technical solution of this application embodiment determines the shared log directory based on the node to be backed up, so as to count the set of log directories of each node, and then back up the logs based on the records in the shared log directory, so as to prevent redundancy in log backup, reduce the backup calculation workload and computing resources of the distributed database, reduce the waste of storage space, and improve the backup efficiency of the distributed database.
[0055] Example 2
[0056] Figure 2A This is a flowchart illustrating a database backup method provided in Embodiment 2 of this application. This embodiment further refines the log backup operation of a distributed database based on the aforementioned implementation methods. Figure 2A As shown, the method includes:
[0057] S210. Obtain the preset backup strategy for the distributed database.
[0058] S220. Determine the node to be backed up according to the preset backup strategy.
[0059] S230. Determine the shared log directory based on the node to be backed up.
[0060] S240. Determine the target index file for the logs to be backed up based on the shared log directory.
[0061] The target index file can be an index of the logs on the node to be backed up. If the logs exist on a certain node, the corresponding target index file can also be found on that node. It is understandable that by querying the target index file, one can determine whether the corresponding logs already exist on the node to be backed up.
[0062] S250. Back up the logs to be backed up according to the target index file.
[0063] Based on the presence of the target index file on the node to be backed up, selective backups of the logs to be backed up are performed (copied to the shared storage node).
[0064] In one optional implementation, backing up the log to be backed up according to the target index file may include: if the target index file exists in the shared log directory, determining the backup start position of the log to be backed up according to the target index file; backing up the log to be backed up according to the backup start position, and updating the target index file.
[0065] The backup start position can be the initial location of the logs to be backed up in the shared directory during the backup process; that is, the backup operation begins from that start position. If the target index file corresponding to the log file in the node to be backed up is in the shared log directory, it can be understood that the log has already been backed up and does not need to be backed up again. Therefore, the position from which the most recent backup update ended is determined based on the target index file, and this position is used as the backup start position for copying the logs to be backed up. After the backup is complete, the target index file corresponding to the backed-up logs is updated in the shared log directory to facilitate queries before the next backup. This further reduces duplicate backups, thereby helping to improve the efficiency of the distributed database.
[0066] In another optional implementation, backing up the log to be backed up according to the backup start position may include: if there is no backup start position in the target index file, then backing up the log to be backed up according to the most recent complete historical log.
[0067] Among them, a complete historical log is a complete historical log file without any missing parts. When the latest backup log does not have a backup start position, it means that the log may be incomplete (and needs to be backed up again). You can find the content of the last backup by searching the next newest complete historical log, and then determine which logs should be backed up this time. Copy these logs that have not been backed up to the shared storage node.
[0068] Based on the above-described embodiments, this application also provides a preferred embodiment, such as... Figure 2B As shown, it specifically includes:
[0069] 1) Obtain a list of log files based on the shared log directory;
[0070] 2) Confirm whether the log index file exists in the shared log directory; if not, directly copy all backup logs from the selected middleware node to the shared log directory; if it exists, proceed to the next step.
[0071] 3) By checking the last log file name in the log index file, confirm whether the compute node in this backup is the same as the compute node in the previous backup. If they are the same, determine the starting position of this backup, copy the remaining logs to the shared log directory, and update the log index file. If the compute nodes are different, proceed to step 4).
[0072] 4) Use the gdbbinlog command in the distributed database to get the latest log cutoff position in the last log file in the shared log directory (which can be used as the starting position of the log for this backup);
[0073] 5) Use the gdbbinlog command to check if the starting log position can be found;
[0074] 6) If it cannot be found, determine that the log in the shared log directory is a multi-transaction log and the transaction has not been written to disk; at this time, select the second to last log and return to step 4);
[0075] 7) If the starting position of the second-to-last log file is not found, then select the third-to-last log file, and so on, until the rollback file time is earlier than the time of the first log file of the selected compute node;
[0076] 8) If none of them are found, copy all the backup log files on the selected compute node to the shared log directory and update the log index file.
[0077] In the technical solution of this application embodiment, a target index file for the logs to be backed up is determined by sharing a log directory, and the logs to be backed up are then backed up according to the target index file. The historical backup status is determined by using the target index file to identify the logs that need to be backed up, thereby helping the distributed database to perform efficient log backups, reducing log redundancy, and improving the working efficiency of the distributed database.
[0078] Example 3
[0079] Figure 3 This is a schematic diagram of a database backup device provided in Embodiment 3 of this application. Figure 3 As shown, the device 300 includes:
[0080] The strategy acquisition module 310 is used to acquire the preset backup strategy of the distributed database;
[0081] The node determination module 320 is used to determine the node to be backed up according to the preset backup strategy;
[0082] The directory determination module 330 is used to determine the shared log directory based on the node to be backed up;
[0083] The log backup module 340 is used to back up the logs of the distributed database to be backed up based on the shared log directory.
[0084] The technical solution of this application embodiment determines the shared log directory based on the node to be backed up, so as to count the set of log directories of each node, and then back up the logs based on the records in the shared log directory, so as to prevent redundancy in log backup, reduce the backup calculation workload and computing resources of the distributed database, reduce the waste of storage space, and improve the backup efficiency of the distributed database.
[0085] In one alternative implementation, the log backup module 340 may include:
[0086] The starting position determination unit is used to determine the starting position for backing up the logs to be backed up based on the target index file if a target index file exists in the shared log directory.
[0087] The log backup unit is used to back up the logs to be backed up according to the backup start position and update the target index file.
[0088] In one optional implementation, the log backup unit may be specifically used for:
[0089] If the backup start position is not found in the target index file, the backup logs to be backed up are backed up based on the most recent complete historical logs.
[0090] In one alternative implementation, the directory determination module 330 may be specifically used for:
[0091] Determine the shared log directory based on the historical log directory of the node to be backed up and the directory of the logs to be backed up.
[0092] In one alternative embodiment, the database backup device 300 may further include:
[0093] The recovery condition acquisition module is used to acquire preset backup recovery conditions;
[0094] The recovery log determination module is used to determine at least two log files to be recovered based on preset backup and recovery conditions;
[0095] The compute node determination module is used to determine whether at least two log files to be recovered belong to the same compute node;
[0096] The file recovery module is used to recover the log files to be recovered based on the judgment results.
[0097] Furthermore, the file recovery module may include:
[0098] The same node recovery unit is used to recover log files based on their log sequence numbers if at least two log files to be recovered belong to the same computing node.
[0099] The different node recovery unit is used to recover log files if at least two log files to be recovered do not belong to the same computing node, based on the existence of the log cutoff position of the current log file to be recovered in the next log file to be recovered.
[0100] The database backup device provided in this application can execute the database backup method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each database backup method.
[0101] Example 4
[0102] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.
[0103] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0104] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0105] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as database backup methods.
[0106] In some embodiments, the database backup method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the database backup method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the database backup method by any other suitable means (e.g., by means of firmware).
[0107] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0108] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0109] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0110] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0111] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0112] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0113] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.
[0114] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A database backup method, characterized in that, The method includes: Obtain the default backup strategy for the distributed database; The nodes to be backed up are determined according to the preset backup strategy; Determine the shared log directory based on the nodes to be backed up; Back up the logs of the distributed database according to the shared log directory; Obtain preset backup and restore conditions; Based on the preset backup and recovery conditions, at least two log files to be recovered are identified; Determine whether the at least two log files to be recovered belong to the same computing node; If the at least two log files to be recovered belong to the same computing node, then the log files to be recovered are recovered according to their log sequence numbers. If the at least two log files to be recovered do not belong to the same computing node, then the log files to be recovered are recovered based on the existence of the current log file's log cutoff position in the next log file to be recovered.
2. The method according to claim 1, characterized in that, The step of backing up the logs of the distributed database according to the shared log directory includes: Based on the shared log directory, determine the target index file for the logs to be backed up; The log to be backed up is backed up according to the target index file.
3. The method according to claim 2, characterized in that, The step of backing up the logs to be backed up according to the target index file includes: If the target index file exists in the shared log directory, then the starting position for backing up the logs to be backed up is determined based on the target index file; Based on the backup start position, the log to be backed up is backed up, and the target index file is updated.
4. The method according to claim 3, characterized in that, The step of backing up the log to be backed up according to the backup start position includes: If the backup start position does not exist in the target index file, the log to be backed up is backed up based on the most recent complete historical log.
5. The method according to any one of claims 1-4, characterized in that, The step of determining the shared log directory based on the node to be backed up includes: The shared log directory is determined based on the historical log directory of the node to be backed up and the directory of the logs to be backed up.
6. A database backup device, characterized in that, include: The strategy acquisition module is used to acquire the preset backup strategies of the distributed database. The node determination module is used to determine the node to be backed up according to the preset backup strategy; The directory determination module is used to determine the shared log directory based on the node to be backed up; The log backup module is used to back up the logs of the distributed database to be backed up according to the shared log directory; The recovery condition acquisition module is used to acquire preset backup recovery conditions; The recovery log determination module is used to determine at least two log files to be recovered based on preset backup and recovery conditions; The compute node determination module is used to determine whether at least two log files to be recovered belong to the same compute node; The file recovery module is used to recover log files to be recovered based on the judgment results. The file recovery module includes: The same node recovery unit is used to recover log files based on their log sequence numbers if at least two log files to be recovered belong to the same computing node. The different node recovery unit is used to recover log files if at least two log files to be recovered do not belong to the same computing node, based on the existence of the log cutoff position of the current log file to be recovered in the next log file to be recovered.
7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the database backup method according to any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the database backup method according to any one of claims 1-5.
Citation Information
Patent Citations
Transaction backup processing method and device
CN105630626A
Data backup method and device, electronic equipment and storage medium
CN114661527A