JP6200387B2 - Redundant system and replication method - Google Patents

Description

  The present invention relates to a master-slave redundancy system and a replication method.

  In a DB / database system with a redundant configuration of master / slave, when double countermeasures are implemented, a redundant configuration of triple (master / slave / slave) and N + 1 (spare unit) It is conceivable to have a configuration.

  Patent Document 1 discloses a technique for preventing an enlargement of a storage area necessary for storing DB difference information in a master / slave redundant configuration.

JP 2013-171483 A

  In the case of a triple (master / slave / slave) redundant configuration, as shown in FIG. 8, in the DB system distributed for each family, a slave is required for each family. There is a problem of increasing.

  Further, in the case of the N + 1 configuration, as shown in FIG. 9, the slave of the family # 1 fails, and after the failure occurs, work for incorporating the spare machine into the family # 1 as a slave occurs. There is a problem that it takes. The work for incorporating the spare machine into the family # 1 includes a master data replication work, a place data setting work such as an IP address, and the like.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to reduce the construction cost of a redundant system and to operate without stopping processing even in the case of a double failure.

In order to solve the above problems, the present invention is a redundant system comprising a plurality of redundant subsystems and a shared DB server, wherein each redundant subsystem includes a master DB server and a first slave. The shared DB server is a second slave DB server shared by the plurality of redundant subsystems, and the master DB server of each redundant subsystem is transferred to the master DB included in the master DB server. If the update has occurred, have rows replication to the first slave DB server and the shared DB server, if the master DB server and the first slave DB server of the redundant sub-system fails, the shared DB server the Operates as a master DB server of a redundant subsystem and the shared DB from other redundant subsystems To stop the replication of the over server.

The present invention is a replication method performed by a redundant system comprising a plurality of redundant subsystems and a shared DB server, each redundant subsystem comprising a master DB server and a first slave DB server, The shared DB server is a second slave DB server shared by each redundant subsystem, and the master DB server of each redundant subsystem includes an update step for updating to the master DB server , and a first slave DB There lines and replication step, the performing replication to the server and the shared DB server, if the master DB server and the first slave DB server of the redundant sub-system fails, the shared DB server, the redundant subsystem Switching step to switch as a master DB server and other redundant subsystems A stop step of stopping the replication to the shared DB server from beam, is carried out.

  According to the present invention, it is possible to reduce the construction cost of a redundant system and to operate without stopping processing even in the case of a double failure.

1 is an overall configuration diagram of a redundant system according to an embodiment of the present invention. It is a block diagram which shows a master DB server structure. It is a block diagram which shows the structure of a 1st slave DB server. It is a block diagram which shows the structure of a shared DB server. It is a figure for demonstrating operation | movement of the redundancy system at the time of normal. It is a figure for demonstrating operation | movement of the redundancy system at the time of a one-system failure. It is a figure for demonstrating operation | movement of the redundancy system at the time of a double failure. It is a figure which shows the redundant structure of triple (master / slave / slave). It is a figure which shows the redundant structure of N + 1.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is an overall configuration diagram of a DB server system (redundant system) of this embodiment.

  The illustrated DB server system includes a plurality of families # 1, # 2, and # 3 (a plurality of redundant subsystems) 1, 2, and 3, and a shared DB server 4, and the DB is distributed for each family. This is a DB server system.

  Each family 1, 2, and 3 operates as a redundant DB of the corresponding SIP servers 5, 6, and 7 (application servers), and includes a master DB server and a first slave server. In the illustrated example, the family # 1_1 is a DB subsystem of the SIP server 5 and includes a master DB server 11 and a first slave DB server 12. Family # 2_2 is a DB subsystem of the SIP server 6 and includes a master DB server 21 and a first slave DB server 22. Family # 3_3 is a DB subsystem of the SIP server 7 and includes a master DB server 31 and a first slave DB server 32.

  In the present embodiment, SIP (Session Initiation Protocol) servers 5, 6, and 7 that perform call processing are used as application servers. However, the application server is not limited to the SIP servers 5, 6, and 7. In the illustrated example, it is assumed that SIP servers are allocated according to telephone numbers, and telephone numbers information (subscriber information, etc.) of corresponding telephone numbers are stored in the families 1, 2, and 3.

  The shared DB server 4 is constructed on the network as a second slave DB server of a plurality of families 1, 2, and 3. As a result, each family 1, 2, 3 has a triple redundant configuration of the master DB server, the first slave DB server, and the second slave DB server (shared DB server 4), and implements countermeasures against double failures. can do.

  FIG. 2 is a block diagram illustrating a configuration of the master DB server 11 of the family # 1_1. The illustrated master DB server 11 includes a destination resolution unit 110, an update unit 111, a replication unit 112, and a master DB 113.

  Upon receiving a destination resolution request (data reference request) including a telephone number from the SIP server 5, the destination resolution unit 110 reads the telephone number information of the requested telephone number from the master DB 113 and transmits it to the SIP server 5. When receiving the data update request from the SIP server 5, the update unit 111 updates the requested data in the master DB 113.

  When the data update process of the master DB 113 by the update unit 111 occurs, the replication unit 112 transmits the update content to the first slave DB server 12 and the shared DB server 4, and updates the update content to the master DB 113 to the first and first 2. Perform replication (synchronization processing) to be reflected in the slave DB. Thereby, the master DB 113 and the first and second slave DBs are always synchronized. The master DB 113 is a DB that stores original original data.

  The master DB servers 21 and 31 of the family # 2_2 and the family # 3 are the same as the master DB server 11 shown in FIG.

  FIG. 3 is a block diagram illustrating a configuration of the first slave DB server 12 of the family # 1_1. The illustrated first slave DB server 12 includes a destination resolution unit 120, an update unit 121, a replication unit 122, and a first slave DB 123.

  The destination resolution unit 120 and the update unit 121 are the same as the destination resolution unit 110 and the update unit 111 of the master DB server 11. Note that the destination resolution unit 120 and the update unit 121 do not operate during normal times. The first slave DB server 12 activates the destination resolution unit 120 and the update unit 121 when the master DB server 11 fails and operates as a master DB server.

  The replication unit 122 receives the update data transmitted from the replication unit 112 of the master DB server 11 and updates the first slave DB 123 so that the first slave DB 123 is synchronized with the master DB 113. The first slave DB 123 is a DB in which a replica (replicated data) of the master DB 113 is stored.

  Note that the first slave DB servers 22 and 32 of the family # 2_2 and family # 3_3 are the same as the first slave DB server 12 shown in FIG.

  FIG. 4 is a block diagram showing the configuration of the shared DB server 4. The shared DB server 4 shown includes a destination resolution unit 40, an update unit 41, a replication unit 42, a replication request unit 43, a master switching unit 44, and a shared DB 45.

  The destination resolution unit 40 and the update unit 41 are the same as the destination resolution unit 110 and the update unit 111 of the master DB server 11. Since one server is used as a shared second slave of a plurality of families, it is necessary to avoid resource depletion. Therefore, the destination resolving unit 40 and the updating unit 41 do not operate during normal times. The shared DB server 4 activates the destination resolution unit 40 and the update unit 41 when the master DB server 11 and the first slave DB server 12 fail and operate as a master DB server.

  The replication unit 122 receives the update data transmitted from the replication unit 112 of the master DB server 11 and updates the family # 1 data of the shared DB 45 so as to synchronize the family # 1 data of the shared DB 45 with the master DB 113. To do.

  The replication request unit 43 transmits a replication request to the master DB server when there is no replication from the master DB server for a predetermined time. When a double failure occurs in the master DB server and the first slave DB server in a certain family, the master switching unit 44 switches itself so that it operates as a master DB server of the family.

  The shared DB 45 is a second slave DB shared by all families. The shared DB 45 shown in the figure includes data for the family # 1, which is a replica (replicated data) of the master DB 113 of the family # 1, and the family # 2. Data for family # 2, which is a replica of the master DB, and data for family # 3, which is a replica of the master DB of family # 3, are stored.

  The master DB servers 11, 21, 31, the first slave DB servers 12, 22, 32 and the shared DB server 4 described above include, for example, a CPU, a memory, an external storage device such as a hard disk, an input device, A general-purpose computer system including an output device can be used. In this computer system, each function of each unit is realized by the CPU executing a predetermined program loaded on the memory. For example, the functions of the master DB server, the first slave DB server, and the shared DB server are as follows: the master DB server CPU in the case of the master DB server program, and the first slave in the case of the first slave DB server program. This is realized by executing the CPU of the DB server and, in the case of a program for the shared DB server, the CPU of the shared DB server.

  The master DB server program, the first slave DB server program, and the shared DB server program are stored in a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD-ROM. Or distributed over a network.

  Next, the operation of this embodiment will be described.

  FIG. 5 is a diagram for explaining the normal operation of the present embodiment. In the illustrated example, a case where data update processing occurs in the family # 1 will be described as an example.

  When receiving the data update request from the SIP server 5, the update unit 111 of the master DB server 11 updates the master DB 113 (S11). The replication unit 112 performs replication to the first slave DB server 12 (S12) and replication to the shared DB server 4 (S13). That is, in order to reflect the update contents to the master DB 113 in the first slave DB 123 and the shared DB 45 (second slave DB for family # 1), a replication instruction including the update contents is transmitted.

  Thereby, the replication unit 122 of the first slave DB server 12 updates the first slave DB 123 based on the update content transmitted from the master DB server 11. Further, the replication unit 42 of the shared DB server 4 updates the shared DB 45 based on the update content transmitted from the master DB server 11. By such processing, the master DB 113, the first slave DB 123, and the shared DB 45 that is the second slave DB are synchronized.

  Further, when the replication request unit 43 of the shared DB server 4 does not receive a replication instruction from the master DB server 11 for a predetermined time, it autonomously transmits a replication request to the master DB server 11 (S14).

  Thereby, the replication unit 112 of the master DB server 11 transmits a replication instruction to the shared DB server 4 when there is unsent replication. On the other hand, when there is no response from the master DB server 11, the replication request unit 43 of the shared DB server 4 detects that the master DB server 11 has failed (failure occurs). Processing after failure detection will be described later.

  FIG. 6 is a diagram for explaining the operation when a single system failure occurs (when the first slave DB server fails) according to this embodiment. In the illustrated example, a case where the first slave DB server 12 of the family # 1 fails will be described as an example.

  When the first slave DB server 12 fails (S21), the master DB server 11 detects the failure, and thereafter operates as a redundant redundant configuration of the master DB 113 and the shared DB 45 (second slave DB).

  That is, after that, when receiving the data update request from the SIP server 5, the update unit 111 of the master DB server 11 updates the master DB 113 (S22). Then, the replication unit 112 performs replication to the shared DB server 4 (S23). That is, in order to reflect the update contents to the master DB 113 in the shared DB 45 (second slave DB for family # 1), a replication instruction including the update contents is transmitted.

  Thereby, the replication unit 42 of the shared DB server 4 updates the shared DB 45 based on the update content transmitted from the master DB server 11. By such processing, the master DB 113 and the shared DB 45 that is the second slave DB are synchronized.

  FIG. 7 is a diagram for explaining the operation at the time of double failure (during both system failures) according to the present embodiment. In the illustrated example, a case where the master DB server 11 and the first slave DB server 12 of the family # 1 have failed will be described as an example.

  Both the master DB server 11 and the first slave DB server 12 fail (S31, S32). As a result, since the replication instruction from the master DB server 11 is not transmitted to the shared DB server 4 for a predetermined time, the replication request unit 43 of the shared DB server 4 transmits a replication request to the master DB server 11. (S33).

  In this case, since the master DB server 11 and the first slave DB server 12 are out of order and there is no response to the replication request in S33, the replication request unit 43 is connected to both the master DB server 11 and the first slave DB server 12. Detect that the system is in failure.

  When a failure is detected, the master switching unit 44 switches the shared DB server 4 to operate as the master DB server 11 of the family # 1 (S34). That is, in order to upgrade to the master DB server, the destination resolution unit 40 and the update unit 41 are activated.

  In addition, the master switching unit 44 notifies the master DB servers 21 and 31 of the other families # 2 and # 3 that the shared DB server 4 operates as the master DB server of the family # 1. 2, access to the shared DB server 4 from # 3 is prohibited (S35). When the master DB servers 21 and 31 of the other families # 2 and # 3 receive the notification from the shared DB server 4, the replication to the shared DB server 4 (second slave DB) is stopped. Thereby, it is possible to avoid resource depletion due to the shared DB server 4 operating as a master DB server.

  In addition, the master switching unit 44 notifies the corresponding SIP server 5 that the shared DB server 4 operates as a master DB server of family # 1. As a result, the SIP server 5 transmits a destination resolution request and a data update request to the shared DB server 4. The destination resolution unit 40 receives the destination resolution request from the SIP server 5, refers to the data for family # 1 stored in the shared DB 45, reads out information related to the telephone number specified in the destination resolution request, Send to server 5. Further, when receiving the data update request from the SIP server 5, the updating unit 41 updates the data for family # 1 in the shared DB 45 (S36).

  After the double failure is recovered, the master switching unit 44 of the shared DB server 4 switches itself from the master DB server to the shared DB server, and stops the destination resolution unit 40 and the update unit 41. Further, the master switching unit 44 notifies the other families # 2 and # 3 that have been prohibited from accessing that the operation as the shared DB server 4 has been resumed (resumption of access). As a result, the master DB servers 21 and 31 of the other families # 2 and # 3 perform replication during the period during which access is prohibited to the shared DB server 4, and the master DB and the shared DB 45 (second slave DB). Synchronize with.

  In the present embodiment described above, redundancy is achieved in a DB server system having a redundant configuration (master / slave) by using one DB server 4 as a shared second slave server of a plurality of families. The efficiency of the configuration can be realized. That is, the construction cost of the redundant system can be reduced, and even if a master / slave double failure occurs, it can be operated without stopping the processing.

  Moreover, in this embodiment, the master DB server of each family always performs replication to the shared DB server 4 to synchronize the master DB and the shared DB. For this reason, in this embodiment, the process of replicating the data in the master DB to the shared DB is not required after a failure occurs, and the shared DB server 4 can be quickly switched to the master DB server. In other words, since the backup is acquired by the replication from the master DB server that is always performed, there is no need for the built-in setting at the time of failure.

  Further, in the present embodiment, even when a master / slave double failure occurs, stable operation can be continued without interrupting application processing by upgrading the shared DB server 4 to a master DB server.

  In addition, this invention is not limited to the said embodiment, A various change and application are possible within a claim.

11, 21, 31: Master DB server 12, 22, 32: First slave DB server 110, 120: Destination resolution unit 111, 121: Update unit 112, 122: Replication unit 113: Master DB
123: First slave DB
4: Shared DB server 40: Destination resolution unit 41: Update unit 42: Replication unit 43: Replication request unit 44: Master switching unit 45: Shared DB

Claims (6)

A redundant system,
A plurality of redundant subsystems and a shared DB server;
Each redundant subsystem includes a master DB server and a first slave DB server,
The shared DB server is a second slave DB server shared by the plurality of redundant subsystems;
Master DB server of each redundant subsystem, if the update to the master DB of the master DB server comprises occurs, have rows replication to the first slave DB server and the shared DB server,
When the master DB server and the first slave DB server of the redundant subsystem fail, the shared DB server operates as the master DB server of the redundant subsystem and the shared DB from other redundant subsystems. A redundant system characterized by stopping replication to the server . The redundant system according to claim 1 , wherein
When the first slave DB server of the redundant subsystem fails, the master DB server of the redundant subsystem replicates only to the shared DB server. The redundancy system according to claim 1 or 2 ,
The redundant system, wherein the shared DB server transmits a replication request to the master DB server when there is no replication from the master DB server for a predetermined time. A replication method performed by a redundant system including a plurality of redundant subsystems and a shared DB server,
Each redundant subsystem includes a master DB server and a first slave DB server,
The shared DB server is a second slave DB server shared by each redundant subsystem,
The master DB server of each redundant subsystem is
An update step for updating the master DB server ;
And replication step of replicating the first slave DB server and the shared DB server, gastric row,
When the master DB server and the first slave DB server of the redundant subsystem fail, the shared DB server
A switching step of switching the redundant subsystem as a master DB server;
And a stopping step of stopping replication from the other redundant subsystem to the shared DB server . The replication method according to claim 4 , wherein
In the replication method, when the first slave DB server fails, replication is performed only on the shared DB server. The replication method according to claim 4 or 5 , wherein
The shared DB server further includes a request step of transmitting a replication request to the master DB server when there is no replication from the master DB server for a predetermined time.

Images