JP2002236602A - Distributed database access processing method at failure of module - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently process an access demand, reducing an influence at the failure of a specific module in a distributed database management system. SOLUTION: The failure of the module is detected by the concerned module Mn. The module Mn gives blocking instructions of a multicasting link between itself and each of other modules M1, M2, etc., and each module blocks the link with the module Mn. The module M1 receiving a transaction from a network performs multicasting communication with a module group excluding the module Mn. Each module checks whether the object transaction exists in the concerned database, and accesses the database if the object transaction exists and returns an access result to the network, but cancels the concerned transaction if it does not exist.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database access processing method in a distributed database management system for managing a plurality of distributed databases when a specific device for managing each database fails.

More specifically, according to the present invention, a database management system that connects to a common channel signaling network, receives a database access processing request (transaction) from the network, and returns corresponding data to the request source is divided into a plurality of parts. Each module contains a common channel signal link connected to a common channel signal network, and receives at least a database access processing request from the link other than itself. The present invention relates to a distributed database access processing method when a module fails in a case where the module has a function of performing multicast communication to another module. In particular, the present invention relates to a database access processing method for minimizing the influence on a database access call even when a specific module fails.

[0003]

2. Description of the Related Art FIG. 1 shows a service control node in an advanced intelligent network (advanced IN) as an example of a distributed database management system. The service control node 100 as the distributed database management system 10 is connected to the exchange 40 via the common channel signaling network 30. The service control node 100
A plurality of database management modules (M) 110 ₁ to 1
10 _n and a coupling mechanism 120 for coupling them. Each of the database management modules 110 _{1 to} 110 _n accommodates the common channel signaling link 20 and is connected to the common channel signaling network 30. The exchange 40 is connected via the common channel signaling network 30
When accessing the service control node 100, it is possible to select and access an arbitrary common line signal link. In the database (DB), location information and authentication information of the mobile phone, a physical number corresponding to a logical number, and the like are stored.
Various types of information for enabling high-performance connection of the telephone are stored.

FIGS. 2 and 3 show a conventional database access processing method in this type of distributed database management system.

FIG. 2 is a diagram showing a first example of a conventional distributed database access method, particularly showing a database access method when multicast communication is not used. FIG. 2A is a diagram showing the operation during normal operation.
The module (M1 in this example) in the service control node 100 that has received the database access request from the network,
A database management module (Mn in this example) holding the access destination data is determined by searching the management table held by itself, destination designation communication (@multicast communication) is performed to the module Mn, and an access request is received. The module Mn that has performed the database access performs a completion response (D
ACK) is returned to the access source module M1, and the read data is returned to the network side. If it is a write request, DACK is similarly returned to the module M1 and write completion is returned to the network side.

FIG. 2B shows the operation when a specific module (Mn) goes down. In this case, the database request received from the network in the module M1 is checked by the module Mn that is down.
Is a request to access the data held by the module, the inter-module communication is not performed, the transaction is treated as a lost call, and a transaction other than the down module Mn (for example, M
If the request is for access to data held by the module 2), access processing to the module M2 is executed in the same manner as in the normal case (,).

FIG. 3 is a diagram showing a second example of a conventional distributed database access method, and shows a database access method using multicast communication for inter-module communication. FIG. 3A is a diagram showing an operation at the time of normal operation. The module M1 that has received a database access request from the network determines all modules M1 including itself without deciding the database management module that holds the access destination data. ＭｎMn performs multicast communication and receives an access request via the communication. Each module checks whether or not the target data exists in a database managed by itself, and if not, the module receives the request. Is discarded, and conversely, if it exists (Mn in this example), a database access is executed, and if it is a read request, a completion response (DACK) is returned to the access source module M1, and the read data is sent to the network. In the case of a write request, return DACK to module M1 and write completion to the network side. To retirement.

FIG. 3B shows the operation when the specific module Mn goes down. In this case, when the module M1 receives a database access request from the network, the module M1 checks whether any database management module in the node 100 is down. The database access request is treated as a lost call, and no multicast communication is executed.

A technique using multicast communication (or broadcast communication or broadcast communication) to access a plurality of distributed destinations is described in the following documents, for example. 1) Makoto Kodera, Akihisa Usui, Satoshi Nakayama, Ei Kawakami: Distributed Database Management System in Wide Area Network, IEICE Technical Report, VOL. 91,
No. 384, p. 9-16 (1991). This document adds a specific site to a broadcast group (CONNECT) or deletes a specific site (DISCONN).
In addition to showing the primitive to perform (ECT), it also mentions how to respond when a specific site goes down. But,
It deals with how to specify the broadcast protocol from the viewpoint of minimizing communication traffic as much as possible to guarantee normal operation by broadcast, and database access processing technology from the viewpoint of minimizing call loss when a specific device fails. It does not mention the specific method of changing the members of the broadcast.

2) Teruharu Joshita, Osamu Takahashi, Tetsuo Sano, Masahide Yamashita, Yukihiro Nakamura, Nagayo Yamauchi, Takayuki Kushida: Highly Reliable Simultaneous Distribution System Applicable to the Internet, Information Processing Society of Japan Research Report, Vol. 95, NO. 117 pp. 9-14
(1995). This document discloses a reliable simultaneous distribution system that can deliver data to a correct registered person without error to a large number of thousands of users, and provides an Internet Protocol (IP) multicast communication function. It expands to realize the connection management function and the error retransmission function with a plurality of partners, but does not disclose a database access processing technology from the viewpoint of minimizing the call loss at the time of failure of a specific device as in the above document. .

3) Chang Y-I, Hwang MH: An
ordered and reliable broadcast protocol fordistrib
uted systems, Computer Communications, vol.
20, no. 6, pp. 487-499, 1997. This document proposes a reliable broadcast protocol using a counter. This protocol circulates a unique token ownership among all nodes in the order specified in the token passing list, and maintains the system state there. However, this document does not disclose a database access processing technique from the viewpoint of minimizing call loss when a specific device fails.

4) Akira Shinoda: Protocol for controlling IP multicast groups, IPSJ research report, VO
L. 98, NO. 84, pp. 99-104 (1998)
Year). This document shows a simple protocol for performing grouping control in data distribution using IP multicast. However, it does not describe a method of controlling a group when a host to be multicast is down.

[0013]

In the above-mentioned conventional distributed database access method at the time of module failure,
In the method of FIG. 2B, the database access request that causes a call loss is kept to a minimum, but since the multicast communication is not used, the module receiving the database access request from the common channel signaling network holds the target data. It is necessary to find the module to be searched by searching the management table. For this reason, each module holds the management table, and as a result, the management table occupies a large amount of main storage area, squeezing the database area, and causing a storage capacity bottleneck against an increase in the number of accommodated users. There is a disadvantage that the number of modules required for an increase in the number of users increases two-dimensionally.

On the other hand, in the method of FIG. 3B, since the multicast communication is used, each module does not need to hold the management table, and there is no problem of increasing the number of management modules. When at least one of the modules is down, all database access requests received from the network are regarded as call losses, and there is a drawback that connection quality is degraded.

[0015] Further, even in the above-mentioned conventional literature related to multicast, there is no specific description of a countermeasure from the viewpoint of reducing the influence of a module failure.

The present invention solves the above-mentioned problems of the prior art, and reduces the influence of a failure of a specific module in a distributed database management system, thereby efficiently processing access requests. It is intended to provide a processing method.

[0017]

According to the present invention, a database management system for receiving a database access processing (input / output) request from a network and returning a corresponding processing result to a request source manages a database divided into a plurality of parts. A plurality of modules and a coupling mechanism thereof, the modules accommodate a line connected to a network, and have a function of performing multicast communication to each module in response to a database access processing request from the line. When a specific module fails in the system,
A database access processing request (transaction) from the network is received via a line accommodated by a normal module, and the module that has received the transaction performs multicast communication using a module group other than the failed module as a multicast group, Each module receiving the transaction checks whether the target transaction exists in the database managed by itself, and if so, accesses the database and performs a database access completion response (DA
CK) is returned to the transmission source, and if there is no transaction, the transaction is discarded.

Further, according to the present invention, when a faulty module is excluded from a multicast group, the fault of the module is detected by the module, and the module instructs each of the other database management modules to block a multicast link between itself and itself. Then, each database management module receiving the instruction performs a procedure of closing a multicast link with a module that is down.

According to the present invention, since the multicast communication is applied to the database access in the distributed database management system, the problem of increasing the number of modules as shown in FIG. Even if a specific module in the management system goes down, the traffic is bypassed so that database access requests are received by other modules, and multicast communication is performed with modules other than the downed module as a group. 3B, the problem of the number of lost calls can be avoided.

Further, when the module is removed from the multicast group in the event of a module failure, the module that has detected the down state notifies the other module as soon as possible,
Since the link connected to the module is blocked, the multicast communication is not terminated by being affected by the module that is down, and the transaction that occurred during that time is not affected.

[0021]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be specifically described below with reference to FIGS. In addition,
An example of a distributed database management system to which the present invention is applied is the service control node 100 in the advanced intelligent network (advanced IN) shown in FIG.

FIG. 4 is a diagram showing a configuration example of each module of the service control node 100 to which the present invention is applied. In FIG. 4, reference numerals 110 _{1 to} 110 _{n denote} database management modules M _{1 to} Mn, and reference numeral 120 denotes a module coupling mechanism (IMC). Each module (M) 110 has an IM
An IMC interface controller (IMCI) 111 having an interface control function with the C120, a network interface controller (NIC) 112 having an interface control function with the network 30, a central processing unit (CPU) 113 executing main processing by software , A main storage device (MM) 114 for holding a database (DB), and the like. The CPU 113 includes, as processing functions related to the present invention, a multicast communication control unit 1131, a database search unit 1132, and a data transmission / reception control unit 1133 with a common channel signal network. Although omitted in FIG. 4, the module is usually provided with a secondary storage device for backup in order to enable restoration when the database is destroyed due to MM failure.

FIG. 5 is a functional block diagram of an embodiment for realizing the multicast communication assumed in the present invention in the module 110. In FIG.
The lower layer is an ATM (up to several MB), and a dedicated transport protocol is provided in the upper layer. Packets received from the upper software (CPU) are copied and transmitted for the number of destinations in the transport layer, and delivery confirmation and retransmission upon NACK reception are performed for each destination. When the ACKs of all the destinations are confirmed, the completion of the multicast is notified from the transport layer to the upper software.

The reason why the method shown in FIG. 5 is adopted is as follows.
In a distributed control system such as the advanced IN service control node 100 shown in FIG. 1, the number of modules is small (20
), And the packet size of the database access request transmitted and received between the modules is relatively small (10 to
0B to 300B) are required at the time of call setting, so that real-time characteristics (up to several tens of ms) need to be guaranteed, and high reliability is required for inter-module communication.

FIG. 6 is a diagram showing a distributed database access processing method when a specific module fails according to the present invention.
Is a diagram showing a processing flow in each module at this time. Hereinafter, the operation will be described in detail with reference to FIGS. The specific module that has failed (down) is Mn. First, a database access request is applied from the common channel signal network 30 to an arbitrary database management module via a line. In this case, since the line accommodated in the down module Mn in the node 100 is closed, an arbitrary line accommodated by another module except this module Mn is selected. It is assumed that the line accommodated by the module M1 has been selected and the module M1 has received an access request. This can be achieved, for example, by known traffic diversion techniques in the network.

The module M 1 receives the access request through the NIC 112 and sends the request to the CPU 113. CPU 113
Then, this access request is sent to the data transmission / reception controller 1133.
To the multicast communication control unit 1131 via
In the multicast communication control unit 1131, the IMCI1
1 is instructed to multicast the access request to all other modules except the module Mn that is down. Thus, the module M excluding the module Mn
The access request is transferred to 1, M2,... On the route of IMCI-IMC-IMCI. Where module M
The down of n occurs asynchronously with the access request, and this is detected by a remote maintenance node (not shown), notified from the node to each database management module, and a multicast connection is performed by a module group other than the down module Mn. Is set (see FIG. 6). A method of forming a multicast group by a module group excluding a down module will be described later. Each module (except Mn) is IMCI111
And passes the received access request to the CPU 113 via the.
The CPU 113 transmits the access request received via the multicast communication control unit 1131 to the database search unit 113.
Then, the database search unit 1132 searches the database based on the access request. If the target data does not exist, the request is discarded. If the target data exists, the access is executed. Then, the CPU 113 transmits the access result to the data transmission / reception control unit 1133 with the network,
Return to the common channel signaling network via 112. The module that accessed the database (M2 here)
Returns a database access completion response (DACK) to the module M1.

FIG. 8 shows an example of the implementation of the method for changing a multicast group according to the present invention in connection with the above steps. FIG. 8 shows an example of a distributed database management system composed of four modules, and shows a procedure for removing the module M4 from the multicast group when the module M4 fails without loss of generality. ing.

FIG. 8A shows a remote maintenance center (RMC).
Similarly, (2) is an example of a method in which a different route is used in the distributed database management system (service control node) in addition to the inter-module communication path in the distributed database management system (service control node). Here, indicates a module down notification, indicates a multicast link blocking notification, and indicates a multicast link blocking. In (1) of FIG. 8,
By following the procedure from, the module M4 is removed. In (2) of FIG. 8, the process is simultaneously performed via the dedicated route, and each of the modules M1 to M3 notified of the process blocks the multicast link to the module M4.

In order to realize the method shown in FIG. 8 (2), for example, each module is connected to a remote maintenance center (RMC).
Utilizing a hardware-controlled communication device that implements an IP protocol provided to communicate with the ISP, a general-purpose switch HUB is used for connection, and the IP address is broadcasted (all).
It is only necessary to specify the “1” pattern) and notify the adjacent module of the down and instruct the link to be closed.

In the reliable multicast communication system premised in the embodiment, a system that can promptly notify the down of a specific module is desirable because the next multicast communication is performed after the acknowledgment of delivery at all destinations is obtained. As for the method, the method via the dedicated route shown in FIG.

FIG. 9 shows an example in which the DB access NG rate with respect to the number of users accommodated in the service control node is evaluated. Here, the down rate of the specific module is 0.000
2, and the module suspension density of the transaction added to the node from the network is set to 10 ⁻² order. Conventional method (Note:
In contrast to case B) of FIG. 3, the NG rate is reduced in the method of the present invention.

[Variations of Embodiments] The embodiments of the present invention are not limited to the above-described ones, and within the scope not departing from the gist, for example, the following various construction methods and modifications are considered, The effect can be obtained. 1) As an example of the system to which the present invention is applied, FIG. 1 shows the service control node. However, the present invention is not limited to this, and any system that manages a distributed database can be similarly applied. For example, a VoIP service (ie,
A call control node (that is, a call agent CA) for realizing a service for transmitting and receiving voice information in IP packets via an IP network, and particularly manages IP address information and related information corresponding to telephone numbers. The present invention is also applicable to an integrated gatekeeper function. 2) The lines distributed and accommodated in the plurality of management modules have been described in the case of the common line signal link, but are not limited thereto, and may be other lines having a similar protocol. 3) A multicast communication protocol between a plurality of modules required for realizing the present invention does not require a special type of protocol, but may be any type as long as it has a delivery confirmation function. 4) Module coupling mechanism between multiple modules (IMC)
May be a bus type or a switch type. It suffices if it has predetermined performance. 5) In the configuration example of each module in FIG. 4, the database (DB) is mounted on the main storage device (MM). However, the place where the database is deployed is limited to the MM. There is no. It may be mounted on a hard disk or a semiconductor file memory as long as the real-time property is not impaired. 6) In the above embodiment, when a specific module has failed, a method using a remote maintenance node has been described as a method of configuring other modules as a multicast communication group. However, the failure of the specific module is detected by some means. Any other module can be used as long as it can block the communication link with the failed module. 7) Exclusive route between modules (2) in FIG. 8 (broken line)
Shows a logical connection relationship, and the network configuration between modules is not limited to a mesh-like or star-like form. 8) In addition, various modifications are possible within the scope of the present invention.

[0033]

As described above, according to the present invention, since multicast communication is applied to database access in a distributed database management system, the number of management modules increases as in the case where multicast communication is not used. Problem is avoided, and when a specific module in the distributed database management system goes down, the traffic is diverted so that a database access request can be received by other modules, and a module other than the downed module is diverted. Are used as a group for multicast communication, so that the problem of an increase in the number of lost calls can be avoided.

When the module is removed from the multicast group in the event of a module failure, the module that has detected the failure notifies the other module as soon as possible,
Since the link connected to the module is closed, the multicast communication does not end due to the module that is down and is not affected by the transaction generated during the termination.

[Brief description of the drawings]

FIG. 1 is a diagram showing an example of a system to which the present invention is applied.

FIG. 2 is a diagram showing a conventional database access method when multicast communication is not used.

FIG. 3 is a diagram illustrating a distributed database access method when using conventional multicast communication.

FIG. 4 is a diagram showing a configuration example of each module in the present invention.

FIG. 5 is a diagram illustrating an example of a functional block of a module that realizes multicast communication.

FIG. 6 is a diagram illustrating a distributed database access method according to the present invention.

FIG. 7 is a diagram showing a processing flow in each module according to the present invention.

FIG. 8 is a diagram showing a multicast group changing method of the present invention.

FIG. 9 is a diagram showing the effect of the present invention.

[Explanation of symbols]

Reference Signs List 10 distributed database management system 20 common line link group 30 common line signal network 40 exchange 100 service control node 110 _{1 to} 110 _n database management module 120 module coupling mechanism

 ────────────────────────────────────────────────── ─── Continuing on the front page (72) Inventor Naoki Takatani 2-3-1 Otemachi, Chiyoda-ku, Tokyo F-term in Nippon Telegraph and Telephone Corporation (reference) 5B075 KK03 5B082 GA08 GB02

Claims (5)

[Claims] 1. A database management system that receives a database access processing (input / output) request from a network and returns a corresponding processing result to a request source is configured including a plurality of database management modules and a coupling mechanism thereof.
Each of the modules accommodates a line connected to the network, and is an access processing method at the time of a module failure in a distributed database management system having a function of performing a multicast communication of a database access processing request from the line to each module. Database access processing request (hereinafter, transaction) is received via a line accommodated by a normal module, and the module that has received the transaction performs multicast communication with a module group excluding the failed module as a multicast group, Each module receiving the transaction checks whether the target transaction exists in the database managed by itself, and if so, accesses the database and returns a database access completion response. Return the DACK) to the source, discards the transaction if it does not exist, distributed database access processing method when the module fault, characterized in that. 2. The distributed database access processing method at the time of a module failure according to claim 1, wherein the module failure is detected by the module, and the module instructs another module to block a multicast link between itself and itself. Performing a distributed database access processing at the time of a module failure, wherein each module receiving the instruction blocks a multicast link between the module and the module that is down. 3. The distributed database access processing method in the event of a module failure according to claim 2, wherein an instruction to block a multicast link from the module that has detected the failure to each of the other modules is issued via a remote maintenance center. Distributed database access processing method at the time of module failure. 4. The distributed database access processing method at the time of module failure according to claim 2, wherein an instruction to close a multicast link from the module in which the failure is detected to each of the other modules is transmitted to the distributed database management system by inter-module communication. A distributed database access processing method in the event of a module failure, wherein the method is performed on a route provided separately from a road. 5. The method according to claim 4, wherein a multicast link block instruction route is provided in each module, and is operated between hardware and the communication control device. A distributed database access processing method at the time of a module failure, wherein the distributed database access processing method is configured by connecting a network to a network.