A method and system for reconstructing an RDS database based on a Docker platform

Abstract

The present invention provides a method and system for reconstructing an RDS database based on a Docker platform, including analyzing the original file format of a compressed database to obtain the database type and version number; automatically pulling a database image that matches the file server based on the database type and version number, and automatically configuring the network and service information under the Docker container; performing a database environment check on the database image under the Docker container, and automatically loading database scripts or current file data in response to meeting the current database environment construction requirements; automatically repairing error instructions during the loading process based on instruction problems accumulated in the Docker container, and simultaneously modifying the version number corresponding to the current image; incrementally updating the environment image data in response to a mismatch between the local image and the file server, and performing repair and archiving of error instructions; and automatically presenting database external link information in conjunction with the RDS database reconstructed by Docker. This application can greatly improve data restoration efficiency and improve forensics efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of database reconstruction, and in particular to a method and system for reconstructing an RDS database based on a Docker platform. Background Art

[0002] With the advantages of RDS databases offered by cloud providers, such as high availability, high security, high performance, and low maintenance costs, small and medium-sized enterprises have turned over their database operations to professional RDS teams at cloud providers, eliminating technical barriers and solving more problems with less money. As a result, many users now directly use RDS. However, while RDS databases offer convenience, they also present certain technical barriers to restoring RDS databases in the forensics industry. Currently, there are three main restoration methods available on the market:

[0003] 1. For conventional databases, the file format corresponding to the original data (such as MYD, ibd, mdf, dbf, map, and db files) must be fixed. The database can then be restored based on file system structure analysis using manual analysis and third-party tools.

[0004] 2. Decompress the locally stored data formats (.sql, .tar.gz, xb.gz, qb.xb, etc.) through certain means, including offline verification. Then, install the same database environment on a virtual machine and restore various databases through manual loading and analysis.

[0005] 3. By working with cloud server vendors to standardize compliance procedures, retain the validity period of original data and conduct online analysis.

[0006] The above method has the following problems:

[0007] 1. Currently, most virtual machines are used to build the same environment, which has the characteristics of occupying large hardware and software resources and can only be used by a specific person in a specific environment, and cannot be reused by multiple people;

[0008] 2. Each database version environment must be installed on the virtual machine. Installing multiple database environments on the same virtual machine may cause environment conflicts. It is also difficult to maintain different database environments installed on multiple virtual machines, making it difficult to accumulate various error messages and summarize experience for reuse.

[0009] 3. In actual forensics, directly fixing the online database into a script format and then manually analyzing and restoring the script file can easily lead to various environmental installation and operation problems, requiring a certain level of technical skills to solve the various restoration problems.

[0010] 4. For compressed formats such as xb, qb, tar.gz, and bz2, you may need to decompress the files in a designated Linux environment to restore the original data format. Then, copy the data to a designated virtual machine on a Windows system. Then, manually analyze and restore the data using third-party recovery tools.

[0011] 5. Offline verification and compliance processes are time-consuming and may incur risks such as expiration of the corresponding RDS database. Summary of the Invention

[0012] In order to solve the above-mentioned technical problems existing in the prior art, the present invention proposes a method and system for reconstructing an RDS database based on the Docker platform to solve the above technical problems.

[0013] According to a first aspect of the present invention, a method for reconstructing an RDS database based on a Docker platform is proposed, comprising:

[0014] S1: Analyze the original file format of the compressed database to obtain the database type and version number;

[0015] S2: Automatically pulls the database image that matches the file server based on the database type and version number, and automatically configures the network and service information under the Docker container;

[0016] S3: Performs database environment verification on the database image in the Docker container. If the database environment meets the requirements, it automatically loads the database script or current file data.

[0017] S4: Based on the accumulated instruction problems of the Docker container, the error instructions in the loading process are automatically repaired, and the version number corresponding to the current image is modified. In response to the mismatch between the local image and the file server, the environment image data is incrementally updated, and the error instruction repair archive is performed;

[0018] S5: Combined with the RDS database reconstructed by Docker, the database external link information is automatically presented.

[0019] In some specific embodiments, obtaining the database type in S1 specifically includes:

[0020] In response to the original file format of the compressed package database being a script database, the script data is analyzed using various database type keywords to obtain the database type;

[0021] In response to the original file format of the compressed package database being a compressed package database file, analyzing the compressed package header file to obtain the compressed package format;

[0022] If the compression format of the reconstructed RDS database is met, the system uses the known compression package format to locate the first address of the compression package's core directory through pointer offset. Based on the RDS database's type database file characteristics, the system detects file characteristics in the compression package's core directory area that match the specific database characteristic values. The RDS database type is then confirmed based on the database characteristic file match.

[0023] In some specific embodiments, obtaining the database version in S1 specifically includes:

[0024] In response to the identified database feature being script data, obtaining a version feature value corresponding to the database type in the script file based on the obtained database type, and obtaining a corresponding version number;

[0025] In response to the identified database feature being compressed package data, the database version feature value file is parsed to obtain the database version number by recursively parsing the data in the core directory area of ​​the compressed package in combination with the database version file feature value.

[0026] In some specific embodiments, the database environment verification in S3 specifically includes: verifying the database type; confirming whether the database version is in a compatible version; whether there is an error message during the startup process, and if there is an error message, automatically verifying the environment information from the accumulated error instructions.

[0027] In some specific embodiments, automatically loading the database script or current file data in S3 specifically includes:

[0028] In response to the original data in script format that meets the requirements of the current database environment, the database script is automatically loaded according to the existing script in the Docker container platform;

[0029] In response to the original data being in a compressed package data format, the system performs password key cracking, automatic decompression, and file level analysis according to different compressed package database formats, and automatically loads and starts the current file data.

[0030] According to a second aspect of the present invention, a computer-readable storage medium is provided, on which one or more computer programs are stored. When the one or more computer programs are executed by a computer processor, any one of the above methods is implemented.

[0031] According to a third aspect of the present invention, a system for reconstructing an RDS database based on a Docker platform is proposed, the system comprising:

[0032] Database type and version number acquisition unit: configured to analyze the original file format of the compressed database and obtain the database type and version number;

[0033] Network and service information configuration unit: This unit is used to automatically pull the database image that matches the file server based on the database type and version number, and automatically configure the network and service information under the Docker container;

[0034] Database environment verification unit: configured to perform database environment verification on the database image under the Docker container, and automatically load the database script or current file data in response to the current database environment construction being satisfied;

[0035] Repair and archiving unit: This unit is used to automatically repair error instructions during the loading process based on the accumulated instruction problems of the Docker container, modify the version number corresponding to the current image, and incrementally update the environment image data in response to the mismatch between the local image and the file server, and perform error instruction repair and archiving.

[0036] Information presentation unit: This unit is configured to automatically present database external link information in conjunction with the RDS database reconstructed by Docker.

[0037] In some specific embodiments, obtaining the database type in the database type and version number obtaining unit specifically includes:

[0038] In response to the original file format of the compressed package database being a script database, the script data is analyzed using various database type keywords to obtain the database type;

[0039] In response to the original file format of the compressed package database being a compressed package database file, analyzing the compressed package header file to obtain the compressed package format;

[0040] If the compression format of the reconstructed RDS database is met, the system uses the known compression package format to locate the first address of the compression package's core directory through pointer offset. Based on the RDS database's type database file characteristics, the system detects file characteristics in the compression package's core directory area that match the specific database characteristic values. The RDS database type is then confirmed based on the database characteristic file match.

[0041] In some specific embodiments, obtaining the database version in the database type and version number obtaining unit specifically includes:

[0042] In response to the identified database feature being script data, obtaining a version feature value corresponding to the database type in the script file based on the obtained database type, and obtaining a corresponding version number;

[0043] In response to the identified database feature being compressed package data, the database version feature value file is parsed to obtain the database version number by recursively parsing the data in the core directory area of ​​the compressed package in combination with the database version file feature value.

[0044] In some specific embodiments, the database environment verification in the database environment verification unit specifically includes: verifying the database type; confirming whether the database version is in a compatible version; whether there is an error message during the startup process, and if there is an error message, automatically verifying the environment information from the accumulated error instructions.

[0045] In some specific embodiments, automatically loading the database script or current file data in the database environment verification unit specifically includes:

[0046] In response to the original data in script format that meets the requirements of the current database environment, the database script is automatically loaded according to the existing script in the Docker container platform;

[0047] In response to the original data being in a compressed package data format, the system performs password key cracking, automatic decompression, and file level analysis according to different compressed package database formats, and automatically loads and starts the current file data.

[0048] The present invention proposes a method and system for reconstructing an RDS database based on a Docker platform, which has the following technical effects: iterative maintenance of differential environments through a private cloud server improves the integrity of information on various differential database environments with high fault tolerance, can avoid the same problems from occurring in different environments, and fully realizes the scenario where a professional builds a certain type of database environment for multiple people to reuse; the introduction of Docker container technology can greatly reduce the occupied disk space and host memory; the file server stores database images based on Linux platform image data, and there is no need to switch and decompress environmental information for different database compression formats; the most important advantage is that for the compressed package database format, the database type and version number can be automatically identified, thereby realizing automatic database reconstruction and restoring database information. By reconstructing the RDS database restoration method under the Docker platform, the efficiency of data restoration can be greatly improved, more valuable clues can be analyzed within a limited time, and the efficiency of on-site evidence collection can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many of the intended advantages of the embodiments will be readily apparent as they become better understood by reference to the following detailed description. Other features, objects, and advantages of the present application will become more apparent upon reading the detailed description of the non-limiting embodiments made with reference to the following drawings:

[0050] Figure 1 This is a flowchart of a method for reconstructing an RDS database based on a Docker platform according to an embodiment of the present application;

[0051] Figure 2 This is a flowchart of a method for reconstructing an RDS database based on a Docker platform according to a specific embodiment of the present application;

[0052] Figure 3 This is a flowchart of automatically identifying the RDS database type based on a compressed data file in a specific embodiment of the present application;

[0053] Figure 4 This is a flowchart of RDS database automatic reconstruction in a specific embodiment of the present application;

[0054] Figure 5 This is a framework diagram of a system for reconstructing an RDS database based on a Docker platform according to an embodiment of the present application;

[0055] Figure 6 It is a structural diagram of a computer system suitable for implementing the electronic device of the embodiment of the present application. DETAILED DESCRIPTION

[0056] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0057] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0058] According to an embodiment of the present application, a method for reconstructing an RDS database based on a Docker platform is provided. Figure 1 The flowchart of a method for reconstructing an RDS database based on a Docker platform according to an embodiment of the present application is shown. Figure 1 As shown, the method includes:

[0059] S101: Analyze the original file format of the compressed database to obtain the database type and version number.

[0060] In a specific embodiment, in response to the original file format of the compressed package database being a script database, the script data is analyzed using various database type keywords to obtain the database type; in response to the original file format of the compressed package database being a compressed package database file, the compressed package header file is analyzed to obtain the compressed package format; if it conforms to the current RDS reconstructed database compression format, the first address of the compressed package core directory is located using a pointer offset based on the known type of compressed package format, and based on the type database file characteristics of the RDS database, the file characteristics that conform to the specific database characteristic values ​​are detected in the compressed package core directory area, and the RDS database type is confirmed based on the database characteristic file match.

[0061] In a specific embodiment, in response to the identified database feature being script data, the corresponding version feature value of this type of database is obtained in the script file through the acquired database type, and the corresponding version number is obtained; in response to the identified database feature being compressed package data, combined with the database version file feature value, the database version number is obtained by recursively parsing the data in the core directory area of ​​the compressed package and parsing the database version feature value file.

[0062] S102: Automatically pull the database image that matches the file server according to the database type and version number, and automatically configure the network and service information under the Docker container.

[0063] S103: Perform database environment verification on the database image in the Docker container, and automatically load the database script or current file data in response to the current database environment being satisfied.

[0064] In a specific embodiment, the database environment verification specifically includes: verifying the database type; confirming whether the database version is in a compatible version; whether there is an error message during the startup process, and if there is an error message, automatically verifying the environment information from the accumulated error instructions.

[0065] In a specific embodiment, automatically loading a database script or current file data specifically includes: in response to satisfying the current database environment construction and the original data currently in script format, automatically loading the database script according to an existing script under the Docker container platform; in response to the original data being in a compressed package data format, performing password key cracking, automatic decompression, and file level analysis according to different compressed package database formats, and automatically loading and starting the current file data.

[0066] S104: Based on the instruction problems accumulated by the Docker container, the error instructions in the loading process are automatically repaired, and the version number corresponding to the current image is modified. In response to the mismatch between the local image and the file server, the environment image data is incrementally updated, and the error instruction repair and archiving are performed.

[0067] S105: Combined with the RDS database reconstructed by Docker, the database external link information is automatically presented.

[0068] Figure 2 A flowchart of a method for reconstructing an RDS database based on a Docker platform according to a specific embodiment of the present application is shown. Figure 2 As shown, this method mainly uses the provided database original data (including: various compressed package data formats for offline evidence collection and fixed database script formats at the evidence collection site). First, by detecting the compressed package (such as 7z format, tar.gz format, xb format, qb format, etc.), combined with the compressed package data format + database file characteristics, the offset is automatically identified to the database type. According to the detected database type and combined with the database characteristics, the database version information is extracted, and the image information corresponding to the database server is automatically pulled from the Docker container. Secondly, the database environment information matching degree of the original database data to be restored is verified (format, system environment information, database version environment, software information, network information, etc. automated script verification). If the currently pulled database environment information matches the current database reconstruction environment, it automatically enters the database automatic reconstruction and restoration process. If the first restoration fails, it is necessary to enter the error correction mode. After the reconstruction is completed, it is automatically archived and the image data corresponding to the file server is updated.

[0069] In a specific embodiment, analyzing the original file format of the compressed database to obtain the database type and version number includes: 1. Automatically identifying the database type and version number based on the data packet format characteristics:

[0070] 1) If it is a common script database, the script data can be quickly analyzed through various database type keywords to directly obtain the database type;

[0071] 2) If it is a compressed database file, you need to analyze the compressed header file to obtain the specific compressed package format;

[0072] 3) Determine whether the current RDS reconstructed database compression format is met. If not, terminate the process. Otherwise, locate the first address of the compressed package core directory using the pointer offset based on the known specific compressed package format.

[0073] 4) Based on the characteristics of various types of RDS database files, the core directory area of ​​the compressed package is detected to see whether it meets the file characteristics of specific database characteristics;

[0074] 5) Database feature file matching is performed based on the formats of stored data files, configuration files, log files, startup script files, and other formats. If the matching degree reaches most of the file storage features of a certain file, it can be confirmed to be a specific RDS database type.

[0075] 2. Combined with the identification of database features, the database version is automatically obtained.

[0076] 1) If it is script data, directly use the obtained database type to find the corresponding version feature value of this type of database in the script file, so as to quickly find the corresponding version number;

[0077] 2) If it is compressed package data, based on step 1, it is necessary to combine the specific database version file feature value, recursively parse the compressed package core directory area data, find the specific database version feature value file, and parse it to obtain the database version number. Figure 3 A flowchart of automatically identifying the RDS database type based on a compressed data file according to a specific embodiment of the present application is shown. Figure 3 As shown, the compressed package format (such as 7z compressed package, tar.gz compressed package, .bz2 compressed package, xb compressed package, qb compressed package, etc.) is automatically detected to determine whether the format parsing is supported. If not, the process ends. If supported, the compressed package type is analyzed and the first address of the core area of ​​the compressed package file is located. The specific database feature is found in the core directory area of ​​the compressed package in combination with various data feature files. It is determined whether the database feature value is found. If not, the process ends. If the database is located, the specific database version number is found in the core directory area according to the database version feature value.

[0078] In a specific embodiment, automatically reconstructing an RDS database on a Docker container platform specifically includes the following steps:

[0079] 1. After starting the Docker container, the database type and version are detected based on the previous steps. The file server (which stores the database image data) is automatically pulled to the Linux server that matches the database image. This server image already has the basic conditions for starting the database.

[0080] 2. After pulling the file server image, automatically configure the network, service and other information under the Docker container;

[0081] 3. After detecting the database type and version information, automatically verify the database environment of the pulled image under the Docker container platform: 1) Verify the database type; 2) Confirm whether the database version is compatible; 3) Check whether there are any error messages during the startup process. If so, automatically verify the environment information based on the accumulated error instructions;

[0082] 4. If the current database environment is built and the current data is in script format, the container on the Docker platform automatically loads the database script based on the existing script;

[0083] 5. If the original data provided is in compressed data format, it is necessary to implement password key cracking, automatic decompression, file level analysis according to different compressed database formats, and automatically load and start the current file data;

[0084] 6. If, during the script loading process or the loading analysis process, errors are reported for instructions during the loading process based on the accumulated instruction problems of the container, the accumulated error instruction library will be screened and automatically corrected. If the error cannot be corrected, relevant human measures will be required to repair it and further improve the error instruction;

[0085] 7. If human intervention is required to repair and improve the instructions in the above steps, the erroneous instructions will be improved and stored, and the version number information corresponding to the current image will be modified at the same time. After the image data is repaired and improved, the database server image version number information corresponding to the file server will be matched again. If the local image does not match the file server, the corresponding instructions will be issued to incrementally update the environment image data;

[0086] 8. After the update, the relevant error instructions are restored and archived for the mirror data, making it easier for different personnel to pull different database mirror information according to actual business scenarios, thereby improving overall efficiency.

[0087] 9. Finally, based on the RDS database that has been reconstructed by Docker, the database external link information is automatically presented.

[0088] Figure 4 A flowchart of RDS database automatic reconstruction according to a specific embodiment of the present application is shown as follows: Figure 4 As shown, after obtaining the database and version information, automatically pull the image, run the environment test, reconstruct the RDS database and automatically repair the problem, and judge whether it is successful. If so, provide external access information. If not, perform manual access repair, improve the error instructions (script + program), and judge whether the local image version number is consistent with the latest version number of the private cloud server. If not, push the improved database image to the private cloud server and update the version information.

[0089] In actual evidence collection, after obtaining the database (compressed data) by fixing on-site data or offline evidence collection, there are certain technical barriers to reproducing and restoring the entire database. This application solves the problem of automatic database restoration for various grassroots staff. It only requires a simple import of compressed database file data to restore the RDS database, which greatly improves the work efficiency of grassroots staff. At the same time, this application uses the file server to store the repaired database environment information to achieve multi-person collaboration, and provides the ability to automatically correct erroneous instructions, improves the database server environment information, and can greatly reduce the occurrence of unnecessary errors and improve evidence collection efficiency. Finally, the introduction of container technology can also reduce various configuration problems caused by hardware deployment and environmental management, and improve the efficiency of setting up the environment. At present, this technical scenario has been partially applied in the Cloud Survey Master (cloud server database fixed) + RDS database automatic reconstruction technology developed by the applicant, which greatly improves the efficiency of cloud server evidence collection.

[0090] Continue to refer Figure 5 , Figure 5 A framework diagram of a system for reconstructing an RDS database based on a Docker platform according to an embodiment of the present application is shown. The system specifically includes a database type and version number acquisition unit 501, a network and service information configuration unit 502, a database environment verification unit 503, a repair and archiving unit 504, and an information presentation unit 505. Among them, the database type and version number acquisition unit 501 is configured to analyze the original file format of the compressed package database to obtain the database type and version number; the network and service information configuration unit 502 is configured to automatically pull the database image that matches the file server according to the database type and version number, and automatically configure the network and service information under the Docker container; the database environment verification unit 503 is configured to perform database environment verification on the database image under the Docker container, and automatically load the database script or current file data in response to meeting the current database environment construction; the repair and archiving unit 504 is configured to automatically repair the error instructions in the loading process according to the instruction problems accumulated by the Docker container, and at the same time modify the version number corresponding to the current image, and in response to the mismatch between the local image and the file server, incrementally update the environment image data, and perform error instruction repair and archiving; the information presentation unit 505 is configured to automatically present database external link information in combination with the RDS database reconstructed by Docker.

[0091] Reference below Figure 6 , which shows a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. Figure 6 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0092] like Figure 6 As shown, the computer system includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the system 600 are also stored in the RAM 603. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0093] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, and the like; an output section 607 including a liquid crystal display (LCD) and speakers; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or a modem. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. Removable media 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read therefrom can be installed into the storage section 608 as needed.

[0094] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the method of the present application are executed. It should be noted that the computer-readable storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, an electromagnetic signal, an optical signal, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0095] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0096] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of the present application may be implemented in software or hardware.

[0098] As another aspect, the present application further provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or may exist independently and not be assembled into the electronic device. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device: analyzes the original file format of the compressed database to obtain the database type and version number; automatically pulls a database image that matches the file server according to the database type and version number, and automatically configures the network and service information under the Docker container; performs a database environment check on the database image under the Docker container, and automatically loads the database script or current file data in response to meeting the current database environment construction; automatically repairs the error instructions in the loading process according to the instruction problems accumulated in the Docker container, and modifies the version number corresponding to the current image; incrementally updates the environment image data in response to the mismatch between the local image and the file server, and performs error instruction repair archiving; and automatically presents database external link information in combination with the RDS database reconstructed by Docker.

[0099] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for reconstructing an RDS database based on a Docker platform, characterized in that: include: S1: Analyze the original file format of the compressed database to obtain the database type and version number; S2: Automatically pull the database image that matches the file server according to the database type and version number, and automatically configure the network and service information under the Docker container; S3: Performing database environment verification on the database image in the Docker container, and automatically loading database scripts or current file data in response to satisfying the current database environment construction; S4: Based on the accumulated instruction problems of the Docker container, automatically repair the error instructions in the loading process, modify the version number corresponding to the current image, respond to the mismatch between the local image and the file server, incrementally update the environment image data, and archive the error instruction repair; S5: Combined with the RDS database reconstructed by Docker, it automatically presents database external link information; Obtaining the database version in S1 specifically includes: In response to the identified database feature being script data, obtaining a version feature value corresponding to the database type in the script file based on the obtained database type, and obtaining a corresponding version number; In response to the identification that the database feature is compressed package data, combining the database version file feature value, recursively parsing the data in the core directory area of ​​the compressed package, parsing the database version feature value file to obtain the database version number; The automatic loading of database scripts or current file data in S3 specifically includes: In response to the original data in script format that meets the requirements of the current database environment, the database script is automatically loaded according to the existing script in the Docker container platform; In response to the original data being in a compressed package data format, the system performs password key cracking, automatic decompression, and file level analysis according to different compressed package database formats, and automatically loads and starts the current file data.

2. The method for reconstructing an RDS database based on a Docker platform according to claim 1, characterized in that: The database type obtained in S1 specifically includes: In response to the original file format of the compressed package database being a script database, the script data is analyzed using various database type keywords to obtain the database type; In response to the original file format of the compressed package database being a compressed package database file, analyzing the compressed package header file to obtain the compressed package format; If it matches the current RDS reconstructed database compression format, the system uses the known compression package format to locate the first address of the compression package's core directory through pointer offset. Based on the RDS database type database file characteristics, the system detects whether the file characteristics in the compression package's core directory area match the specific database characteristic values. Based on the database characteristic file match, the RDS database type is confirmed.

3. The method for reconstructing an RDS database based on a Docker platform according to claim 1, characterized in that: The database environment verification in S3 specifically includes: verifying the database type; confirming whether the database version is in a compatible version; whether there is an error message during the startup process, and if there is an error message, automatically verifying the environment information from the accumulated error instructions.

4. A computer-readable storage medium having one or more computer programs stored thereon, characterized in that: When the one or more computer programs are executed by a computer processor, the method according to any one of claims 1 to 3 is implemented.

5. A system for reconstructing an RDS database based on a Docker platform, characterized in that: The system comprises: Database type and version number acquisition unit: configured to analyze the original file format of the compressed database and obtain the database type and version number; Network and service information configuration unit: configured to automatically pull a database image that matches the file server according to the database type and version number, and automatically configure the network and service information under the Docker container; A database environment verification unit is configured to perform a database environment verification on the database image under the Docker container, and automatically load a database script or current file data in response to satisfying the current database environment construction; Repair and archiving unit: configured to automatically repair error instructions during the loading process based on the instruction problems accumulated by the Docker container, and modify the version number corresponding to the current image. In response to the mismatch between the local image and the file server, the environment image data is incrementally updated, and the error instruction repair and archiving is performed; Information presentation unit: configured to automatically present database external link information in conjunction with the RDS database reconstructed by Docker; The database type and version number obtaining unit obtains the database version specifically includes: In response to the identified database feature being script data, obtaining a version feature value corresponding to the database type in the script file based on the obtained database type, and obtaining a corresponding version number; In response to the identification that the database feature is compressed package data, combining the database version file feature value, recursively parsing the data in the core directory area of ​​the compressed package, parsing the database version feature value file to obtain the database version number; The automatic loading of database scripts or current file data in the database environment verification unit specifically includes: In response to the original data in script format that meets the requirements of the current database environment, the database script is automatically loaded according to the existing script in the Docker container platform; In response to the original data being in a compressed package data format, the system performs password key cracking, automatic decompression, and file level analysis according to different compressed package database formats, and automatically loads and starts the current file data.

6. The system for reconstructing an RDS database based on a Docker platform according to claim 5, characterized in that: The database type and version number obtaining unit obtains the database type specifically includes: In response to the original file format of the compressed package database being a script database, the script data is analyzed using various database type keywords to obtain the database type; In response to the original file format of the compressed package database being a compressed package database file, analyzing the compressed package header file to obtain the compressed package format; If it matches the current RDS reconstructed database compression format, the system uses the known compression package format to locate the first address of the compression package's core directory through pointer offset. Based on the RDS database type database file characteristics, the system detects whether the file characteristics in the compression package's core directory area match the specific database characteristic values. Based on the database characteristic file match, the RDS database type is confirmed.

7. The system for reconstructing an RDS database based on a Docker platform according to claim 5, characterized in that: The database environment verification in the database environment verification unit specifically includes: verifying the database type; confirming whether the database version is in a compatible version; whether there is an error message during the startup process, and if there is an error message, automatically verifying the environment information from the accumulated error instructions.

Images