CN101118509A - Method, device and system for remote disaster recovery of memory database - Google Patents

Abstract

The invention discloses a method for remote disaster recovery of an in-memory database. The method comprises: receiving and backing up a logical log generated after the main in-memory database executes business operations; executing the logical log to update data in the in-memory database for disaster recovery, and Data backup in the disaster recovery memory database; when the main memory database fails, if the disaster recovery database is normal, use the disaster recovery memory database; if the disaster recovery database fails, use the backup data and logical logs to restore the disaster recovery memory database, and then use the disaster recovery database . The invention also discloses a remote disaster recovery device for the memory database, a local device for the remote disaster recovery of the memory database and a remote disaster recovery system for the memory database. By applying the present invention, the memory can be used as the main body of data storage to realize the remote disaster recovery of the memory database.

Description

Method, device and system for remote disaster recovery of memory database

technical field

The invention relates to memory database technology, in particular to a method, device and system for remote disaster recovery of memory databases.

Background technique

Database disaster recovery is based on the database. It establishes a disaster recovery database that is the same as the main database in a logical way and updates it in real time. It is used to take over the business system in time to ensure business continuity when a disaster occurs in the main database.

There are many reasons for the disaster, which can be caused by factors of the computer system where the database is located, such as damage to the storage medium, or by factors other than the computer system, such as natural disasters. Using remote disaster recovery, the geographical location is divided into local and remote, and the main database is established locally, while the disaster recovery database is established in other places, which is equivalent to geographically separating the main database and the disaster recovery database. an important means.

Remote disaster recovery of physical databases, which is widely used at present, is mainly realized through the replication tools of database products or third-party tools. These tools transmit the log files recording business operations in the local master database to remote disaster recovery Log files are executed in the disaster database, and the data in the remote disaster recovery database is updated in real time to realize data synchronization between the remote disaster recovery database and the local database, so that when a disaster occurs in the local database, the remote disaster recovery database can take over the business system in time.

With the continuous improvement of the operation level of operators, higher requirements are put forward for the real-time performance of database operations. The main body of data storage in physical databases is disks, and data access in disks must involve input/output (I/O ) interface, so the physical database has a delay in operation execution, which becomes the real-time performance bottleneck of the physical database, and also affects the data synchronization effect of the primary database and the disaster recovery database when the physical database is remote disaster recovery. Based on the above problems, an in-memory database came into being. It is hoped that the operation of the business system on the database is only for the memory. Since the data access of the memory does not need to involve the I/O interface, it has a great advantage in real-time performance. Most of the existing in-memory database applications use memory as a fast query cache, so as to meet the real-time requirements in terms of data access, while the main body of data storage is still the disk, so the remote disaster recovery solution currently proposed for in-memory databases is also a Realized based on physical database.

With the improvement of application requirements and performance requirements, the data storage body of the memory database will be gradually converted from the disk to the memory itself. However, due to the data volatility of the memory, if the system where the memory database is located fails, all the data in the memory will be lost. The loss cannot be recovered, so the remote disaster recovery capability of the memory database with memory as the main data storage is particularly important.

At present, there is no remote disaster recovery scheme for in-memory databases that uses memory as the main body of data storage.

Contents of the invention

An embodiment of the present invention provides a remote disaster recovery method for an in-memory database. The method can use a memory as a data storage body to implement remote disaster recovery for an in-memory database.

An embodiment of the present invention provides a remote disaster recovery remote-side device for an in-memory database. The device can use a memory as a data storage body to implement remote disaster recovery for an in-memory database.

An embodiment of the present invention provides a local device for remote disaster recovery of an in-memory database. The device can use a memory as a data storage body to implement remote disaster recovery for an in-memory database.

An embodiment of the present invention provides a remote disaster recovery system for an in-memory database. The system can use memory as a data storage body to implement remote disaster recovery for an in-memory database.

An embodiment of the present invention provides a remote disaster recovery method for an in-memory database. The main in-memory database is established locally, and the in-memory database for disaster recovery is established in a different place. The method also includes:

Receive and back up the logical log generated after the main memory database performs business operations;

Execute the logical log, update the data in the disaster recovery memory database, and back up the data in the disaster recovery memory database;

When the main memory database fails, if the disaster recovery database is normal, use the disaster recovery memory database; if the disaster recovery database fails, use the backup data and logical logs to restore the disaster recovery memory database, and then use the disaster recovery database.

An embodiment of the present invention provides a remote disaster recovery remote side device for an in-memory database, the device comprising:

The logical log processing module is used to receive and back up the logical log from the local device; execute the received logical log and update the data in the disaster recovery memory database module;

Disaster recovery memory database module, used to store data;

The disk mirroring module is used to back up the data in the disaster recovery memory database module; when the disaster recovery memory database module fails, use the backup data and logical logs to restore the data in the disaster recovery memory database module data.

An embodiment of the present invention provides a local side device for remote disaster recovery of an in-memory database, the device comprising:

Main memory database module for storing data;

A logical log generation module, configured to generate a logical log for business operations of the main memory database module;

The logical log processing module is configured to read the logical log from the logical log generation module, and send the logical log to the remote device.

An embodiment of the present invention provides a remote disaster recovery system for a memory database. The system includes: a local device and a remote device; the local device includes a main memory database for storing data, and the remote device includes a storage device for storing data In-memory database;

The local side device is configured to generate a logical log for business operations of the main memory database, and send the logical log to the remote side device;

The remote side device is used to receive and back up the logical log from the local side device; execute the received logical log, update the data in the disaster recovery memory database, and back up the data in the disaster recovery memory database; When the disaster recovery memory database fails, use the backup data and logical logs to restore the data in the disaster recovery memory database.

It can be seen that the method, device and system for remote disaster recovery of memory databases in the embodiments of the present invention use logical logs to synchronize the data in the main memory database and the disaster recovery memory database, and use the disaster recovery memory database to take over business in time when the main memory database fails system; and because the main body of data storage is memory, which has the characteristics of data volatility, the logical log of the main memory database and the data in the disaster recovery memory database are backed up. When the disaster recovery memory database fails, the backup data is used. Data and logical logs restore the disaster recovery memory database, and then use the disaster recovery memory database to take over the business system in time.

Description of drawings

FIG. 1 is a schematic structural diagram of a device on the remote side of an in-memory database for remote disaster recovery according to an embodiment of the present invention;

2 is a schematic structural diagram of a local side device for remote disaster recovery of an in-memory database according to an embodiment of the present invention;

3 is a flowchart of a method for remote disaster recovery of an in-memory database according to an embodiment of the present invention;

Fig. 4 is the flow chart of log synchronization in the method for remote disaster recovery of in-memory database according to the embodiment of the present invention;

FIG. 5 is a flow chart of log reception in the method for remote disaster recovery of an in-memory database according to an embodiment of the present invention;

6 is a flow chart of disk mirroring in the method for remote disaster recovery of an in-memory database according to an embodiment of the present invention;

FIG. 7 is a recovery flowchart in the method for remote disaster recovery of an in-memory database according to an embodiment of the present invention.

Detailed ways

In order to make the purpose and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below in conjunction with the accompanying drawings.

First, the device for remote disaster recovery of an in-memory database according to the embodiment of the present invention is introduced, including a local device and a remote device.

Figure 1 is a schematic structural diagram of a device on the remote side of an in-memory database for remote disaster recovery according to an embodiment of the present invention. The device on the remote side includes:

The logical log processing module is used for receiving and backing up the logical log from the local device; executing the received logical log and updating the data in the disaster recovery memory database module.

The disaster recovery memory database module is used to store data.

The disk mirroring module is used to back up the data in the disaster recovery memory database module; when the disaster recovery memory data block fails, use the backup data and logical logs to restore the data in the disaster recovery memory database module data.

The remote disaster recovery device of the memory database provided by the embodiment of the present invention receives the logical log sent by the local device, backs up the logical log and executes the logical log, thereby updating the data in the disaster recovery memory database; and because the main body of the data storage For memory, the data in the disaster recovery memory database is also backed up. When the main memory database fails, the disaster recovery memory database is used to take over the business system in time to process business requests. When the disaster recovery memory database fails, the backup data is used The disaster recovery in-memory database can be restored with the logic log, and then the disaster recovery in-memory database can be used to take over the business system in time to process business requests, thereby ensuring the remote disaster recovery capability with the in-memory database as the data subject.

The remote side device for remote disaster recovery of the memory database provided by the above-mentioned embodiments of the present invention may include a mirrored disk inside the device, or the device may be directly connected to a mirrored disk located outside the device, and the function of the mirrored disk is to store the backup logic For logs and data in the disaster recovery memory database, Figure 1 shows the situation where the remote device is directly connected to a mirrored disk. Based on this situation, the remote side device may further include a heartbeat message processing module, configured to receive a heartbeat message from the local side device, and return a heartbeat response message to the local side device.

The disk image module in the device may also include: an execution module and a flag bit setting module. Wherein, the execution module is used to store the data in the disaster recovery memory database module to the mirror disk; use the data in the mirror disk and the logic log to recover the data in the disaster recovery memory database module. The flag bit setting module is used to set the flag bit for identifying the operation of the execution module according to whether the execution module currently stores the data in the disaster recovery memory database module to the mirror disk.

The logical log processing module in the device may also include: a transceiver module, a buffer module, a judgment module and a data synchronization module.

The transceiver module is used to receive the logic log from the local side device, output it to the mirror disk according to the judgment result of the judgment module, and output it to the cache module; return a confirmation message that the logic log is correctly received to the local side device.

The cache module is used to cache logical logs from the local.

The data synchronization module is used to read the logic log from the cache module and execute it, and update the data stored in the disaster recovery memory database module according to the execution result.

The judging module is configured to obtain a judging result whether the data in the disaster recovery database is currently being stored to the mirror disk according to the flag bits in the disk mirroring module.

FIG. 2 is a schematic structural diagram of a local-side device for remote disaster recovery of an in-memory database according to an embodiment of the present invention. The device includes:

The main memory database module is used to store data.

A logical log generation module, configured to generate a logical log for business operations of the main memory database module.

The logical log processing module is configured to read the logical log from the logical log generation module, and send the logical log to the remote device.

The local side device for remote disaster recovery of the memory database provided by the embodiment of the present invention sends the logic log corresponding to the business operation of the main memory database to the remote side device, so that the remote side device can compare the data in the disaster recovery memory database with the logical log. The data in the main memory database on the local side is synchronized to realize remote disaster recovery.

The above-mentioned local side device may also include a logical log cache disk, or the local side device may be directly connected to a logical log cache disk for receiving the logical log storage backed up by the logical log reading module. Figure 2 shows the local side The case where the device is directly connected to the logical log cache disk. Based on this situation, the local side device of the memory database remote disaster recovery provided by the embodiment of the present invention may further include a heartbeat message processing module, and the logical log processing module in the device may include: a logical log reading module, a cache module, and a transceiver module and logical log deletion modules.

The logical log reading module is used to read the logical log from the logical log generation module, and transmit the heartbeat response message received by the heartbeat message processing module to the cache module when the communication with the remote side device is normal, Backup when the communication with the remote device is not normal.

A caching module, configured to cache the logical logs read by the logical log reading module.

The transceiver module is used to send the logical log stored in the cache module or backed up to the remote device, and receive the confirmation message of correct reception of the logical log returned by the remote device, and the confirmation message includes the identifier corresponding to the correctly received logical log.

The logical log deletion module is configured to delete the identifier included in the confirmation message received by the transceiver module and the corresponding logical log in the cache module or the logical log cache disk.

The heartbeat message processing module is configured to send a heartbeat message to the remote device, and receive a heartbeat response message returned by the remote device.

The remote-side device and the local-side device for remote disaster recovery of the in-memory database in the above-mentioned embodiment of the present invention may constitute a system for remote disaster recovery of the in-memory database in the embodiment of the present invention.

Next, the method for remote disaster recovery of an in-memory database according to the embodiment of the present invention is introduced in detail, and FIG. 3 shows the flow of the method. Before the process shown in Figure 3 starts, the main memory database is firstly established locally, and the disaster recovery memory database is established remotely. The above-mentioned main memory database corresponds to the main memory database module in the local side device already introduced, and the disaster recovery memory database corresponds to the disaster recovery memory database module in the remote side device.

The process shown in Figure 3 includes:

Step 301: Receive and back up the logical log generated after the main memory database executes the business operation.

In this step, the logical log generation module in the local side device generates a logical log that records the executed business operations after the main memory database executes the business operation, and the logical log processing module in the remote side device first receives the above logical log, and then Back up the received logical logs.

Step 302: Execute the received logic log, update the data in the disaster recovery memory database, and back up the data in the disaster recovery memory database.

In this step, the logical log processing module in the remote device executes the received logical log, and can know the business operations performed by the main memory database according to the execution result, and update the data in the disaster recovery memory database to realize the disaster recovery memory The data in the database and the main memory database are synchronized, and the business system can be taken over in time when the main memory database fails. The operation of backing up the updated data is completed by the disk mirroring module in the off-site device, which can operate asynchronously with the data in the above-mentioned update disaster recovery memory database, that is, it is not necessary to back up immediately after each data update, for example, a mirror disk can be set Regularly back up the data in the disaster recovery memory database.

Step 303: When the main memory database fails, if the disaster recovery database is normal, use the disaster recovery memory database; if the disaster recovery database fails, restore the disaster recovery memory database using the backup data and logical logs, and then use the disaster recovery database.

In this step, when the disaster recovery memory database also fails, the disk mirroring module in the remote device can use the backup data to restore the disaster recovery memory database, but as described in step 302, since the data in the disaster recovery database is backed up The data update in the disaster recovery memory database can be asynchronous, so the backup data may not be consistent with the state of the data when the disaster recovery memory database fails. In this case, you need to use the backup logical log to update the backup data. These data are synchronized with the state when the disaster recovery memory database fails, so as to restore the disaster recovery memory database to the state before the failure occurs.

The method for remote disaster recovery of the memory database in the embodiment of the present invention uses logical logs to synchronize the data in the main memory database and the disaster recovery memory database, and when the main memory database fails, the disaster recovery memory database is used to take over the business system in time and process business requests; And because the main body of data storage is memory, which has the characteristics of data volatility, the logical log of the main memory database and the data in the disaster recovery memory database are backed up. When the disaster recovery memory database fails, the backup data and the data in the disaster recovery memory database are used. The logical log restores the disaster recovery memory database, and then uses the disaster recovery memory database to take over the business system in time, thus ensuring the remote disaster recovery capability with the memory database as the data subject.

In the method for remote disaster recovery of an in-memory database provided by the embodiment of the present invention, a mirror disk can be further set in a different place, corresponding to the mirror disk in the remote side device that has been introduced, or directly connected to the mirror disk of the remote side device, the steps The logical log backed up in 301 and the data in the disaster recovery memory database backed up in step 302 can be: the logical log processing module in the off-site side device outputs the logical log to the mirror disk for storage, and the disk mirroring module in the off-site side device will accommodate The data in the disaster memory database is output to the mirror disk for storage.

The method for remote disaster recovery of an in-memory database provided by the embodiment of the present invention can be specifically divided into several implementation processes, including: a log synchronization process, a log receiving process, a disk mirroring process, and a disaster recovery in-memory database recovery process.

Before introducing each of the above specific processes, a preferred implementation manner of logical log storage in the embodiment of the present invention will be introduced first.

The logical log can be stored in the system log table of the shared memory, and a buffer (Buffer) group is formed by adding records. Each logical log is a record in the system log table. The structure of the record is shown in Table 1.

Buffer header logical log logical log logical log logical log

Table I

The structure of the Bufier header shown in Table 1 is shown in Table 2.

logid flag bufsize

Table II

The logid shown in Table 2 represents the unique value of the logic log corresponding to the business operation applied for when performing business data operations. When the logid is greater than 0xffffffff, it is reassigned from 1. The flag shown in Table 2 indicates the remaining space of this record. When the remaining space is not enough to store the logical log, the value of flag can be set to full. The bufsize shown in Table 2 represents the size of this record.

FIG. 4 is a flow chart of log synchronization in the method for remote disaster recovery of in-memory database according to the embodiment of the present invention. The flow mainly describes how to read the generated logical log locally and send it to a different place to realize log synchronization. Set the cache area and logical log cache disk locally. The cache area can be the system log table in the shared memory introduced above. The storage structure can also be shown in Table 1 and Table 2. The cache area and logical log cache disk correspond to The cache module and logical log cache disk in the local device have been introduced. The process shown in Figure 4 includes:

Step 401: Read the logical log from the cache.

In this step, the storage structure in the buffer area can be shown in Table 1 and Table 2. The logical log reading module in the local device reads the logical log generated by the logical log generation module after the business operation is executed, and stores it in the cache in the district. The method for reading the logical log above may be: read the logical log from the bufier whose flag is full.

Step 402: Monitor whether the current local and remote communication is normal, execute step 403 if abnormal, and execute step 405 if normal.

In this step, the monitoring method can be specifically as follows: the heartbeat message processing module in the local side device periodically sends heartbeat messages to the remote side device, and if the heartbeat response returned by the remote side device can be received, it is considered that the communication between the local side and the remote side normal, otherwise considered abnormal.

Step 403: Write the read logical log to the logical log cache disk, and continue to monitor the communication between the local and remote locations.

In this step, if it has been judged in step 402 that the communication between the local and remote places is not normal, the logical log read from the cache cannot be directly sent to the remote side. At this time, the logical log reading module in the local device can send the The read logical log is sent to the logical log cache disk for storage, and the storage structure of the logical log on the logical log cache disk may be the same as that in the cache area. The heartbeat message processing module in the local device can continue to detect whether the communication between the local and the remote is normal.

Step 404: When the communication between the local and remote places returns to normal, send the logical logs in the logical log cache disk.

In this step, after the communication between the local and remote locations returns to normal, the transceiver module in the local device first sends the logical logs written to the logical log cache disk to the remote side when the communication is abnormal. During the sending process, The logical log reading module in the local device continues to write the newly read logical log to the logical log cache disk until the last logical log on the logical log cache disk is sent to the remote side, and the newly read logical log is no longer there. written, but sent directly to the offsite side. In addition to the above-mentioned method of sending logical logs, the transceiver module in the local device can also send the logical logs in the buffer area and the logical log cache disk in any order, and the remote device automatically sends the received logical logs according to the logical log identifier. Logical logs are sorted.

Step 405: Send the read logical log.

In this step, if it is determined in step 402 that the communication between the local and the remote is normal, the transceiver module in the local device can directly read the logical log from the buffer and send it to the remote device.

In order to prevent the storage space occupied by the logical log from being too large, when receiving the confirmation message returned by the device on the remote side, the above process shown in Figure 4 may also include:

Step 406: Receive the returned confirmation message, and delete the logical log that has been sent correctly.

In this step, the transceiver module in the local side device receives the confirmation message returned by the remote side device, which may include the identifier of the logical log that has been correctly received, such as the logid of the logical log that has been introduced, in the local side device The logical log deletion module deletes the corresponding logical log in the cache area or the logical log cache disk according to the identification. If the logical logs sent to the off-site device only include those sent from the cache area, you only need to delete the logical logs in the cache area; if the logical logs sent to the off-site device also include those sent from the logical log cache disk, you also need to delete them Logical logs cache logical logs on disk. The specific deletion method can be as follows: the confirmation message returned by the remote side device includes the logid representing the logical log, traverses the system log table, sets the flag in the buffer header to full, and the maximum logid stored in it is smaller than the one carried in the confirmation message The record of logid is deleted.

The above steps 401 to 406 describe the process of sending logical logs locally. From the perspective of the system program, a disaster recovery communication process can be created, and the disaster recovery communication process completes steps 401 to 406.

FIG. 5 is a flow chart of log receiving in the method for remote disaster recovery of in-memory database according to the embodiment of the present invention. The flow mainly describes how to receive and store the received logical logs in different places. The process shown in Figure 5 includes:

Step 501: Receive logical logs.

In this step, the transceiver module in the remote device receives the logic log from the local device.

Step 502: Determine whether the data in the disaster recovery memory database is currently being stored to the mirror disk, if not, execute step 503, otherwise execute step 504.

In this step, inside the disk mirroring module in the remote side device, the flag bit setting module sets the flag bit identifying the operation of the execution module according to whether the execution module currently stores the data in the disaster recovery memory database module to the mirror disk. The judgment in this step is determined by the judging module in the off-site device, according to the flags in the above-mentioned disk mirroring module, to obtain the judging result whether the data in the disaster recovery memory database is currently being stored to the mirror disk.

Step 503: Write the logical log into the current logical log file in normal communication in the mirror disk, and then execute step 505.

In this step, the transceiver module in the remote device writes the logical log into the mirror disk, the logical log file in the current normal communication, and writes the logical log into the cache module.

Step 504: Write the logical log into the logical log file in the current disk mirroring process in the mirrored disk.

In this step, the transceiver module in the remote device writes the logical log into the logical log file currently being mirrored in the mirror disk, and then writes the logical log into the cache module.

In the above step 503 and step 504, the logical log file during the current normal communication and the logical log file in the current disk mirroring are two files in the mirrored disk, and the purpose of establishment is to distinguish between before and during the disk mirroring. Different storage locations of logical logs in mirrored disks.

Step 505: Send a confirmation message for correct receipt of the logical log, and the message may carry the identifier of the logical log that has been received correctly, such as logid. After receiving the acknowledgment message, the local device may delete the logical logs that have been correctly received by the remote device to save storage space.

In this step, the transceiver module in the remote device returns a confirmation message that the logical log is received correctly to the local device.

Step 506: Execute the logical log to update the data in the disaster recovery memory database.

In this step, the data synchronization module in the remote device reads and executes the logical log from the cache module, and updates the data in the disaster recovery memory database with the execution result.

The above steps 501 to 506 describe the logical log receiving process in different places. From the system program level, disaster recovery communication process, data synchronization process and disk mirroring process can be created. Among them, step 501, step 503, step 504 and step 505 are completed by the disaster recovery communication process; step 506 is completed by the data synchronization process; and storing the data in the disaster recovery database to the mirror disk can be completed by disk mirroring, so in step 502 The judgment step can be completed jointly by the disaster recovery communication process and the disk mirroring process. For example, the disk mirroring process sets a handshake flag, and the disaster recovery communication process shakes hands with the disk mirroring process. The data in the database is stored to mirrored disks.

6 is a flow chart of disk mirroring in the method for remote disaster recovery of an in-memory database according to an embodiment of the present invention. The process mainly describes how to store data in a disaster-tolerant in-memory database in a mirrored disk in a different place.

Step 601: Form a mirror file with data in the disaster recovery memory database.

In this step, the data in the disaster recovery memory database can be used as the file name of the memory block respectively to form a plurality of mirror files. The above-mentioned formation of mirror files can be a preset mirror time interval. The data in the disaster recovery memory database is formed into a mirror file at regular intervals, which is completed by the disk mirroring module in the remote side device.

Step 602: Write the image file into the image disk.

In this step, according to the mirroring time interval set in step 601, after the mirroring file is formed, the disk mirroring module in the remote side device writes the mirroring file into the mirroring disk. In the process of writing the mirrored file to the mirrored disk, the logical log file in the current normal communication is renamed to the old directory. The old directory is set to identify the time point of the disk mirroring. The logical log file during normal communication is renamed to the old directory. In the subsequent steps, if the disk mirroring is successful, the current logical log file during normal communication under the old directory will be deleted. If the disk mirroring fails, the current logical log file under the old directory can be deleted. Logical log file recovery during normal communication.

Step 603: When the mirroring is successful, delete the logical log file and the mirroring file before the mirroring from the mirroring disk, and when the mirroring fails, use the mirroring file that was successfully mirrored last time as the current mirroring file.

In this step, the storage location of the logical log in the mirrored disk will be different depending on whether the mirroring is in progress. It is to delete the logical log files and stored mirror files from the mirror disk during the current normal communication, or back up the files deleted from the mirror disk to a separate disk to release the storage space of the mirror disk. The logical log file in the current mirroring disk will be used as the logical log file during normal communication to store the newly written logical log file when the logical log is written next time. When the new disk mirroring process starts again, a new logical log file can be recreated. The file is used as a logical log file in the process of disk mirroring, and stores the newly written logical log during the disk mirroring process.

Steps 601 to 603 described above describe the process of disk mirroring in different places. From the perspective of the system program, steps 601 to 603 are completed by the created disk mirroring process, which is the same as the disk mirroring process set in the process shown in FIG. 5 .

Fig. 7 is the recovery flowchart of the disaster recovery memory database in the method for remote disaster recovery of the memory database according to the embodiment of the present invention, which mainly describes how to use the data and logical logs stored in the mirror disk when the disaster recovery memory database fails in a different place Restore the disaster recovery memory database so that it can recover and take over the business system in time to process business requests. The processes shown in Figure 7 are all completed by the disk mirroring module in the remote device, and the process includes:

Step 701: directly restore the disaster recovery memory database data stored in the mirror disk to the disaster recovery memory database.

Step 702: Rebuild the index according to the data restored to the disaster recovery memory database.

Step 703: Update the data in the restored disaster recovery memory database according to the logical log stored in the mirror disk.

In this step, when the disaster recovery memory database also fails, the data stored in the mirror disk can be used to restore the disaster recovery memory database, but since the data in the disaster recovery database is stored in the mirror disk and the data in the disaster recovery memory database Updates are often asynchronous, so the data stored in the mirror disk may not be consistent with the state of the data when the disaster recovery memory database fails. In this case, it is necessary to combine the logical logs stored in the mirror disk to update the data restored by the mirror disk , so that these data are synchronized with the state when the disaster recovery memory database fails, so as to restore the disaster recovery memory database to the state before the failure occurs.

Steps 701 to 703 describe the recovery process of the disaster recovery memory database. From the perspective of system programs, steps 701 to 703 are still completed by the disk mirroring process, which is the same as the disk mirroring process shown in Figures 5 and 6. The mirroring process is the same.

To sum up, the above are only preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (19)

1. a remote disaster recovery method for memory database, characterized in that, locally set up a main memory database, and set up a disaster recovery memory database in different places, the method also includes: Receive and back up the logical log generated after the main memory database performs business operations; Execute the logical log, update the data in the disaster recovery memory database, and back up the data in the disaster recovery memory database; When the main memory database fails, if the disaster recovery database is normal, use the disaster recovery memory database; if the disaster recovery database fails, use the backup data and logical logs to restore the disaster recovery memory database, and then use the disaster recovery database. 2. The method according to claim 1, wherein mirroring disks are set in different places; the logical log backup is as follows: storing the logical logs in the mirroring disks; The data backup is: storing the data in the disaster recovery memory database to the mirror disk. 3. The method according to claim 1 or 2, wherein a cache area and a logical log cache disk are set up locally; the receiving main memory database logical log is: When the communication between the local and remote places is normal, receive the logical log from the local cache area; when the communication fails, after waiting for the communication to recover, receive the logical log from the local logical log cache disk and buffer area, the logic The logical logs in the log cache disk include the logical logs stored when the local and remote communication is abnormal, and the newly stored logical logs before the local and remote communication is restored but not all the logical logs in the logical log cache disk are received. 4. The method according to claim 2, wherein after storing the logical log on the mirror disk and before executing the logical log, further comprising: A confirmation message for correct receipt of the logical log is returned to the local, where the confirmation message includes the identifier of the logical log that has been correctly received, so that the logical log corresponding to the identifier can be deleted locally. 5. The method according to claim 2, wherein, before storing the logical log to the mirror disk, it further comprises: judging whether the data in the disaster recovery database is currently being stored to the mirror disk; Store to mirrored disk as: If the data in the disaster recovery database is currently being stored to the mirror disk, the logical log will be stored in the logical log file in the current disk mirroring process in the mirror disk, otherwise, the logical log will be stored in the logic of the current normal communication in the mirror disk log files. 6. The method according to claim 5, wherein, storing the data in the disaster recovery memory database to the mirror disk is as follows: regularly backing up the data in the disaster recovery memory database as a mirror image file, and writing the mirror image file into the mirrored disk. 7. The method according to claim 6, further comprising: If the writing is successful, delete the current logical log file in the mirrored disk during normal communication and the mirrored file stored in the mirrored disk, and change the logical log file in the process of the current disk mirroring to the next time when the logical log is written The logical log file during normal communication, and create a new logical log file in the process of disk mirroring when the logical log is written next time; if the writing fails, the stored mirror file will be used as the current mirror file. 8 . The method according to claim 1 , wherein a buffer area is established in a different place, and after receiving and backing up the logical log, the method further comprises: storing the logical log in the buffer area before executing the logical log. 9. The method according to claim 2, wherein the recovery of the disaster recovery in-memory database using backup data and logical logs is: Restore the data in the mirror disk to the disaster recovery memory database; rebuild the index using said recovered data; Use the logical log in the mirror disk to update the data in the restored disaster recovery memory database. 10. A remote disaster recovery remote side device for an in-memory database, characterized in that the device comprises: The logical log processing module is used to receive and back up the logical log from the local device; execute the received logical log and update the data in the disaster recovery memory database module; Disaster recovery memory database module, used to store data; The disk mirroring module is used to back up the data in the disaster recovery memory database module; when the disaster recovery memory database module fails, use the backup data and logical logs to restore the data in the disaster recovery memory database module data. 11. The device according to claim 10, further comprising a mirror disk, configured to receive the logical log storage output by the logical log processing module, and receive the disaster recovery memory database output by the disk mirroring module data storage in . 12. The device according to claim 11, wherein the disk mirroring module comprises: an execution module and a flag bit setting module; The execution module is used to store the data in the disaster recovery database to the mirror disk; when the disaster recovery database module fails, use the logic log and data in the mirror disk to restore the disaster recovery memory database module data in The flag bit setting module is used to set the flag bit for identifying the operation of the execution module according to whether the execution module currently stores the data in the disaster recovery memory database module to the mirror disk. 13. The device according to claim 12, wherein the logical log processing module comprises: a transceiver module, a cache module, a judgment module and a data synchronization module; The transceiver module is used to receive the logic log from the local side device, output it to the mirror disk according to the judgment result of the judgment module, and output it to the cache module; return a confirmation message that the logic log is correctly received to the local side device; The caching module is used for caching logical logs from the local side device; The judging module is used to obtain the judging result of whether the data in the disaster recovery database is currently being stored to the mirrored disk according to the flag in the disk mirroring module; The data synchronization module is used to read out the logic log from the cache module and execute it, and update the data stored in the disaster recovery memory database module according to the execution result. 14. The device according to claim 10, further comprising a heartbeat message processing module, configured to receive a heartbeat message from the local side device, and return a heartbeat response message to the local side device. 15. A local side device for remote disaster recovery of an in-memory database, characterized in that the device comprises: Main memory database module for storing data; A logical log generation module, configured to generate a logical log for business operations of the main memory database module; The logical log processing module is configured to read the logical log from the logical log generation module, and send the logical log to the remote device. 16. The device according to claim 15, further comprising a heartbeat message processing module, configured to send a heartbeat message to the remote device and receive a heartbeat response message returned by the remote device. 17. The device according to claim 16, wherein the logical log processing module comprises: a logical log reading module, a cache module, a transceiver module, and a logical log deletion module; The logical log reading module is configured to read the logical log from the logical log generation module, and transmit the heartbeat response message received by the heartbeat message processing module to the cache module when the communication with the remote device is normal , back up when the communication with the remote device is not normal; The caching module is used to cache the logical log read by the logical log reading module; The transceiver module is configured to send the logical log in the cache module or backed up to the remote device, and receive a confirmation message that the logical log returned by the remote device is correctly received, and the confirmation message includes an identifier corresponding to the correctly received logical log ; The logical log deletion module is configured to delete the corresponding logical log in the cache module or in the backed up logical log according to the identification included in the confirmation message received by the transceiver module. 18. The device according to claim 17, further comprising a logical log cache disk inside the device, configured to receive the logical log storage backed up by the logical log reading module. 19. A system for remote disaster recovery of a memory database, characterized in that the system includes: a local side device and a remote side device; the local side device includes a main memory database for storing data, and the remote side device includes a main memory database for storing data Disaster recovery memory database; The local side device is configured to generate a logical log for business operations of the main memory database, and send the logical log to the remote side device; The remote side device is used to receive and back up the logical log from the local side device; execute the received logical log, update the data in the disaster recovery memory database, and back up the data in the disaster recovery memory database; When the disaster recovery memory database fails, use the backup data and logical logs to restore the data in the disaster recovery memory database.

Images