KR20210156680A - Database management devices and methods for active and standby nodes in the main memory database management system - Google Patents

Abstract

The present invention relates to a database management device and method of an active node and a standby node of a main memory database management system. When a transaction is lost due to a failure in either one of the active node and the standby node in the main memory database management system, which is duplicated as the active node and the standby node, the database can be managed to prevent data inconsistency between the active node and the standby node.

Description

{Database management devices and methods for active and standby nodes in the main memory database management system}

The present invention relates to an apparatus and method for database management of an active node and a standby node of a main memory database management system. In a main memory database management system duplicated into an active node and a standby node, a failure occurs in either one of the active node and the standby node Accordingly, to a database management apparatus and method for managing a database to prevent data inconsistency between an active node and a standby node when a transaction is lost.

Since high-speed data processing is essential in a communication system or an Internet service system that manages a large number of subscribers, a high-speed data processing capability is required in a database that stores or manages such data. As a database management system of a new concept to satisfy the demand for such high-speed data processing performance, a main memory database management system ("MMDBMS") is emerging.

The main memory database management system is the process of reading and processing the data page or index page containing the record to be accessed from the disk into the memory buffer as needed, and the entire database table and index exist on disk in the conventional disk-based database management system. In contrast, at the time of initial operation, the entire database existing on the disk resides in the memory so that all records are accessed from the memory, thereby enabling high-speed data processing.

In general, a database management system (DBMS) performs logging of data changes to ensure the stability of the database. Logging is a basic function of DBMS to record the insertion/deletion/change of generated data in a stable storage such as disk in real time, and to use it in case of a failure to return to the final database state. Similarly, the main memory DBMS applied to high-performance systems must guarantee the stability of the database, that is, uninterrupted service in any failure situation. are providing

In addition to the high-speed processing performance and stability of the database, it is important for the database management system to ensure durability. This durability is one of the important ACID (Atomic, Consistency, Isolation, Durability) properties in transaction processing. Upon successful completion (COMMIT), it must be guaranteed that the transaction processing result is reflected in the database in any system error.”

In the conventional disk-based DBMS, when a transaction performed in the DBMS is committed to support such durability, all logs of the transaction must be permanently flushed to the disk. Permanently reflecting logs to disk, which is the slowest medium, has deteriorated the overall performance of the DBMS.

Therefore, in the main memory database management system, in order to provide higher performance even if there is a slight loss in terms of durability, when a transaction is committed, the commit is completed even if the log information of the transaction is reflected only in memory. , and then, through a process (or thread) separate from the process (or thread) performing the transaction commit operation, the logs existing in memory are collected and processed to be permanently reflected on the disk at once.

However, when a transaction is processed in this way, even if the transaction performed by the user is committed, there is a risk that the change history of the committed transaction will disappear if the log of the transaction is not permanently reflected on the disk.

For example, when an unexpected failure occurs in the DBMS due to power failure or OS panic, in the case of a transaction that was committed in memory at the time of the failure but not reflected in disk, the log belonging to the transaction is recorded only in memory. Because it is a state, even if a transaction has already been committed, it may be lost depending on the occurrence of a failure.

The loss of such a transaction causes data inconsistency between the two nodes of the redundant database management system, that is, the active node and the standby node.

Therefore, there is a need for a technique for preventing data inconsistency between two nodes due to a transaction loss due to a failure in the redundant main memory database management system.

The technical problem to be achieved by the present invention is to prevent data inconsistency between the active node and the standby node when a transaction is lost due to a failure in either one of the active node and the standby node in a main memory database management system duplicated with an active node and a standby node It is to provide a database management device and method for managing the database so that

The technical problems to be achieved by the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by those of ordinary skill in the art to which the present invention belongs from the description below. There will be.

In order to achieve the above technical object, the database management apparatus of the active node of the main memory database management system according to the present invention is a memory logging unit that records the database log to which the identification number is assigned in time series in the log buffer of the memory of the active node. ; a replication unit that replicates the recorded database log to the standby node; a disk storage unit for periodically storing the recorded database log on the disk of the active node; And when the failure of the active node occurs, the identification number of the last restored log is transmitted to the standby node, and at least one replication log belonging to the transaction including the loss log recorded after the last restoration log is received from the standby node. It includes a recovery unit that recovers the database of the active node based on the received replication log.

In order to achieve the above technical object, the method for managing a database of an active node of a main memory database management system according to the present invention includes: writing a database log to which identification numbers are assigned in time series in a log buffer of a memory of the active node; replicating the recorded database log to the standby node; periodically storing the recorded database log on a disk of the active node; and periodically receiving, from the standby node, an identification number of a database log corresponding to the replication log stored on the disk of the standby node.

More preferably, when the failure of the active node occurs, transmitting the identification number of the last restored last restoration log to the standby node; receiving, from the standby node, at least one or more all replication logs belonging to a transaction including a loss log recorded after the last restoration log; and restoring the database of the active node based on the received replication log.

In order to achieve the above technical problem, the database management apparatus of the standby node of the main memory database management system according to the present invention receives the database log assigned with the identification number in time series from the active node, and performs it based on the replicated database log a memory logging unit that records database changes that occurred during processing of the transaction as a replication log in the log buffer of the standby node's memory; a disk storage unit for periodically storing the recorded replication log on a disk of the standby node; and a log storage reporting unit periodically reporting an identification number of a database log corresponding to the replication log stored in the disk storage unit to the active node; and when the standby node fails, receiving a recovery replication log that replicates the database log after the database log of the last reported identification number from the active node, and recovering the standby node database based on the received recovery replication log includes wealth.

In order to achieve the above technical problem, a database management method of a standby node of a main memory database management system according to the present invention includes: receiving a database log to which an identification number is assigned time-series from an active node to be copied; recording a database change occurring during processing of a transaction performed based on the replicated database log as a replication log in a log buffer of a memory of a standby node; mapping the replication log with the identification number of the database log corresponding to the replication log and storing it in a transaction table in units of transactions; periodically storing the recorded replication log on a disk of the standby node; and periodically reporting the identification number of the database log corresponding to the replication log stored in the disk to the active node.

According to the present invention, when an unexpected failure occurs in any one of the active node and the standby node, data inconsistency due to transaction loss can be prevented by supporting data recovery of the failed node using information duplicated in other nodes. In addition, data consistency can be maintained without additional user intervention, and ultimately, transaction continuity in the main memory database management system can be guaranteed.

1A is a block diagram illustrating a redundant configuration of a main memory database management system according to a preferred embodiment of the present invention.
1B is a diagram illustrating a database log recorded in a log buffer of a memory in the main memory database management system according to an embodiment of the present invention.
2A to 2C are flowcharts illustrating a method of managing a database to ensure transaction continuity in a main memory database management system according to an embodiment of the present invention.
3A to 3D are diagrams for explaining a process of removing data inconsistency due to transaction loss in the main memory database management system according to an exemplary embodiment of the present invention.

The following is merely illustrative of the principles of the invention. Therefore, those skilled in the art will be able to devise various devices that, although not explicitly described or shown herein, embody the principles of the present invention and are included within the spirit and scope of the present invention. Moreover, it is to be understood that all conditional terms and examples listed herein are, in principle, expressly intended only for the purpose of understanding the inventive concept, and not as limiting to the specifically enumerated embodiments and states as such. should be Moreover, it is to be understood that all detailed description reciting the principles, aspects, and embodiments of the invention, as well as specific embodiments, are intended to cover structural and functional equivalents of such matters. Moreover, it is to be understood that such equivalents include not only currently known equivalents, but also equivalents developed in the future, ie, all devices invented to perform the same function, regardless of structure.

Accordingly, the functions of the various elements shown in the drawings including functional blocks denoted as processors or similar concepts may be provided by the use of dedicated hardware as well as hardware having the ability to execute software in association with appropriate software. When provided by a processor, the functionality may be provided by a single dedicated processor, a single shared processor, or a plurality of separate processors, some of which may be shared. In addition, the use of terms presented as processor, control, or similar concepts should not be construed as exclusively referring to hardware having the ability to execute software, and without limitation, digital signal processor (DSP) hardware, ROM for storing software. It should be understood to implicitly include (ROM), RAM (RAM) and non-volatile memory. Other hardware of common knowledge may also be included.

The above objects, features and advantages will become more apparent through the following detailed description in conjunction with the accompanying drawings. In describing the present invention, if it is determined that a detailed description of a related known technology may unnecessarily obscure the gist of the present invention, the detailed description will be omitted or briefly described.

On the other hand, when a part "includes" a certain component, this means that other components may be further included, rather than excluding other components unless otherwise stated.

Hereinafter, the present invention according to a preferred embodiment will be described in detail with reference to the accompanying drawings.

1A is a block diagram illustrating a redundant configuration of a main memory database management system according to an embodiment of the present invention, and FIG. 1B is a database recorded in a log buffer of a memory in the main memory database management system according to the present embodiment. A diagram illustrating a log.

Referring to FIG. 1A , the main memory database management system according to the present embodiment is duplicated into an active node 110 and a standby node 120 to ensure the stability of the database.

The active node 110 according to this embodiment includes a memory logging unit 114, a replication unit 115, a disk storage unit (116), a recovery unit 117 and a recovery information management unit 118.

The memory logging unit 114 records the database log in the log buffer of the local memory 111 .

The database log records changes in the state of the database that occur during transaction processing such as insertion/deletion/change of data or transaction control. be able to keep

1B, the database log 130 according to the present embodiment includes an identifier (TID, 131) of a transaction to which the log belongs, and an identification number (SN, 132) that is time-series assigned to the log, When the database management system commits or recovers the transaction to which the database log belongs, it is possible to determine the transaction to which the log belongs and the execution order of the log.

The replication unit 115 copies the database log recorded in the memory logging unit 114 to the standby node 120 through the communication interface 113 .

The replication unit 115 duplicates the database log including the identification number of the transaction to which the database log belongs and the identification number of the database log and transmits it to the standby node.

The disk storage unit 116 periodically stores the database log recorded in the memory logging unit 114 in the local disk 112 .

The database log storage process performed by the disk storage unit 116 may be performed independently of commit of a transaction including the database log and replication of the database log. For example, the user of the database management system may be set by inputting the storage period of the database log as an absolute time value as an environment setting value of the database management system.

The recovery unit 117 transmits the identification number of the last restored log to the standby node 120 through the communication interface 113 when a failure of the active node 110 occurs, and in response to this, the standby node 120 At least one or more all replication logs belonging to a transaction including a loss log recorded after the last restoration log are received from the communication interface 113, and the database of the active node 110 is restored based on the received replication log.

The recovery information management unit 118 is a component that supports recovery of the counterpart node's database by sending database logs belonging to the transaction determined to be lost in the counterpart node to the counterpart node when a duplicated counterpart node fails.

The recovery information management unit 118 of the active node 110 according to the present embodiment is a database corresponding to the replication log stored in the local disk 122 of the standby node 120 periodically from the standby node 120 which is a duplicated counterpart node. The log identification number is reported, stored in the local memory 111, and when the standby node 120 fails, the database logs recorded after the database log of the last received identification number are read, and the read database logs are stored. By replicating to the standby node 120 , it is possible to recover the database of the standby node 120 with a high possibility of transaction loss due to the occurrence of a failure.

The standby node 120 according to this embodiment includes a memory logging unit 124 , a disk storage unit 125 , a reporting unit 126 , a recovery unit 127 , and a recovery information management unit 128 , among which memory The logging unit 124 , the disk storage unit 125 , the recovery unit 127 , and the recovery information management unit 128 are the memory logging unit 114 , the disk storage unit 116 , and the recovery unit 117 of the active node 110 . ) and the recovery information management unit 118 .

The memory logging unit 124 receives the database log replicated from the active node 110 through the communication interface 123 and performs a local transaction on the database of the standby node 120 based on the received database log, and the local transaction performed in this way Accordingly, the database of the standby node 120 records the changed contents as a replication log in the log buffer of the local memory 121 .

That is, the "replication log" in this embodiment is not a copy of the database log itself received from the active node, but is newly stored in the log buffer of the local memory of the standby node according to the change of the database by the transaction performed based on the copy. It means the log being logged. In this embodiment, the identification number of the replication log recorded in the log buffer of the standby node 120 may be assigned time-series independently from the identification number of the database log recorded in the log buffer of the active node 110. .

Accordingly, in order to prevent data inconsistency between the active node 110 and the standby node 120 and to maintain data consistency, the memory logging unit 124 maps the identification number of the database log corresponding to the replication log and the replication log. Thus, it can be stored in the transaction table of the local memory 121 in units of transactions. For example, when the identification number of the database log and the identification number of the replication log are allocated differently, it is preferable to map the identification number of the database log and the identification number of the replication log to be stored.

The disk storage unit 125 periodically stores the replication log recorded in the log buffer of the local memory 121 in the local disk 122 .

The log storage reporting unit 126 periodically reports the identification number of the database log corresponding to the replication log stored in the disk storage unit 125 to the active node 110 .

The recovery unit 127 receives, through the communication interface 123, a recovery replication log that replicates the database log after the database log of the last reported identification number from the active node 110 when the standby node 120 fails. , restores the database of the standby node 120 based on the received replication log for recovery.

The recovery information management unit 128 is a component that supports recovery of the counterpart node's database by sending database logs belonging to the transaction determined to be lost in the counterpart node to the counterpart node when a duplicated counterpart node fails.

The recovery information management unit 128 of the standby node 120 according to the present embodiment may include a log search unit (not shown) and a duplicate log transmission unit (not shown).

The log search unit (not shown) receives, through the communication interface 123, the identification number of the last restored log from the active node 110 when a failure of the active node 110, which is a duplicated counterpart node, occurs through the communication interface 123, and stores the transaction table. As a basis, all replication logs belonging to the transaction including the loss log after the last restoration log are searched.

The replication log transmission unit (not shown) transmits the replication log searched for by the log search unit (not shown) to the active node 110 through the communication interface 123, thereby causing a transaction loss due to the occurrence of a failure. ) to recover the database.

2A to 2C are flowcharts illustrating a method of managing a database to ensure transaction continuity in an active node and a standby node of the main memory database management system according to an exemplary embodiment of the present invention.

The active node 210 and the standby node 220 according to the present embodiment correspond to the active node 110 and the standby node 120 of the main memory database management system shown in FIG. 1 , respectively. Accordingly, reference is made to the same matters as in the description of the main memory database management system shown in FIG. 1 .

Of these, FIG. 2A illustrates a flow of a data management method in a daily situation in which a failure does not occur in either one of the active node 210 and the standby node 220 according to the present embodiment.

First, referring to FIG. 2A , the active node 210 records a database log related to a state change of the database in a log buffer of a local memory ( S201 ).

The active node 210 copies and transmits the database log recorded in step S201 (S202).

And, independently of the transmission of the replication log in step S202, the database log recorded in step S201 is periodically stored in the local disk (S203).

Since the storage on the disk in step S203 is performed independently of the replication and transmission of the database log in step S202, the execution order may be reversed or may be performed simultaneously, but the present invention is not limited thereto. However, since the storage to the disk of step S203 may become a factor of lowering the performance of the entire database management system as the frequency of its execution increases, it is preferable to perform batch processing for a plurality of database logs with as low a frequency as possible. do.

The standby node 220 performs a transaction based on the database log replicated through step S202 (S204), records changes in the local database that occurred during transaction processing in the log buffer of the local memory (S205), and the database log The identification number and the replication log are mapped and stored in the transaction table of the local memory in units of transactions (S206).

In this case, when the standby node 220 allocates the identification number of the replication log differently from the identification number of the database log, the identification number of the database log and the identification number of the replication log may be mapped and stored on the transaction table.

Then, independently of the storage in the transaction table in step S206, the replication log recorded in step S206 is periodically stored in the local disk (S207).

Since the storage in the disk in step S207 is performed independently of the storage in the transaction table in step S206, the execution order may be reversed or may be performed simultaneously, but the present invention is not limited thereto. However, since the storage to the disk of step S207 can become a factor that degrades the performance of the entire database management system as the execution frequency increases, it is recommended to be performed on a plurality of replication logs at a low frequency as much as possible. desirable.

And, when the storage on the disk in step S207 is completed, in order to report this, the identification number of the database corresponding to the replication log stored on the disk is periodically reported to the active node (S208). This may be transmitted by generating a separate report message, or may be transmitted by attaching it to a reception success confirmation message (ACK) for transmission of the replicated database log in step S202.

2B illustrates a flow of a method of recovering a database of the active node 210 in a situation in which a failure occurs in the active node 210 according to the present embodiment.

First, when the active node 210 recognizes the occurrence of a failure (S211), it is reflected on the disk or stored in the non-volatile memory area to restore the database log that is not lost (S212), and is stored in such local memory and storage. After the restoration operation based on only the existing information is completed, the identification number of the last restored log is transmitted to the standby node 220 (S213).

The standby node 220 searches for a transaction including a loss log after the last restoration log of the identification number received in step S213 based on the transaction table in the local memory, and searches all replication logs belonging to the searched transaction (S214).

Then, the replication log found in step S214 is transmitted to the active node 210 (S215).

The active node 210 recovers a lost transaction on the database based on the replication log received through step S215 (S216).

FIG. 2C illustrates a flow of a method of restoring a database of the standby node 220 in a situation in which a failure occurs in the standby node 220 according to the present embodiment.

First, when the active node 210 recognizes the occurrence of a failure (S221) of the standby node 220 (S222), the database log of the last received identification number among the identification numbers reported through the step S207 from the standby node 220 After that, the database log recorded in the log buffer of the local memory is read through step S201 (S223).

The active node 210 transmits a replication log obtained by copying the database log read in step S223 (S224).

The standby node 220 recovers the replication log or transaction lost because it is not reflected on the disk on the database based on the replication log received through step S224 (S225).

3A to 3D are diagrams for explaining a process of removing data inconsistency due to transaction loss in the main memory database management system according to an exemplary embodiment of the present invention.

3A is a diagram showing four transactions Tx1, Tx2, Tx3, and Tx4 having different life cycles in the main memory database management system according to the present embodiment in a normal situation in which a failure does not occur from an active node to a standby node (Standby host) ) to illustrate the process of replication.

Transactions occurred in the order of Tx1, Tx2, Tx3, and Tx4 in the active node, and transactions are committed in the local memory in the order of Tx3, Tx1, Tx2, and Tx4. Logs belonging to each transaction are replicated to the standby node in the order in which they are recorded. Accordingly, the transactions Tx1', Tx2', Tx3', and Tx4' of the standby node correspond to the transactions Tx1, Tx2, Tx3, and Tx4 of the active node, respectively, and occur in the same order as the transaction generation and commit order of the active node. and committed.

And among these transactions, a situation in which all logs of Tx3 and Tx1 and only some logs of Tx2 are flushed to the disk is exemplified. exemplify the situation

Referring to FIG. 3B , a failure occurs before the commit logs for Tx2 and Tx4 in the active node are reflected on the disk, and the logs recorded in the memory are lost. It is recognized as a transaction that has not been done, and a situation in which Tx2 and Tx4 are lost occurs. Also, this may cause data inconsistency between the active node and the standby node. This is a problem that occurs because the main memory database management system supports commits in memory.

FIG. 3C illustrates a situation in which a failure occurs in the standby node in the situation illustrated in FIG. 3A .

Referring to FIG. 3C , in the standby node, similarly to the occurrence of a failure in the active node, a failure occurs before the commit logs for Tx2' and Tx4' in the standby node are reflected on the disk, and the logs recorded in the memory are lost. When it is restarted, Tx2' is undone and disappears, and since no log is recorded in the log buffer of memory, Tx2' and Tx4' are lost like the active node.

Also, after the system is restarted and the restoration process is performed, the active node attempts to connect to the standby node. If the connection is successful, the active node replicates the log again from the log after the previously replicated log.

That is, the active node has transmitted all of the logs belonging to Tx2 and Tx4, and the standby node recognizes that both have been committed, and the replication execution time is set to a time point after Tx4. Logs belonging to Tx2 and Tx4 are not transmitted again, resulting in data inconsistency between the active node and the standby node. This is also a problem that occurs because the main memory database management system supports commits in memory. Therefore, in this embodiment, the standby node periodically reports the identification numbers of the logs reflected on the disk to the active node, and when the active node recognizes the failure of the standby node, replication is performed again from the log after the reported log. By doing so, these problems are solved.

Fig. 3d illustrates a process of resolving data inconsistency through the data management method according to the present invention in the situation illustrated in Fig. 3b.

Referring to FIG. 3D , the standby node according to the present embodiment maps the identification number of each replication log of the standby node logged according to the transaction performed based on the database log of the active node and the replicated log, and maps it to a transaction unit. Create a transaction mapping table to store.

In the transaction mapping table according to this embodiment, the identification numbers of all logs belonging to the transaction are not stored, but the identification numbers of the start log and the commit log of the transaction are exemplified, but this is only one embodiment. The invention does not limit this.

When the active node fails and all logs and transactions Tx2 and Tx4 recorded later in database 7 are lost, the active node according to this embodiment transmits a message that the identification number of the last restoration log is 6 to the standby node, , the standby node that has received this detects the transactions Tx2 and Tx4 to which the database log 7, 8, and 9 following database log 6 belong, and transmits the replication log of the logs belonging to this to the active node, and the active node based it to recover the database, and to resolve data inconsistencies with the standby node.

As such, according to the present invention, when an unexpected failure occurs in any one of the active node and the standby node, data inconsistency due to transaction loss is prevented by supporting data recovery of the failed node using information duplicated in other nodes. data consistency can be maintained without additional user intervention, and ultimately, the continuity of transactions in the main memory database management system can be guaranteed.

The database management method of the main memory database management system according to the present invention can also be implemented as computer-readable codes on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. include In addition, the computer-readable recording medium is distributed in a computer system connected through a network, so that the computer-readable code can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention pertains.

Although the present invention has been described with reference to one embodiment shown in the accompanying drawings, this is merely exemplary, and those skilled in the art will appreciate that various modifications and equivalent other embodiments are possible therefrom. you will understand Accordingly, the true scope of protection of the present invention should be defined only by the appended claims.

Claims (3)

In the database management apparatus of the active node of the main memory database management system duplicated into an active node and a standby node,
a memory logging unit for recording, in a log buffer of the memory of the active node, a database log to which identification numbers are assigned in time series;
a replication unit for replicating the recorded database log to the standby node;
a disk storage unit for periodically storing the database log on the disk of the active node independently of replication of the database log and the commit of a transaction including the database log; and
When the failure of the active node occurs, the database of the active node is restored based on the database log stored on the disk of the active node and not lost, and the identification number of the last restored log is transmitted to the standby node, and the Receives from the standby node at least one or more all replication logs belonging to a transaction including the loss log recorded after the last restoration log, and is committed in the memory of the active node based on the received replication log but is stored on the disk of the active node. and a recovery unit to recover lost transactions before they are saved;
The replication log records database changes occurring during the processing of a transaction performed based on the replicated database log in the standby node in a log buffer of the standby node's memory, and an identification assigned separately from the identification number of the log of the database. Database management device of the active node, characterized in that it has a number. The method of claim 1,
The identification number of the database log is assigned to increase in time series,
The database management apparatus of an active node, characterized in that the lost log is a database login having an identification number greater than the identification number of the last restoration log. The method of claim 1,
The standby node periodically reports the identification number of the database log corresponding to the replication log stored on the disk of the standby node, and when the standby node fails, after the database log of the last received identification number among the reported identification numbers The apparatus for managing the database of an active node according to claim 1, further comprising: a recovery information manager configured to replicate recorded database logs to the standby node and restore the database of the standby node.

Images