Database physical backup method and device, equipment, medium and product

Abstract

The invention provides a physical backup method and device of a database, equipment, a medium and a product. The method comprises the following steps: firstly, calling a cronjob to create a physical backup task, so that the cronjob creates an execution task at a corresponding backup time according to the physical backup task; calling an execution container according to an execution task created by the cronjob; calling the sysrman in the execution container to execute a backup task on the database; the execution state information of the backup task is sent to the physical backup state; and obtaining execution state information of the backup task from the physical backup state, and displaying the execution state information. According to the scheme, the cronjob tool is called to schedule the timed backup task, and the execution state information of the backup task is sent to the physical backup state, so that the execution state of the physical backup task is monitored in real time.

Description

Technical Field

[0001] The present application relates to the computer field, and in particular to a method, device, equipment, medium and product for physical backup of a database. Background Art

[0002] As the complexity of computer systems and the amount of data increase, modern equipment software supports multiple types of backup. At present, the physical backup of the KES database in the physical environment is performed through the scheduled task crontab tool at the operating system level. This results in the scheduling status of the physical backup in the container cloud scenario not being directly reflected in the status of the Pod, and the scheduling cycle is not easy to automatically modify and display on the container cloud platform.

[0003] Therefore, the traditional physical backup method of KES database cannot realize the real-time display of physical backup status. Summary of the invention

[0004] The embodiments of the present application provide a method, apparatus, device, medium and product for physical backup of a database, which are used to achieve the effect of obtaining the physical backup status in real time.

[0005] In a first aspect, an embodiment of the present application provides a method for physical backup of a database, comprising: calling cronjob to create a physical backup task, so that cronjob creates an execution task at a corresponding backup time according to the physical backup task; calling an execution container according to the execution task created by cronjob; calling sys_rman under the execution container to execute the backup task on the database; and sending the execution status information of the backup task to the physical backup state; obtaining the execution status information of the backup task from the physical backup state, and displaying the execution status information.

[0006] In a possible implementation, before calling cronjob to create a scheduled physical backup task, the following steps are included: declaring backup requirement information in a physical backup custom resource, where the backup requirement information includes a backup type and a backup cycle, and the backup cycle is used to represent the backup time.

[0007] In a possible implementation, before calling sys_rman in the execution container to perform the database backup task, the process further includes: determining whether the node status of the database is normal; calling sys_rman in the execution container to perform the database backup task specifically includes:

[0008] If the node status is normal, sys_rman is called in the execution container to perform the database backup task.

[0009] In a possible implementation, the execution status information of the task is sent to the physical backup state, including: if the node status is abnormal, canceling the backup task, sending the execution status information indicating the backup failure to the physical backup state, and sending the node abnormality information to the physical backup log.

[0010] In one possible implementation, if the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log, including: if the node status is abnormal, the backup task is canceled, and the cronjob is called to rebuild the task; if the task reconstruction fails, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log.

[0011] In a possible implementation, before calling cronjob to rebuild the execution task, it also includes: determining whether the cumulative number of reconstruction times of the execution task has reached a preset maximum number of reconstruction times; calling cronjob to recreate the execution task, specifically including: if the cumulative number of reconstruction times has not reached the maximum number of retries, calling cronjob to rebuild the execution task.

[0012] In a possible implementation, after determining whether the cumulative number of reconstruction times for executing the task has reached a preset maximum number of reconstruction times, the method further includes: if the cumulative number of reconstruction times has reached a maximum number of retries, determining that the reconstruction of the execution task has failed.

[0013] In a possible implementation, the execution status information of the task is sent to the physical backup state, specifically including: obtaining the exit code generated by sys_rman after the backup task is executed; if the exit code indicates that the task is executed successfully, the execution status information indicating the successful execution is sent to the physical backup state; if the exit code indicates that the task is executed unsuccessfully, the execution status information indicating the failed execution is sent to the physical backup state.

[0014] In one possible implementation, if the exit code indicates that the task is executed successfully, the execution status information indicating the successful execution is stored in the physical backup state, specifically including: if the exit code indicates that the task is executed successfully, checking whether the backup set information is correct; wherein the backup set information includes the execution result of the backup task; if the backup set information is correct, sending the execution status information indicating the successful execution to the physical backup state.

[0015] In a possible implementation, if the backup set information is erroneous, execution status information indicating execution failure is sent to the physical backup state, and backup error information is sent to the physical backup log.

[0016] In a possible implementation, the execution log of the backup task is sent to the physical backup log in real time.

[0017] In a second aspect, an embodiment of the present application provides a device for physical backup of a database, including: a creation module, used to call cronjob to create a physical backup task, the physical backup task is to back up the database at the backup time; cronjob is used to create a job based on the physical backup task when the backup time arrives; an execution module, used to call an execution container according to the job; calling sys_rman in the execution container to perform the backup task on the database; and sending the execution status information of the task to the physical backup state; a display module, used to obtain the execution status information of the physical backup task from the physical backup state, and display the execution status information.

[0018] In a third aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;

[0019] Memory stores computer-executable instructions;

[0020] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0021] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0022] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0023] The embodiment of the present application provides a method, electronic device, storage medium and program product for physical backup of a database. First, a cronjob is called to create a physical backup task, so that the cronjob creates an execution task at the corresponding backup time according to the physical backup task; an execution container is called according to the execution task created by the cronjob; sys_rman is called under the execution container to execute the backup task on the database; and the execution status information of the backup task is sent to the physical backup state; the execution status information of the backup task is obtained from the physical backup state, and the execution status information is displayed. This solution implements real-time monitoring of the execution status of the physical backup task by calling the cronjob tool to schedule the scheduled backup task and sending the execution status information of the backup task to the physical backup state. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0025] Figure 1 A schematic diagram of a method for physical backup of a database provided in this application Figure 1 ;

[0026] Figure 2 A schematic diagram of a method for physical backup of a database provided in this application Figure 2 ;

[0027] Figure 3 A schematic diagram of a method for physical backup of a database provided in this application Figure 3 ;

[0028] Figure 4 A schematic diagram of the structure of a device for physical backup of a database provided by the present application;

[0029] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0030] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0031] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0032] As the complexity of computer systems and the amount of data increase, modern equipment software supports multiple types of backup. At present, the physical backup of the KES database in the physical environment is performed through the scheduled task crontab tool at the operating system level. This results in the scheduling status of the physical backup in the container cloud scenario not being directly reflected in the status of the Pod, and the scheduling cycle is not easy to automatically modify and display on the container cloud platform.

[0033] Therefore, the traditional physical backup method of KES database cannot realize the real-time display of physical backup status.

[0034] The present application provides a method for physical backup of a database, which first calls cronjob to create a physical backup task, so that cronjob creates an execution task at the corresponding backup time according to the physical backup task; calls an execution container according to the execution task created by cronjob; calls sys_rman under the execution container to perform a backup task on the database; and sends the execution status information of the backup task to the physical backup state; obtains the execution status information of the backup task from the physical backup state, and displays the execution status information. This solution implements real-time monitoring of the execution status of the physical backup task by calling the cronjob tool to schedule the scheduled backup task and sending the execution status information of the backup task to the physical backup state.

[0035] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0036] Embodiment 1

[0037] Figure 1 A schematic diagram of a method for physical backup of a database provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0038] S101, calling cronjob to create a physical backup task, so that cronjob creates and executes a task at a corresponding backup time according to the physical backup task.

[0039] S102, calling an execution container according to the execution task created by cronjob; calling sys_rman under the execution container to execute a backup task on the database; and sending the execution status information of the backup task to the physical backup state.

[0040] S103, acquiring execution status information of the backup task from the physical backup status, and displaying the execution status information.

[0041] Among them, CronJob is like a timer in Kubernetes (K8s), which allows users to automatically trigger the execution of tasks in the container at a specified time or at a certain time interval. In a containerized environment, CronJob can automatically create and manage Pods (execution containers, the smallest deployable and manageable computing units in Kubernetes) that execute tasks. For example, a data processing application may need to automatically run a data cleaning script at 2 a.m. every day. This scheduled task can be easily implemented through CronJob without manual triggering.

[0042] sys_rman is a tool that encapsulates the RMAN backup and recovery functions and is used to automate database backup and recovery tasks. In a database management system, RMAN (Recovery Manager) usually refers to the Recovery Manager, which is a tool used to back up, recover, and maintain databases.

[0043] In addition, when the task is completed, its related resources will be cleaned up (depending on the configuration) and wait for the next CronJob to be triggered. This can avoid waste of resources and ensure that cluster resources can be used efficiently. For example, if the task is a one-time data backup, after the backup is completed, the execution container and the resources related to the execution task can be automatically deleted until the next backup task needs to be executed and then recreated.

[0044] In actual applications, after calling CronJob to create a physical backup task, according to the schedule setting, an execution task is created after the corresponding backup time arrives, and then the execution container is called according to the execution task, and sys_rman is called under the execution container to perform the backup task on the database; and the execution status information of the backup task is sent to the physical backup state; the execution status information of the backup task is obtained from the physical backup state, and the execution status information is displayed. For example, according to the schedule, when the set time point is reached, CronJob will create a Job (execution task), and this Job will find a suitable node in the cluster to start a Pod containing the specified task container, and then call sys_rman in this container to start the task.

[0045] By calling the cronjob tool to schedule the scheduled backup task and sending the execution status information of the backup task to the physical backup status, real-time monitoring of the execution status of the physical backup task is achieved.

[0046] In some examples, before calling cronjob to create a scheduled physical backup task, include:

[0047] Declare backup requirement information in the physical backup custom resource. The backup requirement information includes the backup type and backup cycle. The backup cycle is used to represent the backup time.

[0048] Among them, the physical backup custom resource (physical backup CR) integrates the related operations and configurations of physical backup into the container cloud environment through custom resources. It is a custom resource used to manage physical backup tasks in the container orchestration system. This resource contains backup demand information; backup types include full backup, incremental backup, and differential backup.

[0049] Specifically, full backup: is a complete backup of the entire database (including all data, indexes, configurations, etc.). It is like taking a complete "snapshot" of the database at a certain moment, and the amount of data backed up is the entire content of the database at that time. Incremental backup: is a backup based on data that has changed since the last backup (which can be a full backup or an incremental backup). For example, after the first full backup, only newly inserted, modified, or deleted data will be recorded in the incremental backup. This backup method has a relatively small amount of data and may be faster. Differential backup: is a backup of all data that has changed since the last full backup. Unlike incremental backup, differential backup records all changes relative to the full backup, rather than changes between each backup, so its data volume is usually larger than incremental backup, but smaller than full backup.

[0050] Declaring backup requirements in the physical backup custom resource not only helps to accurately specify the data range that needs to be backed up, but also automatically triggers and executes backup tasks based on these requirements without manual intervention, greatly improving the efficiency and timeliness of backup. In addition, by declaring different types of backup cycle information in the physical backup CR, a flexible backup scheduling strategy can be implemented to meet the backup requirements in different business scenarios.

[0051] In some examples, before calling sys_rman in the execution container to perform a database backup task, the following steps are also included:

[0052] Determine whether the database node status is normal;

[0053] Call sys_rman in the execution container to perform the database backup task, including:

[0054] If the node status is normal, sys_rman is called under the execution container to perform the database backup task.

[0055] Among them, verifying whether the node status of the database is normal mainly checks the complete status of the database at a certain moment, including the integrity and consistency of the data and various operating states of the nodes (such as storage status, network status, etc.).

[0056] In actual applications, the node status of the database is mainly checked including network connection status, service operation status, database function status, and resource usage status. By checking before the backup task is executed, it can not only ensure the integrity and accuracy of the backup data, but also improve the success rate of the backup task.

[0057] In some examples, sending the execution status information of the backup task to the physical backup state includes:

[0058] If the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log.

[0059] Among them, abnormal node status includes that the node is unreachable or the database process is not running normally; specifically, node unreachable means that in the current network environment, it is impossible to communicate with the node through a normal network connection method; the database is not running normally means that the process has not been started, the process has terminated unexpectedly, or the process is in an abnormal state.

[0060] In actual applications, if a node is in an abnormal state, such as experiencing hardware failure, software crash, or data file corruption, physical backup at this time may result in incomplete or lost backup data; for example, when a database storage system has bad sectors, incorrect data may be read during the backup process and saved to the backup file. Therefore, when a node is in an abnormal state, the backup task needs to be canceled.

[0061] In addition, the database service process crashes or the network connection is interrupted, and the backup operation cannot be completed. When the node is abnormal, the backup task is canceled, and the execution status information of the backup failure is sent to the physical backup status display and the physical backup log to remind the administrator to discover the backup failure in time and perform corresponding repairs according to the specific reasons in the physical log.

[0062] In some examples, if the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log, including:

[0063] If the node status is abnormal, the backup task will be canceled and the cronjob will be called to re-execute the task;

[0064] If the task reconstruction fails, the execution status information indicating the backup failure is sent to the physical backup state, and the node abnormality information is sent to the physical backup log.

[0065] If a node anomaly is found, cancel the backup task; then rebuild the task again based on the physical backup task. In an automated backup environment, you can use pre-written scripts or monitoring systems to detect node anomalies and automatically cancel backup tasks. For example, you can check the key status indicators of the database node (such as whether the process is running, whether the port is open, etc.) in the script. If an anomaly is found, use the command line parameters or API provided by the backup tool to cancel the ongoing backup task. Canceling the backup task in an abnormal state and re-executing it can reduce the scope of the failure during the backup process.

[0066] In some examples, before calling the cronjob to rebuild the execution task, it also includes:

[0067] Determine whether the cumulative number of reconstructions for executing the task has reached the preset maximum number of reconstructions;

[0068] Call cronjob to recreate the execution task, including:

[0069] If the cumulative number of rebuilds does not reach the maximum number of retries, the cronjob is called to rebuild the execution task.

[0070] The maximum number of reconstructions can be preset according to demand. When the cumulative number of reconstructions for the execution task does not reach the maximum number of reconstructions, the task is rebuilt and the physical backup task can be continued when the node returns to normal. For example, the maximum number of reconstructions is preset to 100. When the task is rebuilt for the 100th time, the node returns to normal and the physical backup task can be continued. By setting the maximum number of reconstructions in advance, it is possible to avoid wasting resources due to infinite loop reconstructions.

[0071] In some examples, after determining whether the cumulative number of reconstruction times of executing the task reaches a preset maximum number of reconstruction times, the method further includes:

[0072] If the cumulative number of reconstruction times reaches the maximum number of retries, it is determined that the task reconstruction has failed.

[0073] By presetting the maximum number of reconstructions, when the number is reached, the administrator can be prompted to review the backup strategy. For example, it may be necessary to adjust the backup time window and select a period with lower system load to perform backups to reduce conflicts between backup tasks and other tasks; or change the backup method from full backup to incremental backup to reduce the complexity and resource requirements of each backup, thereby increasing the backup success rate.

[0074] In addition, when the maximum number of rebuilds for a backup task is reached, this may indicate that the system needs more comprehensive maintenance. For example, it may be necessary to inspect and repair the hardware of the node, update patches for the operating system or database software, or re-plan the network topology to improve the operating environment of the backup task. Adjusting the system maintenance plan based on the triggering conditions of the maximum number of rebuilds can more effectively solve the underlying problems that cause backup task failures.

[0075] In some examples, Figure 2 A schematic diagram of a method for physical backup of a database provided in this application Figure 2 ,like Figure 2 As shown, the execution status information of the task is sent to the physical backup state, including:

[0076] S201, obtaining the exit code generated by sys_rman after the backup task is completed.

[0077] S202: If the exit code indicates that the task is successfully executed, the execution status information indicating the successful execution is sent to the physical backup state.

[0078] S203: If the exit code indicates that the task execution has failed, the execution status information indicating the execution failure is sent to the physical backup state.

[0079] Among them, the exit code is an integer value returned by the program to the operating system (or the parent process that called it). When a program is executed, it will inform the operating system or the parent process of its execution status through this exit code. The exit code is a simple communication mechanism used to indicate whether the program ended normally or abnormally due to some error. Returning an exit code of 0 indicates successful execution; returning an exit code other than 0 indicates failure. Different non-zero values ​​indicate different types of failures. For example, a command syntax error is defined as exit code 1, a missing parameter is defined as exit code 2, a database connection timeout returns an exit code of 3, and a file system permission problem returns an exit code of 4.

[0080] Specifically, when sys_rman is called and all steps of the backup task are successfully completed, it will return an exit code indicating success, usually 0, according to the normal process of program design. This means that the backup tool can correctly read the data source (such as database files, storage volumes, etc.), successfully transfer the data to the backup target location (such as tapes, another storage device, etc.), and there are no data inconsistencies, errors, or abnormal interruptions during the backup process. When calling sys_rman, if the command syntax entered by the user is incorrect or the necessary parameters are missing, the backup tool will discover these problems at the command parsing stage. According to its internal error handling mechanism, it will return a non-0 exit code.

[0081] After obtaining the exit code, the exit code will be sent to the physical backup status for display, indicating execution failure or success, so that the administrator can obtain the physical backup status in time.

[0082] In some examples, if the exit code indicates that the task is successfully executed, the execution status information indicating the successful execution is stored in the physical backup state, specifically including:

[0083] If the exit code indicates that the task is successfully executed, check whether the backup set information is correct; the backup set information includes the execution result of the backup task;

[0084] If the backup set information is correct, the execution status information indicating successful execution is sent to the physical backup state.

[0085] Among them, a backup set refers to a collection of physical data to be backed up (such as database files, files in storage volumes, etc.) combined according to certain rules; backup set information includes backup data details (data source information, data range and content), backup attribute related information (backup timestamp, backup type identifier), data size and file quantity.

[0086] Specifically, check whether the backup set information is correct, mainly including data source accuracy, backup attribute matching, and data integrity.

[0087] Source accuracy includes backup source identification and data scope. Confirm whether the source claimed by the backup set is consistent with the source specified by the actual backup operation. For example, in a database backup, check whether the database name, instance number (if any), and IP address of the server recorded in the backup set information completely match the actual backed up database. For a full backup, verify whether the backup set contains all the data of the backup source.

[0088] Backup attribute matching includes backup timestamp and backup type. Check whether the backup timestamp matches the execution time range of the backup task; the backup timestamp should accurately record the start and end time of the backup, and this time range should match the actual start and completion time of the backup task. Ensure that the backup type (full backup, incremental backup, or differential backup) marked in the backup set is consistent with the actual backup strategy implemented.

[0089] Data integrity mainly verifies whether the data size and number of files recorded in the backup set information are consistent with the actual backup data. If the backup set information shows that the data size is 10GB and contains 1,000 files, but the actual inspection finds that the data size is only 8GB and the number of files is 800, this indicates that the backup set may have data loss or recording errors, and further investigation is needed. This inconsistency may be caused by partial data loss during the backup process, statistical errors in the backup tool, or errors in the backup set information recording.

[0090] By checking the backup set information, you can clearly know whether a backup error occurred during the backup process and the specific cause of the error.

[0091] In some examples, if the backup set information is erroneous, execution status information indicating execution failure is sent to the physical backup state, and backup error information is sent to the physical backup log.

[0092] After discovering an error by checking the backup set information, the execution status is displayed to the physical backup status to inform the administrator, and the error information is sent to the physical table backup log for the administrator to query the cause of the error and adjust or repair the backup strategy.

[0093] In some examples, the execution log of the backup task is sent to the physical backup log in real time.

[0094] The execution log of a backup task records detailed information about various operations, events, and statuses from the start to the end of the backup task. This information includes the start time of the backup task, the data source and target location of the backup, the amount of data backed up, and errors and warnings during the backup process. Sending these execution logs to the physical backup log in real time means that while the backup task is in progress, each generated log record is immediately transmitted and stored in a log file or log system specifically used to record physical backup related information.

[0095] By sending logs in real time, administrators can check the progress of backup at any time during the execution of backup tasks. For example, they can know how much data has been backed up, whether errors have occurred, etc. It is like observing the running status of the backup task through a real-time "window", which makes it easier to find problems and take measures in time.

[0096] Figure 3 A schematic diagram of a method for physical backup of a database provided in this application Figure 3 ,like Figure 3As shown, in actual application, firstly, the backup requirement is declared in the physical backup CR, and cronjob is called to create a scheduled backup task according to the backup requirement; when the backup time is not reached, it is in a dormant state, and when the backup time is reached, an execution task is created, and the execution container is called and started; then the node status is judged, and if the status is normal, sys_rman is called to perform physical backup; after the backup, the backup set information is checked, and if the backup set information is correct, the execution is successful and displayed on the physical backup status; if the node is abnormal, the execution task is rebuilt within the maximum reconstruction times, and the node recovers to normal within the maximum reconstruction times, and the backup task can be executed; if the maximum reconstruction times are reached, the execution fails, and the failure status is displayed and sent to the physical backup log; after the backup is completed, the checked backup set information is wrong, and similarly, the execution task is rebuilt within the maximum reconstruction times, and the execution fails when the maximum reconstruction times are reached.

[0097] Embodiment 2

[0098] Figure 4 A schematic diagram of a physical backup device for a database provided in this application, such as Figure 4 As shown, including:

[0099] A creation module 11 is used to call cronjob to create a physical backup task. The physical backup task is to back up the database at the backup time. The cronjob is used to create a job based on the physical backup task when the backup time arrives.

[0100] The execution module 12 is used to call the execution container according to the job; call sys_rman in the execution container to perform the backup task on the database; and send the execution status information of the task to the physical backup state;

[0101] The display module 13 is used to obtain the execution status information of the physical backup task from the physical backup status and display the execution status information.

[0102] Among them, CronJob is like a timer in Kubernetes (K8s), which allows users to automatically trigger the execution of tasks in the container at a specified time or at a certain time interval. In a containerized environment, CronJob can automatically create and manage Pods (execution containers, the smallest deployable and manageable computing units in Kubernetes) that execute tasks. For example, a data processing application may need to automatically run a data cleaning script at 2 a.m. every day. This scheduled task can be easily implemented through CronJob without manual triggering.

[0103] sys_rman is a tool that encapsulates the RMAN backup and recovery functions and is used to automate database backup and recovery tasks. In a database management system, RMAN (Recovery Manager) usually refers to the Recovery Manager, which is a tool used to back up, recover, and maintain databases.

[0104] In addition, when the task is completed, its related resources will be cleaned up (depending on the configuration) and wait for the next CronJob to be triggered. This can avoid waste of resources and ensure that cluster resources can be used efficiently. For example, if the task is a one-time data backup, after the backup is completed, the execution container and the resources related to the execution task can be automatically deleted until the next backup task needs to be executed and then recreated.

[0105] In actual applications, after calling CronJob to create a physical backup task, according to the schedule setting, an execution task is created after the corresponding backup time arrives, and then the execution container is called according to the execution task, and sys_rman is called under the execution container to perform the backup task on the database; and the execution status information of the backup task is sent to the physical backup state; the execution status information of the backup task is obtained from the physical backup state, and the execution status information is displayed. For example, according to the schedule, when the set time point is reached, CronJob will create a Job (execution task), and this Job will find a suitable node in the cluster to start a Pod containing the specified task container, and then call sys_rman in this container to start the task.

[0106] By calling the cronjob tool to schedule the scheduled backup task and sending the execution status information of the backup task to the physical backup status, real-time monitoring of the execution status of the physical backup task is achieved.

[0107] In some examples, the creation module 11 is further configured to, before calling cronjob to create a scheduled physical backup task, include:

[0108] Declare backup requirement information in the physical backup custom resource. The backup requirement information includes the backup type and backup cycle. The backup cycle is used to represent the backup time.

[0109] Among them, the physical backup custom resource (physical backup CR) integrates the related operations and configurations of physical backup into the container cloud environment through custom resources. It is a custom resource used to manage physical backup tasks in the container orchestration system. This resource contains backup demand information; backup types include full backup, incremental backup, and differential backup.

[0110] Specifically, full backup: is a complete backup of the entire database (including all data, indexes, configurations, etc.). It is like taking a complete "snapshot" of the database at a certain moment, and the amount of data backed up is the entire content of the database at that time. Incremental backup: is a backup based on data that has changed since the last backup (which can be a full backup or an incremental backup). For example, after the first full backup, only newly inserted, modified, or deleted data will be recorded in the incremental backup. This backup method has a relatively small amount of data and may be faster. Differential backup: is a backup of all data that has changed since the last full backup. Unlike incremental backup, differential backup records all changes relative to the full backup, rather than changes between each backup, so its data volume is usually larger than incremental backup, but smaller than full backup.

[0111] Declaring backup requirements in the physical backup custom resource not only helps to accurately specify the data range that needs to be backed up, but also automatically triggers and executes backup tasks based on these requirements without manual intervention, greatly improving the efficiency and timeliness of backup. In addition, by declaring different types of backup cycle information in the physical backup CR, a flexible backup scheduling strategy can be implemented to meet the backup requirements in different business scenarios.

[0112] In some examples, the execution module 12 is further configured to, before calling sys_rman in the execution container to perform a backup task on the database, further include:

[0113] Determine whether the database node status is normal;

[0114] In the execution container, sys_rman is called to perform the backup task on the database, including:

[0115] If the node status is normal, sys_rman is called in the execution container to perform the database backup task.

[0116] Among them, verifying whether the node status of the database is normal mainly checks the complete status of the database at a certain moment, including the integrity and consistency of the data and various operating states of the nodes (such as storage status, network status, etc.).

[0117] In actual applications, the node status of the database is mainly checked including network connection status, service operation status, database function status, and resource usage status. By checking before the backup task is executed, it can not only ensure the integrity and accuracy of the backup data, but also improve the success rate of the backup task.

[0118] In some examples, the execution module 12 is further configured to send the execution status information of the backup task to the physical backup state, including:

[0119] If the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log.

[0120] Among them, abnormal node status includes that the node is unreachable or the database process is not running normally; specifically, node unreachable means that in the current network environment, it is impossible to communicate with the node through a normal network connection method; the database is not running normally means that the process has not been started, the process has terminated unexpectedly, or the process is in an abnormal state.

[0121] In actual applications, if a node is in an abnormal state, such as experiencing hardware failure, software crash, or data file corruption, physical backup at this time may result in incomplete or lost backup data; for example, when a database storage system has bad sectors, incorrect data may be read during the backup process and saved to the backup file. Therefore, when a node is in an abnormal state, the backup task needs to be canceled.

[0122] In addition, the database service process crashes or the network connection is interrupted, and the backup operation cannot be completed. When the node is abnormal, the backup task is canceled, and the execution status information of the backup failure is sent to the physical backup status display and the physical backup log to remind the administrator to discover the backup failure in time and perform corresponding repairs according to the specific reasons in the physical log.

[0123] In some examples, the execution module 12 is further used to cancel the backup task if the node status is abnormal, send the execution status information indicating the backup failure to the physical backup state, and send the node abnormality information to the physical backup log, including:

[0124] If the node status is abnormal, the backup task will be canceled and the cronjob will be called to re-execute the task;

[0125] If the task reconstruction fails, the execution status information indicating the backup failure is sent to the physical backup state, and the node abnormality information is sent to the physical backup log.

[0126] If a node anomaly is found, cancel the backup task; then rebuild the task again based on the physical backup task. In an automated backup environment, you can use pre-written scripts or monitoring systems to detect node anomalies and automatically cancel backup tasks. For example, you can check the key status indicators of the database node (such as whether the process is running, whether the port is open, etc.) in the script. If an anomaly is found, use the command line parameters or API provided by the backup tool to cancel the ongoing backup task. Canceling the backup task in an abnormal state and re-executing it can reduce the scope of the failure during the backup process.

[0127] In some examples, the creation module 11 is further used to call the cronjob to rebuild the execution task, and also includes:

[0128] Determine whether the cumulative number of reconstructions for executing the task has reached the preset maximum number of reconstructions;

[0129] Call cronjob to recreate the execution task, including:

[0130] If the cumulative number of rebuilds does not reach the maximum number of retries, the cronjob is called to rebuild the execution task.

[0131] The maximum number of reconstructions can be preset according to demand. When the cumulative number of reconstructions for the execution task does not reach the maximum number of reconstructions, the task is rebuilt and the physical backup task can be continued when the node returns to normal. For example, the maximum number of reconstructions is preset to 100. When the task is rebuilt for the 100th time, the node returns to normal and the physical backup task can be continued. By setting the maximum number of reconstructions in advance, it is possible to avoid wasting resources due to infinite loop reconstructions.

[0132] In some examples, after determining whether the cumulative number of reconstruction times of executing the task reaches a preset maximum number of reconstruction times, the method further includes:

[0133] If the cumulative number of reconstruction times reaches the maximum number of retries, it is determined that the task reconstruction has failed.

[0134] By presetting the maximum number of reconstructions, when the number is reached, the administrator can be prompted to review the backup strategy. For example, it may be necessary to adjust the backup time window and select a period with lower system load to perform backups to reduce conflicts between backup tasks and other tasks; or change the backup method from full backup to incremental backup to reduce the complexity and resource requirements of each backup, thereby increasing the backup success rate.

[0135] In addition, when the maximum number of rebuilds for a backup task is reached, this may indicate that the system needs more comprehensive maintenance. For example, it may be necessary to inspect and repair the hardware of the node, update patches for the operating system or database software, or re-plan the network topology to improve the operating environment of the backup task. Adjusting the system maintenance plan based on the triggering conditions of the maximum number of rebuilds can more effectively solve the underlying problems that cause backup task failures.

[0136] In some examples, the execution module 12 is also used to send the execution status information of the task to the physical backup state, specifically including:

[0137] Get the exit code generated by sys_rman after the backup task is completed.

[0138] If the exit code indicates that the task is successfully executed, the execution status information indicating the successful execution is sent to the physical backup state.

[0139] If the exit code indicates that the task execution failed, the execution status information indicating the execution failure is sent to the physical backup state.

[0140] Among them, the exit code is an integer value returned by the program to the operating system (or the parent process that called it). When a program is executed, it will inform the operating system or the parent process of its execution status through this exit code. The exit code is a simple communication mechanism used to indicate whether the program ended normally or abnormally due to some error. Returning an exit code of 0 indicates successful execution; returning an exit code other than 0 indicates failure. Different non-zero values ​​indicate different types of failures. For example, a command syntax error is defined as exit code 1, a missing parameter is defined as exit code 2, a database connection timeout returns an exit code of 3, and a file system permission problem returns an exit code of 4.

[0141] Specifically, when sys_rman is called and all steps of the backup task are successfully completed, it will return an exit code indicating success, usually 0, according to the normal process of program design. This means that the backup tool can correctly read the data source (such as database files, storage volumes, etc.), successfully transfer the data to the backup target location (such as tapes, another storage device, etc.), and there are no data inconsistencies, errors, or abnormal interruptions during the backup process. When calling sys_rman, if the command syntax entered by the user is incorrect or the necessary parameters are missing, the backup tool will discover these problems at the command parsing stage. According to its internal error handling mechanism, it will return a non-0 exit code.

[0142] After obtaining the exit code, the exit code will be sent to the physical backup status for display, indicating execution failure or success, so that the administrator can obtain the physical backup status in time.

[0143] In some examples, the execution module 12 is further configured to store the execution status information indicating the successful execution to the physical backup state if the exit code indicates that the task is successfully executed, specifically including:

[0144] If the exit code indicates that the task is successfully executed, check whether the backup set information is correct; the backup set information includes the execution result of the backup task;

[0145] If the backup set information is correct, the execution status information indicating successful execution is sent to the physical backup state.

[0146] Among them, a backup set refers to a collection of physical data to be backed up (such as database files, files in storage volumes, etc.) combined according to certain rules; backup set information includes backup data details (data source information, data range and content), backup attribute related information (backup timestamp, backup type identifier), data size and file quantity.

[0147] Specifically, check whether the backup set information is correct, mainly including data source accuracy, backup attribute matching, and data integrity.

[0148] Source accuracy includes backup source identification and data scope. Confirm whether the source claimed by the backup set is consistent with the source specified by the actual backup operation. For example, in a database backup, check whether the database name, instance number (if any), and IP address of the server recorded in the backup set information completely match the actual backed up database. For a full backup, verify whether the backup set contains all the data of the backup source.

[0149] Backup attribute matching includes backup timestamp and backup type. Check whether the backup timestamp matches the execution time range of the backup task; the backup timestamp should accurately record the start and end time of the backup, and this time range should match the actual start and completion time of the backup task. Ensure that the backup type (full backup, incremental backup, or differential backup) marked in the backup set is consistent with the actual backup strategy implemented.

[0150] Data integrity mainly verifies whether the data size and number of files recorded in the backup set information are consistent with the actual backup data. If the backup set information shows that the data size is 10GB and contains 1,000 files, but the actual inspection finds that the data size is only 8GB and the number of files is 800, this indicates that the backup set may have data loss or recording errors, and further investigation is needed. This inconsistency may be caused by partial data loss during the backup process, statistical errors in the backup tool, or errors in the backup set information recording.

[0151] By checking the backup set information, you can clearly know whether a backup error occurred during the backup process and the specific cause of the error.

[0152] In some examples, the execution module 12 is further configured to send execution status information indicating execution failure to the physical backup state if the backup set information is erroneous, and send backup error information to the physical backup log.

[0153] After discovering an error by checking the backup set information, the execution status is displayed to the physical backup status to inform the administrator, and the error information is sent to the physical table backup log for the administrator to query the cause of the error and adjust or repair the backup strategy.

[0154] In some examples, the execution module 12 is further configured to send the execution log of the backup task to the physical backup log in real time.

[0155] The execution log of a backup task records detailed information about various operations, events, and statuses from the start to the end of the backup task. This information includes the start time of the backup task, the data source and target location of the backup, the amount of data backed up, and errors and warnings during the backup process. Sending these execution logs to the physical backup log in real time means that while the backup task is in progress, each generated log record is immediately transmitted and stored in a log file or log system specifically used to record physical backup related information.

[0156] By sending logs in real time, administrators can check the progress of backup at any time during the execution of backup tasks. For example, they can know how much data has been backed up, whether errors have occurred, etc. It is like observing the running status of the backup task through a real-time "window", which makes it easier to find problems and take measures in time.

[0157] The device for physical backup of a database provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and are not described in detail in this embodiment.

[0158] Figure 5 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes: at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected via a bus 504.

[0159] In a specific implementation process, at least one processor 501 executes the computer-executable instructions stored in the memory 502, so that at least one processor 501 executes the above method.

[0160] The specific implementation process of the processor 501 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0161] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0162] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0163] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0164] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0165] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0166] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0167] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for physical backup of a database, characterized in that: include: Calling cronjob to create a physical backup task, so that the cronjob creates an execution task at a corresponding backup time according to the physical backup task; According to the execution task created by the cronjob, an execution container is called; under the execution container, sys_rman is called to perform a backup task on the database; and the execution status information of the backup task is sent to the physical backup state; The execution status information of the backup task is acquired from the physical backup status, and the execution status information is displayed.

2. The method according to claim 1, characterized in that Before calling cronjob to create a scheduled physical backup task, the following steps are included: The backup requirement information is declared in the physical backup custom resource, where the backup requirement information includes a backup type and a backup cycle, and the backup cycle is used to represent the backup time.

3. The method according to claim 1, characterized in that Before calling sys_rman in the execution container to perform the database backup task, the method further includes: Determine whether the node status of the database is normal; The calling of sys_rman under the execution container to perform the backup task on the database specifically includes: If the node status is normal, sys_rman is called in the execution container to perform the backup task on the database.

4. The method according to claim 3, characterized in that The sending the execution status information of the backup task to the physical backup state includes: If the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log.

5. The method according to claim 4, characterized in that If the node status is abnormal, the backup task is canceled, the execution status information indicating the backup failure is sent to the physical backup status, and the node abnormality information is sent to the physical backup log, including: If the node status is abnormal, the backup task is canceled and the cronjob is called to re-execute the task; If the task reconstruction fails, the execution status information indicating the backup failure is sent to the physical backup state, and the node abnormality information is sent to the physical backup log.

6. The method according to claim 5, characterized in that Before calling the cronjob to re-execute the task, the method further includes: Determine whether the cumulative number of reconstructions for executing the task has reached the preset maximum number of reconstructions; The calling of the cronjob to recreate the execution task specifically includes: If the cumulative number of reconstruction times does not reach the maximum number of retries, the cronjob is called to rebuild the execution task.

7. The method according to claim 6, characterized in that After determining whether the cumulative number of reconstruction times of executing the task has reached the preset maximum number of reconstruction times, the method further includes: If the cumulative number of reconstruction times reaches the maximum number of retries, it is determined that the task reconstruction has failed.

8. The method according to claim 1, characterized in that The execution status information of the task is sent to the physical backup state, specifically including: Obtain the exit code generated by the sys_rman after the backup task is completed; If the exit code indicates that the task is successfully executed, the execution status information indicating the successful execution is sent to the physical backup state; If the exit code indicates that the task execution failed, the execution status information indicating the execution failure is sent to the physical backup state.

9. The method according to claim 8, characterized in that If the exit code indicates that the task is successfully executed, then the execution status information indicating the successful execution is stored in the physical backup state, specifically including: If the exit code indicates that the task is successfully executed, check whether the backup set information is correct; wherein the backup set information includes the execution result of the backup task; If the backup set information is correct, the execution status information indicating successful execution is sent to the physical backup state.

10. The method according to claim 9, characterized in that The method further comprises: If the backup set information is wrong, the execution status information indicating the execution failure is sent to the physical backup state, and the backup error information is sent to the physical backup log.

11. The method according to any one of claims 1 to 10, characterized in that: The method further comprises: The execution log of the backup task is sent to the physical backup log in real time.

12. A device for physical backup of a database, characterized in that: include: A creation module is used to call a cronjob to create a physical backup task, wherein the physical backup task is to back up the database at the backup time; the cronjob is used to create a job based on the physical backup task when the backup time arrives; An execution module is used to call an execution container according to the job; call sys_rman in the execution container to perform a backup task on the database; and send the execution status information of the task to the physical backup state; A display module is used to obtain the execution status information of the physical backup task from the physical backup status and display the execution status information.

13. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 11 when executed by a processor.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 11 when being executed by a processor.

Images