Real-time database fault recovery method, system, storage medium and server

Abstract

A method, system, storage medium, and server for real-time database fault recovery. The method includes the following steps: starting a watchdog service process for the real-time database and initializing shared memory; starting and initializing other service processes of the real-time database, including a communication service process, a basic service process, a snapshot service process, and a history service process; requesting from the watchdog service process shared memory for hot standby data and reading and writing data; regularly updating the process running status to the shared memory; restarting a service process if the running status is not updated after a timeout; and requesting from the shared memory hosting process to retrieve data for on-site recovery. The present invention can achieve rapid service restart and data recovery, greatly improving the service stability and data security of the real-time database.

Description

Technical Field

[0001] The present invention belongs to the technical field of real-time database development, and in particular relates to a method, system, storage medium and server for real-time database fault recovery. Background Art

[0002] The foundation for implementing manufacturing innovation strategies in various countries is the collection and analysis of industrial big data, which in turn creates a worry-free environment for future manufacturing systems. Real-time databases are the core services of industrial big data and the foundation of Industry 4.0.

[0003] Power generation companies need to collect massive amounts of real-time production data from industrial control systems such as DCS and auxiliary control systems and store them in real-time databases. They have very high security requirements for this stored data and do not allow the loss of stored data due to software defects.

[0004] To improve the performance of storing massive amounts of real-time production data, real-time databases typically employ data caching strategies. However, this can result in permanent data loss if the service process crashes, as stored data remains in the cache and has not yet been archived. Furthermore, when a real-time database service crashes and restarts, it may need to load a large amount of basic data from disk for initialization, slowing the service startup process and preventing rapid service recovery, resulting in prolonged service interruptions. Summary of the Invention

[0005] The purpose of the present invention is to provide a method, system, storage medium and server for real-time database fault recovery, which solve the problems of cache data loss and slow startup initialization after the service process of the real-time database crashes.

[0006] In order to achieve the above object, the present invention has the following technical solutions:

[0007] In a first aspect, a method for real-time database failure recovery is provided, comprising the following steps:

[0008] Start the real-time database watchdog service process and initialize the shared memory;

[0009] Start and initialize other service processes of the real-time database, including communication service processes, basic service processes, snapshot service processes, and history service processes;

[0010] Other service processes apply to the watchdog service process for shared memory that requires hot standby data and read and write data;

[0011] Other service processes periodically update the process running status to the shared memory;

[0012] If a service process times out and does not update its running status, restart the service process;

[0013] The restarted service process applies to the shared memory hosting process to retrieve data for on-site recovery.

[0014] As a preferred solution of the method of the present invention, the watchdog service process monitors other service processes on the one hand, and automatically restarts the corresponding service process if an abnormality or crash is found; on the other hand, it hosts all shared memories that require hot standby data, so that the shared memory is not recycled when other service processes exit abnormally;

[0015] The watchdog service process can be reverse-detected, and if an abnormality or crash is detected, the watchdog service process will be restarted.

[0016] As a preferred solution of the method of the present invention, the communication service process forwards the message to the corresponding service process for processing according to the function of the API call, and returns the response message to the API caller.

[0017] As a preferred solution of the method of the present invention, the basic service process loads the measurement point table and stores the measurement point table in a shared memory Hash table for long-term storage in the memory for query by other service processes.

[0018] As a preferred solution of the method of the present invention, the snapshot service process is used to realize caching and compression of snapshot data. At least one snapshot data of each measuring point is cached in the shared memory of the snapshot service process. If the measuring point supports compression, other data related to the compression calculation will also be cached in the shared memory of the snapshot service process. When the snapshot data of a certain measuring point is written, if the measuring point snapshot data is compressed, it will directly overwrite the original snapshot data. If it is not compressed, the measuring point snapshot data will be pushed to the history service process.

[0019] As a preferred solution of the method of the present invention, the historical service process is used for archiving and querying historical data, and historical data is cached for each measuring point according to the size of the data page. The historical data cache is stored in the shared memory of the historical service process; the snapshot data pushed by the snapshot service process will first be written into the historical data cache. When the historical data cache of a certain measuring point is full, the historical data cache will be archived and written into the archive file, and then the historical data cache will be cleared to continue waiting for receiving other historical data.

[0020] As a preferred solution of the method of the present invention, the shared memory can be named, and the shared memories corresponding to the same shared memory name are the same shared memory block;

[0021] When multiple service processes hold the same shared memory block, as long as one service process has not released the shared memory block, the shared memory will not be reclaimed, and other service processes can obtain access to the shared memory block again.

[0022] In a second aspect, a system for real-time database failure recovery is provided, comprising:

[0023] The watchdog service process startup module is used to start the real-time database watchdog service process and initialize the shared memory;

[0024] Other service process startup modules are used to start and initialize other service processes of the real-time database, including communication service processes, basic service processes, snapshot service processes, and history service processes;

[0025] The shared memory application module is used by other service processes to apply to the watchdog service process for shared memory that requires hot standby data and to read and write data;

[0026] The process status update module is used by other service processes to periodically update the process running status to the shared memory;

[0027] The process restart module is used to restart a service process if the service process times out and does not update its running status;

[0028] The on-site recovery module is used for the restarted service process to apply to the shared memory hosting process to retrieve data for on-site recovery.

[0029] According to a third aspect, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the method for recovering a real-time database failure is implemented.

[0030] In a fourth aspect, a server is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method for real-time database failure recovery when executing the computer program.

[0031] Compared with the prior art, the first aspect of the present invention has at least the following beneficial effects:

[0032] The real-time database service process stores data that requires hot standby in shared memory, and monitors the running status of all other service processes used for business processing in the real-time database through a watchdog service process. When a service process crashes, the watchdog service process restarts the crashed service process and quickly restores data through the hot standby shared memory, thereby avoiding the risk of data loss due to the crash of the service process. At the same time, the initialization speed of the restarted service process can also be accelerated to quickly restore the service. The present invention realizes a rapid restart of the business service process when it runs abnormally or crashes by jointly holding shared memory through the watchdog service process and the business service process, and can restore the running memory data before the restart, thereby achieving rapid service restart and data recovery, greatly improving the service stability and data security of the real-time database.

[0033] It can be understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0035] Figure 1 This is a diagram showing the relationship between the watchdog service process and other service processes of the present invention;

[0036] Figure 2 A flow chart of a method for real-time database failure recovery according to the present invention;

[0037] Figure 3 A schematic diagram of the shared memory structure of the present invention;

[0038] Figure 4 This is a schematic diagram of the naming method of the shared memory of the present invention;

[0039] Figure 5 This is a monitoring flow chart of the service process of the present invention. DETAILED DESCRIPTION

[0040] To make the objectives, technical solutions, and advantages of the present invention clearer and more specific, the present invention is further described in detail below in conjunction with specific embodiments and accompanying drawings. The present invention can also be implemented or applied through different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0041] The present invention proposes a method for real-time database fault recovery. The real-time database is divided into different service processes according to its function. These service processes include a watchdog service process, a communication service process, a basic service process, a snapshot service process and a history service process. These processes achieve cross-process communication and coordinated operation through the inter-process communication protocol IPC.

[0042] like Figure 2 As shown, in one embodiment, the method proposed by the present invention includes the following steps:

[0043] Step S11: Start the real-time database watchdog service process and initialize the shared memory block;

[0044] Step S12: start and initialize other service processes of the real-time database in sequence;

[0045] Step S13: The real-time database service process applies to the watchdog service process for the shared memory that requires hot standby data, and reads and writes data;

[0046] Step S14: the real-time database service process regularly summarizes the process running status to the shared memory service process running status area;

[0047] Step S15: If it is found that a service process has timed out and has not reported its running status, then the abnormal service process is restarted, otherwise, go to step S14;

[0048] Step S16: The restarted service process applies to the shared memory hosting process to retrieve data for rapid on-site recovery, and then goes to step S14.

[0049] like Figure 3 As shown in the diagram of the holding of each service process and shared memory of the real-time database, the watchdog service process holds all shared memories to ensure that all shared memories are not reclaimed by the system after other service processes crash; the communication service process holds the service running status shared memory block S21, which is used to update the running status of its own process; the basic service process holds the service running status shared memory block S21, which is used to update the running status of its own process, and also holds the allocated counter shared memory block S22 and the measurement point data cache shared memory block set S23, which is used to store the attribute information of all measurement points; the snapshot service process holds the service running status shared memory block S21, which is used to update the running status of its own process, and also holds the allocated counter shared memory block S22 and the snapshot data cache shared memory block set S24, which is used to store snapshot cache data; the history service process holds the service running status shared memory block S21, which is used to update the running status of its own process, and also holds the allocated counter shared memory block S22 and the history data cache shared memory block set S25, which is used to store history cache data.

[0050] like Figure 4 As shown, the shared memory held by the real-time database service processes follows certain naming conventions, facilitating quick access between different service processes to the required shared memory blocks. There is only one service status shared memory block S31 and one allocated counter shared memory block S32 globally, so these shared memory blocks use fixed names: rtdb_service_status.dat and rtdb_sharedmem_counter.dat, respectively. The three shared memory block sets—the measurement point table shared memory block set S33, the snapshot data cache shared memory block set S34, and the historical data cache shared memory block set S35—all consist of multiple fixed-size shared memory blocks. Different shared memory block sets use prefixes and sequence numbers to form shared memory block names. As long as a service process knows the shared memory block allocation counter value, it can format all the shared memory block names for that shared memory set, such as rtdb_snapshot_00000001.dat, rtdb_snapshot_00000002.dat, and rtdb_snapshot_00000003.dat.

[0051] When the above step S11 starts the real-time database watchdog service process, the purpose is to ensure that the watchdog service process is the first service process started by the real-time database; after the watchdog service process is started, the service operation status shared memory block S21 and the allocated counter shared memory block S22 are first initialized. The names of these two shared memory blocks are shown in S31 and S32, namely rtdb_service_status.dat and rtdb_sharedmem_counter.dat. Among them, the service operation status shared memory block contains five data units, which are respectively used to store the watchdog service process operation status, the communication service process operation status, the basic service process operation status, the snapshot service process operation status and the historical service process operation status. These operation status information include the operation status update timestamp of each service process, the working status of important submodules and working threads, etc. The watchdog service process uses this information to determine whether other service processes are operating normally. The allocated counter shared memory blocks include the number of shared memory blocks allocated for the three shared memory block sets: the measurement point table shared memory block set S23, the snapshot data cache shared memory block set S24, and the historical data cache shared memory block set S25. The required capacity of these three shared memory blocks varies depending on the measurement point scale. They cannot be allocated all at once; instead, they are allocated in fixed-size units. If the allocated shared memory is insufficient, further allocation is requested.

[0052] See also Figure 1After the watchdog service process is started, if it is found that other service processes have not been started in step S12, the basic service process S3, the historical service process S5, the snapshot service process S4 and the communication service process S2 will be started in sequence. In step S13, after each service process is started, the corresponding data will be loaded for initialization, as follows:

[0053] The basic service process S3 loads the measurement point attribute information from the measurement point table file and stores it in the form of a hash table in the shared memory block set requested from the watchdog service process. On the one hand, the snapshot service process S4 and the history service process S5 can quickly query the measurement point attribute information across processes. On the other hand, the measurement point table shared memory is shared by the basic service process S3 and the watchdog service process S1. When the basic service process S3 crashes and restarts, it does not need to be reloaded from the measurement point table file, and the measurement point data in the shared memory set can be directly obtained, thereby improving the service recovery speed of the basic service process S3.

[0054] The history service process S5, using the shared memory block set requested from the watchdog service process S1, allocates a historical data cache block for each measurement point to cache the historical data of the measurement point for the user. If the history service process S5 crashes and restarts, it can directly access the historical cached data of the measurement point in the shared memory set, thereby restoring the historical cached data before the crash, ensuring that no data is lost.

[0055] Snapshot service process S4, using the shared memory block set requested from watchdog service process S1, allocates a snapshot cache data block to each measurement point to cache snapshot data for the user. If snapshot service process S4 crashes and restarts, it can directly access the measurement point snapshot cache data in the shared memory set, thereby restoring the snapshot cache data before the crash, ensuring data is not lost.

[0056] Communication service process S2, when other service processes are initialized, the communication service process S2 is initialized last, at this point, the entire real-time database startup process is completed.

[0057] In the above step S14, each service process periodically updates the running status of the process to the service running status shared memory block S21. These running status information include the running status update timestamp of each service process, the working status of important sub-modules and threads, etc. When the process runs abnormally or crashes and exits, the running status will stop updating, and the watchdog service process can detect that the corresponding service process is running abnormally, thereby restoring the service.

[0058] like Figure 5 As shown in the figure, the watchdog service process detects the running status of other service processes. When a service process is found to be abnormal or crashed, a process of quickly restarting the service process and recovering data is adopted. Specifically, the following steps are included:

[0059] Step S41: The watchdog service process detects whether the target service process exists. If the process does not exist, the process proceeds to step S42, otherwise it jumps to step S43;

[0060] Step S42: The watchdog service process detects the status update flag of the target service process in the service running status shared memory block S21. If the flag is not updated within a timeout period, it indicates that the service process exists but is running abnormally, and the service process needs to be forcibly exited.

[0061] Step S43: the watchdog service process restarts the target service process. After the target service process is started, it first obtains the service running status shared memory block S21 and the allocated counter shared memory block S22 held by the watchdog service process.

[0062] S44: If the target service process is a basic service process, obtain the measurement point table shared memory block set S23, complete the measurement point table shared memory fast loading, and resume the service; if it is not a basic service process, proceed to the next step;

[0063] S45: If the target service process is a snapshot service process, then obtain the snapshot data cache shared memory block set S24, complete the snapshot data cache shared memory fast loading, and resume the service; if it is not a snapshot service process, proceed to the next step;

[0064] S46: If the target service process is a historical service process, then obtain the historical data cache shared memory block set S25, complete the historical data cache shared memory fast loading, and resume the service; if it is not a historical service process, proceed to the next step;

[0065] S47: If the target service process is a communication service process, the TCP network server is initialized and the service is restored;

[0066] S48: The service process and corresponding data are quickly restored, and the process jumps to S41 to continue the next round of service process monitoring.

[0067] If the watchdog service process crashes, steps S15 and S16 will not be executed, and the real-time database will lose its corresponding functions. To avoid this situation, during the implementation of the method provided by the present invention, the service process is allowed to reversely detect the running status of the watchdog service process. If it is found that the watchdog service process is running abnormally or crashes, the communication service process restarts the watchdog service process. After the watchdog service process is restarted, it obtains the service running status shared memory block S21 and the allocated counter shared memory block S22, and then obtains the shared memory set of the measurement point data cache shared memory block set S23, the snapshot data cache shared memory block set S24 and the historical data cache shared memory block set S25 based on the counter shared memory block S22, and resumes the service, thereby ensuring that all processes of the entire real-time database are in a monitoring state.

[0068] In another embodiment, a system for real-time database failure recovery is provided, comprising:

[0069] The watchdog service process startup module is used to start the real-time database watchdog service process and initialize the shared memory;

[0070] Other service process startup modules are used to start and initialize other service processes of the real-time database, including communication service processes, basic service processes, snapshot service processes, and history service processes;

[0071] The shared memory application module is used by other service processes to apply to the watchdog service process for shared memory that requires hot standby data and to read and write data;

[0072] The process status update module is used by other service processes to periodically update the process running status to the shared memory;

[0073] The process restart module is used to restart a service process if the service process times out and does not update its running status;

[0074] The on-site recovery module is used for the restarted service process to apply to the shared memory hosting process to retrieve data for on-site recovery.

[0075] In another embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the real-time database failure recovery method when executed by a processor.

[0076] In another embodiment, a server is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method for real-time database failure recovery when executing the computer program.

[0077] Exemplarily, the computer program may be divided into one or more modules / units, which are stored in a computer-readable storage medium and executed by the processor to complete the steps of the real-time database fault recovery method of the present application. The one or more modules / units may be a series of computer-readable instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the server.

[0078] The server can be a computing device such as a laptop, desktop computer, or cloud server. The server may include, but is not limited to, a processor and memory. Those skilled in the art will appreciate that the server may include more or fewer components, or a combination of certain components, or different components. For example, the server may also include input and output devices, network access devices, and buses.

[0079] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0080] The memory may be an internal storage unit of the server, such as a hard disk or memory of the server. The memory may also be an external storage device of the server, such as a plug-in hard disk equipped on the server, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. Furthermore, the memory may include both an internal storage unit of the server and an external storage device. The memory is used to store the computer-readable instructions and other programs and data required by the server. The memory may also be used to temporarily store data that has been output or is about to be output.

[0081] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0082] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0083] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunications signal and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk.

[0084] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0085] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for real-time database failure recovery, characterized in that: The following steps are involved: Start the real-time database watchdog service process and initialize the shared memory; Start and initialize other service processes of the real-time database, including communication service processes, basic service processes, snapshot service processes, and history service processes; Other service processes apply to the watchdog service process for shared memory that requires hot standby data and read and write data; Other service processes periodically update the process running status to the shared memory; If a service process times out and does not update its running status, restart the service process; The restarted service process requests the shared memory hosting process to retrieve data for on-site recovery; The watchdog service process monitors other service processes and automatically restarts the corresponding service process if an exception or crash is found. On the other hand, it hosts all shared memory that requires hot backup data so that the shared memory is not recycled when other service processes exit abnormally. The watchdog service process can be reverse-detected. If an anomaly or crash is detected, the watchdog service process will be restarted. The shared memory can be named, and the shared memories corresponding to the same shared memory name are the same shared memory block; When multiple service processes hold the same shared memory block, as long as one service process has not released the shared memory block, the shared memory will not be reclaimed, and other service processes can obtain access to the shared memory block again.

2. The method for real-time database failure recovery according to claim 1, characterized in that: The communication service process forwards the message to the corresponding service process for processing according to the function of the API call, and returns the response message to the API caller.

3. The method for real-time database failure recovery according to claim 1, characterized in that: The basic service process loads the measurement point table and stores the measurement point table in a shared memory Hash table for long-term storage in the memory for query by other service processes.

4. The method for real-time database failure recovery according to claim 1, characterized in that: The snapshot service process is used to implement caching and compression of snapshot data. At least one snapshot data of each measuring point is cached in the shared memory of the snapshot service process. If the measuring point supports compression, other data related to the compression calculation will also be cached in the shared memory of the snapshot service process. When the snapshot data of a certain measuring point is written, if the measuring point snapshot data is compressed, it will directly overwrite the original snapshot data. If it is not compressed, the measuring point snapshot data will be pushed to the history service process.

5. The method for real-time database failure recovery according to claim 1, characterized in that: The historical service process is used for archiving and querying historical data, and historical data is cached for each measuring point according to the size of the data page. The historical data cache is stored in the shared memory of the historical service process; the snapshot data pushed by the snapshot service process will first be written into the historical data cache. When the historical data cache of a certain measuring point is full, the historical data cache will be archived and written into the archive file, and then the historical data cache will be cleared to continue waiting for receiving other historical data.

6. A real-time database failure recovery system, characterized in that: include: The watchdog service process startup module is used to start the real-time database watchdog service process and initialize the shared memory; Other service process startup modules are used to start and initialize other service processes of the real-time database, including communication service processes, basic service processes, snapshot service processes, and history service processes; The shared memory application module is used by other service processes to apply to the watchdog service process for shared memory that requires hot standby data and to read and write data; The process status update module is used by other service processes to periodically update the process running status to the shared memory; The process restart module is used to restart a service process if the service process times out and does not update its running status; On-site recovery module, used for restarting service process to apply to shared memory hosting process to retrieve data for on-site recovery; The watchdog service process monitors other service processes and automatically restarts the corresponding service process if an exception or crash is found. On the other hand, it hosts all shared memory that requires hot backup data so that the shared memory is not recycled when other service processes exit abnormally. The watchdog service process can be reverse-detected. If an anomaly or crash is detected, the watchdog service process will be restarted. The shared memory can be named, and the shared memories corresponding to the same shared memory name are the same shared memory block; When multiple service processes hold the same shared memory block, as long as one service process has not released the shared memory block, the shared memory will not be reclaimed, and other service processes can obtain access to the shared memory block again.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for real-time database failure recovery according to any one of claims 1 to 5 is implemented.

8. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for real-time database failure recovery according to any one of claims 1 to 5 is implemented.

Images