JP3823169B1 - Data control apparatus, system, method, and program - Google Patents

Abstract

A data control apparatus free from bottlenecks in performance and reliability related to data synchronization maintenance is provided.
An integrated control unit provided in one of a plurality of data control devices that respectively control a plurality of databases whose data synchronization is to be maintained includes the plurality of databases for a first access request issued from a client. Determination unit 110 that determines whether or not data synchronization control between them is necessary, and a single access unit 120 that issues the first access request to its own database if it is determined that it is unnecessary, and is determined to be necessary. In this case, all other data control devices are occupied, and the first access request is transferred to all other data control devices and is also issued from its own database and from the other data control device. A cooperation service unit 150 that issues the second access request issued to its own database.
[Selection] Figure 3

Description

  The present invention relates to one of a plurality of data control devices that respectively control a plurality of databases that should maintain data synchronization, and a data control system composed of the plurality of data control devices, and more particularly to maintain data synchronization Regarding technology.

  Conventionally, a two-tier configuration is widely known as an example of the configuration of a distributed database system. A distributed database system employing a two-layer configuration typically includes a plurality of back-end servers that respectively control a plurality of databases, and one or more front-ends that transfer access requests from clients to one of the back-end servers. It comprises an end server and a replication server that maintains and manages data synchronization among the plurality of databases.

  One of computer software for realizing such a database system is PGCluster (see, for example, Non-Patent Document 1).

  FIG. 24 is a block diagram illustrating an example of a device configuration of the distributed database system 9 realized using PGCluster. The distributed database system 9 includes front-end servers 91 and 92, back-end servers 61, 62, and 63, databases 66, 67, and 68, a replication server 71, and a network 80. The databases 66, 67, and 68 may be controlled by the back-end servers 61, 62, and 63 and included in the back-end servers 61, 62, and 63, respectively.

  The front-end servers 91 and 92 are duplicated, and either one of them operates, and an access request issued from a client (not shown) is transmitted to one of the back-end servers 61, 62, 63, for example, in order to distribute the access load. Forward to one.

  The back-end servers 61, 62, and 63 operate in parallel. When receiving an access request from the front-end servers 91 and 92, the back-end servers 61, 62, and 63 determine whether or not data synchronization control between the databases is necessary for the access request. This determination is made based on, for example, whether the access request relates only to data reference or data addition, update, or deletion.

  If it is determined that the access request is unnecessary, the access request is executed only in its own database, and the execution result is returned to the client that issued the access request via the front-end server. If it is determined that it is necessary, the access request is transferred to the replication server 71.

  When the replication server 71 receives the access request, the replication server 71 transmits the access request to the back-end servers 61, 62, and 63. When the back-end servers 61, 62, 63 receive the access request from the replication server 71, each of the back-end servers 61, 62, 63 executes the access request in its own database, and returns the execution result to the replication server 71. When the replication server 71 receives the execution results from all the back-end servers, the replication server 71 transmits the execution results to the back-end server that transferred the access request. The back-end server that has received the execution result returns the execution result to the client that issued the access request via the front-end server.

  According to this configuration, the replication server 71 has only one execution order of access requests to be executed in all the back-end servers in order to maintain data synchronization (in particular, this means that the data contents match). Managed by. The replication server 71 uses, for example, a data queue (not shown) to accumulate access requests received from the back-end servers 61, 62, and 63 in the data queue in the order of reception, and retrieves the access requests in the order of accumulation so that all back-end servers The execution order of access requests is managed by sending to the server.

  As a result, since access requests are executed in the order managed by the replication server 71 in all back-end servers, there is no discrepancy in execution results due to the difference in execution order between the back-end servers, and all databases To maintain data synchronization.

In this way, the conventional database system achieves the distribution of access load and the maintenance of data synchronization.
PGCluster web page, http://pgcluster.projects.postgresql.org/jp/

However, the conventional database system has the following problems.
First, there is a problem that the load for managing the execution order of access requests is concentrated on one replication server. Because of this problem, it is necessary to introduce an expensive and high-performance replication server that matches the performance of the entire system, or to limit the performance of the entire system to the performance of the replication server. That is, it becomes difficult to realize system scalability.

  Second, there is a problem that data synchronization is lost when a replication server fails. To avoid this problem, for example, it is possible to duplicate the replication server or update the only representative database during a replication server failure. In the former case, the system must be more expensive. In the latter case, a complicated process of recovering data synchronization is required by copying the contents of the representative database to another database at the time of recovery.

  The present invention has been made in view of the above problems, has no performance and reliability bottlenecks related to data synchronization maintenance, and can be recovered quickly after temporarily stopping data synchronization. An object of the present invention is to provide a data control device and a data control system.

In order to solve the above problems, a data control device according to the present invention is one of a plurality of data control devices that respectively control a plurality of databases whose data synchronization is to be maintained, and the plurality of data control devices include: When an access request requiring a synchronous control of data among the plurality of databases is received from the client, the priority is determined, and all other data control devices are attempted to be occupied and the occupation succeeds. If, transfers the pre Kia access request to all the other data controller issues a Kia access requests previously for its database, if not successful the occupancy, the occupancy according to the priority The priority data control device to be changed is identified, and the occupation change indicating the identified priority data control device is transmitted to another data control device, and the occupation A cooperative master unit to accept occupation by the priority data control device giving up, the occupancy changes from the data control device that occupies its own data control current is received, it said received discards the current occupancy Link service means for accepting the occupation by the priority data control device indicated by the occupation change .

In addition, the data control device further includes an occupancy acceptance register that holds occupancy acceptance information indicating the data control device that occupies itself, and the cooperation master means indicates the data control device as described above. after updating the occupancy reception information, attempts to the occupation by sending occupancy request to all other data control device, is occupied accept responses from all of the other data controller with respect to occupancy request itself is transmitted when received Ru, performs processing upon successful the occupation, the cooperative service means, when the occupancy request is received from other data control device, also occupied by the occupancy reception information which the data control unit to indicate that no reply occupied acceptance response and updates the occupancy reception information to indicate the other data controller, otherwise, it returns the occupied rejection response It may be.
Further, the occupancy rejection response received by the data control device indicates a contention data control device that is a data control device that occupies the data control device that transmitted the occupancy rejection response, and the cooperation master means When an occupancy rejection response is received for the transmitted occupancy request, the occupancy rejection response is determined based on a comparison between the priority of the contention data control device indicated by the received occupancy rejection response and the priority of the own data control device. The priority data control device to be changed is specified, an exclusive change indicating the specified priority data control device is transmitted, the occupation acceptance information is updated to indicate the priority data control device, and the cooperation service The means is indicated by the received occupancy change when an occupancy change is received from the data control device indicated by the occupancy acceptance information. And updates the occupancy reception information to indicate priority data control unit may transmit the occupation acceptance response to the priority data control device.

According to this configuration, an access request that requires synchronous control of data among a plurality of databases is executed only after successful occupation of all other data control devices. Performed reliably in the data controller. Further, since the new occupancy request is rejected while the occupancy acceptance information represents the occupancy state, a situation where a plurality of access requests are executed in different orders for each data control device can be avoided. As a result, there is no discrepancy in execution results due to the difference in execution order between the data control devices, and data synchronization is maintained in all databases.
When a plurality of such data control devices cooperate, a data control device that does not succeed in occupying all other data control devices actively yields to the priority data control device, and by exchanging occupancy changes, Since other data control devices occupied by the data control device also give up the occupation to the priority data control device, even if the occupation requests compete, deadlock is avoided in cooperation.
Therefore, without using a replicator that manages the execution order in one place, it is possible to guarantee not only the synchronization of data by the two-phase commit method but also the progress of processing reliably.

  In this way, the maintenance of data synchronization itself is distributed, so that a conventional replication server can be omitted. As a result, a bottleneck in performance and reliability related to maintaining synchronization of data is eliminated from the system, and it becomes easy to realize the scalability of the system.

In addition, the cooperation master unit receives the exclusive permission response or the exclusive rejection response from all other data control devices in response to the exclusive request transmitted by itself, and then receives the exclusive data response device and the received exclusive rejection response. Whether or not the contention data control device indicated by each occupies a data control device other than itself is determined based on the received occupancy permission response or occupancy rejection response, and is indicated by the received occupancy rejection response Of the competing data control devices, one that occupies a data control device other than itself and that has a higher priority than the priority of the own data control device may be specified as the priority data control device.

According to this configuration, it is possible to succeed in the occupation by raising the priority as the occupation change destination of the data control device in the state of occupying the data control device other than its own, as compared with the data control device in the state of not being Since the occupancy is preferentially changed to a highly reliable data control device, the conflict can be resolved with less effort.
Further, the occupancy rejection response received by the data control device identifies occupancy ongoing in the data control device that transmitted the occupancy rejection response, and the occupancy acceptance register further includes all data including the own data control device. Common occupancy information for identifying the occupancy accepted immediately before in common with the data control device is held, and the cooperation master means receives the occupancy rejection response in response to the occupancy request transmitted by itself. If the occupancy identified by the occupancy refusal response is the same as the occupancy identified by the previous occupancy information, the occupancy request may be retransmitted to the data control apparatus that transmitted the occupancy rejection response.
According to this configuration, when a new occupancy request is rejected because the access processed immediately before in its own data control device is still being processed in the other data control device, the occupancy request is not immediately failed but is occupied. It is possible to retry. Thereby, the difference in processing timing between the data control apparatuses is absorbed, and the throughput of the system is improved.

  In addition, the cooperation master unit may change its own occupancy to the priority data control device, and then try again the occupancy before the change.

  According to this configuration, when the occupancy change is performed, the data control device itself can retry its own occupancy before the change, instead of immediately notifying the client that the occupancy has failed. Client processing can be reduced.

  In addition, the cooperation master unit and the cooperation service unit may perform other data control according to at least one of the number of data to be transmitted, whether or not to retransmit, and whether or not the transmitted data is a response. You may change the communication protocol used for communication with an apparatus.

  According to this configuration, a good trade-off between communication overhead and reliability can be achieved by switching between, for example, the TCP protocol and the UDP protocol according to at least one of the above conditions.

  In addition, the data control device further includes server state management means for detecting a failure of another data control device by monitoring the presence / absence of data reception for a predetermined time, and the cooperation master means includes data detected as a failure. The success or failure of the occupation may be determined by excluding the control device.

  According to this configuration, since the failed data control device is automatically disconnected from the system, the influence of the failure of one data control device on the entire system is reduced, and service-free operation is possible.

In addition, the data control device further stores one or more access requests in a specific operation mode, and when the operation mode is canceled, takes out the access requests in the order in which they are stored and stores them in its own database. A holding control means for issuing, and in the operation mode, the cooperation service means may store an access request received from another data control device in the holding control means instead of issuing it to its own database. Good.

  According to this configuration, in the operation mode, the data control apparatus accumulates the second access request while normally executing processing related to maintaining data synchronization. It is possible to accumulate in the execution order necessary for maintaining data synchronization.

  When the operation mode is canceled, data synchronization can be quickly recovered by simply executing one or more access requests stored in this manner in the order in which they are stored. Since there is no need to copy data from another database for data synchronization recovery, the larger the database size, the greater the effect of speeding up data synchronization recovery.

  Thus, extremely high practical value is exhibited when, for example, data update is temporarily suspended for database maintenance and then recovered.

  In addition, the data control device may include a connection means to a dedicated network that connects only the plurality of data control devices.

  According to this configuration, communication traffic relating to data synchronization maintenance can be separated into the dedicated network, which is useful for reducing the load on the network used for connection with the front-end server and the client.

  The present invention can be realized not only as a data control apparatus as described above but also as a data control system including the data control apparatus for each of a plurality of databases. In addition, the present invention can be realized as a data control method having steps executed by characteristic means included in the data control device, or further realized as a computer program.

  According to the data control apparatus of the present invention, since the data synchronization maintenance itself is distributed, the conventional replication server can be omitted. This eliminates a replication server that becomes a bottleneck in terms of performance and reliability related to maintaining synchronization of data from the system, thereby facilitating the realization of system scalability.

  It is also possible to automatically disconnect the failed data control device from the system and reduce the influence of the failure of one data control device on the entire system.

(First embodiment)
A data control device and a data control system according to a first embodiment of the present invention will be described in detail with reference to the drawings.

(overall structure)
FIG. 1 is a device configuration diagram showing an example of a distributed database system including a data control system 10 according to the first embodiment of the present invention. The distributed database system 1 is configured by omitting a replication server from a typical distributed database system having a two-layer configuration described in the background art section. FIG. 1 shows front-end servers 41, 42,..., 4m, network 20, databases 31, 32,.

  The data control system 10 is a system that controls access to the databases 31, 32,..., 3n and maintains and manages data synchronization, and includes back-end servers 11, 12,. Here, the back-end servers 11, 12,..., 1 n are an example of the data control device described in the claims.

  The front end servers 41, 42,..., 4m operate independently in parallel, and an access request issued from a client (not shown) is distributed to one of the back end servers 11, 12,. For example, each server function is realized by using independent computer systems. This access request may be described in SQL (Structured Query Language) as an example.

  The back-end servers 11, 12,..., 1 n operate in parallel, and upon receiving an access request from the front-end servers 41, 42,. ,... Is a server function for performing access processing to 3n, and is realized by using, for example, independent computer systems.

  Here, unique server IDs and priorities are defined for the back-end servers 11, 12,..., 1n, and the back-end servers 11, 12,. Assume that priorities are known in advance.

  The databases 31, 32,..., 3 n are general database functions that operate independently and in parallel, and store, manipulate, and output data according to access requests, for example, using independent computer systems. It is implemented using the same computer system as the back-end servers 11, 12,..., 1n. The case where the databases 31, 32,..., 3n are realized as part of the back-end servers 11, 12,.

  The back end servers 12,..., 1n are the same as the back end server 11, and the databases 32,. Hereinafter, the back end server 11 and the database 31 will be described as a representative.

(Back-end server)
FIG. 2 is a block diagram illustrating an example of a functional configuration of the back-end server 11. FIG. 2 shows a database 31 along with the back-end server 11.

  The back end server 11 includes an integrated control unit 100, a network adapter unit 200, a front end communication control unit 210, a back end communication control unit 220, and a timer unit 400.

  The network adapter unit 200 is physically connected to the network 20, and the front-end communication control unit 210 performs communication with the front-end servers 41, 42,..., 4m via the network adapter unit 200, and back-end communication. The control unit 220 executes communication with the back-end servers 12,..., 1n via the network adapter unit 200. This communication may be performed using, for example, one selected from a TCP (Transmission Control Protocol) over IP (Internet Protocol) and a UDP (User Datagram Protocol) based on a criterion described later.

The timer unit 400 notifies the integrated control unit 100 that a predetermined time has elapsed.
The integrated control unit 100 controls the overall operation of the back-end server 11. For example, the integrated control unit 100 may be a software function performed by a computer system that implements the back-end server 11 executing a predetermined program.

(Database)
The database 31 includes a data storage unit 300 and a database control unit 310. The database 31 is realized by appropriately using a well-known technique, and the present invention does not limit the content thereof. For example, the data storage unit 300 is, for example, a hard disk device, and physically stores data. The database control unit 310 is, for example, an SQL interpreter function, and operates the contents of the data storage unit 300 according to the access request.

(Integrated control unit)
FIG. 3 is a block diagram illustrating an example of a functional configuration of the integrated control unit 100.

  The integrated control unit 100 includes a request determination unit 110, a single access unit 120, a cooperation master unit 130, an occupation reception register 140, and a cooperation service unit 150.

  When the request determination unit 110 receives an access request issued by the client from the front-end servers 41, 42,..., 4m via the front-end communication control unit 210, the access request requires data synchronization control in the entire system. In other words, if the access request is executed only by the database 31, it is determined whether or not the data synchronization with the other database is lost. The request determination unit 110 may make this determination based on whether the access request relates to data reference only, or data addition, update, or deletion, for example, as in the conventional case.

  If it is determined that data synchronization control in the entire system is not necessary (that is, data synchronization is not lost even if the access request is executed only by the database 31), the single access unit 120 is activated in parallel. Deliver the access request. When it is determined that data synchronization control is necessary, the cooperation master unit 130 is activated in parallel and the access request is delivered.

  The single access unit 120 issues the access request delivered from the request determination unit 110 to the database control unit 310. When the execution result is received from the database control unit 310, the execution result is returned to the client that is the issuer of the access request via the front-end communication control unit 210. The single access unit 120 itself is not the main part of the present invention and will not be described in further detail.

  First, the cooperation master unit 130 tries to occupy all the other back-end servers 12,..., 1n for the access request delivered from the request determination unit 110. Details of this occupation will be described later. When the cooperation master unit 130 succeeds in the occupation, the access master unit 130 transfers the access request to all the other back-end servers 12,..., 1n via the back-end communication control unit 220 and issues it to the database control unit 310.

  Upon receiving the access request, the cooperation service unit in the back-end server 12,..., 1n issues the access request to its own database control unit, and returns an access response when it finishes executing its own database.

  The cooperation service unit 150 performs processing according to data received from another back-end server, as represented by processing according to the access request. The cooperation service unit 150 performs processing according to the occupancy request, occupancy change, occupancy response, and access response from other back-end servers in addition to the processing according to this access request. Each will be explained in the following related sections.

  These processes may be started in parallel according to the received data by the process of receiving data.

(Occupancy reception information and last occupancy information)
The occupation reception register 140 holds occupation reception information and immediately preceding occupation information. The occupancy reception information and the previous occupancy information indicate the back-end server occupying the back-end server 11 and the access request related to the occupancy, and are used for occupancy control. The occupation reception information can assume a null value indicating that the back-end server 11 is not occupied by any back-end server.

  FIG. 4 is a diagram illustrating an example of the occupation reception information and the previous occupation information held in the occupation reception register 140. The occupation acceptance information represents the request server ID 141 and the request number 142, and the immediately preceding occupation information represents the request server ID 143 and the request number 144.

  The request server ID 141 is a server ID for identifying a back-end server that occupies the back-end server 11, and the request number 142 is a number uniquely assigned to each access request in the back-end server.

  A combination of the request server ID 141 and the request number 142 is called a request ID. The request ID uniquely identifies the access request throughout the data control system 10.

  The occupation acceptance information indicates that the back end server 11 is not occupied by any back end server by a null value (for example, NULL, 'OFF', etc.).

  The immediately preceding occupation information is updated with the exclusive reception information when it is found that the exclusive request indicated by the exclusive reception information has been accepted by all the back-end servers. Thereby, the last occupation information identifies the occupation accepted immediately before in common with all the back end servers including the back end server 11.

  Note that the content of the access request itself (for example, a query described in SQL) is stored in a storage area (not shown) in association with the request ID.

(Linked master part and occupancy list information)
FIG. 5 is a block diagram illustrating an example of a functional configuration of the cooperation master unit 130.

  The cooperation master unit 130 includes a numbering unit 131, an occupation trial unit 132, an occupation list table 133, and a request issuing unit 138.

  When receiving an access request from the request determination unit 110, the numbering unit 131 generates a unique number in the back-end server 11, and delivers the received access request and the generated number to the occupation trial unit 132. The numbering unit 131 is, for example, a counter, and may generate a unique number by incrementing the counter each time an access request is received.

  The occupancy trial unit 132 updates the occupancy reception information in the occupancy reception register 140 with a request ID including a server ID for identifying the back-end server 11 and a number received from the numbering unit 131, and generates an occupancy request including the request ID. By trying to transmit, it tries to occupy all other backend servers 12,.

  When the cooperation service unit in the back-end server 12,..., 1n receives the occupancy request, it receives if the null value is held in its own occupancy reception register (that is, it is not occupied by any back-end server). After the occupancy reception information of the occupancy reception register is updated with the request ID included in the occupancy request, an occupancy response is returned.

  This exclusive response includes a target request ID, a response server ID, and a reception request ID (not shown). Here, the target request ID is a request ID included in the corresponding occupancy request, the response server ID is a server ID that identifies the back-end server that transmitted the occupancy response, and the reception request ID is the back-end server. Is the exclusive reception information held in the exclusive reception register.

  For convenience of explanation, an exclusive response in which the target request ID and the reception request ID are equal is referred to as an exclusive acceptance response, and an exclusive response in which the target request ID and the reception request ID are different is referred to as an exclusive rejection response. Of course, it is possible to clearly indicate the distinction between the exclusive acceptance response and the exclusive rejection response by including values such as “OK” and “NG” in the exclusive response.

  The cooperation service unit 150 receives occupancy responses returned from the back-end servers 12,..., 1 n and collects them in the occupancy list table 133.

The occupation list table 133 holds the received occupation response as occupation list information.
FIG. 6 is a diagram illustrating an example of occupation list information held in the occupation list table 133. The occupation list information represents the target request ID 134, the response server ID 135, and the reception request ID 136 for the occupation response returned from the back end server in response to the occupation request for each occupation request and each back end server.

FIG. 6 shows both backends for an exclusive request for the target request IDid ₁ when the two backend servers identified by server IDs s ₂ and s ₃ are all other backend servers. An occupation success example in which an occupation acceptance response is collected from the server is shown, and an occupation failure example in which an occupation rejection response is collected from the back-end server identified in s ₃ for the occupation request with respect to the target request IDid ₂ is shown.

  Referring to FIG. 5 again, the occupancy trial unit 132 determines that the occupancy is successful when the occupancy acceptance responses are collected from all the other back-end servers within a predetermined time.

  When the request issuing unit 138 determines that the occupation is successful, the request issuing unit 138 transfers the access request identified by the target request ID to the other back-end servers 12,..., 1n via the back-end communication control unit 220, and The access request is issued to the database control unit 310.

  When the cooperation service unit in the back-end server 12,..., 1n receives the access request, it issues the access request to its own database control unit. When the execution in the own database is completed, an access response indicating the execution result is returned.

  The cooperation service unit 150 receives the access response, and records that the access response has been returned, for example, using flag information (not shown) in the corresponding record of the occupation list information.

  The request issuing unit 138 knows completion of access in the entire system by returning access responses from all the other back-end servers 12,..., 1n and the database control unit 310, and forwards the access request from the client. An access result is returned to the end server via the front end communication control unit 210.

  Further, when one or more exclusive rejection responses are collected, the exclusive trial unit 132 attempts to resolve the conflict as follows.

  First, when the reception request ID included in the collected occupancy rejection response is the same as the previous occupancy information held in the reception occupancy register 140 (that is, it is accepted immediately before by all the back-end servers including the back-end server 11). The occupancy trial unit 132 considers that there is no real conflict with the back-end server, and the occupancy trial unit 132 The occupancy request is continued by resending the occupancy request to the back-end server that has transmitted the occupancy rejection response (that is, retrying occupancy).

  Next, when exclusive responses are collected from all the other back-end servers 12,..., 1n and one or more of them are exclusive rejection responses, the back identified by the reception request ID included in the exclusive rejection response Based on the comparison between the priority order of the end server (referred to as a competing server) and the priority order of the back-end server 11, the priority server whose occupancy is to be changed is specified.

  This comparison is performed using a priority order determined between the back-end servers 12,..., 1n and a rank that takes into consideration whether each back-end server occupies a back-end server other than itself. Done.

  As a specific example of such order, the back-end servers 12,..., 1n that do not occupy any other back-end server are arranged in the priority order, and the back-end servers other than their own are occupied at a higher level. It is possible to use a rank defined by arranging the back-end servers 12,...

  In accordance with this order, the occupation trial unit 132 gives priority to a back-end server in a state of occupying a back-end server other than its own, over the back-end servers that are not so, among the competing servers higher than the back-end server 11. The highest competing server is identified as the priority server.

  Whether or not the back-end server 11 occupies a back-end server other than itself can be determined by whether or not one or more exclusive permission responses are collected, and each of the other back-end servers 12, ... Whether or not 1n occupies a back-end server other than itself includes a reception request ID for identifying a back-end server other than the back-end server that has returned the exclusive rejection response to the received exclusive rejection response It can be judged by whether or not.

  Then, the exclusive change information indicating the change to the specified priority server is transmitted from the back-end server 11 and the exclusive reception information of the exclusive reception register 140 is received with the reception request ID included in the exclusive rejection response indicating the exclusive use by the priority server. Update.

  The occupancy change to be transmitted specifically includes the request ID held in the occupancy reception register 140 before the change, and may include the reception request ID included in the occupancy rejection response from the priority server after the change.

  When the cooperation service unit in the back-end server 12,..., 1n receives the occupancy change, the request ID related to the pre-change included in the received occupancy change and the request reception information request held in its own occupancy reception register. If the IDs match, it is determined that the change is an exclusive change from the genuine back-end server before the change, and the own exclusive reception register is updated with the reception request ID related to the change included in the received exclusive change. The exclusive acceptance response is transmitted to the back-end server identified by the request ID.

  On the other hand, when there is no competing server higher than the back-end server 11, the exclusive trial unit 132 does nothing and waits for the conflict to be resolved by the exclusive trial unit in the competing server performing the above-described processing.

  The occupancy trial unit 132 determines that the occupancy has failed when the occupancy success and the occupancy change cannot be performed within a predetermined time.

  If the request issuing unit 138 determines that the occupation has failed, the request issuing unit 138 notifies the front end server that has transferred the access request from the client of the access failure via the front end communication control unit 210.

(Detailed operation of the main part)
The detailed operation of the main part of the present invention will be described below with reference to flowcharts.

  FIG. 7 is a flowchart illustrating an example of the integrated control process performed by the integrated control unit 100.

  When the integrated control unit 100 receives an access request issued from a client (S101), if the access request is executed only by the database 31, whether or not the synchronization of data with other databases is maintained, in other words, For example, the request determination unit 110 determines whether data synchronization control is necessary for the entire system. If it is determined that data synchronization control is not necessary for the entire system (NO in S102), the access request is handed over to the single access unit 120 (S103), and if it is determined that it is necessary (YES in S102). Then, the access request is delivered to the cooperation master unit 130 (S200).

  FIG. 8 is a flowchart illustrating an example of the cooperation master process performed by the cooperation master unit 130.

  When the cooperation master unit 130 receives the access request from the request determination unit 110, the cooperation master unit 130 waits until the occupancy reception information in the occupancy reception register 140 becomes an empty value (that is, until it is released from the occupancy) (S <b> 210). A request ID consisting of a server ID for identifying and a number generated by the numbering unit 131 is registered in the occupancy reception register 140 as occupancy reception information (S202).

  Then, an exclusive trial process is performed (S300). If the occupation is successful (successful in S203), the access request is transferred to the other back-end servers 12,..., 1n (S204), and the exclusive acceptance register 140 The previous occupation information is updated with the occupation reception information (S205). This updated previous occupation information identifies the occupation requested by the back-end server 11 and accepted in common by all the back-end servers.

  Then, the exclusive acceptance information is deleted by updating it with a null value (S206), and the access request is issued to the database control unit 310 to access the database 31 (S207).

  Further, after waiting for an access response to be returned from the other back-end servers 12,..., 1n and the database control unit 310 (S208), the access result is transmitted to the front-end server that transferred the access request from the client (S208). S209).

  If the occupancy has failed (failed in S203), an access failure is transmitted to the front-end server that transferred the access request from the client (S209).

  If the occupancy is changed (changed in S203), the process returns to S201 to try again the occupancy before the change.

  FIG. 9 is a flowchart illustrating an example of the exclusive trial process performed by the exclusive trial unit 132.

  The occupancy trial unit 132 transmits an occupancy request including the request ID indicated by the occupancy reception information held in the occupancy reception register 140 to all the other back-end servers 12,..., 1n (S301), and the timer unit 400 Is started (S302). This occupancy request may be broadcast or sent individually to each backend server.

  The occupancy trial unit 132 refers to the occupancy response having the target request ID that matches the occupancy reception information from the occupancy list information of the occupancy list table 133 (S303), and the occupancy reception register 140 is included in the referenced occupancy response. If there is an occupancy rejection response having the same acceptance request ID as the previous occupancy information (YES in S304), the occupancy request is retransmitted to the back-end server that transmitted the occupancy rejection response (S305).

  After the exclusive responses are collected from all the other back-end servers (YES in S311), the exclusive trial unit 132 indicates that the exclusive success has been obtained (YES in S312) and cooperates. The process returns to the master process (S313).

  If one or more of the collected occupancy responses is an occupancy rejection response (NO in S312), the occupancy trial unit 132 further adds each backend server to a backend other than its own in the priority order between the backend servers as described above. Using a ranking that takes into account whether or not the server is occupied, a priority server whose own occupation should be changed is identified from among the competing servers (YES in S314), and the identified from the back-end server 11 An exclusive change indicating a change to the priority server is transmitted (S321). This occupancy change may be individually transmitted to the back-end server that has returned the occupancy acceptance response to the back-end server 11 or may be broadcast.

  Then, the occupancy reception information in the occupancy reception register 140 is updated (S322), the occupancy change is indicated, and the process returns to the cooperation master process (S323).

  The exclusive trial unit 132 does not collect exclusive responses from all back-end servers (NO in S311), or if there is no priority server to be specified (that is, a competing server higher than the back-end server 11) (S314). NO), the timer unit 400 is referred to. If the time-out has occurred (YES in S315), the exclusive reception information in the exclusive reception register 140 is deleted by updating it with a null value (S331), the occupation failure is indicated, and the process returns to the cooperation master process (S332). If not timed out (NO in S315), the process returns to S303 and continues.

  FIG. 10 is a flowchart illustrating an example of cooperative service processing performed by the cooperative service unit 150.

  When the cooperation service unit 150 receives data from another back-end server (S401), the cooperation service unit 150 determines the type of the received data.

If the received data is an occupancy request (occupation request in S402), the following processing is performed.
If the occupancy reception information in the occupancy reception register 140 is null (YES in S411), the request ID included in the received occupancy request is registered in the occupancy reception register 140 as occupancy reception information (S413), and an occupancy acceptance response is sent. A reply is made (S414).

  Also, when the occupancy reception information and the request ID included in the received occupancy request are the same, that is, when the occupancy re-request currently accepted is received (YES in S412), an occupancy acceptance response is returned (YES in S412). S414).

In other cases (NO in S412), an exclusive refusal response is returned (S415).
If the received data is an access request (access request in S402), the following processing is performed.

  If the request ID included in the received access request matches the request ID of the occupancy reception information of the occupancy reception register 140 (YES in S421), the previous occupancy information is updated with the occupancy reception information (S422). The immediately preceding occupation information after the update identifies an occupation that is requested by a back-end server other than the back-end server 11 and is commonly accepted by all the back-end servers including the back-end server 11.

  Thereafter, the occupancy acceptance information is deleted by updating it with a null value (S423), and the received access request is issued to the database control unit 310 to be executed in the database 31 (S433), and the back end that has transmitted the access request An access response is returned to the server (S434).

  If the request ID included in the received access request and the request ID of the exclusive reception information in the exclusive reception register 140 do not match (NO in S421), nothing is done.

  When the received data is an occupancy response or an access response (occupied response, access response in S402), if the occupancy response is returned for the first time from the back-end server in response to the occupancy request, the occupancy response is transferred to the occupancy list information in the occupancy list table 133. Register additional. In addition, in the case of an exclusive response returned from the same back-end server for the same exclusive request after the second time or an access response, the corresponding record in the exclusive list information is updated (S441).

  If the received data is an occupancy change (occupation change in S402), if the request ID related to the pre-change included in the received occupancy change matches the occupancy reception information held in the occupancy reception register 140 (in S451) (YES), the occupancy acceptance information in the occupancy acceptance register 140 is updated with the request ID included in the received occupancy change (S452), and an occupancy acceptance response is transmitted to the back-end server identified by the request ID (S453).

(Typical example of cooperative operation)
Hereinafter, a typical example of the cooperative operation will be described with reference to a sequence chart.

  FIG. 11 is a sequence chart showing an example of a normal data synchronization operation. The arrows shown in FIG. 11 represent data flows, and the symbols of the corresponding steps shown in the flowcharts of FIGS. A plurality of data flows corresponding to the same step are distinguished by an alphabetic character attached to a code.

  In FIG. 11, when no back-end server is occupied, the back-end server 11 sends an access request determined to require data synchronization control in the entire system to other back-end servers 12 to 1n. An example of running exclusively is shown.

  In this example, first, the request ID included in the occupancy request corresponding to the access request is registered as occupancy reception information in the occupancy reception registers of all the back-end servers, and then all the other back-end servers 12,. After the exclusive acceptance responses from 1n are collected by the back-end server 11, an access request is issued from the back-end server 11, and all the back-end servers execute the access request in their own databases.

  In this way, since the access request is executed only after all back-end servers accept the occupation by the back-end server 11, the access request is surely executed by all the back-end servers. Further, since an occupancy request corresponding to a new access request is rejected even when it is occupied, a situation in which a plurality of access requests are executed in different orders depending on the back-end server can be avoided.

  Since this is true for any access request of any backend server, this configuration maintains data synchronization between all databases. In addition, since the maintenance of data synchronization itself is distributed, the conventional replication server can be omitted. As a result, a bottleneck in performance and reliability related to maintaining synchronization of data from the system is eliminated, and the system scalability can be easily realized.

  FIG. 12 is a sequence chart showing an example of an exclusive retry operation from the same back-end server. Each data flow represented in FIG. 12 is denoted by the same reference numerals as in FIG.

  In FIG. 12, in the state where one of the other back-end servers (for example, the back-end server 12) is occupied by the back-end server 11, the back-end server 11 needs to perform data synchronization control in the entire system. An example in which the determined access request is executed by occupying the other back-end servers 12 to 1n is shown.

  In this example, the first back-end server 12 is still processing the access request processed immediately before in the back-end server 11, and the occupancy reception register of the back-end server 12 has an occupancy corresponding to the immediately preceding access request. A request ID related to a request (not shown) is registered. Therefore, an exclusive rejection response is returned in response to a new exclusive request from the back-end server 11. The data flow related to the previous access request is indicated by a dotted line.

  The back-end server 11 determines that the occupancy that it has accepted immediately before is the back-end server because the reception request ID included in the returned occupancy rejection response is the same as the previous occupancy information held in the reception occupancy register 140 12 knows that it has not been released yet, and resends the occupancy request, thereby succeeding in occupying after the processing of the back-end server 12 is completed. The subsequent operation is the same as in FIG.

  In this way, even when an occupancy refusal response is received, if it is an occupancy refusal related to the occupancy that it has accepted immediately before, instead of immediately occupying failure, by resending the occupancy request, The possibility of successful occupation increases.

  This absorbs differences in processing timing between back-end servers and improves system throughput.

  FIG. 13 is a sequence chart illustrating an example of an operation for changing the occupation to the competing back-end server. Each data flow represented in FIG. 13 is denoted by the same reference numerals as in FIG.

  FIG. 13 shows an example in which the back-end server 11 that knows that the occupation request has competed with a competing server having a higher priority than itself changes its own occupation to that competing server.

  In this example, the back-end server 11 specifies the priority server based on the received exclusive rejection response, and indicates the change from the back-end server 11 to the priority server to the back-end server 12 that has returned the exclusive acceptance response. The occupant is changed to the priority server by transmitting the occupancy change and updating the occupancy reception information in its own occupancy reception register with the reception request ID included in the occupancy rejection response.

  In this way, the back-end server that knows that the occupancy request has competed with the higher-priority back-end server actively changes its occupancy to the priority server. For example, it can be performed more quickly and smoothly than a simple method of waiting for a predetermined time and retrying.

(Change of communication protocol)
The communication between the front-end server and the back-end server and the communication between the back-end servers are performed using one selected from a plurality of communication protocols (for example, TCP and UDP over IP) according to a predetermined standard. I mentioned earlier.

Hereinafter, the criteria for selection and the significance of changing the communication protocol will be described.
FIG. 14 is a flowchart illustrating an example of a communication protocol selection process.

  This communication protocol selection process is a process for selecting one of TCP and UDP, and may be executed by the front-end communication control unit 210 and the back-end communication control unit 220, or may be executed by the integrated control unit 100. The front-end communication control unit 210 and the back-end communication control unit 220 may perform communication according to the communication protocol selected by the integrated control unit 100.

  The criteria for selection by this communication protocol selection process are when the amount of data to be transmitted exceeds a predetermined threshold (YES in S501), in the case of retransmission (YES in S502), and transmitted data Is a response (YES in S503), TCP is selected (S505), and UDP is selected in other cases (S504).

  In general, UDP communication has a characteristic that the amount of data that can be communicated at one time is limited, the processing overhead required for communication is small, and there is no data arrival confirmation function and communication reliability is low, compared to TCP communication. . In view of this characteristic, it is possible to achieve a good trade-off between communication overhead and reliability by changing the communication protocol used in accordance with the above selection criteria.

(Second Embodiment)
A data control apparatus according to the second embodiment of the present invention will be described in detail with reference to the drawings. The data control apparatus according to the second embodiment is also described using an example of a back-end server, as in the first embodiment.

  The back-end server in the second embodiment has the same role in the distributed database system 1 (see FIG. 1) as compared to the back-end servers 11, 12,..., 1n described in the first embodiment. However, it is different in that a server state management function is added. This server state management function is specifically added to the integrated control unit 100 of the back-end server (see FIG. 2) described in the first embodiment.

  Hereinafter, the integrated control unit in the second embodiment will be described in detail.

(Integrated control unit)
FIG. 15 is a block diagram illustrating an example of a functional configuration of the integrated control unit 100a according to the second embodiment. Compared to the integrated control unit 100 (see FIG. 3) in the first embodiment, the integrated control unit 100a has a server status management unit 160 added, a changed request determination unit 110a, and a cooperation master unit. 130a.

  The server state management unit 160 is a unit that detects a failure state by monitoring the presence / absence of data reception from other back-end servers for a predetermined time, and includes a server state table 161 that holds detection results.

  The server status management unit 160 may monitor whether or not the monitoring data that is determined to be periodically exchanged is received, or received in response to transmission of predetermined data such as a status notification request or an occupancy request. The presence or absence of a response to be performed may be monitored.

  FIG. 16 is a diagram illustrating an example of server status information held in the server status table 161. The server status information represents, for each back-end server, a server ID 162, a server status 163 that indicates whether the server is in operation or in failure, and a reception flag 164 that indicates whether or not reception has occurred.

  The server state management unit 160 performs failure detection by executing server state management processing periodically or after predetermined data such as an occupancy request is transmitted, and the server state table 161 according to the detection result. The server state 163 is updated. This server state management process also detects its own failure, as will be described later.

  The request determination unit 110a refers to the server state table 161, and stops accepting access requests from the front-end communication control unit 210 while the server state of the own back-end server is indicated as “failing”. Is added to the request determination unit 110.

  The cooperation master unit 130a refers to the server status table 161, and excludes back-end servers whose server status is indicated as being out of order, and transmits an occupancy request, determination of success / failure of occupancy, and transmission of an access request. Thus, the cooperation master unit 130 is changed.

  Specifically, this change is made in the flowchart of FIG. 9 by changing S301 so that an occupancy request is transmitted only to the back-end server whose server status is indicated as operating, and S304 indicating that the server status is active. Change to determine whether exclusive acceptance responses have been collected from all back-end servers that have been registered, and in the flowchart of FIG. 8, only access the back-end servers whose server status is indicated as operating in the flowchart of FIG. This is accomplished by changing the request to forward.

(Server status management processing)
FIG. 17 is a flowchart illustrating an example of a server state management process performed by the server state management unit 160.

  The server state management unit 160 sets all the reception flags 164 in the server state table 161 to “NO” (S601), transmits a state notification request to all other back-end servers (S602), and sets the timer unit 400 to Start (S603).

  When the status notification response is received (YES in S604), the reception flag 164 is updated to “YES” and the server status is updated to “in operation” for the back-end server that has transmitted the received status notification response. (S605). After the processing of S604 to S605 is repeated until timeout (S606), if the reception flag 164 remains “NO” for all back-end servers whose server status 163 is indicated as “in operation” (S607) YES), the server state 163 of the own backend server is updated to “failing” (S608). Otherwise (NO in S607), the server status 163 is updated to “failed” for the back-end server in which the reception flag 164 remains “NO” (S609).

  According to this configuration, since the failed back-end server is automatically disconnected from the system, the influence of the failure of one back-end server on the entire system is reduced, and service-free operation is possible.

  Here, the example in which the status notification response is returned in response to the status notification request has been described, but the occupation notification returned in response to the occupation request may be monitored, and the server status management unit 160 may monitor the status notification response. It is also possible to consider a modification in which transmission of the status notification request is omitted by transmitting the information spontaneously and periodically.

(Third embodiment)
A data control apparatus according to the third embodiment of the present invention will be described in detail with reference to the drawings. Similarly to the first and second embodiments, the data control apparatus according to the third embodiment is also described using an example of a back-end server.

  The backend server in the third embodiment plays the same role as the backend servers 11, 12,..., 1n in the distributed database system 1 (see FIG. 1) described in the first embodiment. In addition to the server state management function described in the second embodiment, an access request hold function is added. Specifically, this access request hold function is added to the integrated control unit 100 of the back-end server (see FIG. 2) described in the first embodiment together with the server state management function described above.

  Hereinafter, the integrated control unit in the third embodiment will be described in detail.

(Integrated control unit)
FIG. 18 is a block diagram illustrating an example of a functional configuration of the integrated control unit 100b according to the third embodiment. The integrated control unit 100b is different from the integrated control unit 100a (see FIG. 15) in the second embodiment in that a hold control unit 170 is added and the changed request determination unit 110b, cooperation service unit 150b, And a server state management unit 160b.

  The hold control unit 170 is a unit that accumulates one or more access requests in a specific operation mode, and when the operation mode is canceled, takes out the access requests in the order of accumulation and issues them to the database control unit 310. And a request hold queue 171 for accumulating access requests and outputting them in the order of accumulation.

  FIG. 19 is a diagram illustrating an example of access requests stored in the request hold queue 171. The request hold queue 171 holds a request ID 172 and a request content 173 for each access request.

  The hold controller 170 is instructed by the system administrator to start and release the specific operation mode via a system console (not shown), for example. For convenience of explanation, the specific operation mode is called a hold mode, and instructions for starting and releasing the hold mode are called a hold instruction and a resume instruction, respectively.

  The server state management unit 160b adds a function to the server state management unit 160 to update the server state of its own backend server to “pending” and “in operation” in accordance with control from the holding control unit 170. Become.

  The request determination unit 110b restricts acceptance of access requests from the front-end communication control unit 210 while the server status of the own back-end server is indicated as “pending” (for example, a reference-only command such as a dump command). (Accepting only) is added to the request determination unit 110a.

  While the server status of the own backend server is indicated as “pending”, the cooperation service unit 150b does not issue an access request transferred from another backend server to the database control unit 310, but holds the hold control. The cooperation service unit 150 is changed so as to be accumulated in the request hold queue 171 of the unit 170. And the cooperation service part 150b operate | moves similarly to the cooperation service part 150 except this change.

  FIG. 20 is a flowchart illustrating an example of the cooperative service process performed by the cooperative service unit 150b.

  When the access request is received (access request in S402) and the server state of the backend server is “pending” (YES in S431), the cooperation service unit 150b sends the received access request to the request hold queue. 171 is registered (S432), and only when it is not “pending” (NO in S431), the received access request is issued to the database control unit 310 (S433). Other operations, particularly operations related to occupation, are the same as the operations of the cooperative service unit 150 shown in the flowchart of FIG.

  In this way, since the cooperation service unit 150b performs the processing related to the occupation even during the hold without changing from the operation, the access requests received during the hold are executed in the order in which they were executed, That is, the requests are accumulated in the request hold queue 171 in the order required for maintaining data synchronization.

  FIG. 21 is a flowchart illustrating an example of a hold control process performed by the hold control unit 170.

  When the hold control unit 170 receives a hold instruction (holding in S701), the hold control unit 170 updates the server status 163 of the server status table 161 to “pending” for the own backend server (S702).

  When a resumption instruction is accepted (resume in S701), the first access request is taken out from the request hold queue 171 until the request hold queue 171 becomes empty (NO in S703), and the fetched access request is database controlled. The process of issuing to the unit 310 (S705) is repeated.

  If the request hold queue 171 becomes empty (YES in S703), the server status 163 of the server status table 161 is updated to “in operation” for the own backend server (S706).

  According to this configuration, when the hold mode is released, data synchronization can be performed quickly by simply executing one or more access requests stored in the order required for maintaining data synchronization in the order in which they are stored. I can recover. Since there is no need to copy data from another database for data synchronization recovery, the larger the database size, the greater the effect of speeding up data synchronization recovery.

  Thereby, for example, when a data update is temporarily suspended for database maintenance and then recovered, extremely high practical value is exhibited.

(Modification)
In the embodiments so far, the example in which the communication between the front-end server and the back-end server and the communication between the back-end servers are performed via one network has been described. However, a modification in which communication between back-end servers is performed via a dedicated network separated from communication between the front-end server and the back-end server is also conceivable. Hereinafter, such modifications will be described.

  FIG. 22 is a device configuration diagram illustrating an example of a distributed database system including the data control system 10a according to the modification of the present invention. Compared to the distributed database system 1 (see FIG. 1) described in the first embodiment, the distributed database system 1a includes a dedicated network 21 for connecting the back-end servers 11a, 12a,. Different.

  The back end servers 11 a, 12 a,..., 1 na communicate with the front end server through the network 20 and communicate with other back end servers through the network 21.

  FIG. 23 is a block diagram illustrating an example of a functional configuration of the back-end server 11a. The database 31 shown together with the back-end server 11a is the same as that in the first embodiment.

  The back end server 11 a includes two network adapter units 201 and 202 instead of the network adapter unit 200 in the back end server 11.

  The network adapter unit 201 is physically connected to the network 20, and the front end communication control unit 210 executes communication with the front end server via the network adapter unit 201.

  The network adapter unit 202 is physically connected to the network 21, and the back end communication control unit 220 executes communication with the back end server via the network adapter unit 202.

  According to this configuration, the back-end servers can communicate with each other without being affected by communication traffic between the front-end server and the back-end server. Therefore, compared with the data control system 10, for example, communication between back-end servers such as occupancy request, occupancy change, occupancy response, and access request is performed more stably, and thus the data control system 10a has higher stability. Can be demonstrated.

  INDUSTRIAL APPLICABILITY The data control apparatus of the present invention can be used for a data control system that controls a plurality of databases in which data synchronization is to be maintained, and in particular, maintains data synchronization between the plurality of databases at low cost and efficiently. Useful as a device.

It is an apparatus block diagram which shows an example of the data control system in 1st Embodiment. It is a block diagram which shows an example of a functional structure of a back end server. It is a block diagram which shows an example of a functional structure of an integrated control part. It is a block diagram which shows an example of a functional structure of a cooperation master part. It is a figure which shows an example of the occupation reception information currently hold | maintained at the occupation reception register, and the last occupation information. It is a figure which shows an example of the occupation list information currently hold | maintained at the occupation list table. It is a flowchart which shows an example of an integrated control process. It is a flowchart which shows an example of a cooperation master process. It is a flowchart which shows an example of an occupation trial process. It is a flowchart which shows an example of a cooperation service process. It is a sequence chart which shows an example of normal data synchronous operation | movement. It is a sequence chart which shows an example of an exclusive retry operation | movement. It is a sequence chart which shows an example of an occupation change operation | movement. It is a flowchart which shows an example of a communication protocol selection process. It is a block diagram which shows an example of a functional structure of the integrated control part in 2nd Embodiment. It is a figure which shows an example of the server status information currently hold | maintained at the server status table. It is a flowchart which shows an example of a server state management process. It is a block diagram which shows an example of a functional structure of the integrated control part in 3rd Embodiment. It is a figure which shows an example of the access request accumulate | stored in the request pending | holding queue. It is a flowchart which shows an example of the cooperation service process which performs a pending | holding response. It is a flowchart which shows an example of a pending | holding control process. It is an apparatus block diagram which shows an example of a structure of the data control system in a modification. It is a block diagram which shows an example of a functional structure of the back end server in a modification. It is a block diagram which shows an example of a structure of the conventional data control system.

Explanation of symbols

1, 1a, 9 Distributed database system 10, 10a Data control system 11, 12, ... 1n, 11a, 12a, ... 1na Backend server 20, 21 Network 31, 32, ... 3n Database 41, 42, ..., 4m Front-end server 61, 62, 63 Back-end server 66, 67, 68 Database 71 Replication server 80 Network 91, 92 Front-end server 100, 100a, 100b Integrated control unit 110, 110a, 110b Request determination unit 120 Single access unit 130 , 130a Cooperation master part 131 Numbering part 132 Occupancy trial part 133 Occupancy list table 134 Target request ID
135 Response server ID
136 Acceptance request ID
138 Request issuing unit 140 Occupancy acceptance register 141, 143 Request server ID
142, 144 Request number 150, 150b Cooperation service unit 160, 160b Server status management unit 161 Server status table 162 Server ID
163 Server status 164 Receive flag 170 Hold control unit 171 Request hold queue 172 Request ID
173 Request content 200, 201, 202 Network adapter unit 210 Front-end communication control unit 220 Back-end communication control unit 300 Data storage unit 310 Database control unit 400 Timer unit

Claims (14)

One of a plurality of data control devices that respectively control a plurality of databases in which data synchronization is to be maintained, the plurality of data control devices having a priority order,
When an access request that requires synchronous control of data among the plurality of databases is received from a client , it tries to occupy all other data control devices,
The case of a successful occupancy, transfers the pre Kia access request to all the other data controller issues a Kia access requests previously for its database,
If the occupancy is not successful, the priority data control device to be the occupancy change destination is specified according to the priority, and the occupancy change indicating the specified priority data control device is transmitted to another data control device. A cooperation master means for giving up the occupation and accepting the occupation by the priority data control device ;
When an occupancy change is received from a data control apparatus that currently occupies its own data control apparatus, a cooperative service means that discards the current occupancy and accepts the occupancy by the priority data control apparatus indicated by the received occupancy change A data control device comprising: The data control device further includes:
An occupancy reception register holding occupancy reception information indicating a data control device that occupies itself is provided,
It said linkage master unit, after updating the occupancy reception information to indicate its own data control unit attempts the occupation by sending occupancy request to all other data controller, occupancy request itself is transmitted when occupied acceptance response from all the other data controller Ru received for, performs processing upon successful the occupancy,
The cooperative service means, when occupancy request from other data control device has been received, indicating that it is not also occupied by the occupancy reception information which the data control device, as shown the other data controller The data control apparatus according to claim 1, wherein the exclusive acceptance information is updated and an exclusive acceptance response is returned, and an exclusive rejection response is returned in other cases.   The occupancy rejection response received by the data control device indicates a contention data control device that is a data control device occupying the data control device that transmitted the occupancy rejection response,
  The cooperation master means, when an occupancy rejection response is received for the occupancy request transmitted by itself, the priority order of the contention data control device and the priority order of the own data control device indicated by the received occupancy rejection response Based on the comparison, the priority data control device that should be the occupancy change destination is specified, the occupancy change indicating the specified priority data control device is transmitted, and the occupancy acceptance is indicated to indicate the priority data control device Update information,
  When the occupancy change is received from the data control device indicated by the occupancy acceptance information, the cooperative service unit updates the occupancy acceptance information to indicate the priority data control device indicated by the received occupancy change. And send an exclusive acceptance response to the priority data control device
  The data control apparatus according to claim 2.   The cooperation master means, after the exclusive permission response or exclusive rejection response is received from all other data control devices in response to the exclusive request transmitted by itself,
  Based on the received occupancy permission response or occupancy refusal response, it is determined whether the own data control device and the competing data control device indicated by the received occupancy rejection response occupy other data control devices. And
  Among the competing data control devices indicated by the received occupancy rejection response, one of the data control devices other than its own is occupied, and the priority is higher than the priority of its own data control device. Identify as device
  The data control device according to claim 3.   The occupancy rejection response received by the data control device identifies an occupancy ongoing in the data control device that transmitted the occupancy rejection response,
  The occupancy acceptance register further holds immediately preceding occupancy information that identifies the occupancy accepted immediately before in common with all data control devices including the own data control device,
  When the exclusive master response is received in response to the exclusive request transmitted by the cooperation master unit, the occupation identified by the received exclusive reject response is the same as the exclusive identified by the previous exclusive information. For example, the occupancy request is retransmitted to the data control apparatus that has transmitted the occupancy rejection response.
  The data control device according to claim 3. The data control apparatus according to claim 1 , wherein the cooperation master unit re-attempts its own occupation before the change after changing its own occupation to the priority data control apparatus. The cooperation master unit and the cooperation service unit may be configured to communicate with other data control devices according to at least one of the amount of data to be transmitted, whether to retransmit, and whether to transmit data as a response. The data control apparatus according to claim 1, wherein a communication protocol used for the communication is changed. The data control device further includes:
Server status management means for detecting a failure of another data control device by monitoring the presence or absence of data reception for a predetermined time,
The data control apparatus according to claim 1, wherein the cooperation master unit excludes the data control apparatus detected as a failure and determines whether or not the occupation is successful. The data control device further includes:
One or more access requests are accumulated in a specific operation mode, and when the operation mode is released, the access request is provided in a hold control unit that takes out the access requests in the order of accumulation and issues them to its own database,
The said cooperation service means accumulate | stores in the said hold | maintenance control means instead of issuing the access request received from the other data control apparatus with respect to its own database in the said operation mode. Data controller. The data control apparatus according to claim 1, wherein the data control apparatus includes a connection unit to a dedicated network that connects only the plurality of data control apparatuses. A data control system for controlling a plurality of databases in which data synchronization is to be maintained,
A data control system comprising the data control device according to claim 1 corresponding to each of the plurality of databases. A data control method used in one of a plurality of data control devices respectively corresponding to a plurality of databases in which data synchronization is to be maintained, wherein the plurality of data control devices are prioritized,
When an access request that requires synchronous control of data among the plurality of databases is received from a client , it tries to occupy all other data control devices,
The case of a successful occupancy, transfers the pre Kia access request to all the other data controller issues a Kia access requests previously for its database,
If the occupancy is not successful, the priority data control device to be the occupancy change destination is specified according to the priority, and the occupancy change indicating the specified priority data control device is transmitted to another data control device. A cooperation master step of giving up the occupation and accepting the occupation by the priority data control device ;
When an occupation change is received from a data control apparatus that currently occupies its own data control apparatus, the cooperation service step of discarding the current occupation and accepting the occupation by the priority data control apparatus indicated by the received occupation change A data control method comprising: and. A computer-executable program for operating one of a plurality of data control devices respectively corresponding to a plurality of databases in which data synchronization is to be maintained, wherein the plurality of data control devices are prioritized. And
When an access request that requires synchronous control of data among the plurality of databases is received from a client , it tries to occupy all other data control devices,
The case of a successful occupancy, transfers the pre Kia access request to all the other data controller issues a Kia access requests previously for its database,
If the occupancy is not successful, the priority data control device to be the occupancy change destination is specified according to the priority, and the occupancy change indicating the specified priority data control device is transmitted to another data control device. A cooperation master step of giving up the occupation and accepting the occupation by the priority data control device ;
When an occupation change is received from a data control apparatus that currently occupies its own data control apparatus, the cooperation service step of discarding the current occupation and accepting the occupation by the priority data control apparatus indicated by the received occupation change A program characterized by causing a computer to execute.   A computer-readable recording medium storing the program according to claim 13.

Images