JP5265711B2 - Cache control system and cache control method - Google Patents

Description

  The present invention relates to a cache control system and a cache control method.

  There is a service providing system that provides services to a plurality of clients on a network using large-scale data stored in a database server. In the service providing system, the frequency of use of each data stored in the database server varies for each data.

  Here, there is a cache technology that caches data stored by a World Wide Web (WWW) server. FIG. 35 is a diagram illustrating an example of a system that executes the cache technology. In FIG. 35, a user terminal 100 to a user terminal 102 are terminals used by users. The WWW server 105 is a server that manages data. The WWW cache server 103 and the WWW cache server 104 are servers that store a cache of data managed by the WWW server 105. Further, in a system that executes the cache technology, a number of WWW cache servers corresponding to the number of user terminals are arranged in advance at positions close to the user terminals 100 to 102. In the example shown in FIG. 35, the WWW cache server 103 is arranged as a cache server for the user terminal 100, and the WWW cache server 104 is arranged as a cache server for the user terminals 101 and 102.

  Description will be made using a case where the user terminal 100 acquires data managed by the WWW server 105 under the configuration shown in FIG. In this case, in the system that executes the cache technology, the WWW cache server 103 stores a cache of data once acquired from the WWW server 105 by the user terminal 100. In the system that executes the cache technology, when the user terminal 100 accesses the same data again, the WWW cache server 103 transmits the data to the user terminal 100.

  FIG. 36 is a diagram showing an example of a system in which the cache technology shown in FIG. 35 is generalized. 36, the client terminal 110 to the client terminal 112 correspond to the user terminal 100 to the user terminal 102 in FIG. Further, the cache server 113 and the cache server 114 correspond to the WWW cache server 103 and the WWW cache server 104 in FIG. The database server 115 corresponds to the WWW server 105 in FIG.

  Here, the data stored in the cache server may not be the same as the data stored in the database server. For example, a case where the cache server stores a cache of the data “D” stored in the database server, and a service is provided to the client terminal using the data “D” stored in the cache server is used. explain. Further, the case where the data “D” stored in the database server is updated to “E” after the cache server acquires the data “D” will be described. In this case, the data “D” stored by the cache server is the data before update, and the data stored in the database server and the data stored in the cache server are not the same.

  Based on this, there is a technique called Invalidation Report (hereinafter also referred to as “IR technique”) as a technique for making the data stored in the database server the same as the data stored in the cache server.

  In a system that executes IR technology, IR information that is information about data updated by a database server is generated. Also, in a system that executes the IR technology, the database server and the cache server share the IR information so that the old data out of the data stored in the cache server is invalidated and not used.

  For example, the case where the database server manages passwords for each user will be described. Further, the case where the password of the user “U” is the password “P1” and the cache server stores the password “P1” as the password of the user “U” will be described. Further, the case where the password of the user “U” is changed from the password “P1” to the password “P2” in the database server will be described later. In this case, for example, the database server generates IR information including the user “U” for identifying the updated password “P1”, and shares the generated ID information with the cache server. As a result, the cache server invalidates the cache of the password “P1” stored as the password of the user “U”.

  In the following description, the cache server requests the user “U” password from the client terminal. In this case, the password of the user “U” is invalidated in the cache server, the cache server acquires the password “P2” of the user “U” from the database server, and stores the cache of the password “P2” on the cache server. While storing, the password “P2” is provided to the client terminal.

  In addition, there is a technology that configures a database server using a fault-tolerant technology such as redundancy based on the fact that data stored in a database server is indispensable information for continuing service provision. FIG. 37 is a diagram illustrating an example of a configuration when the database server is duplicated. That is, in the example shown in FIG. 37, the database server 120 and the database server 121 store the same data. In the example illustrated in FIG. 37, the cache server 122 acquires data from the database server 120, and the cache server 123 and the cache server 124 acquire data from the database server 121.

  Here, there are synchronous replication and asynchronous replication as techniques for making the database server redundant. The synchronous replication is a method for updating the database server 120 and the database server 121 at the same time as described with reference to the example of FIG. Asynchronous replication is described with reference to the example of FIG. 37. After the data stored in one of the database servers 120 and 121 is updated, the data is stored in the other database server. It is a method to update the data. In other words, in asynchronous replication, a plurality of database servers are not updated at the same time.

"Distributed System Principle and Paradigm", by Andrew S. Tanenbaum and Maarten van Stein, Tadanori Mizuno, Taro Miyano, Kenji Suzuki, Satoshi Nishiyama, Fumiaki Sato, Teruo Higashino, Pearson Education, Inc., 2003 BUILDING SECURE AND RELIABLE NETWORK APPLICATIONS, Kenneth P. Published by Birman, Manning, 1996 G. Cao, “A Scalable Low-Latency Cache Invalidation Strategy for Mobile Environments”, IEEE Transactions on Knowledge and Data engineering, vol. 15, no. 5, pp. 1251-1265, 2003 Z. Wang, S. K. Das, H. Che, M. Kumar, “A Scalable Asynchronous Cache Consistency Scheme (SACCS) for Mobile Environments”, IEEE Transactions on Parallel and Distributed Systems, vol. 15, no. 11, 2004 J. Gray, P.M. Helland, P.A. O’Neil, D. Shasha, Mohan Kumar, “The Dangers of Replication and a Solution”, Proc. ACM SIGMOD '86, pp. 173-183, June 1996 K. P. Birman, “BUILDING SECURE AND RELIABLE NETWORK APPLICATIONS”, Manning, 1996

  However, when IR technology and asynchronous replication are used together, there is a problem that the cache server may hold old data without invalidating it. Specifically, in a system that executes asynchronous replication, there is a period in which data stored in each of a plurality of database servers is not the same, and IR information is generated for each database server as a result of different update timings. The timing is also different. As a result, for example, when a failure occurs in the database server, the data stored in the database server may not be the same as the data stored in the cache server.

  This will be further described with reference to FIG. FIG. 38 is a diagram illustrating an example of a case where the data stored in the database server and the data stored in the cache server are not the same. The horizontal axis in FIG. 38 represents the time axis, and description will be made assuming that time elapses from the left side to the right side. In the description with reference to FIG. 38, it is assumed that the system configuration is the same as that in FIG.

  Description will be made using a case where data stored in the database server 120 is updated and IR information is registered in the database server 120 at a time point 130 in FIG. The case where IR information is shared between the cache server 122 and the database server 120 at time 131 in FIG. 38 and old data is invalidated in the cache server 122 will be described. The case where the cache server 123 acquires data not held by the cache server 123 from the database server 121 in order to provide the service to the client terminal 126 at time 132 in FIG. 38 will be described. Here, it is assumed that the data acquired by the cache server 123 is data to be updated at the time 130. 38, the update performed on the database server 120 is performed asynchronously on the database server 121. As a result, the data stored in the database server 121 is updated, and the database server 121 is updated with the IR. A description will be given using a case where information is registered. The case where the database server 121 fails at the time 134 in FIG. 38 will be described.

  In this case, the database server 121 is not updated at the time point 132, and the cache server 123 acquires old data at the time point 132. Thereafter, the database server 121 is updated at the time 133, but as a result of the failure at the time 134, the cache server 123 holds the old data acquired at the time 132 without invalidating.

  The disclosed technology has been made in view of the above, and an object thereof is to provide a cache control system and a cache control method capable of invalidating old data stored in a cache server.

  In one aspect, the disclosed cache control system includes a plurality of database servers that store the same data that is updated asynchronously, and a plurality of cache servers that store a cache of data stored in the database server. It becomes. In the cache control system, in one aspect, each of the database servers has a plurality of pieces of update information including update data identification information for identifying the data to be updated when the data of the own database server is updated. A storage unit is provided for storing in the update information storage unit in association with each piece of identification information for identifying the cache server. In the cache control system, in one aspect, each of the cache servers is stored in association with identification information for identifying the cache server by the storage unit in the update information storage unit from each of the plurality of database servers. And an update information acquisition unit for acquiring the update information. In one aspect, the cache control system includes an invalid processing unit that invalidates a cache of data identified by the update information acquired by the acquisition unit.

  According to one aspect of the disclosed cache control system, there is an effect that if there is even one normal database server, old data stored in the cache server can be invalidated.

FIG. 1 is a diagram illustrating an overview of an example of a cache control system according to the first embodiment. FIG. 2 is a block diagram illustrating an example of the configuration of the database server in the first embodiment. FIG. 3 is a diagram illustrating an example of information stored in the user information DB of the database server in the first embodiment. FIG. 4 is a diagram illustrating an example of information stored in the IR information DB of the database server in the first embodiment. FIG. 5 is a diagram illustrating an example of information stored in the distribution information DB of the database server in the first embodiment. FIG. 6 is a diagram illustrating an example of information stored in the device information DB of the database server in the first embodiment. FIG. 7 is a block diagram illustrating an example of the configuration of the cache server according to the first embodiment. FIG. 8 is a diagram illustrating an example of information stored in the cache of the cache server according to the first embodiment. FIG. 9 is a diagram illustrating an example of information stored in the search destination state DB of the cache server according to the first embodiment. FIG. 10 is a diagram illustrating an example of information stored in the update registration state DB of the cache server according to the first embodiment. FIG. 11 is a block diagram illustrating an example of the configuration of the monitoring server according to the first embodiment. FIG. 12 is a diagram illustrating an example of information stored in the device information DB of the monitoring server according to the first embodiment. FIG. 13 is a sequence diagram illustrating an example of a process flow between the database servers in the first embodiment. FIG. 14 is a sequence diagram illustrating an example of a flow of processing between the database server and the monitoring server in the first embodiment. FIG. 15 is a sequence diagram illustrating an example of a process flow between the cache server and the database server according to the first embodiment. FIG. 16 is a sequence diagram illustrating an example of a process flow between the cache server and the database server according to the first embodiment. FIG. 17 is a sequence diagram illustrating an example of a process flow among the client terminal, the cache server, and the database server according to the first embodiment. FIG. 18 is a flowchart illustrating an example of a process flow by the cache response unit of the database server in the first embodiment. FIG. 19 is a flowchart illustrating an example of a process flow by the IR information response unit of the database server in the first embodiment. FIG. 20 is a flowchart illustrating an example of a process flow by the update information response unit of the database server in the first embodiment. FIG. 21 is a flowchart illustrating an example of a process flow by the update success / failure response unit of the database server according to the first embodiment. FIG. 22 is a diagram illustrating an example of an update success / failure result correspondence table according to the first embodiment. FIG. 23 is a flowchart illustrating an example of processing performed by the apparatus status response unit of the database server according to the first embodiment. FIG. 24 is a flowchart illustrating an example of a process flow by the apparatus state storage unit of the database server in the first embodiment. FIG. 25 is a flowchart illustrating an example of a processing flow by the block control unit of the database server in the first embodiment. FIG. 26 is a flowchart illustrating an example of a detailed processing flow by the update information distribution unit of the database server in the first embodiment. FIG. 27 is a flowchart illustrating an example of a processing flow by the update re-propagation unit of the database server according to the first embodiment. FIG. 28 is a flowchart illustrating an example of a flow of processing performed by the cache determination unit of the cache server according to the first embodiment. FIG. 29 is a flowchart illustrating an example of a process flow by the IR information determination unit of the cache server according to the first embodiment. FIG. 30 is a diagram illustrating an example of an update registration state correspondence table according to the first embodiment. FIG. 31 is a diagram illustrating an example of an IR information deletion target determination table according to the first embodiment. FIG. 32 is a flowchart illustrating an example of a flow by the response processing unit of the cache server in the first embodiment. FIG. 33 is a flowchart illustrating an example of a process flow by the failure determination unit of the monitoring server in the first embodiment. FIG. 34 is a diagram illustrating that information processing by the cache control system is specifically realized using a computer. FIG. 35 is a diagram illustrating an example of a system that executes the cache technology. FIG. 36 is a diagram showing an example of a system in which the cache technology shown in FIG. 35 is generalized. FIG. 37 is a diagram illustrating an example of a configuration when the database server is duplicated. FIG. 38 is a diagram illustrating an example of a case where the data stored in the database server and the data stored in the cache server are not the same.

  Hereinafter, embodiments of the disclosed cache control system and cache control method will be described in detail with reference to the drawings. Note that the invention disclosed by this embodiment is not limited. Each embodiment can be appropriately combined within a range in which processing contents do not contradict each other.

[Overview of Cache Control System According to Embodiment 1]
An overview of the cache control system according to the first embodiment will be described. The cache control system according to the first embodiment includes a database server 200, a cache server 300, a monitoring server 400, and a client terminal 500. The database server 200 stores data. The cache server 300 stores a cache of data stored in the database server 200. The monitoring server 400 monitors the database server 200. The client terminal 500 is a terminal used by a user and receives a service based on data stored in the database server 200.

  FIG. 1 is a diagram illustrating an overview of an example of a cache control system according to the first embodiment. In the example illustrated in FIG. 1, the cache control system according to the first embodiment illustrates a case where the two database servers 200, the two cache servers 300, the one monitoring server 400, and the one client terminal 500 are included. . Two database servers 200, two cache servers 300, one monitoring server 400, and one client terminal 500 are connected to each other via a network.

  In the example illustrated in FIG. 1, the cache control system has two database servers 200, two cache servers 300, one monitoring server 400, and one client terminal 500. It is not limited to. For example, the cache control system may include three or more database servers 200, three or more cache servers 300, two or more monitoring servers 400, and 2 Two or more client terminals 500 may be included.

  When describing the overall image of the cache control system, as shown in FIG. 1, the two database servers 200 are described as a database server 200-1 and a database server 200-2, respectively. As shown in FIG. 1, the two cache servers 300 are referred to as a cache server 300-1 and a cache server 300-2.

  Here, in the example shown in (1) of FIG. 1, the client terminal 500 transmits a data request for requesting data stored in the database server 200-1 or the database server 200-2 to the cache server 300-1. . Further, as shown in (4) of FIG. 1, the client terminal 500 provides various services to the user using the data received from the cache server 300-1. For example, the client terminal 500 outputs the data received from the cache server 300-1 to the user, or provides the user with a service executed using the data received from the cache server 300-1.

  The database server 200-1 and the database server 200-2 have a storage unit that stores a large amount of data. The data stored in the storage unit of the database server 200-1 or the database server 200-2 is used or referred to by the client terminal 500, for example.

  The database server 200-1 and the database server 200-2 store the same data updated asynchronously. Further, the database server 200-1 and the database server 200-2 each have an independent configuration as a database server. For example, in the example shown in FIGS. 1A and 1B, when the database server 200-1 is updated, the database server 200-1 distributes the update data to the database server 200-2, and the database server 200-1 -2, the updated data included in the distributed update data is registered. As a result, the data is updated.

  Further, each of the database server 200-1 and the database server 200-2 generates IR information when the data stored in the own database server is updated. In the cache control system, the IR information is information for notifying the cache server 300 that data has been updated.

  The cache server 300-1 and the cache server 300-2 store a cache of data stored in the database server 200-1 and the database server 200-2. For example, the cache server 300-1 and the cache server 300-2 store a cache of data used in the past by the client terminal 500 among the data stored in the database server 200-1 or the database server 200-2. Note that the cache server 300-1 and the cache server 300-2 realize high-speed access from the client terminal 500 by storing the cache server 300-1 and the cache server 300-2 in the cache of its own device.

  Further, when the cache server 300-1 and the cache server 300-2 receive a data request from the client terminal 500, if the data requested by the data request is stored in the own device, the cache server 300-1 and the cache server 300-2 store the data request in the own device. Data to be transmitted to the client terminal 500. On the other hand, when the cache server 300-1 and the cache server 300-2 do not store the data requested by the data request in its own device, as shown in (2) of FIG. It transmits to the server 200-1 and the database server 200-2. Then, as shown in (3) of FIG. 1, when the cache server 300-1 and the cache server 300-2 receive a data response as a response to the data search request from the database server 200-1 or the database server 200-2, The cache of the received data is stored in the cache of its own device, and the received data is transmitted to the client terminal 500 as shown in (4) of FIG.

  Further, as shown in FIG. 1A, the cache server 300-1 and the cache server 300-2 make an IR information request to the database server 200-1 and the database server 200-2 at an arbitrary timing. Send. Here, when the IR information is generated by the database server 200-1 or the database server 200-2, as shown in FIG. 1B, the cache server 300-1 and the cache server 300-2 A response of IR information is received. Then, the cache server 300-1 and the cache server 300-2 invalidate old data stored in the self-device in response to the data request from the client terminal 500, thereby responding to the data request from the client terminal 500. Do not send old data.

  The monitoring server 400 monitors the states of the database server 200-1 and the database server 200-2. Here, as shown in (i) of FIG. 1, the monitoring server 400 acquires device information that is information about the state of the database server 200-1 or the database server 200-2 and determines the state of the database server 200. To do. Then, as shown in (ii) of FIG. 1, the monitoring server 400 stores, for the database server 200-1 and the database server 200-2, the device status that is the determination result for each database server 200. Send device status storage request. Further, as shown in (iii) of FIG. 1, the monitoring server 400 transmits a blocking request for blocking transmission / reception of data to / from the cache server 300 to the database server 200 determined to have failed. .

  Here, as will be described in detail later, in the cache control system according to the first embodiment, each database server 200 has key information for identifying data to be updated when the data of the own database server 200 is updated. The IR information included is generated in association with each identification information for identifying a plurality of cache servers. In addition, each cache server 300 acquires IR information generated in association with identification information for identifying its own cache server from each of a plurality of database servers 200, and invalidates the cache of data identified by the acquired IR information. To. As a result, if there is at least one normal database server 200, the data before update stored in the cache server 300 can be invalidated. The key information is also referred to as “update data identification information”, and the IR information is also referred to as “update information”.

  Further, as will be described in detail later, in the cache control system according to the first embodiment, each of the plurality of database servers 200 displays an update result indicating whether or not the data update has been completed for each of the plurality of database servers 200. Remember. In addition, each cache server 300 acquires an update result for each of the plurality of database servers 200 from the database server 200. Then, the cache server 300 determines whether or not the update has been completed for all of the plurality of database servers based on each of the update result information, and deletes the IR information from the database server 200 when it is determined that the update has been completed. The delete process is executed, and if it is determined that the update has not ended, the delete process is not executed. As a result, as will be described in detail later, no matter what situation the database server 200 breaks down, the cache server 300 will not continue to store old data while being valid, and the database server and the cache server can be reliably Can be matched.

  Further, as will be described in detail later, in the cache control system according to the first embodiment, the cache server 300 determines, for each of the plurality of database servers 200, whether or not the update in the database server 200 is normally executed. To do. Then, the cache server 300 determines whether or not the update has been completed for all the database servers 200 that are determined to be normally executed, and executes the deletion process when it is determined that the update has ended. If it is determined that the update has not been completed, the deletion process is not executed. As a result, the database server 200 and the cache server 300 can be matched.

[Configuration of Cache Control System According to First Embodiment]
An example of the configuration of the cache control system according to the first embodiment will be described. Hereinafter, an example of the configuration of the database server 200 in the first embodiment, an example of the configuration of the cache server 300 in the first embodiment, and an example of the configuration of the monitoring server 400 in the first embodiment will be described in order.

[Configuration of Database Server 200 in Embodiment 1]
FIG. 2 is a block diagram illustrating an example of the configuration of the database server in the first embodiment. In the example illustrated in FIG. 2, the database server 200 includes a communication control I / F unit 201, a storage unit 210, and a control unit 220.

  The communication control I / F unit 201 is connected to the control unit 220. The communication control I / F unit 201 transmits / receives data to / from the cache server 300, the monitoring server 400, and another database server 200. Details of information transmitted and received by the communication control I / F unit 201 will be described later as appropriate.

  The storage unit 210 is connected to the control unit 220. The storage unit 210 stores data and programs used for various processes performed by the control unit 220. The storage unit 210 is, for example, a semiconductor memory device such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. In the example illustrated in FIG. 2, the storage unit 210 includes a user information DB 211, an IR information DB 212, a distribution information DB 213, and a device information DB 214. The IR information DB 212 is also referred to as an “update information storage unit”, and the distribution information DB 213 is also referred to as an “update result storage unit”.

  The user information DB 211 stores data used by the client terminal 500 and data used when providing a service to the client terminal 500. Here, each of the user information DBs 211 of the plurality of database servers 200 is updated asynchronously and stores the same data.

  Below, it demonstrates using the case where user information DB211 matches and memorize | stores key information and attribute information. Here, the attribute information is data to be updated. In the following, when a specific example is described, description is made using the case where the attribute information is a password that is unique for each user. However, the present invention is not limited to this and is arbitrary information. Good. Key information is information that uniquely identifies attribute information. In the following, when a specific example is described, the case where the key information is user information for identifying a user will be described. However, the present invention is not limited to this, and is arbitrary information. good.

  In the following, the case where the user information DB 211 stores key information and attribute information in the same table will be described. However, the present invention is not limited to this, and may be stored in separate tables. In the following, the case where the key information and the attribute information are separate information will be described. However, the present invention is not limited to this, and one piece of information may be used. It may be distributed.

  FIG. 3 is a diagram illustrating an example of information stored in the user information DB of the database server in the first embodiment. In the example illustrated in FIG. 3, the user information DB 211 stores key information “U001” and attribute information “P001” in association with each other, and stores key information “U002” and attribute information “P002” in association with each other. That is, the user information DB 211 stores that the data identified by the key information “U001” is attribute information “P001”.

  Returning to the description of FIG. The IR information DB 212 stores IR information in association with identification information for identifying a cache server. FIG. 4 is a diagram illustrating an example of information stored in the IR information DB of the database server in the first embodiment. In the example illustrated in FIG. 4, the IR information DB 212 stores IR information including key information and an update ID in association with “cache server name” that is identification information for identifying a cache server. Here, the update ID is information that uniquely identifies an update to the data stored in the database server 200. The cache server name stored in the IR information DB 212 indicates the cache server 300 to which the IR information is applied.

  In the example shown in FIG. 4, the IR information DB 212 stores IR information including key information “U001” and update ID “I001” in association with the cache server name “cache server“ A ””. That is, the IR information DB 212 is identified by the key information “U001” among the data stored in the user information DB 211 by the update identified by the update ID “I001” as the IR information applied to the cache server “A”. IR information indicating that the data to be updated is stored.

  Here, in the IR information DB 212, when data of the database server 200 is updated, IR information is generated by the control unit 220 for each cache server 300 and stored by the control unit 220, as will be described later. That is, the IR information DB 212 stores the IR information in association with all the cache server names in a stage before the IR information is generated and before being used for the cache server 300. Further, the IR information stored in the IR information DB 212 is referred to by the cache server 300 when the cache server 300 updates the cache in its own device, as will be described later.

  Returning to the description of FIG. The distribution information DB 213 stores an update result indicating whether or not the data update has been completed for each of the plurality of database servers 200. FIG. 5 is a diagram illustrating an example of information stored in the distribution information DB of the database server in the first embodiment. In the example illustrated in FIG. 5, the distribution information DB 213 includes “update ID”, “database server name” that is identification information for uniquely identifying the database server 200, “distribution result”, and “update result”. Remember the record.

  Here, the distribution result indicates whether or not the update data is distributed when an arbitrary database server is updated. In the following, the distribution result “OK” indicates a case where distribution of update data is successful. The distribution result “undistributed” corresponds to a case where update data is not distributed or a case where distribution for update fails. That is, when the distribution result is “OK”, it indicates that the update data has arrived at the database server 200, and when the update result is “undelivered”, the update data has not arrived at the database server 200. Indicates.

  The update result indicates whether or not the data update is completed. In the following, the update result “initial” indicates that the update identified by the update ID has not been performed. The update result “OK” indicates that the update identified by the update ID is successful. The update result “NG” indicates that the update identified by the update ID has failed. That is, when the update result is “OK”, it indicates that the update is reflected on the database server 200, and when the update result is “initial” or “NG”, the update is reflected on the database server 200. Indicates no.

  In the example illustrated in FIG. 5, the distribution information DB 213 stores a record including the update ID “I001”, the database server name “database server A”, the distribution result “OK”, and the update result “OK”. In other words, in the example shown in FIG. 5, the distribution information DB 213 stores the successful distribution of update data to the database server “A” for the update identified by the update ID “I001”. Remember that it has finished.

  The information stored in the distribution information DB 213 is updated by the control unit 220 and used when the cache server 300 determines whether to delete the IR information from the database server 200. Further, the distribution information DB 213 of the plurality of database servers 200 stores the same information. In other words, each of the plurality of database servers 200 shares a distribution result and an update result for each database server 200.

  The information stored in the distribution information DB 213 is used when the cache server 300 determines whether or not to execute a deletion process for deleting the IR information from the database server 200, as will be described later. The information stored in the distribution information DB 213 is updated by the control unit 220 as described later.

  Returning to the description of FIG. The device information DB 214 stores the state of each database server 200. Specifically, the device information DB 214 receives, for each database server 200, update data from another database server 200, executes update, and distributes update data to the other database server 200. Information indicating whether or not is possible is stored.

  FIG. 6 is a diagram illustrating an example of information stored in the device information DB of the database server in the first embodiment. In the example illustrated in FIG. 6, the device information DB 214 stores “device state” indicating the state of the database server 200 in association with “database server name”. In the following description, the device status “normal” indicates that the resource used when the database server 200 distributes or receives update data or executes update is operating normally, and the update data is distributed or received. Indicates that it is possible. The device state “failure” indicates that one or more of the resources used when the database server 200 distributes, receives, or executes update data is out of order, and the update data is distributed. Indicates that it cannot be received or updated.

  In the example illustrated in FIG. 6, the device information DB 214 stores the device state “normal” in association with the database server name “database server A”. Further, the device information DB 214 stores the device state “normal” in association with the database server name “database server B”. That is, the device information DB 214 stores that both the database server “A” and the database server “B” are in a state in which update data can be distributed and received. Each device information DB 214 of each database server 300 stores device information for all database servers 200.

  Here, the information stored in the device information DB 214 is used when the database server 200 determines the database server 200 to be a distribution destination to which the update data is distributed when the data in the user information DB 211 of the own database server is updated. Used for. The information stored in the device information DB 214 is updated by the monitoring server 400.

  Returning to the description of FIG. The control unit 220 is connected to the communication control I / F unit 201 and the storage unit 210. The control unit 220 has an internal memory that stores a control program such as an OS (Operating System) and a program that defines various processing procedures, and controls various processes. The control unit 220 is, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a central processing unit (CPU), or a micro processing unit (MPU). In the example shown in FIG. 2, the control unit 220 includes a cache response unit 221, an IR information response unit 222, an update information response unit 223, an update success / failure response unit 224, a device status response unit 225, and a device status storage unit. 226, a block control unit 227, an update information distribution unit 228, and an update re-propagation unit 229. Details of each part will be described later. The update information distribution unit 228 is also referred to as a “storage unit”. The update information response unit 223 is also referred to as an “update information transmission unit”.

[Configuration of Cache Server in Embodiment 1]
FIG. 7 is a block diagram illustrating an example of the configuration of the cache server according to the first embodiment. In the example illustrated in FIG. 7, the cache server 300 includes a communication control I / F unit 301, a storage unit 310, and a control unit 320.

  The communication control I / F unit 301 is connected to the control unit 320. The communication control I / F unit 301 exchanges data with the database server 200 and the client terminal 500. Details of information transmitted and received by the communication control I / F unit 301 will be described later as appropriate.

  Storage unit 310 is connected to control unit 320. The storage unit 310 stores data and programs used for various processes performed by the control unit 320. The storage unit 310 is, for example, a semiconductor memory element such as a RAM or a flash memory, or a hard disk or an optical disk. In the example illustrated in FIG. 7, the storage unit 310 includes a cache 311, a search destination state DB 312, and an update registration state DB 313.

  The cache 311 stores a cache of data stored in the user information DB 211 of the database server 200. Specifically, the cache 311 stores a cache of data used in the past among the data stored in the user information DB 211.

  FIG. 8 is a diagram illustrating an example of information stored in the cache of the cache server according to the first embodiment. In the example illustrated in FIG. 8, the cache 311 stores key information and attribute information in association with each other. In the example illustrated in FIG. 8, the cache 311 stores key information “U001” and attribute information “P001” in association with each other, and stores key information “U002” and attribute information “P002” in association with each other.

  Note that the data stored in the cache 311 is part or all of the data stored in the user information DB 211. A case where the data in the user information DB 211 is updated and the cache 311 stores a copy of the updated data will be described. In this case, the data stored in the cache 311 is old data. The old data stored in the cache 311 is deleted by the control unit 320 based on the IR information acquired from the database server 200, as will be described later.

  Returning to the description of FIG. The search destination status DB 312 stores the status of each database server 200. Specifically, the search destination state DB 312 stores whether or not each database server 200 may be a data search request transmission destination. That is, the search destination state DB 312 stores the database server name of the database server 200 that may request a search for the data requested by the data request when there is no cache for the data requested by the data request.

  FIG. 9 is a diagram illustrating an example of information stored in the search destination state DB of the cache server according to the first embodiment. In the example shown in FIG. 9, “database server name” and “blocking state” are stored in association with each other. Here, the blocked state “non-blocked” indicates that the database server 200 is not blocked and may be a data search request transmission destination to the database server 200. Further, the blocked state “blocked” indicates that the database server 200 is blocked and cannot be a transmission destination of a data search request to the database server 200.

  That is, as will be described later, when the cache server 300 transmits a data search request to the database server 200, the cache server 300 does not transmit the data search request to the database server 200 in the blocked state “blocked”. Further, when the cache server 300 executes a data search request to the database server 200, the cache server 300 transmits the data search request to the database server 200 that is in the blocked state “not blocked”.

  In the example illustrated in FIG. 9, the search destination state DB 312 stores the database server name “database server A” and the blocked state “unblocked” in association with each other. In addition, the search destination state DB 312 stores the database server name “database server B” and the blocked state “unblocked” in association with each other. That is, the search destination state DB 312 indicates that both the database server “A” and the database server “B” are not blocked, and a data search is possible.

  Each database server 200 identified by each database server name stored in the search destination status DB 312 includes a search destination as a transmission destination when the cache server 300 transmits a data search request for data that does not exist in its own device. The database server 200 becomes. In addition, the initial value of the blocking state in the search destination state DB 312 is, for example, “blocking”. The blocking state stored in the search destination state DB 312 is updated by the control unit 320 as described later.

  Returning to the description of FIG. The update registration state DB 313 stores, for each of the plurality of database servers 200, whether or not the data update is successful in the database server 200. FIG. 10 is a diagram illustrating an example of information stored in the update registration state DB 313 of the cache server according to the first embodiment. In the example illustrated in FIG. 10, the update registration state DB 313 stores a “database server name” and an “update registration state” that indicates whether data update has been successful in the database server 200 in association with each other. .

  Here, the registration status information “normal” indicates that the database server 200 is normally updated. The registration status information “propagation abnormality detection” indicates that the database server 200 detects that the update has failed due to a failure or the like. The registration state information “propagation abnormality” indicates that the update has failed in the database server 200 due to a failure or the like, and the state in which the update has failed continues. The registration status information “normally transitioning” indicates that the previous update registration status was “propagation abnormality” due to failure recovery or the like, but now the database server 200 is updating normally.

  In the example illustrated in FIG. 10, the update registration state DB 313 stores the database server name “database server A” and the update registration state “normal” in association with each other. Further, the update registration state DB 313 stores the database server name “database server B” and the update registration state “normal” in association with each other. That is, the update registration state DB 313 stores that the update is normally performed in the database server “A” and the database server “B”.

  Note that the information stored in the update registration state DB 313 is used when the control unit 320 determines whether or not to execute a deletion process for deleting the IR information from the database server 200, as will be described later. The information stored in the update registration state DB 313 is updated by the control unit 320 as will be described later. Further, the update registration state DB 313 stores, for example, the update registration state “propagation abnormality” as an initial value of the update registration state for all the database servers 200 that may be referred to by the own apparatus.

  Returning to the description of FIG. The control unit 320 is connected to the communication control I / F unit 301 and the storage unit 310. The control unit 320 has an internal memory that stores a control program such as an OS and a program that defines various processing procedures, and controls various processes. The control unit 320 is, for example, an ASIC, FPGA, CPU, MPU, or the like. In the example illustrated in FIG. 7, the control unit 320 includes a cache determination unit 321, an IR information determination unit 322, and a response processing unit 323. Details of each part will be described later. The IR information determination unit 322 is also referred to as “update information acquisition unit”, “invalid processing unit”, “update result acquisition unit”, “deletion processing unit”, and “update state determination unit”.

[Configuration of Monitoring Server in First Embodiment]
FIG. 11 is a block diagram illustrating an example of the configuration of the monitoring server according to the first embodiment. In the example illustrated in FIG. 11, the monitoring server 400 includes a communication control I / F unit 401, a storage unit 410, and a control unit 420.

  The communication control I / F unit 401 is connected to the control unit 420. The communication control I / F unit 401 transmits / receives data to / from each database server 200. Details of information transmitted and received by the communication control I / F unit 401 will be described later as appropriate.

  Storage unit 410 is connected to control unit 420. The storage unit 410 stores data and programs used for various processes performed by the control unit 420. The storage unit 410 is, for example, a semiconductor memory element such as a RAM or a flash memory, or a hard disk or an optical disk. In the example illustrated in FIG. 11, the storage unit 410 includes a device information DB 411.

  The device information DB 411 stores the state of each database server 200. FIG. 12 is a diagram illustrating an example of information stored in the device information DB of the monitoring server according to the first embodiment. In the example illustrated in FIG. 12, the device information DB 411 stores “device state” in association with “database server name”. The device information DB 411 stores the database server name of each of the plurality of database servers 200 as an initial value.

  In the example illustrated in FIG. 12, the device information DB 411 stores the device state “normal” in association with the database server name “database server A”. Further, the device information DB 411 stores the device state “normal” in association with the database server name “database server B”. That is, the device information DB 411 stores that both the database server “A” and the database server “B” are in a state in which update data can be distributed, received, and updated. Information stored in the device information DB 411 is stored by the control unit 420.

  Returning to the description of FIG. The control unit 420 is connected to the communication control I / F unit 401 and the storage unit 410. The control unit 420 has an internal memory that stores a control program such as an OS and a program that defines various processing procedures, and controls various processes. The control unit 420 is, for example, an ASIC, FPGA, CPU, MPU, or the like. In the example illustrated in FIG. 11, the control unit 420 includes a failure determination unit 421. Details of the failure determination unit 421 will be described later.

[Processing by Cache Control System According to Embodiment 1]
Processing performed by the cache control system according to the first embodiment will be described. Hereinafter, an example of a flow of processing between devices included in the cache control system will be briefly described with reference to a sequence diagram, and then an example of a detailed processing flow by each unit of each device will be described with reference to a flowchart.

[Processing between Database Servers in Embodiment 1]
FIG. 13 is a sequence diagram illustrating an example of a process flow between the database servers in the first embodiment. In FIG. 13, a case where there are two database servers 200 will be described. Specifically, description will be made using the database server “A” and the database server “B”. In the following description, a case where there is an update instruction for data stored in the user information DB 211 of the database server “A” will be described.

  As shown in FIG. 13, when there is an update instruction (Yes at Step S1401), the update information distribution unit 228 of the database server “A” pays out an update ID (Step S1402). For example, the update information distribution unit 228 pays out the distribution time as an update ID, or pays out information obtained by adding a branch number to the distribution information as an update ID. To explain with a more detailed example, the update information distribution unit 228 issues an update ID “I001”.

  Then, the update information distribution unit 228 distributes update data to each of the plurality of database servers 200 (step S1403). For example, the update information distribution unit 228 transmits to the database server “B” the update ID “I001”, key information for identifying data to be updated according to the update instruction, and the updated data.

  Thereafter, the update information distribution unit 228 of the database server “A” stores the distribution result for each database server 200 in association with the update ID in each of the distribution information DBs 213 of the plurality of database servers 200 (step S1404). For example, the update information distribution unit 228 stores the distribution result “OK” in association with the database server name of the database server 200 that has been successfully distributed and the update ID “I001”, and the database server 200 that has not been successfully distributed. The distribution result “undelivered” is stored in association with the database server name and the update ID “I001”. Note that the update information distribution unit 228 also sets the distribution result “undistributed” in association with the database server name and the update ID “I001” for the database server 200 whose device state is not normal and has not become a distribution destination. Store as initial value.

  Then, the update information distribution unit 228 of the database server “A” updates the user information DB 211 of the database server 200 with the distribution result “OK” (step S1405). Then, the update information distribution unit 228 of the database server “A” stores the update result for each database server 200 in association with the update ID in each of the distribution information DBs 213 of the plurality of database servers 200 (step S1406). For example, the update information distribution unit 228 stores the update result “OK” in association with the database server name of the database server 200 that has been determined to have been successfully updated and the update ID “I001”. More specifically, the update information distribution unit 228 stores the update result “OK” in association with the database server name “database server B” and the update ID “I001”. The update information distribution unit 228 also stores the update result “OK” in association with the update ID “I001” for the database server name “database server A”. For example, the update information distribution unit 228 stores the update result “NG” in association with the database server name of the database server 200 that has not been determined to have been successfully updated and the update ID “I001”. That is, each database server 200 stores an update result indicating whether or not the data update is completed for each of the plurality of database servers 200.

  Here, in each database server 200, when the user information DB 211 is updated, the update information distribution unit 228 generates IR information and stores it in the IR information DB 212 of the database server 200 of the own device (step S1407). . Specifically, the update information distribution unit 228 associates the update ID and key information included in the update data and stores them in the IR information DB 212. Here, the update information distribution unit 228 stores IR information in association with each of the cache server names of a plurality of cache servers 300 connected to the database server 200. For example, the update information distribution unit 228 stores IR information in association with the cache server name “cache server A”, and stores IR information in association with the cache server name “cache server B”.

  That is, each update information distribution unit 228 of each database server 300 associates IR information including key information for identifying the data to be updated with each of a plurality of cache server names when the data of the own database server is updated. And stored in the IR information DB 212.

  In the example illustrated in FIG. 13, IR information is generated and stored as a result of updating the user information DB 211 for both the database server “A” and the database server “B”.

  In addition, said process procedure is not limited to said order, You may change suitably in the range which does not contradict a process content. For example, in the above description, the case where there are two database servers 200 has been described. However, the present invention is not limited to this, and may be three or more.

  In the above description, the update information distribution unit 228 of the database server “A” updates the user information DB 211 of the database server “B” or stores the distribution result and the update result in the distribution information DB 213. Shown in the example. However, the present invention is not limited to this, and the update information distribution unit 228 of the database server “B” may update the user information DB 211 or store the distribution result and the update result in the distribution information DB 213. As will be described later, the update re-propagation unit 229 distributes the update data to the database server 200 to which the update information distribution unit 228 has not distributed update data.

[Processing between Database Server and Monitoring Server in Embodiment 1]
FIG. 14 is a sequence diagram illustrating an example of a flow of processing between the database server and the monitoring server in the first embodiment. The processing described below is executed regularly or irregularly. In the example shown in FIG. 14, one database server 200 is shown for convenience of description.

  As illustrated in FIG. 14, the failure determination unit 421 of the monitoring server 400 acquires a list of database server names from the device information DB 411 of its own device at the transmission timing (Yes in step S1501), and uses the acquired database server name. An apparatus status request is transmitted to each identified database server 200 (step S1502). For example, the failure determination unit 421 transmits a device status request to the database server “A”.

  Thereafter, upon receiving the device status request, the device status response unit 225 of the database server 200 confirms the status of the device itself (step S1503), and transmits device information serving as a response corresponding to the device status request (step S1504). . For example, the device status response unit 225 checks various processes used when processing by the update information distribution unit 228 and the update re-propagation unit 229 described later, the status of the network, and the like, and transmits them as device information.

  After that, when receiving the device information, the failure determination unit 421 of the monitoring server 400 executes failure determination based on the device state response from the database server 200 (step S1505), and stores the determination result in the device information DB 411 (step S1505). S1506). For example, when it is determined that the device state of the database server “A” is “normal”, the failure determination unit 421 is associated with the database server “A” among the device states stored in the device information DB 411. Update the device status to “Normal”.

  If the failure determination unit 421 of the monitoring server 400 determines that there is a failure (Yes at step S1507), the database server 200 that is the processing target transmits / receives data to / from the cache server 300. A block request for blocking is transmitted (step S1508). If the failure determination unit 421 does not determine that there is a failure (No in step S1507), the failure determination unit 421 does not transmit a block request.

  Then, the failure determination unit 421 of the monitoring server 400 returns to step S1502 and repeats the process when not executing all the database servers 200 (No at step S1509). On the other hand, when the failure determination unit 421 is executed for all the database servers 200 (Yes at step S1509), the failure determination unit 421 issues a device state storage request for storing each device state as a determination result for each database server 200 to the database server. 200 (step S1510), and the process ends.

  On the other hand, when the database server 200 receives the block request, the block control unit 227 blocks data transmission / reception with the cache server (step S1511). In the database server 200, when the device status storage request is received, the device status storage unit 226 acquires the device status for each database server 200 from the received device information storage request and stores it in the device information DB 214 of the own device. (Step S1512).

[Processing between Cache Server and Database Server in Embodiment 1]
15 and 16 are sequence diagrams illustrating an example of a flow of processing between the cache server and the database server according to the first embodiment. As will be described in detail below, the series of processing described in FIG. 15 is executed when the cache server 300 updates the search destination state DB 312. Also, a series of processes described in FIG. 16 is executed when the cache server 300 acquires IR information from the database server 200. In the following, for convenience of explanation, the processing executed when the cache server 300 updates the search destination state DB 312 and the processing in which the cache server 300 acquires IR information from the database server 200 will be described separately. You may perform continuously as a series of processes.

  FIG. 15 shows an example of the flow of processing performed between the cache server 300 and the database server 200 when the cache server 300 updates the search destination state DB 312.

  In the example illustrated in FIG. 15, the IR information determination unit 322 of the cache server 300 transmits an update success / failure request including the database server name stored in the search destination state DB 312 when the transmission timing comes (Yes in Step S1601) (Step S1602). ). The update success / failure request is information for requesting an update success / failure result indicating the status of update processing in the database server 200. Further, the IR information determination unit 322 transmits an update success / failure request for each database server name stored in the search destination state DB 312.

  Thereafter, when receiving the update success / failure request, the update success / failure response unit 224 of the database server 200 acquires an update result associated with the database server name included in the received update success / failure request from the distribution information DB 213 (step S1603). For example, when “database server A” is included in the update success / failure request, the update success / failure response unit 224 acquires the update result “OK” in the example illustrated in FIG.

  Then, the update information distribution unit 228 of the database server 200 determines an update success / failure result based on the acquired update result (step S1604), and responds to the cache server 300 with the update success / failure result (step S1605). Note that the update success / failure result determination process performed by the update information distribution unit 228 will be described later, and a description thereof will be omitted here.

  Thereafter, when receiving the update success / failure result from the database server 200, the IR information determination unit 322 of the cache server 300 determines the update registration state of the database server 200 based on the received update success / failure result (step S1606). That is, the IR information determination unit 322 determines, for each of the plurality of database servers 200, whether or not the update in the database server 200 is normally executed. Note that the update registration state determination processing by the IR information determination unit 322 will be described later, and thus the description thereof is omitted here.

  Then, the IR information determination unit 322 of the cache server 300 stores the update registration state that is the determination result in the update registration state DB 313 (step S1607). Further, the IR information determination unit 322 updates the closed state of the search destination state DB 312 (step S1608). Specifically, as will be described in detail later, when the update registration state is “normal”, the block state “unblocked” is stored, and when the update registration state is not “normal”, the block state Stores “block”.

  Next, an example of the flow of processing performed between the cache server 300 and the database server 200 when the cache server 300 acquires IR information from the database server 200 will be described with reference to FIG.

  As shown in FIG. 16, the IR information determination unit 322 of the cache server 300 transmits an IR information request including its own cache server name at the transmission timing (Yes at Step S1701) (Step S1702). For example, the cache server “A” transmits an IR information request including the cache server name “cache server A”. In this case, the IR information determination unit 322 requests IR information for the cache server “A”. That is, the IR information determination unit 322 acquires IR information stored in association with the cache server name that identifies the own cache server 300 from each of the plurality of database servers 200 using the IR information DB 212.

  After that, when receiving the IR information request, the IR information response unit 222 of the database server 200 acquires IR information corresponding to the “cache server name” included in the received IR information request from the IR information DB 212 of the own apparatus (step S1703), and transmits to the cache server 300 as an IR information response (step S1704). That is, the IR information response unit 233 transmits IR information including the key information and the update ID.

  Thereafter, the IR information determination unit 322 of the cache server 300 transmits an update information request using the update ID included in the IR information as a key (step S1705). For example, a case where key information “U001” and update ID “I001” are received as IR information will be described. In this case, the IR information determination unit 322 transmits an update information request including the update ID “I001”. That is, the IR information determination unit 322 requests each update result indicating whether or not each database server 200 has been updated for the update identified by the update ID. In other words, the IR information determination unit 322 acquires update results for each of the plurality of database servers 200 stored in the distribution information DB 213 from the database server 200.

  After that, when the update information response unit 223 of the database server 200 receives the update information request from the cache server 300, it distributes all the “database server name, update result” associated with the update ID included in the received update information request. Obtained from the information DB 213 (step S1706), and transmits it to the cache server 300 as an update information response (step S1707).

  Thereafter, the IR information determination unit 322 of the cache server 300 can delete the IR information based on the update registration state stored for each database server 200 in the update registration state DB 313 of the own device and the received update result. IR information deletion determination processing is executed to determine whether or not (step S1708). The details of the IR information deletion determination process will be described later and will be described later.

  If the IR information determination unit 322 of the cache server 300 determines that deletion is possible (Yes in step S1709), the data identified by the key information included in the IR information determined to be deleted is stored. Delete from the cache 311 (step S1710). That is, the IR information determination unit 322 invalidates the cache of data identified by the IR information.

  Further, the IR information determination unit 322 transmits an IR information deletion request for deleting the IR information determined to be deleted to the database server 200 (step S1711). The IR information deletion request includes an update ID included in the IR information to be deleted. Thereafter, when the database server 200 receives the IR information deletion request, the IR information including the update ID included in the IR information deletion request is deleted (step S1713).

  That is, the IR information determination unit 322 of the cache server 300 deletes the IR information from the cache server 300 by transmitting an IR information deletion request. Specifically, as will be described in detail later, the IR information determination unit 322 determines whether or not the update has been completed for all of the plurality of database servers 200 based on each update result, and the update has been completed. If it is determined, a deletion process for deleting the IR information from the IR information DB 212 is executed, and if it is determined that the update has not ended, the deletion process is not executed. More specifically, the IR information determination unit 322 determines whether or not the update has been completed for all the database servers 200 that are determined to be in a normally executed state, and determines that the update has been completed. Executes the deletion process and does not execute the deletion process when it is determined that the update has not ended.

  Further, the IR information determination unit 322 of the cache server 300 determines whether or not the processing has been executed for all the database servers 200 from which the IR information is acquired (step S1712). (Yes in S1712), the process is terminated. On the other hand, if it is determined that the IR information determination unit 322 is not executing (No at Step S1712), the process returns to Step S1702 described above and repeats the process.

[Processing between Client Terminal, Cache Server, and Database Server in Embodiment 1]
FIG. 17 is a sequence diagram illustrating an example of a process flow among the client terminal, the cache server, and the database server according to the first embodiment. Specifically, the flow of processing when the client terminal transmits a data request to the cache server 300 will be described. Hereinafter, when the client terminal 500 transmits a data request to the cache server 300, the cache server 300 does not store the attribute information identified by the key information included in the data request received from the client terminal 500. It explains using.

  As shown in FIG. 17, at the transmission timing (Yes at Step S1801), the client terminal 500 transmits a data request including key information for identifying requested data to the cache server 300 (Step S1802). For example, the client terminal 500 transmits a data request to the cache server 300 when using data that the device itself does not store.

  After that, when receiving a data request from the client terminal 500, the cache determination unit 321 of the cache server 300 acquires key information included in the received data request and stores attribute information associated with the acquired key information in the cache 311. To search (step S1803).

  Here, when the attribute information associated with the key information does not exist in the cache 311, the cache determination unit 321 of the cache server 300 searches for a database server name that is not in the search destination state DB 312 or the blocked state “blocked”. (Step S1804). Then, the cache determination unit 321 transmits a data search request for requesting attribute information corresponding to the key information included in the data request, to the database server 200 that is not blocked obtained as a result of the search (step S1805). .

  Thereafter, when the cache response unit 221 of the database server 200 receives the data search request from the cache server 300, the cache response unit 221 acquires key information from the received data search request and attributes corresponding to the key information acquired from the user information DB 211 of the own device. Information is acquired (step S1806). Then, the cache response unit 221 transmits a response to the data search request to the cache server 300 (step S1807). For example, if the attribute information corresponding to the acquired key information exists in the user information DB 211 of the own device, the cache response unit 221 transmits the acquired attribute information as a data response and does not exist in the user information DB 211 of the own device. In this case, the fact that the key information does not exist is transmitted as a data response.

  Thereafter, when receiving a data response, the response processing unit 323 of the cache server 300 transmits a data response to the data request from the client terminal 500 to the client terminal 500 (step S1808). For example, the response processing unit 323 transmits that the key information does not exist to the client terminal 500, transmits attribute information acquired from the user information DB 211, and transmits attribute information acquired from the cache 311 to the client terminal 500. Or send.

[Processing by Cache Response Unit of Database Server in Embodiment 1]
FIG. 18 is a flowchart illustrating an example of a process flow by the cache response unit of the database server in the first embodiment. As described below, the cache response unit 221 executes a series of processes described below each time a data search request is received from the cache server 300.

  As illustrated in FIG. 18, when the cache response unit 221 receives a data search request from the cache server 300 (Yes in step S1201), the cache response unit 221 acquires key information from the received data search request (step S1202). Then, the cache response unit 221 acquires attribute information corresponding to the acquired key information from the user information DB 211 of the own device (step S1203).

  When the attribute information corresponding to the acquired key information is present in the user information DB 211 of the own device (Yes in step S1204), the cache response unit 221 acquires the attribute information from the user information DB 211 and stores the attribute information in the cache server 300. A response is made (step S1205). On the other hand, if the attribute information corresponding to the acquired key information does not exist in the user information DB 211 of the own device (No at step S1204), the cache response unit 221 indicates that the key information included in the data request does not exist. Responds to 300 (step S1206). That is, the cache response unit 221 transmits a data response to the data search request to the cache server 300.

[Processing by IR Information Response Unit of Database Server in Embodiment 1]
FIG. 19 is a flowchart illustrating an example of a process flow by the IR information response unit of the database server in the first embodiment. As will be described below, the IR information response unit 222 executes a series of processes described below each time an IR information request is received from the cache server 300.

  As shown in FIG. 19, when receiving the IR information request (Yes at Step S1301), the IR information response unit 222 of the database server 200 acquires the “cache server name” included in the received IR information request (Step S1302). . That is, the cache server name of the cache server 300 that is the transmission source of the IR information request is acquired.

  Then, the IR information response unit 222 acquires “key information, update ID” associated with the acquired “cache server name” from the IR information DB 212 of the own apparatus (step S1303). That is, the IR information response unit 222 acquires IR information destined for the cache server 300 that is the transmission source of the IR information request.

  Here, when the “key information, update ID” associated with the acquired “cache server name” exists in the IR information DB 212 of the own apparatus (Yes in step S1304), the IR information response unit 222 determines that the cache server The “key information, update ID” associated with the name is returned to the cache server 300 (step S1305). On the other hand, when there is no “key information, update ID” associated with the acquired “cache server name” (No in step S1304), the IR information response unit 222 sets “no IR information” to the cache server 300. (Step S1306). That is, the IR information response unit 222 transmits an IR information response to the cache server 300 in response to the IR information request.

  That is, when receiving the IR information request from the cache server 300, the IR information response unit 222 determines whether the IR information associated with the cache server name indicating the transmission source of the IR information request is stored in the IR information DB 212. judge. Then, when stored in the IR information DB 212, the IR information response unit 222 acquires IR information associated with “cache server name” and responds to the cache server 300. Here, “key information” and “update ID” included in the IR information indicate that “key information” has been updated in the own apparatus, and the distribution status of the update information can be referred to by “update ID”. Further, the IR information response unit 222 responds “no IR information” to the cache server 300 when IR information is not stored in the IR information DB 212.

[Processing by Update Information Response Unit of Database Server in Embodiment 1]
FIG. 20 is a flowchart illustrating an example of a process flow by the update information response unit of the database server in the first embodiment. As will be described below, the update information response unit 223 executes a series of processes described below each time an update information request is received from the cache server 300.

  As illustrated in FIG. 20, when the update information response unit 223 of the database server 200 receives an update information request from the cache server 300 (Yes in step S501), the update information response unit 223 acquires an update ID included in the received update information request (step S502). ). For example, the update information response unit 223 acquires the update ID “I001”.

  Then, the update information response unit 223 acquires all the “database server name and update result” associated with the “update ID” acquired from the distribution information DB 213 of the own device (step S503). For example, the update information response unit 223 acquires all combinations of database server names and update results associated with the update ID “I001”.

  Here, the update information response unit 223 responds to the update ID when “database server name, update result” associated with “update ID” exists in the distribution information DB 213 of the own device (Yes in step S504). The attached “database server name, update result” is returned to the cache server 300 (step S505). On the other hand, if there is no “database server name, update result” associated with the “update ID” in the distribution information DB 213 of the own device (No in step S504), the update information response unit 223 determines “no update information”. In response to the cache server 300 (step S506). That is, the update information response unit 223 transmits an update information response to the cache server 300 in response to the update information request.

  Here, the “database server name” and “update result” acquired by the update information response unit 223 are update information corresponding to the IR information acquired by the cache server 300 as a result of the IR information request, respectively. Whether the update identified by the update ID is completed is shown for each database server name.

[Processing by update success / failure response unit of database server in embodiment 1]
FIG. 21 is a flowchart illustrating an example of a process flow by the update success / failure response unit of the database server according to the first embodiment. As will be described below, the update success / failure response unit 224 executes a series of processes described below each time it receives update success / failure request information from the cache server 300.

  As illustrated in FIG. 21, when the update success / failure response unit 224 of the database server 200 receives an update success / failure request from the cache server 300 (Yes in step S601), the database server 200 acquires a database server name included in the received update success / failure request (step S601). S602). For example, the update success / failure response unit 224 acquires the database server name “database server A”.

  Then, the update success / failure response unit 224 acquires an update result corresponding to the database server name acquired from the update success / failure request from the distribution information DB 213 of the own device (step S603). For example, in the example illustrated in FIG. 5, the distribution information DB 213 stores the update result “OK” in association with the database server name “database server A”. In this case, the update success / failure response unit 224 acquires the update result “OK”.

  That is, when the update success / failure response unit 224 receives the distribution success / failure request from the cache server 300, the update success / failure response unit 224 determines whether or not the database server name included in the distribution success / failure request is stored in the distribution information DB 213. If the update success / failure response unit 224 determines that the update information is stored in the distribution information DB 213, the update success / failure response unit 224 acquires all combinations of update results and update IDs associated with the “database server name”.

  Then, the update success / failure response unit 224 determines an update success / failure result based on the acquired update result (step S604), and returns an update success / failure result as a determination result to the cache server 300 (step S605). Here, the update success / failure result is information indicating the state of the update process being executed in the database server 200.

  Here, the determination of the update success / failure result will be further described. The update success / failure response unit 224 determines an update success / failure result based on the update success / failure result correspondence table in which the update result of the distribution information DB 213 and the update success / failure result are associated with each other.

  FIG. 22 is a diagram illustrating an example of an update success / failure result correspondence table according to the first embodiment. In the example illustrated in FIG. 22, the case where the update success / failure result is any one of “registration normal”, “registration abnormality”, and “waiting for registration” is illustrated as an example, but the present invention is not limited to this. Any update success / failure result may be used. Here, “registration normal” indicates that the update information has been successfully registered in the corresponding database server 200. “Registration abnormality” indicates that registration of update information has failed in the corresponding database server 200. “Waiting for registration” indicates that update information distribution or update re-propagation processing is currently being performed between the database servers 200, and that update information will be registered in the corresponding database server 200 in the future.

  As illustrated in FIG. 22, when the update success / failure response unit 224 acquires an update result from the distribution information DB 213, the update success / failure response unit 224 acquires an update success / failure result associated with the acquired update result from the update success / failure result correspondence table and sets it as a determination result. . For example, the case where the update result “OK” is acquired from the distribution information DB 213 will be described. In this case, the update success / failure response unit 224 acquires the update success / failure result “registration normal” associated with the update result “OK” and uses it as the determination result.

  That is, the update success / failure response unit 224 determines the “update success / failure result” in the database server name using the update success / failure result correspondence table, and caches any of “registration normal”, “registration abnormality”, and “waiting for registration”. Responds to server 300. For example, when the “update result of distribution information DB” is “no record”, the update success / failure response unit 224 uses the update success / failure result “registration normal” in the same row in the update success / failure result correspondence table as the determination result. .

[Processing by Device Status Response Unit of Database Server in Embodiment 1]
FIG. 23 is a flowchart illustrating an example of processing performed by the apparatus status response unit of the database server according to the first embodiment. As described below, the device status response unit 225 executes a series of processes described below each time a device status request is received from the monitoring server 400.

  As illustrated in FIG. 23, the device status response unit 225 of the database server 200 receives a device status request from the monitoring server 400 (Yes in step S801), and checks the status of the distribution-related resource of the own device (step S802). Specifically, the device status response unit 225 checks various processes and network statuses used when the device itself executes processing by an update information distribution unit 228 and an update re-propagation unit 229 described later.

  Then, the device state response unit 225 transmits a device state response serving as a response corresponding to the device state request (step S803), and ends the process. For example, the device status response unit 225 transmits information on the confirmed distribution-related resources to the monitoring server 400 as a device status response, and ends the process.

[Processing by the apparatus status storage unit of the database server in the first embodiment]
FIG. 24 is a flowchart illustrating an example of a process flow by the apparatus state storage unit of the database server in the first embodiment. As will be described below, the device status storage unit 226 executes a series of processes described below each time a device status storage request is received from the monitoring server 400.

  As illustrated in FIG. 24, when the apparatus state storage unit 226 of the database server 200 receives the apparatus state storage request from the monitoring server 400 (Yes in step S901), the apparatus state storage unit 226 of each database server 200 receives the apparatus state storage request from the received apparatus state storage request. The device state is acquired (step S902) and stored in the device information DB 214 of the own device (step S903).

  For example, the device state storage unit 226 receives the device state of the database server “A” and the device state of the database server “B” from the monitoring server 400 and stores them in association with the received device state database server name.

[Flow by Blocking Control Unit of Database Server in Embodiment 1]
FIG. 25 is a flowchart illustrating an example of a processing flow by the block control unit of the database server in the first embodiment. As described below, the block control unit 227 executes a series of processes described below each time a block request is received from the monitoring server 400.

  As illustrated in FIG. 25, when the block control unit 227 receives a block request from the monitoring server 400 (Yes in step S701), the block control unit 227 performs a blocking process on a search request provided by the own device to the cache server 300 (step S702). That is, the block control unit 227 blocks data transmission / reception with the cache server.

  Then, when the blocking process is successful (Yes at Step S703), the blocking control unit 227 responds to the monitoring server 400 with the blocking success (Step S704). On the other hand, when the blocking process has failed (No at step S703), the blocking control unit 227 responds to the monitoring server 400 with the blocking control unit 227 (block S705). Then, the closing control unit ends the process.

  That is, when receiving the blocking request from the monitoring server 400, the blocking control unit 227 blocks all requests from the cache server 300 provided by the own device, and responds to the monitoring server 400 with success or failure of blocking.

[Processing by Update Information Distribution Unit of Database Server in Embodiment 1]
FIG. 26 is a flowchart illustrating an example of a detailed processing flow by the update information distribution unit of the database server in the first embodiment. When the user information DB 211 is updated, the update information distribution unit 228 performs a series of processes described below. The series of processes described below is a process executed by the update information distribution unit 228 of the database server “A” that has received the update instruction in the series of processes described with reference to FIG. 13. In the following description, a specific example will be described using a case where an update instruction is given to the database server “A”.

  As illustrated in FIG. 26, when there is an update instruction, the update information distribution unit 228 of the database server 200 determines whether the own apparatus is a distribution apparatus (step S301). For example, if the own device is a device that has received an update instruction from a user, the update information distribution unit 228 determines that the device is a device that performs distribution, and is a device that has received update data from another database server 200. In some cases, it is determined that the device is not a distribution device. Here, if the update information distribution unit 228 determines that the device is not a device that performs distribution (No in step S301), it indicates that the distribution process or the update process has failed because the update process cannot be continued. A registration failure is returned (step S310), and the process is terminated.

  If the update information distribution unit 228 determines that the device is a device that performs distribution (Yes at Step S301), the update information distribution unit 228 determines the distribution order of update data (Step S302). Specifically, the update information distribution unit 228 acquires the device state associated with the database server name from the device information DB 214 of the own device, and generates a list of the database servers 200 associated with the device state “normal”. To do. Further, the update information distribution unit 228 generates a list so that the head of the list is the own device. Here, the list generated by the update information distribution unit 228 becomes a list of the database servers 200 as distribution destinations, and the arrangement order of the database servers 200 described in the list becomes the distribution order.

  Then, the update information distribution unit 228 issues an update ID (Step S303). The update ID becomes identification information having order in the cache control system. For example, the update information distribution unit 228 pays out the distribution time as an update ID, or pays out information obtained by adding a branch number to the distribution information as an update ID. For example, the update information distribution unit 228 pays out the update ID “I001”.

  Then, the update information distribution unit 228 distributes update data to the database server 200 that is a distribution destination (step S304). That is, the update information distribution unit 228 selects one undelivered database server 200 in accordance with the distribution order from the list of database servers 200 associated with the device state “normal”, and updates the selected database server 200 with the update data. Send. The update information distribution unit 228 transmits an update ID, key information for identifying updated data, and updated data as update data.

  Then, the update information distribution unit 228 determines whether the distribution is successful (step S305), and when it is determined that the distribution is successful (Yes in step S305), distributes all of the database servers 200 that are the distribution destinations. It is determined whether it has been done (step S307). If the update information distribution unit 228 determines that the distribution is not executed for all the database servers 200 that are the distribution destinations (No at Step S307), the update information distribution unit 228 returns to Step S304 and repeats the process.

  On the other hand, when the update information distribution unit 228 determines that the distribution has failed (No at Step S305), the update information distribution unit 228 determines whether the database server 200 that is the distribution destination is its own device (Step S306). Note that the case where the delivery to the own device fails is, for example, a case where the own device is out of order and the update instruction cannot be received normally. Here, if the update information distribution unit 228 determines that the database server 200 that is the distribution destination is its own device (Yes in step S306), the update process cannot be continued, so the distribution process or the update process A registration failure indicating that has failed has been returned (step S310), and the process is terminated.

  On the other hand, if the update information distribution unit 228 determines that the database server 200 that is the distribution destination is not its own device (No at Step S306), the update information distribution unit 228 executes the process at Step S307 described above.

  In step S307 described above, when it is determined that the distribution has been executed for all the database servers 200 that are the distribution destinations (Yes in step S307), the update information distribution unit 228 associates the update ID with the database server 200. Each distribution result is stored in the distribution information DB 213 in association with the update ID (step S308). Specifically, the update information distribution unit 228 stores the distribution result “OK” in association with the database server name of the database server 200 that has been successfully distributed and the update ID “I001”, and the database that has not been successfully distributed. The server 200 also stores the distribution result “undistributed” in association with the database server name and the update ID “I001”. Further, the update information distribution unit 228 also sets the distribution result “undistributed” in association with the database server name and the update ID “I001” for the database server 200 whose device state is not normal and has not become a distribution destination. Store.

  Here, the update information distribution unit 228 stores the distribution result for each database server 200 in all the database servers 200. That is, the distribution result for each database server 200 is stored in the distribution information DB 213 of all the database servers 200. For example, the update information distribution unit 228 of the database server “A” may store directly in the distribution information DB 213 of the database server “B”, and the database server “B” transmits and receives data to and from the database server “B”. B ”may be stored in the distribution information DB 213 of the database server“ B ”.

  Then, the update information distribution unit 228 acquires a database server name whose distribution result of the distribution information DB 213 is “OK” (step S311). Here, the update information distribution unit 228 creates a list of the acquired database server names so that the head of the created list becomes its own device.

  Then, the update information distribution unit 228 selects one database server 200 whose distribution result is “OK”, and updates the user information DB 211 of the selected database server 200 (step S312). Specifically, the update information distribution unit 228 includes, among the data stored in the user information DB 211, data identified by key information included in the update data distributed in advance, in the update data distributed in advance. Update to the updated data.

  Here, in each database server 200, when the data in the user information DB 211 of the database server 200 is updated, the update information distribution unit 228 generates IR information and stores it in the IR information DB 212 of the database server 200 of its own device. Store. That is, the update information distribution unit 228 associates the update ID included in the update data with the key information and stores them in the IR information DB 212. Here, the update information distribution unit 228 stores IR information in association with each of the cache server names of a plurality of cache servers 300 connected to the database server 200.

  For example, the update information distribution unit 228 of the database server “A” may directly update the user information DB 211 of the database server “B”, and the user information DB 211 is added to the update information distribution unit 228 of the database server “B”. You may make it update. Similarly, the update information distribution unit 228 of the database server “A” may directly store IR information in the IR information DB 212 of the database server “B”, and the update information distribution unit 228 of the database server “B” IR information may be stored.

  Then, the update information distribution unit 228 determines whether the update has been successful (step S313). If the update information distribution unit 228 determines that the update is successful (Yes at Step S313), the update information distribution unit 228 stores the update result “OK” in association with the name of the database server that was successfully updated (Step S316). .

  On the other hand, if the update information distribution unit 228 does not determine that the update has succeeded (No at Step S313), the update information distribution unit 228 determines whether or not the database server 200 that is the update destination is its own device (Step S314). . Here, when the update information distribution unit 228 determines that the database server 200 that is the update destination is its own device (Yes in step S314), the update information cannot be continued, so the update information distribution unit 228 performs processing from the distribution information DB 213. The line including the target update ID is deleted (step S309), a registration failure indicating that the distribution process or the update process has failed is returned (step S310), and the process ends. In addition, when the update information distribution unit 228 determines that the database server 200 that is the update destination is not its own device (No in step S314), the update information distribution unit 228 associates it with the database server name that has not been successfully updated, The update result “NG” is stored (step S315).

  Here, the update information distribution unit 228 stores the update results for each database server 200 in all the database servers 200. That is, the update result for each database server 200 is stored in the distribution information DB 213 of all the database servers 200. For example, the update information distribution unit 228 of the database server “A” may store directly in the distribution information DB 213 of the database server “B”, and the database server “B” transmits and receives data to and from the database server “B”. B ”may be stored in the distribution information DB 213 of the database server“ B ”.

  Then, the update information distribution unit 228 determines whether or not the update has been performed for all the database servers 200 that are update destinations (step S317). Here, when the update information distribution unit 228 determines that the update has not been performed for all the database servers 200 that are the update destinations (No at Step S317), the update information distribution unit 228 returns to Step S312 and repeats the process. On the other hand, if the update information distribution unit 228 determines that the update has been performed for all the database servers 200 that are the update destinations (Yes in step S317), the update information distribution unit 228 sends a registration success response indicating that the update process has ended (step S318). ), The process is terminated.

[Processing by Update Repropagation Unit of Database Server in Embodiment 1]
FIG. 27 is a flowchart illustrating an example of a processing flow by the update re-propagation unit of the database server according to the first embodiment. As will be described below, the update data is transmitted to the database server 200 that has not been distributed by the update information distribution unit 228.

  That is, as will be described below, the update re-propagation unit 229 performs the update on the database server 200 in which the update data distribution unit 228 has not delivered update data or the database server 200 in which update has not been performed due to a failure or the like. , Distribute update data or execute update. Note that the update re-propagation unit 229 periodically executes the processing described below or irregularly.

  As illustrated in FIG. 27, when the update re-propagation unit 229 of the database server 200 starts the re-propagation process, the update re-propagation unit 229 determines whether or not the own database server 200 is a distribution device (step S401). If the update re-propagation unit 229 determines that the update re-propagation unit 229 is a distribution device (Yes at Step S401), the update re-propagation unit 229 acquires an update ID other than “OK” as the update result of the own device from the distribution information DB 213 (Step S402). .

  Here, when there is an update ID (Yes at Step S403), the update re-propagating unit 229 updates the data of the database server 200 to be updated using the update data corresponding to the update ID (Step S404). .

  Then, when the update of the database server 200 to be updated is successful (Yes in step S405), the update re-propagation unit 229 associates the update result “OK” with the name of the database server that has been successfully updated, and the distribution information DB 213. (Step S407).

  Then, the update re-propagation unit 229 determines whether or not there is an unprocessed update ID (step S408), and determines that all the update IDs have been processed (No at step S408). A list of database servers 200 other than the apparatus is created (step S409).

  On the other hand, returning to step S408, if the update re-propagating unit 229 determines that there is an unprocessed update ID (Yes at step S408), the update re-propagating unit 229 returns to step S404 and repeats the process.

  Returning to step S405, the update re-propagation unit 229 stores the update result “NG” in the update result column corresponding to the target database server name in the distribution information DB 213 when the update has failed (No in step S405) (step S405). S406), the processing after step S409 is continued. Returning to step S403, if the update ID does not exist (No at step S403), the update re-propagation unit 229 continues the processing from step S409.

  Next, the process after step S409 is demonstrated. As will be described below, the update re-propagation unit 229 stores, for each database server 200, a result other than “OK” as the distribution result of the corresponding database server 200 from the list of database servers 200 other than the device. The update ID of the row is acquired from the distribution information DB 213, and processing and updating for distributing update data are executed.

  As shown in step S409, the update re-propagation unit 229 determines the search order by an arbitrary method (step S409). Then, the update re-propagation unit 229 acquires an update ID of a row in which a result other than the distribution result “OK” is stored for one database server 200 selected according to the search order (step S410). For example, a case where the database server 200 serving as a distribution apparatus is the database server “A” and the database server “B” is selected will be described. In this case, the update re-propagation unit 229 of the database server “A” refers to the distribution information DB 213 of the own device, and among the update IDs associated with the database server name “database server B”, other than the distribution result “OK”. An update ID associated with is acquired.

  Here, when the update ID exists (Yes at Step S411), the update re-propagation unit 229 distributes the update data for the acquired update ID to the target database server 200 and stores the distribution result in the distribution information DB 213. (Step S412). That is, the update re-propagation unit 229 stores the distribution result “OK” when the distribution is successful, and stores the distribution result “undistributed” when the distribution is not successful.

  Then, the update re-propagation unit 229 determines whether or not all the update IDs acquired in step S410 have been processed (step S413). If it is determined that the update ID has not been processed (No in step S413), the process returns to step S412 to perform the process. repeat. On the other hand, when the update re-propagation unit 229 determines that all the processes have been processed (Yes at Step S413), the process after Step S414 is performed. In step S411, even if there is no update ID in the first place (No in step S411), the processing after step S414 is performed.

  Then, the update re-propagation unit 229 acquires an update ID other than “OK” as the update result of the database server 200 to be processed from the distribution information DB 213 (step S414). For example, a case where the database server 200 serving as a distribution apparatus is the database server “A” and the database server “B” is selected will be described. In this case, the update re-propagation unit 229 of the database server “A” refers to the distribution information DB 213 of the own device, and the update ID associated with the database server name “database server B” is other than the update result “OK”. An update ID associated with is acquired.

  Here, when there is an update ID (Yes at Step S415), the update re-propagating unit 229 updates the user information DB 211 of the database server 200 to be processed using the distributed update data corresponding to the update ID. (Step S416). If the update re-propagation unit 229 succeeds in updating (Yes in step S417), the update re-propagation unit 229 associates the update result “OK” with the update ID to be processed and the database server name to be processed. Stored in the distribution information DB 213 (step S418). On the other hand, if the update has not been successfully updated (No at Step S417), the update re-propagation unit 229 associates the update result “NG” with the update ID that is the processing target and the database server name that is the processing target. Is stored in the distribution information DB 213 (step S420).

  When the update ID to be processed still remains (No at Step S419), the update re-propagating unit 229 returns to Step S416 and repeats the process. On the other hand, when all update IDs have been processed (Yes at Step S419), the update re-propagation unit 229 determines whether the processing has been executed for all the database servers 200 (Step S421). If it is determined that the process has been executed (Yes at step S421), the process ends. On the other hand, if the update re-propagation unit 229 determines that the process is not executed (No at Step S421), the update re-propagation unit 229 returns to Step S410, selects the next database server 200 according to the search order, and repeats the process.

[Processing by Cache Determination Unit of Cache Server in Embodiment 1]
FIG. 28 is a flowchart illustrating an example of a flow of processing performed by the cache determination unit of the cache server according to the first embodiment. As will be described below, each time the cache determination unit 321 of the cache server 300 receives a data request from the client terminal 500, it executes a series of processes shown in FIG. That is, every time a data request including key information of data requested by the client terminal 500 is transmitted to the cache server 300, the processing described below is executed.

  As illustrated in FIG. 28, when the cache determination unit 321 of the cache server 300 receives a data request from the client terminal 500 (Yes in step S101), the cache determination unit 321 acquires key information included in the received data request and includes the acquired key information. The associated attribute information is searched in the cache 311 (step S102).

  Here, when the attribute information associated with the key information exists in the cache 311 (Yes at Step S103), the cache determination unit 321 outputs the attribute information stored in the cache 311 to the response processing unit 323. (Step S104).

  For example, a case where key information “U001” is included in the data request will be described. In this case, the cache determination unit 321 searches the cache 311 for attribute information associated with the key information “U001”. Here, for example, when the cache 311 stores the key information “U001” and the attribute information “P001” in association with each other, the cache determination unit 321 acquires the attribute information “P001” from the cache 311 and returns a response. The data is output to the processing unit 323.

  On the other hand, returning to step S103, if the attribute information associated with the key information does not exist in the cache 311 (No in step S103), the cache determination unit 321 has the blocking state “blocking” from the search destination state DB 312. A database server name that does not exist is searched (step S105). That is, the cache determination unit 321 searches the database server 200 that is not in the blocked state “blocked” by referring to the search destination state DB 312 in the own device.

  Here, when all the blocked states of the database server 200 are “blocked” (Yes at Step S106), the cache determination unit 321 outputs a search failure to the response processing unit 323 (Step S111). That is, in this case, there is no database server 200 as a request destination for requesting data that the cache server 300 does not have in the cache 311 of its own device, and data cannot be acquired from the database server 200 and transmitted to the client terminal 500. Based on this, the cache determination unit 321 outputs a search failure to the response processing unit 323.

  On the other hand, if all of the blocked states of the database server 200 are not “blocked” (No at Step S106), the cache determination unit 321 selects one of the unblocked database servers 200 and is included in the data request. A data search request for requesting attribute information corresponding to the key information is transmitted to the selected non-blocked database server 200 (step S107).

  In other words, when the attribute information is not stored in the cache 311, for example, the cache determination unit 321 transmits a data search request for requesting attribute information corresponding to the key information “U001” included in the data request. Here, in the example illustrated in FIG. 9, the database server 200 that is the transmission destination is the database server “A” or the database server “B” associated with the blocked state “not blocked”.

  Then, the cache determination unit 321 receives a response to the data search request from the database server 200 (step S108). Here, if there is a search result (Yes at Step S109), the cache determination unit 321 stores the data in the cache 311 (Step S110), and outputs the attribute information to the client terminal 500. On the other hand, when there is no search result (No at Step S109), the cache determination unit 321 outputs that the key information included in the data request does not exist to the response processing unit 323 (Step S112).

[Processing by IR Information Determination Unit of Cache Server in Embodiment 1]
FIG. 29 is a flowchart illustrating an example of a process flow by the IR information determination unit of the cache server according to the first embodiment. In the following, the cache will be described using a case where the process executed when the cache server 300 updates the search destination state DB 312 and the process where the cache server 300 continuously acquires IR information from the database server 200. The IR information determination unit 322 of the server 300 performs a series of processes described below periodically or irregularly.

  As shown in FIG. 29, the IR information determination unit 322 of the cache server 300 determines the search order of the database server 200 that is a search destination of IR information (step S201). Here, each database server 200 as a search destination of IR information becomes each database server 200 identified by the database server name stored in the search destination state DB 312 of each cache server 300. That is, based on the fact that IR information cannot be acquired from a database server 200 that has not been updated normally, the IR information determination unit 322 performs update processing for each database server 200 that is a search destination of IR information. Search the status.

  Returning to the description of FIG. Then, the IR information determination unit 322 transmits an update success / failure information search request including the name of the database server to be searched to the database server 200 (step S202). The case where the database server 200 as a search destination is the database server “A” will be described. In this case, the IR information determination unit 322 transmits an update success / failure request including the database server name “database server A” to any database server 200.

  The IR information determination unit 322 receives the update success / failure result from the database server 200 (step S203), and determines the update registration state of the database server 200 based on the received update success / failure result (step S204).

  Here, the update registration state determination process by the IR information determination unit 322 will be further described. Specifically, the IR information determination unit 322 determines the current update registration state based on the received update success / failure result and the previous update registration state determination result. For example, the IR information determination unit 322 determines the update registration state based on the update registration state correspondence table in which the update success / failure result, the previous update registration state determination result, and the current update registration state are associated with each other. Further, the IR information determination unit 322 stores the update registration state that is the determination result in the update registration state DB 313.

  FIG. 30 is a diagram illustrating an example of an update registration state correspondence table according to the first embodiment. In the example illustrated in FIG. 30, the update registration state is one of “normal”, “propagation abnormality detection”, “propagation abnormality”, and “during normal transition”. Any update registration state may be used.

  As shown in FIG. 30, when receiving the update success / failure result, the IR information determination unit 322 acquires the update registration state from the update registration state correspondence table using the previous update registration state and the received update success / failure result as search keys. The current update registration state is assumed. For example, the case where the update result “registration normal” is received will be described. Further, the case where the previous update registration state stored in the update registration state DB 313 is “propagation abnormality” will be described. In this case, the IR information determination unit 322 acquires the update registration state “normal” from the update registration state correspondence table using the update result “registration normal” and the previous update registration state “arbitrary” as search keys, and updates this time. Registered.

  Then, the IR information determination unit 322 determines whether the update registration state is other than “normal” (step S205). If the IR information determination unit 322 determines that the update registration state is “normal” (No at step S205), the IR information determination unit 322 determines a database that is a search destination of IR information with respect to the search destination state DB 312 of the own device. The block state “unblocked” is stored in association with the database server name of the server 200 (step S207). On the other hand, when the IR information determination unit 322 determines that the update registration state is other than “normal” (Yes at Step S205), the IR information determination unit 322 makes a database that is a search destination of IR information with respect to the search destination state DB 312 of the own device. The blocked state “blocked” is stored in association with the database server name of the server 200 (step S206).

  Then, the IR information determination unit 322 determines whether the processing has been executed for each of all the database servers 200 (step S208), and if it is determined that the processing has not been executed (No in step S208), the search order is the next. The database server 200 is determined, the process returns to step S202 described above, and the process is repeated.

  When it is determined that the processing has been executed for each of the database servers 200 (Yes in step S208), the IR information determination unit 322 sets the search order for searching IR information for each database server 200 to an arbitrary method. (Step S210).

  Then, the IR information determination unit 322 transmits an IR information request including its own cache server name to the database server 200 (step S211). For example, the cache server “A” transmits an IR information request including the cache server name “cache server A”.

  When receiving the search result from the database server 200 (step S212), the IR information determination unit 322 determines whether IR information exists in the received search result (step S213). If the IR information determination unit 322 determines that IR information exists (Yes at Step S213), the IR information determination unit 322 transmits an update information request using the update ID included in the IR information as a key (Step S214). For example, a case where key information “U001” and update ID “I001” are received as IR information will be described. In this case, the IR information determination unit 322 transmits an update information request including the update ID “I001”. That is, the IR information determination unit 322 acquires information indicating whether or not each database server 200 has been updated for the update identified by the update ID. In other words, the IR information determination unit 322 acquires the update result for the update identified by the update ID included in the received IR information for all the database servers 200 from which the IR information is acquired.

  When receiving the update result corresponding to the update ID from the database server 200 (step S215), the IR information determination unit 322 receives the update registration state stored for each database server 200 in the update registration state DB 313 of the own device, and the reception Based on the updated result, IR information deletion determination processing for determining whether to delete IR information is executed (step S216).

  For example, the IR information determination unit 322 performs IR information deletion determination processing based on an IR information deletion target determination table in which a condition that enables IR information to be deleted is associated with each combination of update registration states of each database server 200. Execute. FIG. 31 is a diagram illustrating an example of an IR information deletion target determination table according to the first embodiment. In the example illustrated in FIG. 31, a case where there are “two” database servers 200 from which IR information is acquired will be described. That is, for example, the IR information determination unit 322 acquires all update registration states for each database server from the update registration state DB 313 of the own device. Then, the IR information determination unit 322 applies each of the acquired update registration states to the IR information deletion target determination table to determine IR information that can be deleted.

  In the example illustrated in FIG. 31, the IR information deletion target determination table includes “update registration status of the IR information deletion target database server (server 1)” and “update registration status of the IR information deletion non-target database server (server 2)”. In association with these combinations, “the state of the update ID that is the IR information deletion target” is stored.

  Here, “the update registration state of the IR information deletion target database server (server 1)” indicates the database server 200 that is a target for determining whether or not to delete the IR information. For example, in step S211 described above, the database server 200 that is the transmission destination that transmitted the IR information request corresponds. In the following description, it is assumed that “the update registration status of the IR information deletion target database server (server 1)” is the database server “A”.

  The “IR information deletion non-target database server (server 2) update registration status” is a database server other than the “IR information deletion target database server (server 1) update registration status” among the plurality of database servers 200. 200 is shown. For example, all the database servers 200 excluding the database server “A” from the database server 200 whose database server name is stored in the update registration state DB 313 correspond to each of them. In the following description, the case where “the update registration state of the IR information deletion non-target database server (server 2)” is one database server “B” will be described.

  “The state of the update ID that is the target of IR information deletion” indicates a condition under which IR information can be deleted. Specifically, “(Server 1) (Server 2) is OK” indicates that IR information including an update ID having an update result “OK” in both (Server 1) and (Server 2) can be deleted. It shows that it becomes. “(Server 1) is OK” indicates that IR information including an update ID having an update result “OK” at (Server 1) can be deleted. Here, the database server 200 from which IR information is deleted is the “IR information deletion target database server (server 1)”.

  Here, a case where the update registration state of the database server “A” is “normal” and the update registration state of the database server “B” is “normal” will be described. In this case, the IR information determination unit 322 combines the update registration state “normal” of the IR information deletion target database server (server 2) and the update registration state “normal” of the IR information deletion non-target database server (server 2). "Status of update ID to be deleted of IR information" associated with the ID is acquired. In the example illustrated in FIG. 31, the IR information determination unit 322 acquires the status of update ID that is the IR information deletion target “both (server 1) and (server 2) are OK”. In this case, “OK for both (Server 1) and (Server 2)” is a condition for enabling the IR information to be deleted. That is, for the update ID whose update result is “OK” in the database server “A” and whose update result is “OK” in the database server “B”, IR information is received from the database server “A”. It is determined that it can be deleted. Then, the IR information determination unit 322 includes “the database server name, the update result” included in the update result response received from the database server 200, with “(server 1) (server 2) OK” as the obtained condition. And IR information matching the condition is determined to be deleteable.

  A detailed example will be described. For example, the case where the “update registration state” of the database server “A” is “normal” will be described. Further, for example, the case where the “update registration state” of the database server “B” is “normal” will be described. Further, for example, a case where “server name, update result” included in the update information response is “database server“ A ”, OK”, “database server“ B ”, OK” will be described. In this case, the IR information determination unit 322 acquires the IR information deletion possible condition “(Server 1) (Server 2) is OK” from the IR information deletion target determination table. Here, since (Server 1) is the database server “A” and (Server 2) is the database server “B”, the IR information deletion target determination table determines that the IR information can be deleted.

  Further, a detailed example will be described. For example, the case where the “update registration state” of the database server “A” is “normal” will be described. Further, for example, a case where the “update registration state” of the database server “B” is “propagation abnormality detection” will be described. Further, for example, a case where “server name, update result” included in the update information response is “database server“ A ”, OK”, “database server“ B ”, NG” will be described. In this case, the IR information determination unit 322 acquires the IR information deletion enable condition “(Server 1) (Server 2) is OK” from the IR information deletion target determination table. As a result, the IR information determination unit 322 determines that the IR information cannot be deleted.

  That is, the IR information determination unit 322 acquires update results for each of a plurality of database servers stored in the distribution information DB 213 from the database server 200. Then, the IR information determination unit 322 determines, for each update ID, whether or not the update has been completed for all the plurality of database servers based on each of the acquired update results, and for the update ID that is determined to have been updated. It is determined that the IR information can be deleted, and it is determined that the IR information is not deleted for the update ID that has not been determined to have been updated.

  More specifically, the IR information determination unit 322 determines, for each of a plurality of database servers, whether or not the update in the database server 200 is being executed normally. Then, the IR information determination unit 322 determines whether or not the update has been completed for all the database servers 200 determined to be in a normally executed state, and when it is determined that the update has ended, the IR information is determined. Is determined to be deleted. If it is determined that the update has not been completed, it is determined that the IR information is not deleted.

  Returning to the description of FIG. If the IR information determination unit 322 determines that the IR information can be deleted as a result of the IR information deletion determination process (Yes in step S217), the IR information determination unit 322 uses the key information included in the IR information determined to be deleted. The identified data is deleted from the cache 311. For example, the IR information determination unit 322 includes the attribute information identified by the key information included in the IR information determined to be deleted and the key information itself included in the IR information determined to be deleted. Delete from the cache 311 (step S218).

  That is, the IR information determination unit 322 uses the “key information” of the IR information when the IR information can be deleted, and when the corresponding key information exists in the cache 311 of the own device, ”And“ attribute information ”associated with the key information are deleted to update the cache 311.

  Then, the IR information determination unit 322 transmits an IR information deletion request to the selected database server 200 (step S219). That is, for example, the IR information determination unit 322 transmits an IR information deletion request including an update ID for IR information to be deleted to the database server “A”, so that the IR information is transmitted to the database server “A”. To delete.

  Then, the IR information determination unit 322 determines whether or not the processing has been executed for all the database servers 200 from which the IR information is acquired (step S220), and if it is determined that the processing has been executed (Yes in step S220), The process ends. On the other hand, if it is determined that the IR information determination unit 322 is not executing (No at Step S220), the database server to be searched next is determined in accordance with the search order determined at Step S210 (Step S221), and the above-described processing is performed. Returning to step S211, the processing is repeated.

  In other words, the IR information determination unit 322 acquires IR information from each database server 200 that is not blocked, and repeats the processing from step S212 to step S219 described above.

  In step S213, when IR information does not exist (No in step S213), the IR information determination unit 322 executes the above-described processing after step S220 without executing the IR deletion determination processing. If the IR information cannot be deleted in step S217 (No in step S217), the IR information determination unit 322 performs the process from step S220 described above without performing the process of deleting the IR information.

  Note that in step S210 described above, the IR information determination unit 322 may determine the search order for searching IR information for each database server 200 in which the blocked state “non-blocked” is stored by any method. In other words, each database server 200 in which the blocking state “blocking” is stored may not be a search destination for searching IR information.

[Flow by Response Processing Unit of Cache Server in Example 1]
FIG. 32 is a flowchart illustrating an example of a flow by the response processing unit of the cache server in the first embodiment. As will be described below, the response processing unit 323 executes the following processing when transmitting a response to the data request to the client terminal 500.

  As shown in FIG. 32, when response information is input from the cache determination unit 321 (Yes in step S1001), the response processing unit 323 specifies “key information, attribute information”, “key information” specified by the cache determination unit 321. Based on “None” and “Search failure”, the response information to the client terminal 500 is assembled (step S1002). Then, the response processing unit 323 transmits the assembled response information to the client terminal 500 (step S1003). That is, the response processing unit 323 transmits the information input by the cache determination unit 321 to the client terminal 500 as response information.

[Processing by Failure Determination Unit of Monitoring Server in Example 1]
FIG. 33 is a flowchart illustrating an example of a process flow by the failure determination unit of the monitoring server in the first embodiment. The failure determination unit 421 periodically executes a series of processes described with reference to FIG. 33 or irregularly.

  As illustrated in FIG. 33, the failure determination unit 421 acquires a list of database server names from the device information DB 411 of its own device, and determines the processing order (step S1101). For example, the failure determination unit 421 determines the order described in the acquired list as the processing order.

  Then, the failure determination unit 421 transmits a device status request to the database server 200 (step S1102). For example, the failure determination unit 421 transmits a device status request to the database server 200 described at the beginning of the list.

  Thereafter, the failure determination unit 421 executes processing for receiving a device status response from the database server 200 (step S1103), and determines whether a device status response has been received (step S1004). If the failure determination unit 421 determines that a device status response has been received (Yes at step S1104), the failure determination unit 421 performs failure determination based on a predetermined determination criterion using the received device information ( Step S1105). That is, for example, when the failure determination unit 421 receives information indicating the state of the distribution-related resource of the database server 200, the failure determination unit 421 performs failure determination based on the received information. Note that the determination process by the failure determination unit 421 may be performed using an arbitrary method using an arbitrary determination criterion.

  Then, when the determination result of the device state is normal (Yes at Step S1106), the failure determination unit 421 determines the database server name of the database server 200 that is the processing target among the device states stored in the device information DB 411. Is updated to the device state “normal” (step S1107).

  If the failure determination unit 421 has processed all the database servers 200 (No at step S1110), the failure determination unit 421 selects the next database server 200 from the list of database server names (step S1112), and returns to step S1102. Repeat the process. On the other hand, if the failure determination unit 421 has not performed processing for all the database servers 200 (Yes in step S1110), the apparatus state storage request for storing the apparatus state that is the determination result for each database server 200 is stored. Is transmitted to each database server 200 (step S1111), and the process is terminated.

  On the other hand, returning to the above-described step S1104, the case where it is determined that the device status response has not been received (No in step S1104) or the case where the device status determination result is not normal (No in step S1106) will be described. In this case, the failure determination unit 421 updates the device state associated with the database server name of the database server 200 to be processed among the device states stored in the device information DB 411 to the device state “failure”. (Step S1108). Then, the failure determination unit 421 closes the cache server 300 by transmitting to the database server 200 that is the processing target a block request that blocks data transmission and reception with the cache server 300 (step S1109). ). And the process after step S1110 mentioned above is performed.

  In addition, the failure determination unit 421 once transmits a block request, and when the blocking process fails in the database server 200, for example, transmits a block request again and repeats until it succeeds. However, the present invention is not limited to this, and may not be repeated until successful. For example, the failure determination unit 421 may terminate the process as an error after transmitting a blocking request a predetermined number of times. That is, when the blockage fails, it is not necessary to repeat at all, and it is not necessary to repeat it more than a predetermined number of times, based on the assumption that some unexpected failure exists.

[Effect of Example 1]
As described above, according to the first embodiment, in the cache control system, each database server has a plurality of IR information including key information for identifying data to be updated when the data in the database server is updated. The information is stored in the IR information DB 212 in association with the cache server name for identifying the cache server 300. Each of the cache servers 300 acquires IR information stored in the IR information DB 212 in association with the cache server name that identifies the cache server from each of the plurality of database servers 200. Then, the cache server 300 invalidates the cache of data identified by the acquired IR information. As a result, if there is at least one normal database server 200, the data before update stored in the cache server 300 can be invalidated.

  Further, according to the first embodiment, in the cache control system, each of the plurality of database servers 200 has the distribution information DB 213 that stores an update result indicating whether or not the data update is completed for each of the plurality of database servers 200. Have. Each of the cache servers 300 acquires update results for each of the plurality of database servers 200 stored in the distribution information DB 213 from the database server 200. Then, each of the cache servers 300 determines whether or not the update has been completed for all of the plurality of database servers 200 based on each of the acquired update results, and if it is determined that the update has ended, the acquired IR information Is deleted from the IR information DB 212. If it is determined that the update has not been completed, the deletion process is not executed. As a result, the database server 200 and the cache server 300 can be matched. For example, if even one updated database server remains, it is possible to prevent old data from remaining valid in the cache data.

  That is, the case where the cache server acquires IR information from each database server and deletes IR information from the database server as soon as IR information is acquired will be described. Further, a case where there are a database server “1” and a database server “2” will be described. Further, a case where IR information is generated by updating the database server “1” will be described. When the cache server requests IR information from the database server “1” and the database server “2”, the cache server acquires IR information from the database server “1”. Then, the cache server deletes old data in its own cache based on the IR information, and deletes the IR information from the database server “1”. Here, it is assumed that a failure occurs in the database server “1” before the update to the database server “1” is reflected in the database server “2”. Then, when the cache server receives the data request from the client terminal, the cache server deletes the old data and requests the data from the database server. Here, the database server “1” is out of order, and the cache server requests data from the database server “2”. Here, the update is not reflected in the database server “2”, and the IR information is also deleted from the database server “1”. As a result, when the cache server receives the old data from the database server “2”, the cache server continues to hold the old data while being valid.

  On the other hand, as described above, according to the first embodiment, in the cache control system, the cache server 300 deletes the IR information after confirming that the update is reflected in all the database servers 200. Therefore, even if the database server 200 fails at any point in time, it is possible to delete old data without fail.

  Further, according to the first embodiment, in the cache control system, the cache server 300 determines, for each of the plurality of database servers 200, whether or not the update in the database server 200 is normally executed. Then, the cache server 300 determines whether or not the update has been completed for all the database servers 200 that are determined to be normally executed, and executes the deletion process when it is determined that the update has been completed. However, if it is determined that the update has not ended, the deletion process is not executed. As a result, the database server 200 and the cache server 300 can be matched.

  According to the first embodiment, the cache control system further includes the monitoring server 400 that monitors the database server. Then, the monitoring server 400 determines whether or not the state of the database server 200 is normal based on the monitoring result, and transmits / receives data to / from the cache server 300 for the database server 200 determined to be not normal. Block. As a result, it is possible to prevent the abnormal database server 200 from responding to the cache server 300.

[System configuration]
Also, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-mentioned document and drawings (FIGS. 1 to 33) are arbitrarily changed unless otherwise specified. be able to.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part of the distribution / integration may be functionally or physically distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. For example, with the distribution information DB 213 of the database server 200 as an external device, the database servers 200 may be connected via a network and share the same distribution information DB 213. For example, the monitoring server 400 may not be used.

[program]
FIG. 34 is a diagram illustrating that information processing by the cache control system is specifically realized using a computer. As illustrated in FIG. 34, the computer 3000 includes, for example, a memory 3010, a CPU (Central Processing Unit) 3020, a hard disk drive interface 3030, and a network interface 3070. Each part of the computer 3000 is connected by a bus 3100.

  The memory 3010 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 3030 is connected to the hard disk drive 3080 as illustrated in FIG.

  Here, as illustrated in FIG. 34, the hard disk drive 3080 stores, for example, an OS 3081, an application program 3082, a program module 3083, and program data 3084. In other words, the update program according to the disclosed technology is stored in, for example, the hard disk drive 3080 as the program module 3083 in which instructions executed by the computer are described. Specifically, a program module in which each procedure for executing the same information processing as each unit of the control unit 220, each unit of the control unit 320, and each unit of the control unit 420 described in the above embodiment is described in the hard disk drive 3080. Remembered.

  In addition, data used in information processing by the cache control system, such as the data stored in the storage unit 210, the storage unit 310, and the storage unit 410 described in the above embodiments, is, for example, a hard disk drive 3080 as program data 3084. Is remembered. The CPU 3020 reads the program module 3083 and program data 3084 stored in the hard disk drive 3080 to the RAM as necessary, and executes various procedures.

  Note that the program module 3083 and the program data 3084 related to the program that executes the cache control system are not limited to being stored in the hard disk drive 3080. For example, the program module 3083 and the program data 3084 may be stored in a removable storage medium. In this case, the CPU 3020 reads data via a removable storage medium such as a disk drive. Similarly, the program module 3083 and program data 3084 related to the update program may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). . In this case, the CPU 3020 reads various data by accessing another computer via the network interface.

[Others]
Note that the control program of the cache control system described in this embodiment can be distributed via a network such as the Internet. The control program can also be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD, and being read from the recording medium by the computer.

200 Database Server 201 Communication Control I / F Unit 210 Storage Unit 211 User Information DB
212 IR information DB
213 Distribution information DB
214 Device information DB
220 Control unit 221 Cache response unit 222 IR information response unit 223 Update information response unit 224 Update success / failure response unit 225 Device status response unit 226 Device status storage unit 227 Blocking control unit 228 Update information distribution unit 229 Update repropagation unit 300 Cache server 301 Communication control I / F unit 310 Storage unit 311 Cache 312 Search destination state DB
313 Update registration status DB
320 Control Unit 321 Cache Determination Unit 322 IR Information Determination Unit 323 Response Processing Unit 400 Monitoring Server 401 Communication Control I / F Unit 410 Storage Unit 411 Device Information DB
420 Control Unit 421 Failure Determination Unit 500 Client Terminal

Claims (10)

A cache control system having a plurality of database servers storing the same data updated asynchronously and a plurality of cache servers storing a cache of data stored in the database server,
Each of the database servers
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. A storage unit
Each of the cache servers
An update information acquisition unit that acquires the update information stored in association with identification information that identifies the cache server by the storage unit in the update information storage unit from each of the plurality of database servers,
A cache control system comprising: an invalidation processing unit that invalidates a cache of data identified by update information acquired by the update information acquisition unit. Each of the plurality of database servers includes:
For each of the plurality of database servers, further comprising an update result storage unit for storing an update result indicating whether or not the update of the data has been completed,
Each of the cache servers
An update result acquisition unit that acquires the update result for each of a plurality of database servers stored in the update result storage unit from the database server;
Based on each update result acquired by the update result acquisition unit, it is determined whether or not the update has been completed for all the plurality of database servers, and when it is determined that the update has been completed, the update information acquisition unit A deletion processing unit that performs a deletion process for deleting the update information acquired from the update information storage unit, and when it is determined that the update has not been completed, further includes a deletion processing unit that does not execute the deletion process. The cache control system according to claim 1. The cache server is
An update state determination unit that determines, for each of the plurality of database servers, whether or not the update in the database server is normally executed;
The deletion processing unit of the cache server determines whether or not the update has been completed for all the database servers that are determined to be normally executed by the update state determination unit, and determines that the update has been completed. 3. The cache control system according to claim 2, wherein the deletion process is executed when the update is completed, and the deletion process is not executed when it is determined that the update is not completed. A cache control method applied to a cache control system having a plurality of database servers storing the same data updated asynchronously and a plurality of cache servers storing a cache of data stored in the database server ,
Each of the database servers
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. Including a storing step to
Each of the cache servers
An update information acquisition step for acquiring the update information stored in association with identification information for identifying the own cache server in the update information storage unit by the storage step from each of the plurality of database servers;
A cache control method comprising: an invalidation processing step of invalidating a cache of data identified by the update information acquired by the update information acquisition step. Each of the cache servers
The update result for each of the plurality of database servers stored in the update result storage unit that stores an update result indicating whether or not the update of the data has been completed for each of the plurality of database servers is acquired from the database server. Update result acquisition step,
Based on each of the update results acquired by the update result acquisition step, it is determined whether the update has been completed for all of the plurality of database servers, and when it is determined that the update has been completed, the update information acquisition step Deleting the update information acquired by the update information storage unit from the update information storage unit, and when it is determined that the update has not been completed, further includes a deletion process step that does not execute the delete process The cache control method according to claim 4. The cache server is
An update state determination step of determining for each of the plurality of database servers whether or not the update in the database server is normally executed,
The deletion processing step of the cache server determines whether or not the update has been completed for all the database servers that are determined to be normally executed by the update state determination step, and determines that the update has ended. 6. The cache control method according to claim 5, wherein the deletion process is executed if the update process is performed, and the deletion process is not executed if it is determined that the update has not ended. A database used in a cache control system having a plurality of database servers that store the same data updated asynchronously and a plurality of cache servers that store a cache of data stored in the database server,
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. A storage unit,
A cache of data identified by the acquired update information by acquiring the update information stored in the update information storage unit in association with identification information for identifying the own cache server by the storage unit from each of the plurality of database servers A database server, comprising: an update information transmission unit that transmits update information when update information is requested from a cache server that invalidates. A database control program used in a cache control system having a plurality of database servers storing the same data updated asynchronously and a plurality of cache servers storing caches of data stored in the database servers. And
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. Storage procedure to
A cache of data identified by the acquired update information by acquiring the update information stored in association with the identification information for identifying the own cache server by the storage procedure from each of the plurality of database servers. When the update information is requested from the cache server that invalidates the database, an update information transmission procedure for transmitting the update information is executed. A control program for a cache server used in a cache control system having a plurality of database servers storing the same data updated asynchronously and a plurality of cache servers storing a cache of data stored in the database server There,
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. An update information acquisition unit that acquires the update information stored in association with identification information that identifies the cache server by the storage unit in the update information storage unit,
A cache server, comprising: an invalidation processing unit that invalidates a cache of data identified by update information acquired by the update information acquisition unit. Cache server control of the cache server used in a cache control system having a plurality of database servers storing the same data updated asynchronously and a plurality of cache servers storing a cache of data stored in the database server A program,
When the data of its own database server is updated, update information including update data identification information for identifying the data to be updated is stored in the update information storage unit in association with each of the plurality of identification information for identifying the cache server. An update information acquisition procedure for acquiring the update information stored in association with identification information for identifying the own cache server by the storage unit in the update information storage unit, from each of the database servers including the storage unit,
A cache server control program for executing an invalidation processing procedure for invalidating a cache of data identified by update information acquired by the update information acquisition procedure.

Images