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.
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.