OpenGauss database mirror image backup recovery method and device and electronic equipment

Abstract

The invention relates to an openGauss database mirror image backup recovery method and an openGauss database mirror image backup recovery device. The method comprises the following steps: executing full backup, and backing up a dependency item of database service, a data file and a WAL file; incremental backup is executed, and only the data pages and the WAL files which are changed since the last backup are backed up; and executing recovery operation: executing full-amount recovery and specified time point recovery, and supporting single-node recovery and cluster recovery. According to the openGauss database mirror image backup and recovery method based on the CDM technology flow, the backup and recovery efficiency is remarkably improved through the functions of original format backup, incremental backup, specified time point recovery and the like; the method is high in flexibility, supports full backup, incremental backup and specified time point recovery, and can meet backup requirements in different scenes; according to the method, the backup data is kept in a native format, additional processing is not needed during recovery, and data integrity and availability are ensured.

Description

Technical Field

[0001] This application belongs to the technical field of database backup, and particularly relates to an openGauss database mirror backup and recovery method, device, computer-readable storage medium, and electronic device. Background Technique

[0002] Mirror backup and recovery technology, also known as CDM (Copy Data Management) backup and recovery technology, is a new data management technology. Its core goal is to ensure the reliability and integrity of enterprise data, and at the same time be able to quickly recover data when needed to reduce business interruption time and lower the risk of data loss. Mirror backup and recovery technology captures data in its native format, and the backup data maintains the same format as the production environment without the need for data format conversion. This native-format backup data can be directly mounted and used, greatly improving the recovery speed.

[0003] Based on the characteristics of CDM backup and recovery technology, the industry is actively exploring and developing mirror backup and recovery solutions adapted to the openGauss database. For the openGauss database, the core of this backup solution lies in maintaining the native format of the backup data, that is, not modifying the backup data, so that the database can be immediately restored to the normal running state without additional data processing during recovery. This backup method is also called raw format backup.

[0004] To ensure the integrity of database backup and the reliability of recovery, the openGauss database mirror backup solution based on CDM backup and recovery technology needs to meet the following specification requirements: (1) Backup database services and their dependencies: In the backup initialization stage, not only the data files of the database need to be backed up, but also the configuration files, parameter settings, log files, etc. related to the database service need to be backed up simultaneously to ensure that the database service can be started and run normally during recovery; (2) Support incremental backup: Through incremental backup, the time and storage space required for backup can be significantly reduced, while maintaining the integrity and consistency of the backup data; (3) Support recovery at a specified time point: Users can restore the database to any specified time point according to their needs, minimizing the risk of data loss.

[0005] In traditional backup solutions, the openGauss database mainly relies on tools such as pg_basebackup and gs_probackup. However, pg_basebackup only supports full backups and depends on the existing database service, lacking flexibility, especially in scenarios that require incremental backups and point-in-time recovery. Although gs_probackup supports full and incremental backups, there is still room for improvement in backup format and recovery speed. Therefore, developing a more efficient, flexible, and mirror backup and recovery method that supports the original format backup has become an industry need. Summary of the Invention

[0006] To address the above problems, this application proposes a new openGauss database mirror backup and recovery method. Based on the CDM technology flow, this method realizes backup and recovery functions similar to Oracle's Image Copy, significantly improving backup and recovery efficiency.

[0007] This method draws on the core concept of CDM technology and achieves efficient backup and recovery through the following key features: Original format backup: During the backup process, the data's native format is maintained without additional conversion, ensuring that it can be directly mounted and used during recovery, significantly reducing recovery time.

[0008] Incremental backup support: Combining the incremental backup mechanism of CDM technology, only the data blocks that have changed since the last backup are backed up, reducing the time and storage space required for backup.

[0009] Point-in-time recovery: By combining with the WAL (Write-Ahead Logging) log, it supports restoring the database to any specified point in time, minimizing the risk of data loss.

[0010] Backup dependency integrity: During backup initialization, relevant configuration files, log files, and the running environment of the database service are simultaneously backed up to ensure that the database can be started normally during recovery.

[0011] The overall design architecture of this application is as Figure 1 shown, and its core functions and processes are described as follows: 1. Backup process When users use CDM backup technology, the following three types of key files are backed up to the specified backup destination: Data files: Contain the main data files of the database and are the basis for the database to run.

[0012] WAL files (Write-Ahead Logging files): These are the pre-written log files of the database, used to record all modification operations of the database and are crucial for implementing Point-in-Time Recovery (PITR).

[0013] Data block service dependencies (Other files): Include configuration files, parameter settings, and other related files of the database service to ensure the integrity and dependencies of the backup data.

[0014] 2. Recovery process Full recovery: Based on the complete data set backed up to the destination, users can perform a full recovery operation to restore the database to the state at the time of backup.

[0015] Point-in-Time Recovery (PITR recovery): By combining the archived WAL files, users can achieve Point-in-Time Recovery. This process allows users to restore the database to any state after the backup time point, minimizing data loss.

[0016] Recovery modes: Based on full recovery, two recovery modes are supported: Single-node recovery: Users can first restore the database to a single-node state, which is suitable for scenarios where quick startup of the database service is required.

[0017] Cluster recovery: For a distributed database environment, after single-node recovery is completed, users can expand the single node to a complete cluster through the expansion function to complete cluster recovery.

[0018] Limitations: Point-in-Time Recovery cannot be automatically restored to a cluster in one step. It is necessary to first restore to a single node and then complete cluster recovery through the expansion function.

[0019] To further improve the efficiency and flexibility of database backup and recovery, this solution innovatively proposes database service backup and original format incremental backup functions, and the specific implementation methods are as follows: (I) Full backup 1. Database service backup First, execute the gs_ctl build -b cdm_init -C -D command to back up the dependencies of the database service. This command will back up the following key paths and files: $GAUSSHOME: The installation directory of the openGauss database, containing executable files and configuration files.

[0020] $GPHOME: If Greenplum-related components are used, this path contains relevant configurations and tools.

[0021] cm configuration file: The configuration file related to cluster management, which is used to ensure the normal startup and operation of the database service.

[0022] 2. Backup of Data Node (DN) Configuration Files After completing the backup of database service dependencies, further backup the configuration files of the data node (DN). These configuration files are crucial for the correct startup and operation of the database instance during recovery.

[0023] 3. Full Data Backup Under the backup path environment, call the gs_ctl build -b cdm_full command to perform a full backup of the database's data files. This command synchronizes the host's data directory completely to the backup target location in the form of a full mirror, ensuring the integrity of the backup data.

[0024] 4. Backup Mode Description The gs_ctl build -b cdm_init -C -D command supports two backup scenarios: local backup and remote backup: When the -C parameter is not specified, local backup is performed, and the backup data is stored in the local specified path.

[0025] When the -C parameter is added, remote backup is performed, and the backup data will be transferred to the remote specified location.

[0026] Through the above process, this solution realizes the complete backup of database service dependencies and the full backup of data files, providing a reliable basis for subsequent recovery operations.

[0027] As an example, the process of full backup in this solution is as Figure 2 shown, and the specific steps are as follows: (1) Start the process: Execute cdm_init.

[0028] (2) Determine whether it is a cluster node: If it is a cluster node, proceed to the next step.

[0029] If it is not a cluster node, directly copy the source format file of the installation directory to the bin_back directory, and then write the environment variables to the cdm_backup.sh script.

[0030] (3) Copy files (for cluster nodes): Copy the source format file of the installation directory and the source format file of the cluster service to the bin_back directory.

[0031] (4) Determine whether it is environment variable separation: If it is environment variable separation, obtain the actual environment variable file from the source, and then write the environment variables into the cdm_backup.sh script.

[0032] If it is not environment variable separation, directly write the environment variables into the cdm_backup.sh script.

[0033] (5)Initialize the database: Use the gs_initdb command to initialize an empty database to data_back.

[0034] (6)Modify the source and backup database replication slots to establish communication.

[0035] The entire process performs different operations according to whether it is a cluster node and whether the environment variables are separated. The ultimate goal is to initialize the database and establish communication to achieve full backup.

[0036] (2)Incremental backup. Incremental backup means that based on the previous backup (full backup or incremental backup), only the data pages and WAL log files that have changed since the last backup are backed up. This backup method significantly reduces the backup data volume and backup time by recording the changed parts of the data. In the openGauss database environment, the incremental backup in this solution is achieved through the following process: 1. Trigger the incremental backup request: The backup side triggers the CDM incremental backup process by executing the gs_ctl build -b cdm_inc -D command.

[0037] 2. Send the backup request: The gs_ctl command sends the incremental backup request to the data node (DN) to request the changed data since the last backup.

[0038] 3. Obtain the changed data: The source side (database server) queries the CDM module to obtain a list of all changed pages.

[0039] 4. Data transfer: The source side sends the changed data page files to the backup side to complete the incremental backup of the data.

[0040] 5. WAL log backup: After the data page backup is completed, the WAL log files are backed up to the remote storage to ensure data integrity and consistency.

[0041] 6. Recovery process: During recovery, the full backup needs to be restored first, and then the incremental backups are applied in chronological order. Although this recovery method is relatively complex in operation, it can minimize the risk of data loss.

[0042] As an example, the process of incremental backup in this solution is as Figure 3As shown in the figure, it involves two nodes: a backup node and a source node. The specific steps are as follows: (1) Backup node: Obtain the LSN (Log Sequence Number) of the previous backup.

[0043] Send an incremental backup request to the source node.

[0044] (2) Source node: After receiving the incremental backup request, obtain the check LSN.

[0045] Generate CDM information.

[0046] Obtain the changed pages (i.e., the data pages that have changed since the last backup).

[0047] Send the changed pages to the backup node.

[0048] (3) Backup node: After receiving the changed pages, perform the operation of backing up the modified pages.

[0049] (4) Source node: Send the XLOG (transaction log) to the backup node.

[0050] (5) Backup node: After receiving the XLOG, perform the operation of backing up the XLOG to complete the incremental backup.

[0051] The entire process realizes incremental backup by transmitting backup requests, changed pages, and transaction logs between the backup node and the source node, ensuring that the backup node can obtain all changes since the last backup.

[0052] Through the above mechanism, this solution realizes an efficient and flexible incremental backup function, providing a better solution for database backup and recovery.

[0053] Specifically, to achieve the above object, this application provides the following technical solutions: The first aspect of this application provides an openGauss database mirror backup and recovery method, and the method includes: Perform a full backup: Back up the dependencies, data files, and WAL files of the database service; Perform an incremental backup: Only back up the data pages and WAL files that have changed since the last backup; Perform a recovery operation: Include performing a full recovery and a recovery at a specified time point, and support single-node recovery and cluster recovery.

[0054] Optionally, in the method of the present application, the execution of the full backup includes the following steps: Execute the gs_ctl build -b cdm_init -C -D command to back up the dependencies of the database service, where the dependencies include $GAUSSHOME, $GPHOME, and the cm configuration file related to cluster management; Back up the configuration files of the data nodes; Call the gs_ctl build -b cdm_full command to perform a full backup of the data files of the database.

[0055] Optionally, in the method of the present application, the gs_ctl build -b cdm_init -C -D command supports two cases: local backup and remote backup: When the -C parameter is not specified, local backup is performed, and the backup data is stored in the local specified path; When the -C parameter is added, remote backup is performed, and the backup data will be transferred to the remote specified location.

[0056] Optionally, in the method of the present application, the execution of the full backup further includes the following steps: (1) Start process: Execute cdm_init; (2) Determine whether it is a cluster node: If it is a cluster node, proceed to the next step; If it is not a cluster node, directly copy the source format file of the installation directory to the bin_back directory, and then write the environment variables into the cdm_backup.sh script; (3) For cluster nodes, copy files: Copy the source format file of the installation directory and the source format file of the cluster service to the bin_back directory; (4) Determine whether it is environment variable separation: If it is environment variable separation, obtain the actual environment variable file from the source, and then write the environment variables into the cdm_backup.sh script; If it is not environment variable separation, directly write the environment variables into the cdm_backup.sh script; (5) Initialize the database: Use the gs_initdb command to initialize an empty database to data_back; (6) Modify the source and the backup database replication slot to establish communication.

[0057] Optionally, in the method of the present application, the execution of the incremental backup includes the following steps: The backup end triggers the incremental backup process by executing the gs_ctl build -b cdm_inc -D command; Send the incremental backup request to the data node to request the changed data since the last backup; Query the CDM module to obtain a list of all changed pages; Send the changed data page file to the backup end to complete the incremental backup of the data; Back up the WAL file to the remote storage to ensure data integrity and consistency.

[0058] Optionally, in the method of this application, the execution of the incremental backup further includes the following steps: (1) Backup node: Obtain the LSN of the previous backup; Send an incremental backup request to the source node; (2) Source node: After receiving the incremental backup request, obtain the check LSN; Generate CDM information; Obtain the data change pages that have changed since the last backup; Send the data change pages to the backup node; (3) Backup node: After receiving the data change pages, perform the operation of backing up the modified pages; (4) Source node: Send the XLOG (transaction log) to the backup node; (5) Backup node: After receiving the XLOG, perform the operation of backing up the XLOG to complete the incremental backup.

[0059] Optionally, in the method of this application, the recovery operation includes: Full recovery: Based on the complete backup data set, restore the database to the state at the time of backup; Recovery at a specified time point: Combine the archived WAL files to restore the database to any state after the backup time point.

[0060] Optionally, in the method of this application, the recovery operation supports the following two modes: Single-node recovery: Restore the database to a single-node state; Cluster recovery: After the single-node recovery is completed, expand the single node to a complete cluster through the expansion function.

[0061] The second aspect of this application provides an openGauss database mirror backup and recovery device, and the device includes: Full backup module: used to back up the dependencies, data files, and WAL files of the database service; Incremental backup module: used to back up only the data pages and WAL files that have changed since the last backup; Recovery module: used to perform full recovery and recovery at a specified point in time, and support single-node recovery and cluster recovery.

[0062] When the device is running, it implements the steps of the aforementioned openGauss database mirror backup and recovery method.

[0063] The third aspect of this application provides an electronic device, including: a memory and a processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the aforementioned openGauss database mirror backup and recovery method.

[0064] The fourth aspect of this application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the aforementioned openGauss database mirror backup and recovery method.

[0065] In summary, the openGauss database mirror backup and recovery method proposed in this application, through functions such as original format backup, incremental backup, and recovery at a specified point in time, significantly improves the backup and recovery efficiency. Compared with existing backup tools, this method has the following advantages: (1) High efficiency: The original format backup and incremental backup mechanisms significantly improve the speed of backup and recovery.

[0066] (2) Flexibility: Supports full backup, incremental backup, and recovery at a specified point in time, meeting the backup requirements in different scenarios.

[0067] (3) Reliability: The backup data maintains the native format and does not require additional processing during recovery, ensuring data integrity and availability.

[0068] (4) This method fills the gap in the field of efficient mirror backup and recovery of openGauss databases, provides new ideas for the development of database backup and recovery technologies, and by introducing the CDM technology flow, this method is expected to become the preferred solution for openGauss database backup and recovery, further enhancing the reliability and business continuity of the database.

[0069] Other features and advantages of the present application will be elaborated in detail in the subsequent description, or can be understood by implementing the relevant technical solutions of the present application. The objectives and other advantages of the present application can be achieved by the technical features and means clearly pointed out in the description, claims, and drawings, and can be obtained through the implementation process of these technical contents. Brief Description of the Drawings

[0070] To more clearly elaborate on the technical solutions of the embodiments of the present application, the drawings involved in the description of the embodiments will be briefly introduced below. It should be noted that the drawings only show some embodiments of the present application. For those skilled in the art, without creative efforts, other relevant drawings can be deduced based on these drawings.

[0071] Figure 1 It is the overall design architecture diagram of the present application.

[0072] Figure 2 It is the full backup flowchart in an embodiment of the present application (highlighting the backup of database dependencies during initialization).

[0073] Figure 3 It is the incremental backup flowchart in an embodiment of the present application (highlighting the implementation of backing up changed pages by relying on the existing openGausscdm logic).

[0074] Figure 4 It is the overall implementation flowchart of the openGauss database mirror backup and recovery method of the present application.

[0075] Figure 5 It is the component structure diagram of the openGauss database mirror backup and recovery device of the present application.

[0076] Figure 6 It is the schematic diagram of the structure of the electronic device provided by the embodiment of the present application.

[0077] Figure 7 It is an example diagram of the full backup operation result in an embodiment of the present application.

[0078] Figure 8 It is the final state diagram of the full backup directory in an embodiment of the present application.

[0079] Figure 9 It is an example diagram of the pg_hba.conf file at the source end of the full backup in an embodiment of the present application.

[0080] Figure 10 It is an example diagram of the modified result of the replication slot at the backup end of the full backup in an embodiment of the present application.

[0081] Figure 11This is the flowchart of incremental backup execution in an embodiment of the present application.

[0082] Figure 12 This is an example diagram of full recovery profile settings in an embodiment of the present application.

[0083] Figure 13 This is an example diagram of full recovery environment variable settings in an embodiment of the present application.

[0084] Figure 14 This is an example diagram of the execution result of full recovery in an embodiment of the present application. Detailed implementation manners

[0085] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer and more understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It should be clear that the described embodiments are only some embodiments of the present application, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0086] In this document, the term "including" and any form of its deformation (such as "including", "including") are open expressions and should be understood as "including but not limited to", that is, the listed content is not an exhaustive list and may also include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on", that is, the referred basis or condition may not be the only factor and may also involve other relevant factors. The term "an embodiment" should be understood as "at least one embodiment", that is, the described embodiment is not the only possible implementation manner, and there may also be other similar embodiments.

[0087] In the present application, when the terms "one" and "multiple" are used to modify relevant elements or features, their expressions are illustrative rather than restrictive. Unless clearly stated otherwise in the context, "one" should be understood as "at least one", and "multiple" should be understood as "at least two". Those skilled in the art should reasonably interpret these terms according to the semantic and logical relationships in the context to ensure that they cover the possibility of "one or more".

[0088] Term explanation: WAL: Write Ahead Logging, which is a mechanism used by databases to recover transaction persistence.

[0089] PITR: Point-In-Time Recovery, a database recovery technology that allows users to restore a database to a specific point in time to avoid losing important data or restoring data corrupted due to accidental deletion or incorrect operations.

[0090] LSN: Log Sequence Number, a log sequence number used to represent the timing of transactions.

[0091] Figure 4 The following shows the overall implementation process of the openGauss database mirror backup and recovery method provided by this application, including the following steps: Perform a full backup: Back up the dependencies of the database service, data files, and WAL files; Perform an incremental backup: Only back up the data pages and WAL files that have changed since the last backup; Perform a recovery operation: Include performing a full recovery and a recovery at a specified point in time, and support single-node recovery and cluster recovery.

[0092] To more clearly elaborate on the technical solution of this application, the following will be further illustrated through examples in specific scenarios.

[0093] Prepare the following test environment, and the database has been installed on the source side: Operating System IP Address Test User CentOS Linux7 172.16.100.101 Source End wanq CentOS Linux7 172.16.100.96 Target End wanq And ensure that $GAUSSHOME and $PGDATA have been configured on the source side. These two variables mainly represent the binary installation path and data path of the database.

[0094] The same user wanq needs to exist on the backup side.

[0095] (1) Full backup: Take the example of not doing a local backup and only doing a remote backup.

[0096] Specific instruction: pw_ctl build -b cdm_full -D / home / wanq / data / cdmtest -C 172.16.100.101 Execution process: Log in to 172.16.100.96 using the wanq user, establish an SSH mutual trust with the source side, and execute the above command.

[0097] Execution result: In the first stage, check and prepare the backup directory.

[0098] In the second stage, install the data copy.

[0099] In the third stage, generate database data.

[0100] In the fourth stage, the replication slots at the source and target ends are modified.

[0101] (Same as local) In the fifth stage, a full backup is performed.

[0102] The specific operation results are as Figure 7 shown.

[0103] The final state of the backup directory is as Figure 8 shown.

[0104] After the backup is completed, the pg_hba.conf file at the source end is added as Figure 9 shown.

[0105] After the replication slot at the backup end is modified, it is as Figure 10 shown.

[0106] (2) Incremental backup: Specific instruction: pg_ctl build -b cdm_inc -D / home / wanq / data / cdmtest Execution process: Log in to 172.16.100.96 using the wanq user and execute the above command, as Figure 11 shown.

[0107] (3) Full recovery: Specific instruction: pg_ctl build -b cdm_restore -D / home / wanq / data / cdmtest -A / home / wanq / data / cdm_restore.conf Taking local recovery as an example, local recovery means that the IP of the recovery node is set to be the same as that of the backup node.

[0108] 1. Log in to the 172.16.100.96 environment and set the recovery configuration file as Figure 12 shown.

[0109] Name the configuration file cdm_restore.conf and store it in the / home / wanq / data / directory.

[0110] 2. Set the environment variables, as Figure 13 shown.

[0111] 3. Execute the following command: pg_ctl build -b cdm_restore -D / home / wanq / data / cdmtest -A / home / wanq / data / cdm_restore.conf 4. The execution result is as Figure 14 shown below.

[0112] According to the process of creating a recovery directory, parsing recovery information, copying backup set data, and starting the database, a database instance with a specified port value was finally started.

[0113] Figure 5 As shown below is an openGauss database mirror backup and recovery device proposed in this application. The device includes: Full backup module: used to back up dependencies, data files, and WAL files of the database service; Incremental backup module: used to back up only the data pages and WAL files that have changed since the last backup; Recovery module: used to perform full recovery and recovery at a specified time point, and support single-node recovery and cluster recovery.

[0114] When the above device runs, it implements the steps of the openGauss database mirror backup and recovery method disclosed in this application.

[0115] The flowcharts and block diagrams in the accompanying drawings show possible implementations of devices, methods, and computer program products according to various embodiments of this application, including architecture, functions, and operations. In these figures, each box may represent a module, program segment, or part of code, which contains one or more executable instructions for implementing the specified logical function. It should be noted that each box in the block diagram and / or flowchart, as well as combinations of these boxes, can be implemented using a dedicated hardware-based system to implement the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0116] As Figure 6 shown below, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing computer programs executable by the processor, and a communication bus 340. Among them, the processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 runs the executable computer program to implement the steps of the above openGauss database mirror backup and recovery method.

[0117] It is understandable that, in addition to a memory and a processor, the electronic device may further include an input device (such as a keyboard), an output device (such as a display), and other communication modules. These input devices, output devices, and other communication modules communicate with the processor through an I / O interface (i.e., an input / output interface).

[0118] The operations of this application can be implemented by writing computer program code using one or more programming languages or combinations thereof. The programming languages include but are not limited to the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc.; Conventional procedural programming languages, such as the "C" language or similar programming languages.

[0119] The execution modes of the program code include but are not limited to: Executing entirely on the user's computer; Executing partially on the user's computer and partially on a remote computer; Executing as an independent software package; Executing entirely on a remote computer or server.

[0120] In scenarios involving a remote computer, the remote computer can be connected to the user's computer through any type of network, and the network includes but is not limited to a local area network (LAN) or a wide area network (WAN). In addition, the remote computer can also be connected to an external computer through an Internet service provider, for example, by using the Internet for connection.

[0121] Furthermore, this application also discloses a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device can execute each step of the openGauss database mirror backup and recovery method disclosed in this application.

[0122] In the context of this application, a computer-readable storage medium refers to a tangible medium that can store computer program code and related data. Specific examples include but are not limited to the following: (1) Portable computer disks: Removable magnetic storage media such as floppy disks.

[0123] (2) Hard disks: Fixed storage devices including mechanical hard disks and solid-state drives.

[0124] (3) Random access memory (RAM): A volatile storage medium for temporarily storing data and program code.

[0125] (4) Read-only memory (ROM): A non-volatile storage medium for storing fixed programs and data.

[0126] (5) Erasable Programmable Read-Only Memory (EPROM) or Flash Memory: A non-volatile storage medium that supports multiple erasures and programming.

[0127] (6) Fiber optic storage device: A storage medium based on fiber optic technology.

[0128] (7) Portable Compact Disc Read-Only Memory (CD-ROM): A read-only medium that stores data in the form of an optical disc.

[0129] (8) Optical storage device: Storage media based on optical principles such as DVDs, Blu-ray discs, etc.

[0130] (9) Magnetic storage device: Storage media based on magnetic principles such as magnetic tapes, magnetic disks, etc.

[0131] (10) Any suitable combination of the above: For example, combining multiple storage media to meet different storage requirements.

[0132] These computer-readable storage media can be used to store the program code and related data described in this application to support the operation of the program and the persistent storage of data.

[0133] In particular, according to the embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, the embodiments of this application relate to a computer program product that includes a computer program carried on a non-transitory computer-readable medium. This computer program contains program code for executing the openGauss database mirror backup and recovery method disclosed in this application. When this computer program is executed by a processing device, it can implement the above functions defined in the embodiments of this application.

[0134] Although there are several specific implementation details in the above discussion, these details should not be construed as limiting the scope of this application. The above description is only for the preferred embodiments of this application and an explanation of the technical principles applied. Those skilled in the art should understand that the scope of the disclosure involved in this application is not limited to the technical solutions formed by the specific combinations of the above technical features. At the same time, this application should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept.

[0135] Those skilled in the art should also understand that they can modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or replacements will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An openGauss database image backup and recovery method, characterized in that: The method comprises: Perform a full backup: back up the database service dependencies, data files, and WAL files; Perform incremental backup: back up only the data pages and WAL files that have changed since the last backup; Perform recovery operations: including full recovery and recovery at a specified time point, and supports single-node recovery and cluster recovery.

2. The method according to claim 1, characterized in that The full backup comprises the following steps: Run the gs_ctl build -b cdm_init -C -D command to back up the dependencies of the database service, including $GAUSSHOME, $GPHOME, and cm configuration files related to cluster management. Back up the configuration files of the data nodes; Run the gs_ctl build -b cdm_full command to perform a full backup of the database data files.

3. The method according to claim 2, characterized in that The gs_ctl build -b cdm_init -C -D command supports local backup and remote backup: If the -C parameter is not specified, local backup is performed and the backup data is stored in the specified local path. When the -C parameter is added, remote backup is performed and the backup data is transferred to the specified remote location.

4. The method according to claim 1, characterized in that: The full backup also includes the following steps: (1) Start the process: execute cdm_init; (2) Determine whether it is a cluster node: If it is a cluster node, go to the next step; If it is not a cluster node, directly copy the installation directory source format file to the bin_backup directory, and then write the environment variables into the cdm_backup.sh script; (3) For cluster nodes, copy files: Copy the installation directory source format files and cluster service source format files to the bin_back directory; (4) Determine whether it is environment variable separation: If the environment variables are separated, get the actual environment variable file from the source, and then write the environment variables into the cdm_backup.sh script; If the environment variables are not separated, write the environment variables directly into the cdm_backup.sh script; (5) Initialize the database: Use the gs_initdb command to initialize the empty database to data_back; (6) Modify the source and backup database replication slots to establish communication.

5. The method according to claim 1, characterized in that The incremental backup comprises the following steps: The backup end triggers the incremental backup process by executing the gs_ctl build -b cdm_inc -D command; Send an incremental backup request to the data node, requesting the changed data since the last backup; Query the CDM module to obtain a list of all changed pages; Send the changed data page files to the backup end to complete the incremental backup of the data; Back up WAL files to remote storage to ensure data integrity and consistency.

6. The method according to claim 1, characterized in that The incremental backup also includes the following steps: (1) Backup Node: Get the LSN of the last backup; Send incremental backup request to the source node; (2) Source node: After receiving the incremental backup request, obtain the check LSN; Generate CDM information; Get the data changes page that have changed since the last backup; Send data change page to backup node; (3) Backup Node: After receiving the data change page, perform the operation of backing up the modified page; (4) Source node: Send XLOG to the backup node; (5) Backup Node: After receiving the XLOG, perform the XLOG backup operation to complete the incremental backup.

7. The method according to claim 1, characterized in that The recovery operation includes: Full recovery: Based on the complete data set of the backup, the database is restored to the state at the time of the backup; Specified point-in-time recovery: Combine archived WAL files to restore the database to any state after the backup time point.

8. The method according to claim 7, characterized in that The recovery operation supports the following two modes: Single-node recovery: restore the database to a single-node state; Cluster recovery: After a single node is restored, the capacity expansion function is used to expand the single node into a complete cluster.

9. An openGauss database mirror backup and recovery device, characterized in that: The device comprises: Full backup module: used to back up database service dependencies, data files, and WAL files; Incremental backup module: used to back up only the data pages and WAL files that have changed since the last backup; Recovery module: used to perform full recovery and recovery at a specified time point, and supports single-node recovery and cluster recovery.

10. An electronic device, characterized in that: include: Memory and processor; Memory: used to store computer programs; Processor: used for executing the computer program to implement the steps of the openGauss database mirror backup and recovery method according to any one of claims 1 to 8.

Images