KR20020075062A - A Method of Database Replication - Google Patents

Abstract

PURPOSE: A method for a database replication is provided to copy modified contents of a database(local database) with respect to many databases which are physically located at different portions into other databases(remote database). CONSTITUTION: Replication transmitters created by replication managers try a connection to replication receivers of a priority database server(S101,S102). If a replication receiver is connected, the replication transmitter transmits information of tables which participate in a replication to the replication receiver, receives a replication constraint condition checking result, and checks a success or not(S103). A replication starting point is adjusted and the position thereof is stored in a corresponding replication object(S104). It is checked whether a replication terminating request exists from a user database server or other database server(S105). If a replication terminating request does not exist and a replication LSN(XLSN, LSN: log sequence number) is not identified with the current LSN of the database server(S107), a log record of the XLSN position is obtained in a database log, and the XLSN value is increased(S108). If the obtained log record is not a data modification or transaction control log(S109), the stage is returned to the above (S105) stage. If the obtained log record is a data modification or transaction control log and a log record type is a transaction starting log, a transaction is registered in a replication transaction table.

Description

A method of database replication

The present invention relates to a database replication method for replicating changes of one database (local database) to other databases (remote databases) for a plurality of physically separated databases. Definition and operation of redundancy through a convenient redundancy user interface, introduction of the concept of a replication object, detection and response to failures or network disconnections between redundant systems, and a database based on a database change log It relates to a redundancy method.

Redundancy of the database is intended to reliably serve the database. For example, in the case of CDMA subscriber service, a home location register (HLR) system that manages mobile subscriber service is responsible for subscribers (usually hundreds of thousands) registered to it. I am in charge of the service. If this HLR system goes down in any event, it will not be able to serve the subscribers it manages while the system is being recovered. Therefore, most mobile communication companies realize uninterrupted service by copying data managed by HLR system to other HLR system and moving subscriber service to the system that is immediately copied if one HLR system fails during operation.

Referring to FIG. 1, a general method of database duplication is to change a database 16a or 16b in a different system to reflect the contents in a counterpart database (ⓕ). When the application service 17a is not possible due to the failure of the other database server 10b can perform the same application service 17b instead.

In more detail, the most primitive method of the prior art for duplication is duplication at the application level, which applies the same query to both database servers 10a and 10b (ⓖ, ⓗ). . This method not only reduces the redundancy performance but also makes it difficult to guarantee the consistency of the databases 16a and 16b against the occurrence of failure of the network and the database servers 10a and 10b.

In addition, the database query word processed by the local database server 10a is transmitted to the remote database server 10b, and database replication is performed in the form of processing the query word by the remote database server 10b (ⓐ). In this method, the same query is executed on both sides, so there is less load balance effect, and queries such as inserting the contents of a table that does not exist in the counterpart database into a duplicate table cannot be duplicated. There are many problems.

On the other hand, the redundancy is performed at the execution plan level (ⓑ), and the performance of applying redundancy on the counterpart system is lower than that of (ⓐ) because it does not go through steps such as parsing and validity checking. It is difficult to guarantee the locality of the system because the performance of the system is degraded due to communication and interference with the system, and the execution plan is larger in size than the SQL statement or the log. Redundancy by replacing the log stored on disk with SQL type (ⓒ) has the advantage of guaranteeing the locality of the system. However, the cost of constructing SQL by combining logs is high, and the query is re-applied to apply redundancy on the other server. It is expensive to carry out.

In addition, the change log of the local database 16a is sent to the remote database server 10b, and the log is processed at the data storage manager level to perform redundancy (ⓔ). The change log of the local database 16a is performed. The record itself is transmitted to the remote database server 10b to reflect this log to the database 16b, and the databases 16a and 16b are duplicated in the same manner as the database recovery procedure. However, this means that both the local database 16a and the remote database 16b must have the same logical structure. That is, since all record identifiers (RIDs) must be the same for both, the duplication method is very complicated, there are many restrictions for duplication, and there are many inconveniences to use. For example, in the redundancy between two databases 10a and 10b, it is difficult to change both databases 10a and 10b at the same time, and in most cases, only a change of the local database 10a is provided. Therefore, this method has a problem in that it can be operated mostly in the form of active-standby.

Accordingly, the present invention is to solve such a problem, the present invention is to change the local database in defining a replication object using a database replication interface of a structure such as SQL, and performing the replication using this object as the basic information Transmit the log to a remote server by converting the log into a redundant record, and the remote server replicates the duplicate record as if its data storage manager handled the transaction, improving the ease of use, improving the performance of the replication, server or Its purpose is to provide database redundancy methods to detect and cope with network failures, and to make databases consistent.

1 is a conceptual diagram of a general database redundancy method;

2 is a hardware configuration diagram to which a database duplication method according to the present invention is applied;

3 is a conceptual diagram for implementing a topology of a database redundancy method according to the present invention;

4 is a diagram illustrating a database redundancy structure between servers implementing a database redundancy method according to the present invention;

5 is an explanatory diagram of a user interface of a database redundancy method according to the present invention;

6 is a configuration diagram of a redundant object used in a database duplication method according to the present invention;

7 is a block diagram of an item participating in the duplication using the database duplication method according to the present invention;

8A to 8C are flowcharts illustrating operations of a redundant sender to which a database duplication method according to the present invention is applied;

9 is an operation flowchart of a redundant receiver to which a database replication method according to the present invention is applied.

<Explanation of symbols for the main parts of the drawings>

20a, 20b: Computer system 21a-21n: Processor

22: memory area 23: auxiliary storage device

30: local database 31 ~ 33: remote database

40a, 40b: database server 41a, 41b: replication manager

42a, 42b: redundant receiver 43a, 43b: redundant transmitter

In order to achieve the above object, the present invention provides a method for generating a duplicate object, the method comprising: storing information about a duplicate object and a table participating in the duplicate in a duplicate meta table of a database using a predetermined command; Handshaking by a duplication manager of a local database server and a remote database server to meet a condition for performing duplication; Transmitting, by the replication sender of the local database server, a replication record of a unique log using a database change log to the remote database server; Reflecting the unique log received by the redundant receiver of the remote database server through the transaction processing technique of the redundant administrator in its database; Detecting and responding to a failure of the system or the local database server or the remote database server and disconnection of the network during the redundancy; And automatically reflecting the duplicated contents that could not be reflected in the opposite database after the failure is recovered.

Preferably, the predetermined command is a command having a structure similar to SQL.

Preferably, the handshaking step is characterized in that the replication manager of the local database server to complete the replication preparation by performing a connection with the replication manager of the remote database server and confirm the replication constraints between each other.

Preferably, the unique log is characterized in that the redundant login XLOG.

Another aspect of the invention is a duplication method for replicating a local database to a remote database in real time, comprising: providing a user interface of a predetermined command to define and operate database duplication; Introducing a redundancy object to store information on redundancy in the local database or the remote database for operation management; Maintaining a duplicate transaction table for concurrency of normal and duplicate transactions; Creating a redundant log of a unique log by using a database log to minimize redundant data to be transmitted; Removing a search transaction and transmitting only a transaction including a database change log to a counterpart database server to improve communication speed; And setting a redundancy restart position to ensure consistency between the redundant databases from server or network failure.

Preferably, the predetermined command is characterized in that the command of the SQL statement form.

Preferably, the unique log is characterized in that the XLOG.

Another feature of the present invention, the redundant sender generated by the replication manager first attempts to connect with the replication receiver of the counterpart database server; Examining whether there is a duplication termination request if the connection fails, if there is no termination request, attempting to connect with the other party again, and terminating the connection attempt with the duplex sender if there is a termination request; If connected to a counterpart redundant receiver, the duplex sender transmits information of tables participating in the duplication to the counterpart duplex receiver, and receives a result of a duplicate constraint check from the counterpart to check whether the counterpart is successful; Adjusting the redundancy starting point from where in the redundancy table to start redundancy if the redundancy constraint is successful, storing the position in the redundancy object, and preparing to transmit redundancy data; Checking whether there is a duplication termination request from the user database server or the counterpart database server, and terminating the duplication transmission if there is a duplication termination request; When there is no duplication termination request in the duplication termination request step, if the duplication LSN is equal to the current LSN of the user database server, checking whether the duplication buffer is empty and moving back to the initial position of the duplication data transmission unit if the duplication buffer is empty; On the other hand, if the XLSN is equal to the LSN, increasing the XLSN value after obtaining a log record of the XLSN position in the database log; And if the obtained log record is not a data change or transaction control log, moves to the initial position of the redundant data transmitter, and processes the data according to a log type if the data change or transaction control log is used.

Preferably, the processing according to the log type may include registering a transaction in a redundant transaction table and moving to a first position of the redundant data transmitter if a log record type is a transaction start log; If the log type is a change log related to deletion, insertion, or modification, determining whether to log in a replication target and checking whether a transaction corresponding to the replication target log exists in a replication table if it is a replication target log; If the transaction does not exist in the replication transaction table, moving to requesting termination of the replication, and if present, determining whether a current change log appears at the beginning of the transaction; Indicating that the transaction is the first if the transaction is first, converting the transaction start log into an XLOG structure, and storing the transaction in a duplication buffer; If the obtained change log does not appear at the beginning of the transaction, converting the change log into an XLOG structure and storing the change log in the redundant buffer and moving to the initial position of the redundant data transmitter; If the type of log record is a transaction termination log, checking whether the transaction corresponding to the transaction termination log exists in a redundant transaction table and whether a data change occurred in the transaction; If a data change occurs in the transaction, storing a termination log in the duplication buffer, adjusting the XLSN to a duplication position, and then removing the transaction from the duplication transaction table; If the transaction is removed from the replication transaction table, the transaction is moved to the initial position of the replication data transmission unit. If no change log occurs in the transaction corresponding to the termination log, the transaction is a search transaction and thus the transaction is removed from the replication table. Moving to the beginning of the redundant data transmitter; Checking whether the redundancy buffer is full before putting XLOG into the redundancy buffer, and if the redundancy buffer is full, transmitting the entire contents of the redundancy buffer to the counterpart server; Adjusting the restart position of the duplication if the transaction remains in the duplication transaction table after the entire contents of the duplication buffer is transmitted to the counterpart server, and if none, setting the XLSN value to the duplication restart position; And if the transaction remains in the redundant transaction table, and if an incomplete transaction remains among the transmitted transactions, the server may recover from the failure if the replication is no longer possible due to a server or network failure, and then restart the transaction again from the beginning. It further includes a step for ensuring consistency between databases by retransmitting.

Another feature of the present invention, the duplication receiver generated by the duplication manager to check whether the communication with the duplex sender of the counterpart database server is in a normal state; If the communication state is not normal in the step, checking the duplication transaction table to withdraw all remaining transactions and ending the duplication reception operation; Withdrawing the transaction remaining in the replication table at the end of the replication reception operation because it is not completed; And if the communication state is normal, receiving the replication log from the counterpart database server, checking whether the replication buffer is empty, and if it is empty, returns to receiving the replication log again, and if not, returns the replication log from the replication buffer. It reads and processes according to each replication log type.

Preferably, the processing according to the replication log type includes: starting the transaction if the type of the replication log is a transaction start log, and registering the transaction in a replication transaction table; If the type of the duplication log is an insert, update, or delete log, searching for a corresponding transaction in a duplication transaction table and reflecting the corresponding transaction in a database according to each log type; And if the type of the replication log is a transaction termination log, terminating the transaction and removing the transaction from the replication transaction table.

Hereinafter, the configuration and operation of the present invention will be described in detail with reference to the accompanying drawings.

FIG. 2 is a hardware configuration diagram to which a database duplication method according to the present invention is applied and includes a single computer system 20a including a plurality of processors 21a to 21n, a memory area 22 of a main memory device, and a secondary memory device 23. As shown in FIG. ) And one or more computer systems 20b similar to this computer system 20a are capable of operating in a networked general hardware environment.

3 is a conceptual diagram illustrating a replication topology of a database replication method according to the present invention.

In Fig. 3, the present invention basically duplicates the databases 30 to 33 in an active-active form. Local database (30: DB-1) can be replicated to multiple remote databases (31: DB-2, 32: DB-3, 33: DB-4), and multiple remote databases (31: DB-2, 32 at the same time). : DB-3, 33: DB-4) can be reflected to the local database (30: DB-1). That is, the present invention supports N: M redundancy between a local database (30: DB-1) and a remote database (31: DB-2, 32: DB-3, 33: DB-4). Provides form of database redundancy.

4 is a diagram illustrating a database redundancy structure between servers implementing a database redundancy method according to the present invention.

In FIG. 4, the redundancy managers 41a and 41b prepare to allow their database server 40a or 40b to duplicate and connect to the remote database server 40b or 40a to perform redundancy. do. The redundant sender 43a, 43b converts the change log into XLOG and transmits it to the remote database server 40b or 40a. The redundant receiver 42a, 42b receives the XLOG received from the counterpart database server 40a or 40b. It is responsible for reflecting the data in its own database. These duplicated senders 43a and 43b and duplicated receivers 42a and 42b are generated as many as the number of duplicated objects in operation, and the corresponding duplicated receivers 42a and 42b and the duplicated senders 43a and 43b are destroyed when specific duplication is stopped. .

5 is an explanatory diagram of a user interface of a database redundancy method according to the present invention.

5, the functions provided by the user interface for performing database replication of the present invention include creation (S50) and deletion (S51) of replication objects, start (S52) and stop (S53) of replication, and replication table. Copy (S54), quick start of redundancy (S55) and the like. These interface specifications follow the SQL form, which is the standard query language of the databases 30 to 33 shown in Fig. 3, so that they are not only very familiar to database users, but also convenient to use. Each function will be described as follows.

The user must first define a replication object before performing the replication task. The basic unit of redundancy is a table. The replication object defines information about which tables of the local database 30 are duplicated to which tables of the remote databases 31 to 33, and uses a statement such as (S50). Where rep1 is the name of the replication object and remotehost and portno are the IP address and port number of the remote server. localtableA is a replication target table name of the local database 30 and localtableB is a replication target table of the remote databases 31 to 33. One redundant object may include several tables and each table of the local database 30 has a 1: 1 correspondence with the tables of the remote databases 31 to 33. You can also define multiple replication objects in one database.

FIG. 6 illustrates redundant objects stored in a database, and FIG. 7 illustrates information about tables included in each redundant object. These are not directly related to the basic principle of the present invention, so detailed description thereof will be omitted.

If you have an interface for creating duplicate objects, you also need a user interface to delete duplicate objects. The present invention deletes the duplicated object created through the drop replication command (S51). When the command is executed, the duplicated object stored in the meta tables of the databases 30 to 33 is removed. For example, if a duplicate object called rep1 is deleted, an object called rep1 (record) in the metatable of FIG. 6 and all objects corresponding to rep1 in the metatable of FIG. 7 are removed.

After defining database replication, use the 'alter replication rep1 start' interface (S52) to perform replication. Then, the tables included in the replication object rep1 are replicated to the corresponding tables in the remote databases 31 to 33. Several replication objects are defined in the local database 30, and in order to duplicate all of them, a replication start command should be performed for each replication object in the same manner as in S52. To stop the replication in progress, use 'alter replication rep1 stop' command (S53), and to stop the desired replication, execute the replication stop command for each replication object.

The 'alter replication rep1 sync' command S54 is used to copy the entire contents of the table of the local database 30 in the replication relationship to the remote databases 31 to 33. When the database servers 40a and 40b are started, even if they have not been duplicated to the remote databases 31 to 33 previously, if you want to duplicate the changed contents from now on, the 'alter replication rep1 quickstart' command Use

Hereinafter, a duplication operation method of the present invention will be described in detail. In this description, it is assumed that duplication is performed between two databases 30 and 31, and one duplication object is defined in each database.

Looking at the operation of the replication manager (41a, 41b), when the startup of the database server (40a, 40b) (startup), the replication manager (41a, 41b) finds the replication object to be activated from the replication metatable to find the replication object Create a duplicate sender (43a, 43b) for and tells the other database server (40b or 40a) that its database server (40a or 40b) is ready to perform the replication. In addition, by waiting for a replication request from the counterpart database server 40b or 40a, if there is a replication request, the replication receivers 42a and 42b are generated. If the user stops the redundancy, the redundancy managers 41a and 41b destroy the redundancy transmitters 43a and 43b.

The operation method of the redundant transmitters 43a and 43b will be described with reference to FIGS. 8A to 8C.

The duplication transmitters 43a and 43b generated by the duplication managers 41a and 41b first attempt to connect with the duplication receivers 42a or 42b of the partner database server 40a or 40b (steps S101 and S102). If this fails, it examines whether there is a duplicate termination request (step S134), and if there is no termination request, attempts to connect with the partner receiver again (step S102). If there is a termination request, the connection attempt with the redundant transmitters 43a and 43b ends. When connected to the other redundant receiver 42b or 42a, the redundant transmitter 43a, 43b transmits the information of the tables participating in the replication to the other redundant receiver 42b or 42a, and receives the result of the duplicate constraint check from the other party. It is checked whether it has been done (step S103). If the redundancy constraint fails, the sender terminates.

If it succeeds in step S103, the process of preparing to transmit the duplicated data is completed by adjusting the redundancy starting point from which to start the redundancy table and storing the position in the duplicated object (step S104).

Next, it is checked whether there is a duplication termination request from the user database server or the counterpart database server 40a or 40b (step S105), and the duplication transmission is terminated when there is a request. If there is no replication termination request, if the replication LSN (XLSN, log sequence number) is the same value as the current LSN of the database server 40a or 40b (step S107), the replication buffer (not shown) is empty. If it checks (step S106) and it is empty, it moves to the initial position (step S105) of a redundant data transmitter (not shown) again. On the other hand, if the XLSN is not equal to the LSN, the XLSN value is increased after acquiring the log record of the XLSN position in the database log (step S108).

If the acquired log record is not a data change or transaction control log (step S109), the controller moves to the initial position of the redundant data transmitter (step S105), and if the data change or transaction control log is processed as follows according to the log type. If the log record type is a transaction start log (step S110), the transaction is registered in the redundant transaction table (step S114), and the procedure moves to the initial position of the redundant data transmitter (step S105).

If the log record type is a change log related to deletion, insertion, or modification (step S113), it is determined whether the target log is a replication target (step S121). If the log record is not a replication target log, the process moves to step S105. It is checked whether a transaction exists in the redundancy table (step S122). If it does not exist, go to step S105. If present, determine whether the current change log appears at the beginning of the transaction (step S123). If so, indicate that it is the first one (step S126), and convert it to a transaction start log XLOG structure and store it in the redundant buffer. The change log is converted into an XLOG structure and stored in a redundant buffer (step S125). If the acquired change log does not appear at the beginning of the transaction, the change log is immediately converted into an XLOG structure and stored in a redundant buffer (step S125). Then, it moves to the initial position (step S105) of a redundant data transmission part.

If the type of log record is a transaction termination log, it is checked whether a transaction corresponding to the transaction termination log exists in the redundant transaction table (step S115) and whether a data change has occurred in the transaction (step S116). If so, the end log is stored in the duplication buffer, the XLSN is adjusted to the duplication position, and the corresponding transaction is removed from the duplication transaction table (step S120). Then it moves to the beginning of the redundant data transmitter. If the change log has never occurred in the transaction corresponding to the end log in step S116, the transaction is a search transaction and thus removes the transaction from the duplicated table (step S120), and moves to the beginning of the duplicated data transmitter.

Before putting the XLOG into the duplication buffer, it is always checked whether the duplication buffer is full (step S117, step S124, step S127). If the redundancy buffer is full, the entire contents of the redundancy buffer are transferred to the counterpart database servers 40a and 40b (step S129). Then, if a transaction remains in the redundancy transaction table, the restart position of the redundancy is adjusted (step S131, step S132). If none, the XLSN value is set to the redundancy restart position (step S133). Remaining transactions in the redundant transaction table means that incomplete transactions remain among the transmitted transactions.

In this situation, if the database server 40a or 40b can no longer be duplicated due to a network failure, after recovering from the failure, the database 30 to 33 is retransmitted from the beginning to the counterpart database servers 40b and 40a. This is to ensure the consistency between the two.

An operation method of the redundant receivers 42a and 42b will be described with reference to FIG. 9.

The duplication receivers 42a and 42b generated by the duplication managers 41a and 41b check whether communication with the duplex transmitters 43b and 43a of the partner database server 40b or 40a is in a normal state (step S201). If the communication state is not normal, the duplication transaction table is checked (step S205), and all remaining transactions are rolled back (step S206, step S207) and the duplication reception operation is terminated. In this state, the remaining transactions in the replication table are incomplete transactions and are therefore withdrawn.

If the communication state is normal, a duplicate log (XLOG) is received from the partner database server 40b or 40a (step S202). It is checked whether the redundant buffer is empty (step S203), and if it is empty, it returns to the state for receiving XLOG again (step S201), and if it is not empty, it reads the XLOG from the redundant buffer (step S204) and writes to each XLOG type. Therefore, process as follows.

If the type of XLOG is a transaction start log (step S208), the transaction is started (step S209), and the transaction is registered in the redundant transaction table (step S210). If the type of XLOG is an insert, update, or delete log (step S214), the corresponding transaction is retrieved from the redundant transaction table (step S215) and reflected in the databases 30 to 33 according to each log type (step S216). If the XLOG type is a transaction end log (step S211), this transaction ends (step S212) and the corresponding transaction is removed from the duplicated transaction table (step S213).

As described above, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims below and equivalents thereof.

As a result, according to the database duplication method according to the present invention the following advantages occur.

In other words, it supports a convenient interface in defining and managing database redundancy, and provides excellent performance by using the replication manager-level transaction processing method of the other server while redundancy based on logs, and provides a redundancy topology of the network structure. Redundancy is also possible. In addition, it detects and responds to failures during redundancy, and reflects database changes that were not reflected after failure recovery to the other database to maintain consistency among the redundant databases and to minimize communication data to be transmitted to the other server. It can improve database stability, non-stop services, and load balancing.

Claims (11)

In creating a replication object, storing information about a replication object and a table participating in the replication in a replication meta table of a database using a predetermined command; Handshaking by a duplication manager of a local database server and a remote database server to meet a condition for performing duplication; Transmitting, by the replication sender of the local database server, a replication record of a unique log using a database change log to the remote database server; Reflecting the unique log received by the replication receiver of the remote database server through the transaction processing technique of the replication manager in its database; Detecting and responding to a failure of the system or the local database server or the remote database server and disconnection of the network during the redundancy; And And automatically reflecting the duplicated contents that could not be reflected in the opposite database after the failure is recovered. The method of claim 1, wherein the predetermined command is Database redundancy method characterized by a command having a structure similar to SQL. The method of claim 1, wherein the handshaking step A replication method of a local database server, in which a replication manager of a remote database server connects with a replication manager of a remote database server and checks a replication constraint between each other to prepare for replication. The method of claim 1, wherein the unique log is Database redundancy method characterized by redundant login XLOG. In a redundant method of replicating a local database to a remote database in real time, Providing a user interface of a predetermined command to define and operate database redundancy; Introducing a redundancy object to store information on redundancy in the local database or the remote database for operation management; Maintaining a duplicate transaction table for concurrency of normal and duplicate transactions; Creating a redundant log of a unique log by using a database log to minimize redundant data to be transmitted; Removing a search transaction and transmitting only a transaction including a database change log to a counterpart server to improve communication speed; And Setting a redundancy restart position to ensure consistency between the redundant databases from a database server or network failure. The method of claim 5, wherein the predetermined command is Database redundancy method characterized in that the SQL statement type command. The method of claim 5, wherein the unique log is Database redundancy method characterized by XLOG. The duplication sender generated by the duplication manager first attempts to connect with the duplication receiver of the counterpart database server; Examining whether there is a duplication termination request if the connection fails, if there is no termination request, attempting to connect with the other party again, and terminating the connection attempt with the duplex sender if there is a termination request; If connected to a counterpart redundant receiver, the duplex sender transmits information of tables participating in the duplication to the counterpart duplex receiver, and receives a result of a duplicate constraint check from the counterpart to check whether the counterpart is successful; Adjusting the redundancy starting point from where in the redundancy table to start redundancy if the redundancy constraint is successful, storing the position in the redundancy object, and preparing to transmit redundancy data; Checking whether there is a duplication termination request from the user database server or the counterpart database server, and terminating the duplication transmission if there is a duplication termination request; When there is no duplication termination request in the duplication termination request step, if the duplication LSN is equal to the current LSN of the user database server, checking whether the duplication buffer is empty and moving back to the initial position of the duplication data transmission unit if the duplication buffer is empty; On the other hand, if the XLSN is equal to the LSN, increasing the XLSN value after obtaining a log record of the XLSN position in the database log; And If the obtained log record is not a data change or transaction control log, moving to the initial position of the redundant data transmitter, and if the data change or transaction control log, processing according to the log type. 9. The method of claim 8, wherein the processing according to the log type is If a log record type is a transaction start log, registering a transaction in a redundant transaction table and moving to a first position of the redundant data transmitter; If the log type is a change log related to deletion, insertion, or modification, determining whether to log in a replication target and checking whether a transaction corresponding to the replication target log exists in a replication table if it is a replication target log; If the transaction does not exist in the replication transaction table, moving to requesting termination of the replication, and if present, determining whether a current change log appears at the beginning of the transaction; Indicating that the transaction is the first if the transaction is first, converting the transaction start log into an XLOG structure, and storing the transaction in a duplication buffer; If the obtained change log does not appear at the beginning of the transaction, converting the change log into an XLOG structure and storing the change log in the redundant buffer and moving to the initial position of the redundant data transmitter; If the type of log record is a transaction termination log, checking whether the transaction corresponding to the transaction termination log exists in a redundant transaction table and whether a data change occurred in the transaction; If a data change occurs in the transaction, storing a termination log in the duplication buffer, adjusting the XLSN to a duplication position, and then removing the transaction from the duplication transaction table; If the transaction is removed from the replication transaction table, the transaction is moved to the initial position of the replication data transmission unit. If no change log occurs in the transaction corresponding to the termination log, the transaction is a search transaction and thus the transaction is removed from the replication table. Moving to the beginning of the redundant data transmitter; Checking whether the redundancy buffer is full before putting XLOG into the redundancy buffer, and if the redundancy buffer is full, transmitting the entire contents of the redundancy buffer to the counterpart server; Adjusting the restart position of the duplication if the transaction remains in the duplication transaction table after the entire contents of the duplication buffer is transmitted to the counterpart server, and if none, setting the XLSN value to the duplication restart position; And If the transaction remains in the redundant transaction table and there is an incomplete transaction among the transmitted transactions, if the server or network failure can no longer be duplicated, after recovering from the failure, the transaction is returned to the counterpart server from the beginning. And resending to ensure consistency between databases. The duplication receiver generated by the duplication manager checks whether communication with the duplex sender of the counterpart database server is normal; If the communication state is not normal in the step, checking the duplication transaction table to withdraw all remaining transactions and ending the duplication reception operation; Withdrawing the transaction remaining in the replication table at the end of the replication reception operation because it is not completed; And If the communication status is normal, the replication log is received from the partner database server. If the replication buffer is empty, the replication log is checked. If the communication status is empty, the replication log is returned to the reception of the replication log. If the communication status is empty, the replication log is returned from the replication buffer. Read and process according to each replication log type. The method of claim 10, wherein the processing according to the duplication log type comprises: Starting the transaction if the type of the replication log is a transaction start log and registering the transaction in a replication transaction table; If the type of the duplication log is an insert, update, or delete log, searching for a corresponding transaction in a duplication transaction table and reflecting the corresponding transaction in a database according to each log type; And If the type of replication log is a transaction termination log, terminating the transaction and removing the transaction from the replication transaction table.