CN112749043A - Database disaster recovery method, system, device and medium - Google Patents

Database disaster recovery method, system, device and medium Download PDF

Info

Publication number
CN112749043A
CN112749043A CN202110057634.0A CN202110057634A CN112749043A CN 112749043 A CN112749043 A CN 112749043A CN 202110057634 A CN202110057634 A CN 202110057634A CN 112749043 A CN112749043 A CN 112749043A
Authority
CN
China
Prior art keywords
module
database
login information
field value
database table
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110057634.0A
Other languages
Chinese (zh)
Other versions
CN112749043B (en
Inventor
张波业
马豹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202110057634.0A priority Critical patent/CN112749043B/en
Publication of CN112749043A publication Critical patent/CN112749043A/en
Application granted granted Critical
Publication of CN112749043B publication Critical patent/CN112749043B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1435Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1464Management of the backup or restore process for networked environments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a method, a system, equipment and a storage medium for database disaster recovery, wherein the method comprises the following steps: circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database; screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information; judging whether the deployment, the configuration modification or the upgrade is abnormal or not; and in response to the occurrence of an exception during the execution of the deployment, the modification of the configuration or the upgrade, determining the cause of the exception and recovering through the backed-up database table according to the cause. The method is mainly oriented to core backup and recovery operation of the module database table, has certain independence, can recover in time when the multi-architecture cloud platform is abnormal, and improves the robustness and reliability of the cloud platform.

Description

Database disaster recovery method, system, device and medium
Technical Field
The present invention relates to the field of databases, and more particularly, to a method, a system, a computer device, and a readable medium for database disaster recovery.
Background
The database service is used as a very important ring of the cloud platform, records service information about all relevant function modules of the cloud platform, and once an exception occurs, operation failures such as deployment, upgrade, configuration modification and the like can be caused, and from the practical viewpoint, failure scenes are mainly focused on the following situations:
1) when the original service container module fails, the original service container module needs to be redeployed (deployed) after being deleted;
2) deploying (deploy) a new function service module;
3) single, multiple and full scale upgrades (upsgrades) for cloud platform upgrades;
4) performing a modify configuration (reconfigure) operation on the single or multiple modules;
in the above scenarios, there may be scenarios depending on operation services related to the operation database, such as a scenario of upgrading a circuit, where the circuit service corresponds to a service table in the circuit, and the table includes information such as availability _ zone (available domain), object _ current _ version (version number used by the circuit service), host (host name), etc. currently used by the circuit, because each module code version needs to have corresponding database table version information, some values are fixed, and if changed, operations on the database in the upgrading process will inevitably report an error, thereby causing upgrading failure. The recovery maintenance mechanism of the existing tool for the database is still incomplete, and no special tool is currently implemented for the disaster recovery maintenance tool of the database table operation level.
Disclosure of Invention
In view of this, an object of the embodiments of the present invention is to provide a method, a system, a computer device, and a computer-readable storage medium for database disaster recovery, which are mainly oriented to core backup and recovery operations of a module database table, have a certain independence, solve the problem of failed execution of operations such as deployment, configuration modification, and upgrade of a multi-architecture cloud platform due to abnormal operation of a database in the deployment, configuration modification, and upgrade processes, and improve the robustness and reliability of the cloud platform.
Based on the above object, an aspect of the embodiments of the present invention provides a database disaster recovery method, including the following steps: circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database; screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information; judging whether the deployment, the configuration modification or the upgrade is abnormal or not; and responding to the occurrence of an exception when deployment, configuration modification or upgrading is executed, determining the reason of the exception and recovering through the backed-up database table according to the reason.
In some embodiments, the method further comprises: comparing the acquired login information with preset and stored basic login information; and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
In some embodiments, the reading the file corresponding to the module name to obtain the login information of each database includes: presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
In some embodiments, the determining a cause of the abnormality and the restoring via the backup file according to the cause includes: importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and in response to the field value of the temporary file not matching the field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
On the other hand, the embodiment of the invention also provides a database disaster recovery system, which comprises: the acquisition module is configured for circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database; the screening module is configured to screen the database table to determine the database table to be backed up, and back up the database table to be backed up according to the login information; the judging module is configured to judge whether the exception occurs when the deployment, the configuration modification or the upgrade is executed; and the recovery module is configured to determine the reason of the abnormality and recover the abnormality through the backed-up database table according to the reason in response to the occurrence of the abnormality during deployment, configuration modification or upgrading.
In some embodiments, the system further comprises a comparison module configured to: comparing the acquired login information with preset and stored basic login information; and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
In some embodiments, the obtaining module is configured to: presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
In some embodiments, the recovery module is configured to: importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and in response to the field value of the temporary file not matching the field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
In another aspect of the embodiments of the present invention, there is also provided a computer device, including: at least one processor; and a memory storing computer instructions executable on the processor, the instructions when executed by the processor implementing the steps of the method as above.
In a further aspect of the embodiments of the present invention, a computer-readable storage medium is also provided, in which a computer program for implementing the above method steps is stored when the computer program is executed by a processor.
The invention has the following beneficial technical effects: the core backup and recovery operation mainly oriented to the module database table has certain independence, solves the problem of failed execution of operations such as deployment, configuration modification and upgrade caused by abnormal operation of the database in the deployment, configuration modification and upgrade processes of the multi-architecture cloud platform, and improves the robustness and reliability of the cloud platform.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by using the drawings without creative efforts.
Fig. 1 is a schematic diagram of an embodiment of a database disaster recovery method provided in the present invention;
fig. 2 is a schematic hardware structure diagram of an embodiment of a database disaster recovery computer device provided in the present invention;
fig. 3 is a schematic diagram of an embodiment of a computer storage medium for database disaster recovery according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the following embodiments of the present invention are described in further detail with reference to the accompanying drawings.
It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are used for distinguishing two entities with the same name but different names or different parameters, and it should be noted that "first" and "second" are merely for convenience of description and should not be construed as limitations of the embodiments of the present invention, and they are not described in any more detail in the following embodiments.
In view of the foregoing, a first aspect of the embodiments of the present invention provides an embodiment of a method for database disaster recovery. Fig. 1 is a schematic diagram illustrating an embodiment of a database disaster recovery method provided by the present invention. As shown in fig. 1, the embodiment of the present invention includes the following steps:
s1, circularly and sequentially logging in the remote node, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database;
s2, screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information;
s3, judging whether the deployment, the configuration modification or the upgrade is abnormal; and
and S4, responding to the abnormity when the deployment, the configuration modification or the upgrade is executed, determining the reason of the abnormity and recovering through the backed up database table according to the reason.
The embodiment of the invention provides a systematic design mechanism of an open multi-architecture cloud platform database disaster recovery tool set, which is mainly oriented to core backup and recovery operations of a module database table, has certain independence, solves the problem of failed execution of operations such as deployment, configuration modification and upgrade of a multi-architecture cloud platform due to abnormal operation of the database in the processes of deployment, configuration modification and upgrade, and improves the robustness and reliability of the cloud platform; the embodiment of the invention comprehensively uses a module database login information acquisition tool A, a module database table query tool B, a module database table backup screening list tool C, a module database table backup tool D and a module database table backup recovery tool E, each tool module has independence and detachability and certain logic correlation, and forms a complete database disaster recovery tool set system.
And (3) acquiring a database login mode and a password by using a module database login information acquisition tool A and storing the database login mode and the password as a local file. Firstly, checking whether a database storage directory exists, and if the database storage directory does not exist, establishing: mkdir/tmp/module _ database _ save _ direction (this is only an example and not a limitation); if the database save directory exists, the method continues to judge whether a login information file module _ database _ login _ info (also exemplified here) exists, if not, vi, vim or other methods are carried out to create the file, and if so, the subsequent steps are continued.
And the execution cycle sequentially logs in the remote nodes, sequentially reads the module names in the module service configuration file directory of the current remote node, and reads files corresponding to the module names to acquire the login information of each database. In this embodiment, the method includes an outer loop for logging in each node, and an inner loop for acquiring all database login information in one node. Specifically, the outer loop logic implementation method comprises the following steps: reading information configuration files of a cluster host of a current node (generally a database service node or a control node) of a cloud platform, wherein the number of platform nodes is large, particularly production environment, executing circulation and sequentially logging in a remote node in combination with hosts files, and then switching to a module service (module) configuration file directory. The internal circulation logic implementation method comprises the following steps: under the directory of the current node module service (module) configuration file, the following loop logic is executed: and sequentially reading the module _ name and switching to a specified service directory, scanning and reading files, extracting information about database (database) registration in the configuration file, and marking the module name with tag and recording the module name in a registration information file for storage.
In some embodiments, the reading the file corresponding to the module name to obtain the login information of each database includes: presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file. The method for extracting the database login information comprises the following steps: firstly, writing an information matching paradigm, then reading a configuration file, extracting definition information of a database (database) segment, and following a format: module name (module _ name) -password (password) and then saved to the login information file.
In some embodiments, the method further comprises: comparing the acquired login information with preset and stored basic login information; and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information. Before the definition information of the database segment is stored, whether the module to be stored and the database login information exist at present is judged, if yes, whether the extracted password is consistent with the password of the specified module in the file is judged, if not, replacement updating is carried out, and if not, the module to be stored and the database login information do not exist, and the module to be stored and the database login information are directly stored.
The cloud platform is generally a multi-node, and the same functional module service may be deployed on a plurality of nodes, so when the remote node is stored in the database information record storage node, the following processing needs to be performed: comparing the module and the database login information transmitted by the node with the existing information stored in the database login information file, if the module and the database login information are consistent, directly jumping out of the loop, executing the next loop, and if the module and the database login information are inconsistent, respectively performing database testability login by using the two acquired passwords and returning an information prompt indicating whether normal login can be performed or not (because the databases are various, the databases have certain open source characteristics, and only a corresponding database login test command needs to be packaged), and finally storing the password information capable of performing normal login. The implementation mode of transmitting data information from a remote node is not unique, and the method is open, because a three-party telnet tool used by a cloud platform may not be unique, and only related commands need to be packaged, for example, as follows: for example, if the database information saving node is a and the remote node is b, if we want to save a module nova _ api database login information into the/tmp/module _ database _ save _ direction/module _ database _ location _ info of the a node, the obtained information of the b node may be saved in a temporary file nova _ api _ database _ info first and then transmitted into the node a, the module _ database _ location _ info and the nova _ api _ database _ info are read, and the database information about the nova _ api is compared, so that the transmission and comparison of data are realized.
And querying the database table to be backed up by using a module database table query tool B. In view of the fact that the number of cloud platform modules is large, generally, a plurality of database tables exist in each module, some tables are updated in real time, such as resource tables, and the operation is frequent, and the influence of such tables on deployment (deployment), configuration modification (reconfiguration), and upgrade (upgrade) may be small, so that targeted and selective backup is required for such tables during backup, and therefore, query and record of the database tables of each module need to be performed in advance. The logic of the implementation method comprises the following steps: reading database login information about a module in a login information file, encapsulating a command, logging, inquiring and storing the command in a/tmp/module _ table _ info temporary file, wherein the encapsulation command is implemented as follows: 1) entering a data base container by the docker exec; 2) mysql-u < module _ name > -p < module _ password > -D < module _ database _ name > >/tmp/module _ table _ info < < EOF; use module _ database _ name; show tables; EOF.
And screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information. And screening the database table to be backed up by using the module database table backup screening list tool C. And determining the type of the module database table (module _ table _ name) needing to be backed up according to the/tmp/module _ table _ info table information, and deleting the redundant table name by using a tool if the table which does not need to be backed up exists. The logic of the implementation method comprises the following steps: inputting parameters of delete (delete), module name (module _ name) and table (module _ table _ name), starting program execution, acquiring parameters (supporting one or more table parameter names), reading/tmp/module _ table _ info file, executing circulation, matching and judging the acquired parameter names with the table names in the module _ table _ info file, executing delete operation, completing circulation, wherein the number and types of the tables stored in the module _ table _ info file are the module table (module _ table _ name) to be backed up finally.
And backing up the database table to be backed up by using the module database table backup tool D. The backup operation is started in connection with the table saved in the module _ table _ info file determined by tool C. The logic of the implementation method comprises the following steps: executing a program, reading a module _ table _ info file, starting circulation, encapsulating a database table backup command in advance, judging whether a/tmp/module _ database _ table _ backup (for avoiding confusion, creating and saving a directory by modules) directory exists, backing up all tables in the module _ table _ info file in sequence if the directory exists, creating if the directory does not exist, and then saving;
and judging whether the exception occurs when the deployment, the configuration modification or the upgrade is executed. And in response to the occurrence of an exception during the execution of deployment, configuration modification or upgrade, determining the reason of the exception and recovering through the backup file according to the reason. When deployment (deployment), configuration modification (reconfigure) or upgrade (upgrade) is executed (a single module or a plurality of modules are supported in three cases), whether database-related operation abnormity occurs or not is observed and judged, if the abnormity occurs, a tool E is used, and if the abnormity does not occur, the operation is ended (remarks: deployment, configuration modification or upgrade, from the production practice analysis, the data base is identical in nature and is caused by certain unchangeable operation).
In some embodiments, the determining a cause of the abnormality and the restoring via the backup file according to the cause includes: importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and in response to the field value of the temporary file not matching the field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
And executing the backup recovery operation of the database table by using the module database table backup recovery tool E. The logic of the implementation method comprises the following steps: inputting parameters: recovery operation (recovery), module name (if null, all modules are to perform scan recovery operation < all _ module > by default, and if single or multiple, corresponding recovery operation is performed), recovery operation is performed: first scan/tmp/module _ table _ info file (possibly more than one), execute loop operation, mainly for 5 cases:
1) the field values are modified: respectively reading table name information in a specified module _ table _ info file, logging in a module database (module _ database _ name), importing a backed-up database table into the specified module database (module _ database _ name) in a temporary tmp _ module _ table _ name mode, then performing loop detection comparison, comparing field values of the database table module _ table _ name and the tmp _ module _ table _ name, if no match is found, extracting a field value in the tmp _ module _ table _ name, updating and replacing the field value into a field value corresponding to the data module _ table _ name of the specified module (module _ name), and directly displaying normal (normal) skipping until a loop is completed;
2) field value deletion: respectively reading table name information in a specified module _ table _ info file, logging in a module database (module _ database _ name), importing a backed-up database table into the specified module database (module _ database _ name) in a temporary tmp _ module _ table _ name mode, then performing cyclic detection comparison, comparing field values of the database table module _ table _ name and the tmp _ module _ table _ name, and if the table is missing, importing a corresponding table in the tmp _ module _ table _ name into the corresponding field value of the data module _ table _ name of the specified module (module _ name) until the cycle is completed;
3) and field value addition: respectively reading table name information in a specified module _ table _ info file, logging in a module database (module _ database _ name), importing a backed-up database table into the specified module database (module _ database _ name) in a temporary tmp _ module _ table _ name mode, then performing cyclic detection comparison, comparing field values of the database table module _ table _ name and the tmp _ module _ table _ name, and deleting the field value corresponding to the database table module _ table _ name of the specified module (module _ name) if the field values are found to be more, until the cycle is completed;
4) the module database table has redundant tables: reading table name information in a module _ table _ info file of a designated module, logging in a module database (module _ database _ name), comparing tables, and if strange redundant tables exist, executing deletion operation until similar operations of other modules are circularly completed;
5) missing of the module database table: reading table name information in a module _ table _ info file of a designated module, logging in a module database (module _ database _ name), comparing tables, and if a needed table is found to be less, executing import recovery operation of the corresponding table until circulation is completed, and performing similar operation on other modules;
and after the execution of the recovery operation cycle is completed, circularly deleting the temporary database table tmp _ module _ table _ name.
It should be particularly noted that, the steps in the embodiments of the method for database disaster recovery may be intersected, replaced, added, or deleted, and therefore, these methods for database disaster recovery that are transformed by reasonable permutation and combination should also belong to the scope of the present invention, and should not limit the scope of the present invention to the embodiments.
In view of the above object, a second aspect of the embodiments of the present invention provides a database disaster recovery system, including: the acquisition module is configured for circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database; the screening module is configured to screen the database table to determine the database table to be backed up, and back up the database table to be backed up according to the login information; the judging module is configured to judge whether the exception occurs when the deployment, the configuration modification or the upgrade is executed; and the recovery module is configured to determine the reason of the abnormality and recover the abnormality through the backed-up database table according to the reason in response to the occurrence of the abnormality during deployment, configuration modification or upgrading.
In some embodiments, the system further comprises a comparison module configured to: comparing the acquired login information with preset and stored basic login information; and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
In some embodiments, the obtaining module is configured to: presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
In some embodiments, the recovery module is configured to: importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and in response to the field value of the temporary file not matching the field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
In view of the above object, a third aspect of the embodiments of the present invention provides a computer device, including: at least one processor; and a memory storing computer instructions executable on the processor, the instructions being executable by the processor to perform the steps of: s1, circularly and sequentially logging in the remote node, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database; s2, screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information; s3, judging whether the deployment, the configuration modification or the upgrade is abnormal; and S4, responding to the abnormity when the deployment, the modification configuration or the upgrade is executed, determining the reason of the abnormity and recovering through the database table backed up according to the reason.
In some embodiments, the steps further comprise: comparing the acquired login information with preset and stored basic login information; and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
In some embodiments, the reading the file corresponding to the module name to obtain the login information of each database includes: presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
In some embodiments, the determining a cause of the abnormality and the restoring via the backup file according to the cause includes: importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and in response to the field value of the temporary file not matching the field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
Fig. 2 is a schematic hardware structure diagram of an embodiment of the database disaster recovery computer device according to the present invention.
Taking the apparatus shown in fig. 2 as an example, the apparatus includes a processor 201 and a memory 202, and may further include: an input device 203 and an output device 204.
The processor 201, the memory 202, the input device 203 and the output device 204 may be connected by a bus or other means, and fig. 2 illustrates the connection by a bus as an example.
The memory 202, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the database disaster recovery method in the embodiments of the present application. The processor 201 executes various functional applications of the server and data processing by running the nonvolatile software programs, instructions and modules stored in the memory 202, that is, the method for database disaster recovery of the above-described method embodiment is implemented.
The memory 202 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the method of database disaster recovery, and the like. Further, the memory 202 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 202 may optionally include memory located remotely from processor 201, which may be connected to local modules via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The input device 203 may receive information such as a user name and a password that are input. The output device 204 may include a display device such as a display screen.
Program instructions/modules corresponding to one or more database disaster recovery methods are stored in the memory 202, and when executed by the processor 201, perform the database disaster recovery method in any of the above-described method embodiments.
Any embodiment of the computer device executing the database disaster recovery method can achieve the same or similar effects as any corresponding method embodiment.
The invention also provides a computer readable storage medium storing a computer program which, when executed by a processor, performs the method as above.
Fig. 3 is a schematic diagram of an embodiment of a computer storage medium for database disaster recovery according to the present invention. Taking the computer storage medium as shown in fig. 3 as an example, the computer readable storage medium 3 stores a computer program 31 which, when executed by a processor, performs the method as described above.
Finally, it should be noted that, as one of ordinary skill in the art can appreciate that all or part of the processes of the methods of the above embodiments can be implemented by a computer program to instruct related hardware, and the program of the method of database disaster recovery can be stored in a computer readable storage medium, and when executed, the program can include the processes of the embodiments of the methods described above. The storage medium of the program may be a magnetic disk, an optical disk, a Read Only Memory (ROM), a Random Access Memory (RAM), or the like. The embodiments of the computer program may achieve the same or similar effects as any of the above-described method embodiments.
The foregoing is an exemplary embodiment of the present disclosure, but it should be noted that various changes and modifications could be made herein without departing from the scope of the present disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the disclosed embodiments described herein need not be performed in any particular order. Furthermore, although elements of the disclosed embodiments of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.
It should be understood that, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly supports the exception. It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items.
The numbers of the embodiments disclosed in the embodiments of the present invention are merely for description, and do not represent the merits of the embodiments.
It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, of embodiments of the invention is limited to these examples; within the idea of an embodiment of the invention, also technical features in the above embodiment or in different embodiments may be combined and there are many other variations of the different aspects of the embodiments of the invention as described above, which are not provided in detail for the sake of brevity. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the embodiments of the present invention are intended to be included within the scope of the embodiments of the present invention.

Claims (10)

1. A database disaster recovery method is characterized by comprising the following steps:
circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database;
screening the database table to determine the database table to be backed up, and backing up the database table to be backed up according to the login information;
judging whether the deployment, the configuration modification or the upgrade is abnormal or not; and
and in response to the occurrence of an exception during deployment, configuration modification or upgrade execution, determining the reason of the exception and recovering through the backed-up database table according to the reason.
2. The method of claim 1, further comprising:
comparing the acquired login information with preset and stored basic login information; and
and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
3. The method of claim 1, wherein reading the file corresponding to the module name to obtain the login information of each database comprises:
presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
4. The method of claim 1, wherein the determining a cause of the anomaly and restoring via the backup file according to the cause comprises:
importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and
in response to a field value of the temporary file not matching a field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
5. A system for database disaster recovery, comprising:
the acquisition module is configured for circularly and sequentially logging in the remote nodes, sequentially reading module names in a module service configuration file directory of the current remote node, and reading files corresponding to the module names to acquire login information of each database;
the screening module is configured to screen the database table to determine the database table to be backed up, and back up the database table to be backed up according to the login information;
the judging module is configured to judge whether the exception occurs when the deployment, the configuration modification or the upgrade is executed; and
and the recovery module is configured to determine the reason of the abnormality and recover the abnormality through the backed-up database table according to the reason in response to the occurrence of the abnormality during deployment, configuration modification or upgrading.
6. The system of claim 5, further comprising a comparison module configured to:
comparing the acquired login information with preset and stored basic login information; and
and in response to the obtained login information not being consistent with the basic login information, updating the basic login information with the obtained login information.
7. The system of claim 5, wherein the acquisition module is configured to:
presetting an information matching paradigm, reading a configuration file corresponding to the module name, and extracting definition information of a database segment in the configuration file.
8. The system of claim 5, wherein the recovery module is configured to:
importing a backup database table into a designated module database in a temporary file mode, and comparing a field value of a temporary file with a field value of the designated module database; and
in response to a field value of the temporary file not matching a field value of the specified module database, replacing the field value of the specified module database with the field value of the temporary file.
9. A computer device, comprising:
at least one processor; and
a memory storing computer instructions executable on the processor, the instructions when executed by the processor implementing the steps of the method of any one of claims 1 to 4.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 4.
CN202110057634.0A 2021-01-15 2021-01-15 Database disaster recovery method, system, device and medium Active CN112749043B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110057634.0A CN112749043B (en) 2021-01-15 2021-01-15 Database disaster recovery method, system, device and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110057634.0A CN112749043B (en) 2021-01-15 2021-01-15 Database disaster recovery method, system, device and medium

Publications (2)

Publication Number Publication Date
CN112749043A true CN112749043A (en) 2021-05-04
CN112749043B CN112749043B (en) 2022-07-08

Family

ID=75652252

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110057634.0A Active CN112749043B (en) 2021-01-15 2021-01-15 Database disaster recovery method, system, device and medium

Country Status (1)

Country Link
CN (1) CN112749043B (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113254456A (en) * 2021-06-29 2021-08-13 山东浪潮通软信息科技有限公司 Database data information comparison method, system, equipment and storage medium
CN114168381A (en) * 2021-11-26 2022-03-11 云赛智联股份有限公司 Disaster recovery data management system and method for government affair disaster recovery center

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103473151A (en) * 2013-09-10 2013-12-25 中国银行股份有限公司 Database table backup method and device
WO2016058333A1 (en) * 2014-10-15 2016-04-21 中兴通讯股份有限公司 Data recovery method and device for database, and computer storage medium
CN106126204A (en) * 2016-06-15 2016-11-16 中邮建技术有限公司 A kind of iterative regarded as output controlling method of information system based on modularized design

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103473151A (en) * 2013-09-10 2013-12-25 中国银行股份有限公司 Database table backup method and device
WO2016058333A1 (en) * 2014-10-15 2016-04-21 中兴通讯股份有限公司 Data recovery method and device for database, and computer storage medium
CN106126204A (en) * 2016-06-15 2016-11-16 中邮建技术有限公司 A kind of iterative regarded as output controlling method of information system based on modularized design

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113254456A (en) * 2021-06-29 2021-08-13 山东浪潮通软信息科技有限公司 Database data information comparison method, system, equipment and storage medium
CN114168381A (en) * 2021-11-26 2022-03-11 云赛智联股份有限公司 Disaster recovery data management system and method for government affair disaster recovery center
CN114168381B (en) * 2021-11-26 2024-08-23 云赛智联股份有限公司 Disaster backup data management system and method for government disaster backup center

Also Published As

Publication number Publication date
CN112749043B (en) 2022-07-08

Similar Documents

Publication Publication Date Title
US11860821B2 (en) Generating target application packages for groups of computing devices
CN108804618B (en) Database configuration method, device, computer equipment and storage medium
US8150948B2 (en) Complex software deployment
US10853227B2 (en) Systems and methods for modular test platform for applications
CN112749043B (en) Database disaster recovery method, system, device and medium
US8024712B1 (en) Collecting application logs
US8438418B2 (en) Simplifying automated software maintenance of data centers
JP4598065B2 (en) Monitoring simulation apparatus, method and program thereof
CN110196804B (en) Service testing method and device, storage medium and electronic device
CA3161519A1 (en) Unit testing of components of dataflow graphs
CN109840194B (en) Method and system for detecting configuration file
CN111651352B (en) Warehouse code merging method and device
CN101588268A (en) Method and device for configuration files of universal extensible management device
CN103026337B (en) The extraction of dispensing assembly and reconstruct
CN106445541B (en) Software construction method, software construction device and software construction system
CN112732280B (en) Personal habit data management system for computer users
CN109586994A (en) A kind of whole machine cabinet server burn-in test monitoring method and system
CN114385458A (en) Sensor monitoring method and device based on event bus model
CN115002107A (en) Method, system, equipment and storage medium for deploying fragment service
CN112256554B (en) Method and equipment for testing based on scene test cases
CN113836234A (en) Method, system, equipment and storage medium for synchronizing offline operation data
CN108762745B (en) Service script generation method and device
WO2016120989A1 (en) Management computer and rule test method
CN111857744A (en) Installation method, system, equipment and medium of super-fusion system
CN111400243A (en) Research and development management system based on pipeline service and file storage method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant