JP2014154031A - Difference update device, difference update system, difference update method, difference update program and difference update server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the communication load required for updating cache.SOLUTION: The difference update device includes a cache storage unit, a reception unit, and an update unit. The cache storage unit stores cache of data stored in a master server, which is one of a plurality of servers. The reception unit, when the data stored in the master server has been updated, receives a difference update notification to the effect that difference between updated data and the data before the update is updated, from the master server or a new master server selected from replica servers other than the master server, out of a plurality of servers for which synchronization of the difference update notification with transmission completion information which indicates whether transmission of the difference update notification is completed or not has been executed by the master server. The update unit updates the cache by use of the received difference update notification.

Description

  Embodiments described herein relate generally to a differential update device, a differential update system, a differential update method, a differential update program, and a differential update server.

  In order to improve the performance of the system, a technique for holding a cache of data managed on the server side on the client side is used. For example, when a client acquires a file used by an application running on its own device from the server, the client stores the acquired file as cache data (hereinafter abbreviated as “cache”) in a cache memory in its own device. As a result, when the client uses a file acquired from the server again, the client reads the cache memory, thereby reducing the amount of communication between the server and the client.

  In the above technique, not only the file itself but also the directory information such as the name of the file and the directory to which the file belongs, the attribute, the update date and time, the size, and the information indicating the physical storage location are cached (directory cache). ) Is also held. This technique is used, for example, to suppress the amount of communication between the server and the client in a distributed system environment in which a plurality of clients are connected to the server and to improve the processing speed.

  Note that a distributed system is required to have high availability enough to withstand server failures and network partitioning. For this reason, for example, a technique is used in which a server failure is detected by itself and event information such as failure is notified to other resources and resources are automatically switched. Also, if a hardware resource failure occurs between the event occurrence and the transmission completion, event information is missed, and system failure detection and switching will fail. For this reason, there has been proposed a technique for notifying the possibility of a missed delivery when switching occurs and complementing the missed information on each client side.

Mike Burrows, “The Chubby lock service for loosely-coupled distributed systems”, OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006. [online], [January 22, 2013 search ] Internet <http://research.google.com/archive/chubby‐osdi06.pdf> Tushar Chandra et al. “Paxos Made Live-An Engineering Perspective“, PODC’07: Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing, Portland, Oregon, USA, August, 2007.

  However, the above-described conventional technique has a problem that a communication load required for updating the cache is large. For example, when directory information is updated in the above directory cache, each client once deletes the cache of the directory information before update that has been held, and receives the updated directory information again. Was big.

  Here, a case where 10,000 files are managed under a certain directory in the server and 10,000 file names are held as a cache on the client side will be described. Here, when one file is added to the server side, the server manages 10001 files under the directory. Each client once deletes 10000 file names and re-receives 10001 file names after adding the files. That is, each client is re-received 10001 file names including 10,000 file names that have not changed even though there are no changes in the 10,000 file names held before the addition of the file. As a result, the communication load was large.

  Further, when the above directory cache is applied to a distributed system, the re-reception process is performed by all the clients having the corresponding directory cache, so that the communication load is large. Note that the above-described problem is not limited to the case where the directory cache is updated. For example, the problem is similarly described when the cache of a file acquired from the server is updated.

  Accordingly, the present invention has been made to solve the above-described problems of the prior art, and an object thereof is to reduce the communication load required for cache update.

  The difference update apparatus according to the embodiment includes a cache storage unit, a reception unit, and an update unit. The cache storage unit stores a cache of data stored in a master server that is one of a plurality of servers. When the data stored in the master server is updated, the reception unit transmits a difference update notification for updating the difference between the updated data and the data before the update, and transmission of the difference update notification. A new process selected from the master server or a replica server other than the master server among the plurality of servers in which the synchronization processing with the transmission completion information indicating whether or not the master server has been completed is performed. The difference update notification is received from the master server. The update unit updates the cache using the received difference update notification.

  According to one aspect of the technology disclosed in the present application, it is possible to reduce the communication load required for updating the cache.

FIG. 1 is a diagram for explaining the outline of the life and death monitoring system according to the first embodiment. FIG. 2 is a block diagram illustrating a configuration of the life and death monitoring system according to the first embodiment. FIG. 3 is a diagram showing a list of session information. FIG. 4 is a diagram showing a node information list. FIG. 5 shows an event list. FIG. 6 is a diagram showing a session list. FIG. 7 is a diagram for explaining the switching process to the new master by the alive monitoring system. FIG. 8 is a diagram for explaining the flow of the missed sending prevention process by the life and death monitoring system according to the first embodiment. FIG. 9 is a diagram for explaining the flow of the missed sending prevention process by the life and death monitoring system according to the first embodiment. FIG. 10 is a diagram for explaining the flow of the missed sending prevention process by the life and death monitoring system according to the first embodiment. FIG. 11 is a diagram for explaining the flow of the missed sending prevention process by the life and death monitoring system according to the first embodiment. FIG. 12 is a diagram for explaining the flow of the missed sending prevention process by the life and death monitoring system according to the first embodiment. FIG. 13 is a sequence diagram illustrating a flow of difference update processing by the alive monitoring system according to the first embodiment. FIG. 14 is a flowchart for explaining the processing procedure of the periodic communication start processing of the client according to the first embodiment. FIG. 15 is a flowchart for explaining the processing procedure of the regular communication reception processing of the client according to the first embodiment. FIG. 16 is a flowchart for explaining a processing procedure of client event processing according to the first embodiment. FIG. 17 is a flowchart for explaining a processing procedure when a client directory information acquisition request is generated according to the first embodiment. FIG. 18 is a flowchart for explaining a processing procedure when a client node addition / deletion request is generated according to the first embodiment. FIG. 19 is a flowchart for explaining a processing procedure of event distribution processing in the life and death monitoring apparatus according to the first embodiment. FIG. 20 is a flowchart for explaining the processing procedure of the difference update processing in the life and death monitoring apparatus according to the first embodiment. FIG. 21 is a diagram for explaining the effect of the life and death monitoring system according to the first embodiment. FIG. 22 is a sequence diagram illustrating a flow of difference update processing by the alive monitoring system according to the second embodiment. FIG. 23 is a flowchart for explaining a processing procedure when a client node addition / deletion request is generated according to the third embodiment. FIG. 24 is a diagram illustrating a computer that executes a differential update program.

  Exemplary embodiments of a differential update device, a differential update system, a differential update method, a differential update program, and a differential update server according to the present invention will be described below with reference to the accompanying drawings. In the following, a life / death monitoring system that provides a difference update process for updating a difference before and after rewriting of cache data (hereinafter abbreviated as “cache”) as a part of the life / death monitoring service will be described, but the present invention is limited by this embodiment. Is not to be done.

[First Embodiment]
Hereinafter, in the first embodiment, the outline of the life and death monitoring system according to the first embodiment, the configuration of the life and death monitoring system, and the flow of processing will be described in order, and finally, the effects of the first embodiment will be described.

[Outline of Alive Monitoring System]
The outline of the life and death monitoring system according to the first embodiment will be described with reference to FIG. FIG. 1 is a diagram for explaining the outline of the life and death monitoring system according to the first embodiment.

  The life and death monitoring system 1 according to the first embodiment includes a life and death monitoring device 10 and a plurality of clients 20A and 20B connected to the life and death monitoring device 10. The life and death monitoring apparatus 10 includes a plurality of servers, and among the plurality of servers, the role of one server is the master 10A, and the roles of the other servers are the replicas 10B to 10E. Note that the configuration of the life and death monitoring system 1 is not limited to the example in FIG. 1. For example, the life and death monitoring system 1 may include an arbitrary number of servers and an arbitrary number of clients. Further, the clients 20A and 20B are collectively referred to as the client 20 when collectively referred to without distinction.

  In the first embodiment, the alive monitoring system 1 realizes the missed sending prevention process, and when the directory information about the data stored in the master 10A is updated, the directory cache that is the cache data of the directory information is updated. In the storing client 20, the directory cache difference update process is performed.

  Here, the configuration for preventing the event information from being missed is realized by the alive monitoring apparatus 10. That is, the life and death monitoring apparatus 10 makes event information redundant on a system that can withstand a server failure and network disconnection. Specifically, the life and death monitoring apparatus 10 stores event information managed by the master 10A in the replicas 10B to 10E by making the event information managed by the master 10A redundant by replication. For example, the life and death monitoring apparatus 10 performs redundancy to withstand a server failure or network partition by using a replication technique based on an existing Paxos algorithm or a Quorum protocol.

  In the alive monitoring apparatus 10, when an event occurs, the master 10A delivers event information to the plurality of clients 20A and 20B. Here, when a failure occurs in the master 10A, the master is switched from the master 10A to the replica 10B, and the replica 10B, which is a new master, is reconnected to the plurality of clients 20A and 20B, and the transmission has not been completed. Information is transmitted to a plurality of clients 20A and 20B.

  This eliminates the need for supplementing the missed event information on the client 20 side, so that the system configuration is not complicated, and the event information can be delivered from the new master when the master fails. A sending prevention process is realized.

  Under such a configuration, when the directory information about the data stored in the master 10A is updated, each client 20 receives from the master 10A a difference update notification indicating that the directory information difference update processing is performed. The directory cache is updated using the received difference update notification.

  FIG. 1 illustrates a case where the directory cache stored by the client 20B is updated. In the example of FIG. 1, the master 10 </ b> A and the replicas 10 </ b> B to 10 </ b> E store files with the file names “File 1 to 3” under the directory with the directory name “directory A” (hereinafter abbreviated as directory A). Further, the client 20B has already acquired a list of file names under the directory A as a directory cache (directory monitoring) and stores it. That is, the client 20B monitors the directory A of the alive monitoring apparatus 10.

  Here, for example, when the client 20A adds a new file with the file name “File4” under the directory A by the client 20A, the master 10A adds an additional notification (difference) to add the added file name “File4” to the list. Update notification) is sent to the client 20B. Then, using the received addition notification, the client 20B adds the file name “File4” to the list, that is, updates information corresponding to the difference before and after the update (difference update).

  Further, for example, when a failure occurs in the master 10A and an additional notification is not transmitted to the client 20, an untransmitted additional notification is transmitted to the client 20B by the missed sending prevention process. Specifically, the master is switched from the master 10A to the replica 10B, and the replica 10B, which is a new master, transmits an unsent addition notification as event information to the client 20B, thereby performing differential update.

  As a result, even when a failure occurs in the master 10A, the directory cache difference update process is realized, so that the communication load required for updating the directory cache can be reduced.

  In the example of FIG. 1, the case where the directory cache is updated as a file is added has been described. However, the embodiment is not limited to this. For example, the directory cache is updated as the directory information is updated. Updated. Specifically, the directory information cache is updated by updating the directory information by adding or deleting files or by adding or deleting directories.

  In the example of FIG. 1, the case where the file name is stored in the client 20 as the directory cache and updated is described, but the embodiment is not limited to this. For example, the client 20 stores directory information (directory entry) such as information indicating the name, attribute, update date / time, size, and physical storage location of files and directories belonging to the directory of the master 10A as a directory cache. In the following, a file and a directory are collectively referred to as “node”.

[Configuration of Alive Monitoring System]
The configuration of the life and death monitoring system 1 shown in FIG. 1 will be described with reference to FIG. FIG. 2 is a block diagram illustrating a configuration of the life and death monitoring system according to the first embodiment. As shown in FIG. 2, the alive monitoring system 1 includes a alive monitoring device 10 and a client 20, and a master 10 </ b> A of the alive monitoring device 10 and the client 20 are connected. The configuration of each of these devices will be described below.

  The life and death monitoring apparatus 10 includes a master 10A that is one of a plurality of servers, and replicas 10B to 10E that are other servers. Further, the master 10A and the replicas 10B to 10E hold independent databases 30A to 30E, respectively.

  The databases 30 </ b> A to 30 </ b> E store, for example, various types of information used by applications that operate on the client 20. Specifically, the databases 30A to 30E store various files used by applications under a predetermined directory.

  Further, for example, the databases 30 </ b> A to 30 </ b> E store event information that is information regarding events that have occurred on the alive monitoring apparatus 10. Further, since the event information stored in each of the databases 30A to 30E is synchronized, it is assumed that event information having the same content is stored.

  The master 10A and the replicas 10B to 10E include an update unit 11, a generation unit 12, an event transmission unit 13, a synchronization unit 14, a connection unit 15, a transmission incomplete event transmission unit 16, and a storage unit 17. Each server (master 10A and replicas 10B to 10E) has a different role in the master and the replica, but the configuration is the same. The processing of each of these units will be described below. Further, in the following description, the case where the master 10A is a master and the replica 10B becomes a new master after a failure occurs in the master 10A will be described as an example.

  The storage unit 17 stores data and programs necessary for various processes. For example, the storage unit 17 of the master 10A has a session information list that is information for managing sessions, a node information list that is information for managing nodes, and an event list that is information for managing event information. And remember. Note that the node information list and the event list are also stored in the databases 30A to 30E held by the master 10A and the replicas 10B to 10E, respectively. The databases 30A to 30E described above store a session list that is a list of sessions. Hereinafter, the session information list, the node information list, the event list, and the session list will be specifically described with reference to FIGS.

  For example, as illustrated in FIG. 3, the storage unit 17 of the master 10 </ b> A includes a “session ID” that uniquely identifies a session as a list of session information, “client information” that is information about each client 20, and each client The “node ID being accessed” indicating the node ID of the node 20 is currently accessing, and the “event entry to be transmitted” that is the event ID of the event information to be transmitted to the client 20 are stored in association with each other. 3, for example, the storage unit 17 has a session ID “1”, an IP address “10.0.0.1” as client information, and a node ID “Nid = 1” being accessed. And the entry “Eid = 1, 2, 5” of the event to be transmitted are stored in association with each other. That is, in the storage unit 17, the client 20 with the IP address “10.0.0.1” connected in the session with the session ID “1” holds the directory cache with the node ID “Nid = 1”. Stores transmission of event information of event ID “Eid = 1, 2, 5” to the client 20.

  Further, for example, as illustrated in FIG. 4, the storage unit 17 of the master 10 </ b> A includes a “node ID” that uniquely identifies a node and a node ID of a parent node (directory) to which the node belongs as a node information list. The “parent node ID” that is indicated, the “node type” that indicates the type of the node, and the “session ID being accessed” that indicates the session ID of the session that is currently accessing the node are stored in association with each other. 4, for example, the storage unit 17 stores, for example, a node ID “1”, a parent node ID “Pid = 0”, a node type “directory”, and a session ID “Sid = 1” being accessed. , 3 "in association with each other. The parent node ID is not limited to the example shown in FIG. 4, and information indicating a route may be stored.

  Further, for example, as illustrated in FIG. 5, the storage unit 17 of the master 10 </ b> A has an “event ID” that uniquely identifies an event as an event list, and a “event generation source The node ID, the “event type” indicating the event type, and the “event generation source session ID” indicating the session ID of the session that is the event generation source are stored in association with each other. Referring to the example of FIG. 5, for example, the storage unit 17 stores an event ID “1”, an event occurrence source node ID “Nid = 2”, an event type “add file”, and an event occurrence source session. The ID “Sid = 2” is stored in association with each other. In other words, the storage unit 17 uses, as an event with the event ID “1”, that the file with the node ID “Nid = 2” is added by a request from the client 20 connected in the session with the session ID “Sid = 2”. Remember. In the example of FIG. 5, the case where addition or deletion of a node is registered as an event is illustrated, but the present invention is not limited to this, for example, update of file contents, invalidation of access to a node, etc. Various events that occur for the node may be registered.

  Further, as illustrated in FIG. 6, the databases 30 </ b> A to 30 </ b> E include a “session ID” that uniquely identifies a session, “client information” that is information about each client 20, The “node ID being accessed” indicating the node ID of the accessing node is stored in association with each other. Referring to the example of FIG. 6, the databases 30A to 30E have, for example, a session ID “1”, an IP address “10.0.0.1” as client information, and a node ID “Nid = 1” being accessed. Is stored in association with each other.

  Here, the node information list, event list, and session list stored in the databases 30B-30E of the replicas 10B-10E are copies of the node information list, event list, and session list stored in the database 30A of the master 10A. Further, as described above, the databases 30B to 30E of the replicas 10B to 10E do not store a session information list. For this reason, when any of the replicas 10B to 10E is switched to the master, a session information list is constructed from the event list and session list stored in the databases 30B to 30E, and the session information list is stored in the storage unit 17. set.

  The update unit 11 updates various information managed by the alive monitoring apparatus 10. Specifically, the update unit 11 receives a request to update various information stored in the database 30 from the client 20. And the update part 11 updates the various information memorize | stored in the database 30 according to the received request | requirement. More specifically, the update unit 11 receives a node addition / deletion request, which is a request for adding or deleting a node, from the client 20 on which the requesting application operates.

  As an example, when the update unit 11 of the master 10A receives an addition request for adding a file with the node ID “2” from a client connected in the session with the session ID “2”, the update unit 11 receives the node ID “2”. 'Is newly added to the database 30A. As another example, when the update unit 11 of the master 10A receives a deletion request to delete the file with the node ID “6” from the client connected with the session with the session ID “3”, The file with the node ID “6” is deleted from the database 30A.

  The generation unit 12 generates a difference update notification for updating the difference between the updated information and the information before the update for the information updated by the update unit 11. Specifically, the generation unit 12 of the master 10A generates a difference update notification when various information stored in the database 30 is updated. Then, the generation unit 12 registers the generated difference update notification as event information in the event list. Here, as the event ID registered by the generation unit 12, for example, an event ID obtained by increasing the event ID by 1 in the order of registration in the event list is selected and registered by the generation unit 12.

  The event transmission unit 13 transmits, to the client 20, event information stored as an event list in the storage unit 17 held by the own server when the own server is the master 10 </ b> A. Specifically, the event transmission unit 13 transmits the event information to the client 20 by adding the event information to the alive monitoring information that is periodically transmitted to the client 20. Here, the life and death monitoring performed between the life and death monitoring apparatus 10 and the client 20 is for confirming that the connection between both computers of the life and death monitoring apparatus 10 and the client 20 is maintained. Further, the event transmission unit 13 adds, as event information, an “event ID” that uniquely identifies the event and an “event type” that indicates the type of the event to the alive monitoring information, and transmits the information to the client 20.

  In addition, for example, when transmitting a difference update notification as event information, the event transmission unit 13 acquires a list of notification destination clients that are notification destinations of the difference update notification, and performs a difference update on the acquired notification destination client. Send notifications.

  The event transmitting unit 13 transmits the event information to the client 20 using a communication path that guarantees the communication order in order to maintain the order of the event information to be transmitted to the client 20. For example, the event transmission unit 13 transmits event information to the client 20 through a communication path using TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). However, when applying a communication path using UDP, it is necessary to add a function for guaranteeing the communication order to UDP communication.

  When the own server is the master 10A, the synchronization unit 14 notifies the replicas 10B to 10E of the event information stored in the database 30A held by the master 10A and stores them in the databases 30B to 30E. Specifically, every time an event occurs and event information is registered in a database held by the server, the synchronization unit 14 notifies the replicas 10B to 10E of the event information and stores them in the databases 30B to 30E.

  In addition, the synchronization unit 14 notifies the replicas 10B to 10E of information indicating whether or not the transmission of the event information to the client 20 is completed, and stores the information in the databases 30B to 30E of the replicas 10B to 10E, respectively. Here, the synchronization unit 14 sets the “latest transmission completion event ID” that is the event ID of the latest event information transmitted to the client 20 to the replicas 10B to 10E as information indicating whether or not the transmission of the event information has been completed. Notification is made and stored in the databases 30B to 30E of the replicas 10B to 10E, respectively.

  When a failure occurs in the master 10A, the connection unit 15 connects the replica 10B, which is a new master selected from the replicas 10B to 10E, and the client 20 so that they can communicate with each other. Specifically, the connection unit 15 accepts a master inquiry transmitted from the client library 21 of the client 20 and, when the server 10 is a replica 10B that is a new master, connects to the client 20 so as to be communicable. . Note that the selection of a new master is performed using, for example, a master selection function based on an existing Paxos.

  The transmission incomplete event transmission unit 16 uses the latest transmission completion event ID to identify event information that has not been transmitted to the client 20 among the event information stored in the database 20B held by the replica 10B that is the new master. Then, the event information that has not been transmitted is transmitted to the client 20. Specifically, the transmission incomplete event transmission unit 16 specifies event information having an event ID that is newer than the event information of the latest transmission completion event ID as event information that has not been transmitted, and transmits the event information to the client 20. .

  The client 20 includes a client library 21 and an application 22. The client library 21 includes a session management unit 21a, a cache update unit 21b, and a cache storage unit 21c, and periodically communicates with the master 10A for alive monitoring.

  When event information is added to the alive monitoring information received from the master 10A, the session management unit 21a uses the latest transmission completion event ID that is the event ID of the latest event information transmitted by the master 10A. Redundant sending confirmation processing is performed to check whether event information has been received twice. The latest transmission completion event ID and the latest reception completion event ID stored in the alive monitoring device 10 are the same type of information, and are “latest reception completion event ID” from the client perspective, and from the alive monitoring device perspective, “Latest transmission completion event ID”. Specifically, the session management unit 21a holds the latest reception completion event ID, and notifies the application 22 of event information if the event ID of the received event information is newer than the latest reception completion event ID. .

  In addition, when the master 10A fails and failover occurs, the session management unit 21a changes the connection destination to the replica 10B that is a new master. Here, a case where the client 20 has not reconnected during a failover due to a failure or the like will be described with reference to FIG. FIG. 7 is a diagram for explaining the switching process to the new master by the alive monitoring system. As illustrated in FIG. 7, a failure occurs in the master 10A, and the master is replaced by failover, and the replica 10B becomes the new master (see (1) in FIG. 7). Here, it is assumed that the client 20B does not reconnect with the replica 10B as the new master during the failover (see (2) in FIG. 7), and the client 20A reconnects with the replica 10B as the new master. (See (3) of FIG. 7).

  In this case, the replica 10B that is the new master uses the storage unit 17 and the database 30B of the replica 10B that is the new master to obtain information on a session that has not been reconnected for a certain period of time (in this example, a session with the failed client 20B). Delete from. In other words, when the session is disconnected, it is not necessary to transmit event information to the client, so information related to the session is deleted from the storage unit 17 and the database 30B (see (4) in FIG. 7).

  In addition, when a difference update notification is added as event information to the received alive monitoring information, the session management unit 21a notifies the cache update unit 21b of the difference update notification. For example, if a difference update notification with event ID “1” is added to the received alive monitoring information, the session management unit 21a notifies the cache update unit 21b of the difference update notification.

  The cache update unit 21b performs differential update of the directory cache using the differential update notification notified from the master 10A. As an example, the cache update unit 21b receives a difference update notification of the event ID “1” from the session management unit 21a. Here, the difference update notification of the event ID “1” is a difference update notification indicating that the file of the node ID “2” has been added. As a result, the cache update unit 21b adds the file name of the node ID “2” to the directory cache stored in the cache storage unit 21c. As another example, the cache update unit 21b receives a difference update notification of the event ID “4” from the session management unit 21a. Here, the difference update notification of the event ID “4” is a difference update notification indicating that the file of the node ID “6” has been deleted. As a result, the cache update unit 21b deletes the file name of the node ID “6” from the directory cache stored in the cache storage unit 21c.

  The cache storage unit 21c stores a cache of various information managed by the master 10A. Specifically, the cache storage unit 21c stores a directory cache of various types of information acquired from the master 10A for use by the application 22.

[Non-delivery prevention processing by life and death monitoring system]
A flow of event information missing sending prevention processing by the life and death monitoring system 1 according to the first embodiment will be described with reference to FIGS. 8 to 12. In the present embodiment, a description will be given of a missed transmission prevention process that is performed in order to prevent missing of a difference update notification when a difference update notification generated by node update is notified to each client 20 as event information. However, the embodiment is not limited to this. For example, the event information miss-prevention process can be executed even when each client 20 is notified of various events generated by a request from the application 22 operating on each client 20.

  FIG. 8 to FIG. 12 are sequence diagrams showing the flow of the missed sending prevention process by the life and death monitoring system 1 according to the first embodiment. FIG. 8 shows a flow of normal event delivery processing performed by the alive monitoring system to prevent event information from being missed. 9 to 12 show a flow of event delivery processing at the time of failover by the alive monitoring system. 9 to 12 are different when a failover occurs. Specifically, the example of FIG. 9 shows a case where a failover occurs before an event occurs, and the example of FIG. 10 shows a case where a failover occurs before event information transmission, and the example of FIG. Shows a case where a failover occurs before receiving a response, and the example in FIG. 12 shows a case where a failover occurs after receiving a response.

  First, the flow of normal event delivery processing performed by the life and death monitoring system to prevent event information from being missed will be described with reference to FIG. As shown in FIG. 8, when an event occurs (step S101), the master 10A registers the event information in the storage unit 17 and the database 30A (step S102), and notifies the replicas 10B and 10C of a copy of the event information ( Step S103). Upon receiving the copy of the event information, the replicas 10B and 10C register the copy of the event information in the databases 30B and 30C, and transmit a response indicating that the registration has been performed to the master 10A (step S104).

  Then, the master 10A adds the event information to the alive monitoring information that is periodically communicated, and transmits the event information to the client library 21 of the client 20 (step S105). When the reception of the event information is completed, the client library 21 performs a redundant transmission confirmation process for confirming whether the event information has been received twice using the latest transmission completion event ID (step S106). If the event information is not received twice, the client library 21 notifies the application 22 of the event information (step S107).

  Then, the client library 21 transmits an event reception completion response including the latest reception completion event ID to the master 10A (step S108). Subsequently, when receiving the event reception completion response, the master 10A registers that the transmission of the event information is completed and updates the latest reception completion event ID (step S109). Thereafter, the master 10A notifies the replicas 10B and 10C of a copy of the latest reception completion event ID (step S110). When the replicas 10B and 10C receive a copy of the latest reception completion event ID, the replicas 10B and 10C register the latest reception completion event ID in the databases 30B and 30C, and transmit a response indicating that the registration has been performed to the master 10A (step S111). Then, the master 10A receives the responses from the replicas 10B and 10C, and deletes the event information that has been transmitted when the responses are obtained from all the clients 20 that should receive the event information (step S112). Thereafter, when the event information is deleted from its own database 30A, the master 10A causes the replicas 10B and 10C to replicate the deletion of the event information (step S113). Then, when replicating the deletion of the event information and deleting the event information from the databases 30B and 30C, the replicas 10B and 10C transmit a response indicating that the deletion has been performed to the master 10A (step S114).

  Next, a flow of event delivery processing at the time of failover by the alive monitoring system according to the first embodiment will be described with reference to FIG. As shown in FIG. 9, when an event occurs (step S201), the master 10A registers the event information in the storage unit 17 and the database 30A (step S202), and notifies the replicas 10B and 10C of a copy of the event information. (Step S203).

  Then, a failure occurs in the master 10A (step S204), and the replica 10B is switched to the new master by failover. Here, since the master 10A is out of order, communication cannot be performed and the response from the replica 10C fails (step S205). Further, when the client library 21 detects disconnection with the master 10A because the periodic communication with the master 10A has been interrupted, the client library 21 inquires of one of the replicas (step S206), and from the replica 10B, which is the new master. A reply indicating that it is a new master is received (step S208). Then, the client library 21 requests reconnection with the replica 10B that is the new master (step S209), establishes a session with the replica 10B that is the new master, and reconnects with the master (step S210). Further, in parallel with the reconnection process with the client library 21, the replica 10B that is the new master reads the event information from the database 30B and performs a process of restoring the event information (step S207).

  Then, the replica 10B, which is the new master, identifies event information that has not been transmitted to the client 20 among the event information using the latest reception completion event ID, and the event information that has not been transmitted yet is identified by the client 20. (Step S211). When the reception of the event information is completed, the client library 21 performs a redundant transmission confirmation process for confirming whether the event information has been received twice using the latest transmission completion event ID (step S212). If the event information is not received twice, the client library 21 notifies the application 22 of the event information (step S213).

  Then, the client library 21 transmits an event reception completion response including the latest reception completion event ID to the replica 10B that is the new master (step S214). Subsequently, when receiving the event reception completion response, the replica 10B, which is the new master, registers that the transmission of the event information has been completed and updates the latest reception completion event ID (step S215). Thereafter, the replica 10B, which is the new master, notifies the replica 10C of a copy of the latest reception completion event ID (step S216). When the replica 10C receives a copy of the latest reception completion event ID, the replica 10C registers the latest reception completion event ID in the database 30C, and transmits a response to the effect that registration has been performed to the replica 10B that is the new master (step S217). Then, the replica 10B, which is the new master, receives the response from the replica 10C, and deletes the event information that has been transmitted when the responses are obtained from all the clients 20 that should receive the event information (step S218). After that, when the event information is deleted from its own database 30B, the replica 10B, which is the new master, replicates the deletion of the event information to the replica 10C (step S219). Then, when replicating the deletion of the event information and deleting the event information from the database 30C, the replica 10C transmits a response indicating that the deletion has been performed to the replica 10B that is the new master (step S220).

  Next, the flow of event delivery processing during failover by the alive monitoring system according to the first embodiment will be described with reference to FIG. As shown in FIG. 10, when an event occurs (step S301), the master 10A registers the event information in the storage unit 17 and the database 30A (step S302), and notifies the replicas 10B and 10C of a copy of the event information. (Step S303). Upon receiving the copy of the event information, the replicas 10B and 10C register the copy of the event information in the databases 30B and 30C, and transmit a response indicating that the registration has been performed to the master 10A (step S304).

  When a failure occurs in the master 10A (step S305) and transmission of event information fails (step S306), the replica 10B is switched to the replica 10B that is the new master by failover. Subsequently, the replica 10B, which is the new master, reads the event information from the database 30B and performs a process of restoring the event information (step S307). Here, when the client library 21 detects disconnection with the master 10A because the periodic communication with the master 10A is interrupted, the client library 21 inquires of one of the replicas of the master (step S308), and the replica 10B which is the new master. A reply indicating that it is a new master is received (step S309). Then, the client library 21 requests reconnection with the replica 10B that is the new master (step S310), establishes a session with the replica 10B that is the new master, and reconnects with the master (step S311).

  Then, the replica 10B, which is the new master, identifies event information that has not been transmitted to the client 20 among the event information using the latest reception completion event ID, and the event information that has not been transmitted yet is identified by the client 20. (Step S312). When the reception of the event information is completed, the client library 21 performs a redundant transmission confirmation process for confirming whether the event information has been received twice using the latest transmission completion event ID (step S313). If the event information is not received twice, the client library 21 notifies the application 22 of the event information (step S314).

  Then, the client library 21 transmits an event reception completion response including the latest reception completion event ID to the replica 10B that is the new master (step S315). Subsequently, when receiving the event reception completion response, the replica 10B, which is the new master, registers that the transmission of the event information has been completed and updates the latest reception completion event ID (step S316). Thereafter, the replica 10B, which is the new master, notifies the replica 10C of a copy of the latest reception completion event ID (step S317). When the replica 10C receives a copy of the latest reception completion event ID, the replica 10C registers the latest reception completion event ID in the database 30C, and transmits a response to the effect that registration has been performed to the replica 10B, which is the new master (step S318). Then, the replica 10B, which is the new master, receives the response from the replica 10C, and deletes the event information that has been transmitted when the responses are obtained from all the clients 20 that should receive the event information (step S319). Thereafter, when the event information is deleted from its own database 30B, the replica 10B as the new master causes the replica 10C to replicate the deletion of the event information (step S320). Then, when replicating the deletion of the event information and deleting the event information from the database 30C, the replica 10C transmits a response indicating that the deletion has been performed to the replica 10B, which is the new master (step S321).

  Next, the flow of event delivery processing during failover by the alive monitoring system according to the first embodiment will be described with reference to FIG. As shown in FIG. 11, when an event occurs (step S401), the master 10A registers the event information in the storage unit 17 and the database 30A (step S402), and notifies the replicas 10B and 10C of a copy of the event information. (Step S403). Upon receiving the copy of the event information, the replicas 10B and 10C register the copy of the event information in the databases 30B and 30C, and transmit a response indicating that the registration has been performed to the master 10A (step S404).

  Then, the master 10A adds the event information to the alive monitoring information that is periodically communicated, and transmits the event information to the client library 21 of the client 20 (step S405). When the reception of the event information is completed, the client library 21 performs a redundant transmission confirmation process for confirming whether the event information has been received twice using the latest transmission completion event ID (step S406). If the event information is not received twice, the client library 21 notifies the application 22 of the event information (step S407).

  Then, a failure occurs in the master 10A, and the replica 10B is switched to the replica 10B that is the new master by failover (step S408). Subsequently, the replica 10B, which is the new master, reads the event information from the database 30B and performs a process of restoring the event information (step S409). Further, since a failure has occurred in the master 10A, the client library 21 fails to transmit an event reception completion response to the old master 10A (step S410). Here, when the client library 21 detects disconnection with the master 10A because the periodic communication with the master 10A has been interrupted, the client library 21 inquires of one of the replicas of the master (step S411), and the replica 10B which is the new master. A reply indicating that it is a new master is received (step S412). Then, the client library 21 requests reconnection with the replica 10B that is the new master (step S413), establishes a session with the replica 10B that is the new master, and reconnects with the master (step S414).

  Subsequently, the replica 10B that is the new master specifies event information that has not been transmitted to the client 20 among the event information using the latest reception completion event ID, and the event information that has not been transmitted yet is identified by the client 10 20 (step S415). Then, when the reception of the event information is completed, the client library 21 performs a redundant sending confirmation process for checking whether the event information has been received twice using the latest transmission completion event ID (step S416). Here, since the received event information is the event information received in step S405, the client library 21 sends an event reception completion response including the latest reception completion event ID without notifying the application 22 of the event information. The data is transmitted to the replica 10B that is the new master (step S417).

  Subsequently, when receiving the event reception completion response, the replica 10B, which is the new master, registers that the transmission of the event information has been completed and updates the latest reception completion event ID (step S418). Thereafter, the replica 10B, which is the new master, notifies the replica 10C of a copy of the latest reception completion event ID (step S419). When the replica 10C receives a copy of the latest reception completion event ID, the replica 10C registers the latest reception completion event ID in the database 30C and transmits a response indicating that the registration has been performed to the replica 10B, which is the new master (step S420). Then, the replica 10B, which is the new master, receives the response from the replica 10C, and deletes the event information that has been transmitted when the responses are obtained from all the clients 20 that should receive the event information (step S421). After that, when the event information is deleted from its own database 30B, the replica 10B, which is the new master, replicates the deletion of the event information to the replica 10C (step S422). Then, when replicating the deletion of the event information and deleting the event information from the database 30C, the replica 10C transmits a response indicating that the deletion has been performed to the replica 10B that is the new master (step S423).

  Next, the flow of event delivery processing at the time of failover by the alive monitoring system according to the first embodiment will be described with reference to FIG. As shown in FIG. 12, when an event occurs (step S501), the master 10A registers the event information in the storage unit 17 and the database 30A (step S502), and notifies the replicas 10B and 10C of a copy of the event information. (Step S503). Upon receiving the copy of the event information, the replicas 10B and 10C register the copy of the event information in the databases 30B and 30C, and transmit a response indicating that the registration has been performed to the master 10A (step S504).

  Then, the master 10A adds event information to the alive monitoring information that is periodically communicated, and transmits the event information to the client library 21 of the client 20 (step S505). When the reception of the event information is completed, the client library 21 performs a redundant sending confirmation process for checking whether the event information has been received twice using the latest transmission completion event ID (step S506). If the event information is not received twice, the client library 21 notifies the application 22 of the event information (step S507).

  Then, the client library 21 transmits an event reception completion response including the latest reception completion event ID to the master 10A (step S508). Here, a failure occurs in the master 10A, and the replica 10B is switched to the replica 10B that is the new master by failover (step S509). Subsequently, the replica 10B, which is the new master, reads the event information from the database 30B and performs a process of restoring the event information (step S510). Here, when the client library 21 detects disconnection with the master 10A because the periodic communication with the master 10A is interrupted, the client library 21 inquires of one of the replicas of the master (step S511), and the replica 10B which is the new master. A reply indicating that it is a new master is received (step S512). Then, the client library 21 requests reconnection with the replica 10B that is the new master (step S513), establishes a session with the replica 10B that is the new master, and reconnects with the master (step S514).

  Subsequently, the replica 10B that is the new master specifies event information that has not been transmitted to the client 20 among the event information using the latest reception completion event ID, and the event information that has not been transmitted yet is identified by the client 10 20 (step S515). Then, when the reception of the event information is completed, the client library 21 performs a redundant sending confirmation process for checking whether the event information has been received twice using the latest transmission completion event ID (step S516). Here, since the received event information is the event information received in step S505, the client library 21 sends an event reception completion response including the latest reception completion event ID without notifying the application 22 of the event information. The data is transmitted to the replica 10B that is the new master (step S517).

  Subsequently, when receiving the event reception completion response, the replica 10B, which is the new master, registers that the transmission of the event information has been completed and updates the latest reception completion event ID (step S518). Thereafter, the replica 10B, which is the new master, notifies the replica 10C of a copy of the latest reception completion event ID (step S519). When the replica 10C receives a copy of the latest reception completion event ID, the replica 10C registers the latest reception completion event ID in the database 30C, and transmits a response indicating that the registration has been performed to the replica 10B, which is the new master (step S520). Then, the replica 10B, which is the new master, receives the response from the replica 10C, and deletes the event information that has been transmitted when the responses are prepared from all the clients 20 that should receive the event information (step S521). After that, when the event information is deleted from its own database 30B, the replica 10B, which is the new master, replicates the deletion of the event information to the replica 10C (step S522). Then, when replicating the deletion of the event information and deleting the event information from the database 30C, the replica 10C transmits a response indicating that the deletion has been performed to the replica 10B that is the new master (step S523).

[Difference update processing by alive monitoring system]
The flow of the difference update process by the alive monitoring system 1 according to the first embodiment will be described with reference to FIG. FIG. 13 is a sequence diagram showing a flow of difference update processing by the alive monitoring system 1 according to the first embodiment. FIG. 13 shows a case where the client 20B acquires the directory cache of the directory information “File1, Dir2” stored in the master 10A, and updates the directory cache according to the addition of the file with the file name “File3” by the client 20A. Illustrate.

  As shown in FIG. 13, when a directory information acquisition request for acquiring directory information from the application 22 is generated (step S601), the client 20B transmits the directory information acquisition request to the master 10A (step S602). Upon receiving the directory information list corresponding to the transmitted directory information acquisition request from the master 10A (step S603), the client 20B stores the list in the cache storage unit 21c (step S604). As a result, the client 20B acquires the directory cache of the directory information “File1, Dir2”.

  Thereafter, every time a directory information acquisition request is generated from the application 22 (step S605), the client 20B reads the acquired directory cache (step S606) and uses it.

  Here, when the client 20A transmits a request to add a new file with the file name “File3” to the master 10A (step S607), the master 10A creates a file (step S608). When the master 10A creates a file with the file name “File3”, the master 10A notifies the client 20A of the completion of the file creation (step S609).

  When a new file with the file name “File3” is newly added, the master 10A generates a difference update notification indicating that the file name “File3” is added as an event. Then, the master 10A transmits a difference update notification for adding the file name “File3” to the client 20B holding the directory cache (step S610). As a result, the client 20B updates the directory cache list (step S611), and adds the directory information of the file name “File3” to the list. Then, the client 20B transmits an update completion notification to the master 10A (step S612).

  Thereafter, every time a directory information acquisition request is generated from the application 22 (step S613), the client 20B reads the updated directory cache (step S614) and uses it.

  Note that the master 10A also executes the processing after step S101 in FIG. 8 after generating a difference update notification as an event when the file is updated. This prevents the difference update notification from being missed. That is, when a failure occurs in the master 10A after the difference update notification is generated, the difference update notification is transmitted to the notification destination client 20 by any one of the processes in FIGS. Therefore, the master 10A can transmit the difference update notification to the notification destination client 20 without missing it.

  FIG. 13 illustrates the case where the client 20 that adds or deletes a node is different from the client 20 that holds the directory cache. However, even if these clients are the same, the difference update process is performed by the same process. Done. For example, in FIG. 13, if the client 20A holds the directory cache, the master 10A also transmits a difference update notification to the effect that the file name “File3” is added to the client 20A (step S610). As a result, the client 20A updates the directory cache list (step S611), and adds the directory information of the file name “File3” to the list. Then, the client 20A transmits an update completion notification to the master 10A (step S612).

  Here, the difference update process when a file is added and the difference update process when a file is deleted will be described in detail with reference to FIGS. 13 and 3 to 5. Here, the client 20A illustrated in FIG. 13 is connected to the master 10A with the session ID “Sid = 2”, and the client 20B is connected to the master 10A with the session ID “Sid = 1”. Further, the master 10A subordinates the directory with the node ID “Nid = 1”, the file with the node ID “Nid = 5” (file name “File1” in FIG. 13), and the directory with the node ID “Nid = 3” (see FIG. 13). 13 directory names “Dir2”). Further, it is assumed that the client 20B has already acquired the directory information of the directory having the node ID “Nid = 1” illustrated in FIG. 4 in the process of step S602.

  First, the difference update process when a file is added will be described. In step S607, for example, the client 20A transmits a request to add a file with the file name “File3” to the master 10A under the directory with the node ID “Nid = 1”. When the master 10A receives a request to add a file with the file name “File3”, the master 10A creates a file with the file name “File3” (step S608). When the master 10A creates a file with the file name “File3”, the master 10A updates various lists illustrated in FIGS. 3 to 5 as metadata of the created file.

  Specifically, when the file with the file name “File3” is created, the update unit 11 of the master 10A assigns a node ID for identifying the created file and registers it in the node information list. In the example illustrated in FIG. 4, the update unit 11 stores a record in which a node ID “2”, a parent node ID “Pid = 1”, a node type “file”, and a session ID “Sid = 2” being accessed are associated. Add to the node information list.

  Also, when the file with the file name “File3” is created, the generation unit 12 of the master 10A generates event information (difference update notification) for notifying that the file has been created and registers it in the event list. . In the example illustrated in FIG. 5, the generation unit 12 associates an event generation source node ID “Nid = 2”, an event type “file addition”, and an event generation source session ID “Sid = 2” with an event. The event information of ID “1” is registered in the event list.

  Further, when the file with the file name “File3” is created, the event transmission unit 13 of the master 10A specifies the notification destination of the difference update notification with the event ID “1” and registers it in the session information list. In the example illustrated in FIG. 3, the event transmission unit 13 refers to the node information list, and accesses the session ID “Sid” that corresponds to the node ID “Nid = 1” of the directory in which the file with the file name “File3” is created. = 1, 3 ”. Then, the event transmission unit 13 refers to the session information list and adds “Eid = 1” to “entry of event to be transmitted” corresponding to each identified session ID “Sid = 1, 3”.

  As described above, the master 10A registers the metadata of the created file in the various lists illustrated in FIGS. 3 to 5 along with the creation of the file with the file name “File3”. Thereafter, the event transmission unit 13 notifies the client 20A of completion of file creation (step S609).

  The event transmitting unit 13 refers to the session information list when periodically transmitting alive monitoring information to each client 20. Then, the event transmission unit 13 transmits the event information (difference update notification) in “entry of event to be transmitted” to the client 20 connected with the corresponding session ID. Here, a case where periodic alive monitoring information is transmitted to the client 20 (client 20B in FIG. 13) connected with the session ID “1” will be described with reference to FIG. In this case, the event transmitting unit 13 refers to the session information list illustrated in FIG. 3 and identifies “Eid = 1, 2, 5” as the entry of the event transmitted to the session ID “1”. Then, the event transmission unit 13 acquires each event information of the event ID “1, 2, 5” from the event list. Then, the event transmission unit 13 adds the acquired event information to the alive monitoring information and transmits it. As a result, the event information (difference update notification) of the event ID “1” for notifying that the file with the file name “File3” has been created is notified to the client connected with the session ID “1” (step S610). ). As described above, the master 10A executes the difference update process according to the addition of the file.

  Next, a difference update process when a file is deleted will be described. As processing corresponding to step S607, for example, the client 20A transmits to the master 10A a request to delete the file with the node ID “Nid = 6” under the directory with the node ID “Nid = 3”. When receiving the request to delete the file with the node ID “Nid = 6”, the master 10A deletes the file with the node ID “Nid = 6” (corresponding to step S608). Further, when deleting the file with the node ID “Nid = 6”, the master 10 </ b> A updates various lists illustrated in FIGS. 3 to 5 as metadata of the deleted file.

  Specifically, when the file with the node ID “Nid = 6” is deleted, the update unit 11 of the master 10A deletes the record corresponding to the node ID of the deleted file from the node information list. In the example illustrated in FIG. 4, the update unit 11 sets a node ID “6”, a parent node ID “Pid = 3”, a node type “file”, and a session ID “None” being accessed as node information. Remove from the list. Here, for convenience of explanation, the case where there is no session ID being accessed in the deleted file is illustrated, but there may be a case where there is a session ID being accessed in the deleted node. In such a case, the master 10A may separately perform processing for notifying the client 20 connected with the session ID that access is invalid.

  Further, when the file with the node ID “Nid = 6” is deleted, the generation unit 12 of the master 10A generates event information (difference update notification) for notifying that the file has been deleted, and displays the event list. sign up. In the example illustrated in FIG. 5, the generation unit 12 associates an event generation source node ID “Nid = 6”, an event type “file deletion”, and an event generation source session ID “Sid = 3” with an event. The event information of ID “4” is registered in the event list.

  Further, when the file with the node ID “Nid = 6” is deleted, the event transmission unit 13 of the master 10A specifies the notification destination of the difference update notification with the event ID “4” and registers it in the session information list. In the example illustrated in FIG. 3, the event transmission unit 13 refers to the node information list, and accesses the session ID “Sid” being accessed corresponding to the node ID “Nid = 3” of the directory to which the file with the node ID “Nid = 6” belongs. = 4 "is specified. Then, the event transmission unit 13 refers to the session information list and adds “Eid = 4” to “entry of event to be transmitted” corresponding to the identified session ID “Sid = 4”.

  As described above, the master 10A registers the metadata of the deleted file in the various lists illustrated in FIGS. 3 to 5 along with the deletion of the file having the node ID “Nid = 6”. Thereafter, the event transmission unit 13 notifies the client 20A of the completion of file deletion (corresponding to step S609).

  The event transmitting unit 13 refers to the session information list when periodically transmitting alive monitoring information to each client 20. Then, the event transmission unit 13 transmits the event information (difference update notification) in “entry of event to be transmitted” to the client 20 connected with the corresponding session ID. Here, a case where periodic alive monitoring information is transmitted to the client 20 connected with the session ID “4” will be described with reference to FIG. 3. In this case, the event transmitting unit 13 refers to the session information list illustrated in FIG. 3 and identifies “Eid = 3, 4, 7” as an entry of the event transmitted to the session ID “4”. Then, the event transmission unit 13 acquires each event information of the event ID “3, 4, 7” from the event list. Then, the event transmission unit 13 adds the acquired event information to the alive monitoring information and transmits it. As a result, event information (difference update notification) of the event ID “4” for notifying that the file with the node ID “Nid = 6” has been deleted is notified to the client connected with the session ID “4” ( Equivalent to step S610). As described above, the master 10A executes the difference update process according to the file deletion.

[Processing by client]
Next, processing performed by the client 20 according to the first embodiment will be described with reference to FIGS. FIG. 14 is a flowchart for explaining the processing procedure of the periodic communication start processing of the client according to the first embodiment. FIG. 15 is a flowchart for explaining the processing procedure of the regular communication reception processing of the client according to the first embodiment. FIG. 16 is a flowchart for explaining a processing procedure of client event processing according to the first embodiment. FIG. 17 is a flowchart for explaining a processing procedure when a client directory information acquisition request is generated according to the first embodiment. FIG. 18 is a flowchart for explaining a processing procedure when a client node addition / deletion request is generated according to the first embodiment.

  First, the processing procedure of the regular communication start process of the client will be described using FIG. As shown in FIG. 14, the client 20 makes a connection request to all the servers 10A to 10E (step S701). When the client 20 receives the connection destination of the master 10A (step S702), the client 20 transmits a reception completion response to the master 10A (step S703).

  Subsequently, the client 20 sets an alive monitoring timer (step S704), performs a periodic communication reception process (detailed later using FIG. 13) (step S705), and ends the process.

  Next, the processing procedure of the periodic communication reception process of the client will be described using FIG. As shown in FIG. 15, the client 20 determines whether it has been received before the alive monitoring timeout (step S801). As a result, when the alive monitoring information is received before the alive monitoring timeout (Yes at Step S801), the client 20 performs event processing (described later in detail with reference to FIG. 16) (Step S802) to the master 10A. A reception completion response is transmitted (step S803), the alive monitoring timer is reset, then set again (step S804), and the process returns to step S801.

  In step S801, when the client 20 does not receive the alive monitoring information before the alive monitoring timeout (No in step S801), the client 20 ends the process.

  Next, a processing procedure of client event processing will be described with reference to FIG. As shown in FIG. 16, the client 20 determines whether or not event information has been received, that is, whether or not event information has been added to life / death monitoring information (step S901). As a result, when the event information has not been received (No at Step S901), the client 20 ends the process. On the other hand, when the event information is received (Yes at Step S901), the client 20 determines whether the received event information is event information that has not been received before (Step S902).

  As a result, if the event information is not event information that has not been received before, that is, event information that has been received previously (No at step S902), the client 20 ends the processing. On the other hand, if the event information has not been received before (Yes at step S902), the client 20 determines whether the received event is a difference update notification (step S903).

  As a result, when it is a difference update notification (Yes at step S903), the client 20 updates the directory cache by difference (step S904), and proceeds to the process of step S905. On the other hand, if it is not the difference update notification (No at Step S903), the client 20 proceeds to the process at Step S905 without executing the process at Step S904.

  Subsequently, the client 20 determines whether or not the received event information is event information notified to the application (step S905). As a result, when the event information is to be notified to the application (Yes at Step S905), the client 20 notifies the application 22 of the event information (Step S906) and ends the processing. On the other hand, if the event information is not to be notified to the application (No at Step S905), the client 20 ends the process without executing the process at Step S906.

  Next, a processing procedure when a client directory information acquisition request is generated will be described with reference to FIG. As shown in FIG. 17, when a directory information acquisition request is generated from an application (Yes at Step S1001), the client 20 determines whether or not the directory cache is held (Step S1002). As a result, when the directory cache is held (Yes at Step S1002), the client 20 reads the held directory cache and returns it to the application (Step S1003). The client 20 does not start the process until a directory information acquisition request is issued from the application (No at step S1001).

  On the other hand, if the client 20 does not hold the directory cache (No at Step S1002), the client 20 transmits the generated directory information acquisition request to the master 10A (Step S1004). When the client 20 receives the directory information corresponding to the transmitted directory information acquisition request from the master 10A (step S1005), the client 20 stores the directory information as a directory cache in the cache storage unit 21c (step S1006).

  Next, a processing procedure when a client node addition / deletion request is generated will be described with reference to FIG. As illustrated in FIG. 18, when an addition / deletion request for adding or deleting a node is generated from the application (Yes in step S1101), the client 20 transmits a node addition / deletion request to the master 10A (step S1102). ). Then, when the master 10A adds or deletes a node, the client 20 receives a response indicating that the node has been added or deleted from the master 10A (step S1103), and ends the process. The client 20 does not start the processing until an addition / deletion request for adding or deleting a node is issued from the application (No at Step S1101).

  The processing procedure when a client node addition / deletion request is generated is not limited to the above example. For example, when adding a node, if the client 20 holds the directory cache of the node corresponding to the parent node ID of the added node, the client 20 adds the node without waiting for a difference update notification from the master 10A. Node directory information may be added to the directory cache. If the client 20 holds the directory cache of the deleted node when the node is deleted, the directory information of the deleted node is stored in the directory cache without waiting for a differential update notification from the master 10A. You may delete from.

[Processing by life and death monitoring device]
Next, processing by the life and death monitoring apparatus according to the first embodiment will be described with reference to FIGS. 19 and 20. FIG. 19 is a flowchart for explaining a processing procedure of event distribution processing in the alive monitoring apparatus 10 according to the first embodiment. FIG. 20 is a flowchart for explaining the processing procedure of the difference update processing in the life and death monitoring apparatus 10 according to the first embodiment.

  First, the procedure of the event distribution process in the alive monitoring apparatus 10 according to the first embodiment will be described with reference to FIG. As shown in FIG. 19, when an event occurs, the master 10A registers event information (step S1201), and notifies the replicas 10B to 10E of replication of the event information (step S1202). Then, the master 10A transmits event information to the client 20 (step S1203), and receives an event reception completion response including the latest reception completion event ID from the client (step S1204). Then, the master 10A registers the latest reception completion event ID included in the event reception completion response (step S1205).

  Subsequently, the master 10A duplicates the latest reception completion event ID included in the event reception completion response and notifies the replicas 10B to 10E (step S1206). Thereafter, the master 10A determines whether there is a response from all the clients that transmitted the event information (step S1207). As a result, when there is no response from all the clients that transmitted the event information (No at Step S1207), the master 10A ends the process.

  Further, when there is a response from all the clients that transmitted the event information (Yes at Step S1207), the master 10A deletes the event information (Step S1208), and replicates the event information deletion to the replicas 10B to 10E (Step S1209). ), The process is terminated.

  Next, a processing procedure of difference update processing in the life and death monitoring apparatus 10 according to the first embodiment will be described with reference to FIG. As illustrated in FIG. 20, when the master 10A receives a node addition / deletion request from the client 20 (Yes in step S1301), the master 10A updates the database 30A based on the node addition / deletion request (step S1302). Then, the master 10A transmits a response indicating completion of addition / deletion to the client 20 that is the transmission source of the node addition / deletion request (step S1303).

  Further, when the master 10A updates the database 30A based on the node addition / deletion request, the master 10A generates a difference update notification of the updated node (step S1304), and registers this as event information in the event list. That is, as shown in steps S1201 and S1202 of FIG. 19, the master 10A registers the difference update notification as event information, and notifies the replicas 10B to 10E of a copy of the registered event information. For example, when the master 10A receives an addition request for adding the file with the node ID “2” from the client connected in the session with the session ID “2”, the node ID “Nid = 2” of the event occurrence source. ”, The event type“ add file ”, and the session ID“ Sid = 2 ”of the event occurrence source are associated with each other and registered in the event list as an event with the event ID“ 1 ”.

  Then, the master 10A acquires a list of notification destination clients that are notification destinations of the difference update notification (step S1305). For example, the master 10A refers to the node information list and acquires the session ID “Sid = 1, 3” that is accessing the node with the parent node ID “Pid = 1” of the node ID “Nid = 2” of the event generation source. To do. Then, the master 10A refers to the session information list and adds “Eid = 1” to “entry of event to be transmitted” corresponding to each acquired session ID “Sid = 1, 3”.

  Then, the master 10A transmits a difference update notification to the notification destination client as event information (step S1306). That is, as shown in steps S1203 to S1209 in FIG. 19, the master 10A transmits a difference update notification as event information to each client and receives a response. For example, when the master 10A transmits a difference update notification to each of the clients with the IP addresses “10.0.0.1” and “10.0.1.4” and receives responses from all the destination clients, The event information with event ID “1” (difference update notification) is deleted.

[Effect of the first embodiment]
The client 20 according to the first embodiment stores a cache of data stored in a master server that is one of a plurality of servers. When the data stored in the master server is updated, the client 20 transmits a difference update notification for updating the difference between the updated data and the data before the update, and transmission of the difference update notification. A new process selected from the master server or a replica server other than the master server among the plurality of servers in which the synchronization processing with the transmission completion information indicating whether or not the master server has been completed is performed. The difference update notification is received from the master server. The client 20 updates the cache using the received difference update notification. For this reason, the client 20 can reduce the communication load required for updating the cache. For example, since the alive monitoring apparatus 10 performs differential update only on the nodes that are added to or deleted from the directory cache, the communication load required for cache update can be reduced, and directory information can be updated at high speed. it can.

  Here, the effect of the life and death monitoring system according to the first embodiment will be described with reference to FIG. FIG. 21 is a diagram for explaining the effect of the life and death monitoring system according to the first embodiment. In FIG. 21, three clients 20A to 20C (computers 1 to 3) that are targets of alive monitoring are connected to the alive monitoring apparatus 10, and a fourth client 20D (computer 4) is added. The difference update process is illustrated. In FIG. 21, it is assumed that the names of the clients 20A to 20D (computers 1 to 4) are “m1 to m4”, respectively.

  The left side of FIG. 21 shows the state of the alive monitoring system before the fourth client 20D is added. In this case, the life and death monitoring apparatus 10 is composed of five servers and is connected to the clients 20A to 20C. At this time, the alive monitoring apparatus 10 creates files with the file names “m1, m2, m3” having the names of the connected clients 20A to 20C (computers 1 to 3), and the directory with the directory name “mDir”. I hold it under me. Each of the clients 20A to 20C monitors the directory with the directory name “mDir”, and holds the file names “m1, m2, and m3” as caches of the directory name “mDir”. In addition, the alive monitoring apparatus 10 stores information indicating that each of the clients 20A to 20C holds a cache of the directory name “mDir”.

  Here, when the fourth client 20D (computer) is connected to the alive monitoring device 10 as the alive monitoring target, the client 20D indicates the own device under the directory with the directory name “mDir” of the alive monitoring device 10. A request to create a file with the file name “m4” is transmitted (1. file addition), and this is added (2. file addition). Here, in the prior art, after deleting the cache held by each of the clients 20A to 20C before the addition, the file names “m1, m2, m3, m4” which are the directory information after the addition are received again. So the communication load was large. That is, each of the clients 20A to 20C re-receives the file names “m1, m2, and m3” that have not changed before and after the addition of the file, so that the communication load is large.

  In contrast, the alive monitoring apparatus 10 according to the first embodiment adds the file name “m4” to the cache held by each client 20 when the file with the file name “m4” is added. Perform differential update notification. Specifically, the alive monitoring apparatus 10 identifies the clients 20A to 20C that hold the directory information of the parent directory name “mDir” of the added file name “m4” as notification destination clients (3. Preparation for difference notification) ). Then, the alive monitoring apparatus 10 transmits a difference update notification indicating that the file name “m4” is added to each of the identified clients 20A to 20C (4. update information notification). As described above, the life and death monitoring system according to the first embodiment does not notify each of the clients 20A to 20C of the file name “m1, m2, m3, m4”, but newly added the file name “ Since only “m4” can be notified, the communication load required to update the cache can be reduced.

  Furthermore, a specific example is given and demonstrated. For example, a case will be described in which one file is added to the server side in a situation where 10,000 files are managed under the directory with the directory name “mDir” in the server. In this case, according to the prior art, 10001 file names are notified to each client 20 again. In contrast, the alive monitoring apparatus 10 according to the first embodiment notifies each client 20 of only one added file name. For this reason, the alive monitoring apparatus 10 according to the first embodiment can reduce the communication load required for updating the cache.

  Further, in the related art, for example, if a failure occurs in the master 10A after the difference update notification is generated, the difference update notification may be missed to some clients 20. That is, in the conventional technique, since the maintenance of the cache is not secured, the cache differential update technique cannot be implemented in the distributed system. In contrast, the life and death monitoring apparatus 10 according to the first embodiment prevents the difference update notification from being missed by performing the missed sending prevention process. Therefore, even if a failure occurs, the difference update notification is missing. Sending can be prevented. In other words, the alive monitoring device 10 can maintain the cache even before and after the failover, so that it is possible to implement the cache differential update technology for the distributed system.

[Second Embodiment]
In the first embodiment described above, the case where the directory cache is differentially updated has been described, but the embodiment is not limited to this. For example, the embodiment may be applied to the case where the cache of the file acquired from the master 10A is differentially updated. Therefore, in the second embodiment, a case will be described in which the cache of the file acquired from the master 10A is differentially updated.

  The life and death monitoring system 1 according to the second embodiment has basically the same functional configuration as the life and death monitoring system 1 shown in FIG. 2, and the client 20 receives data such as files instead of directory information. It is different in that it is held as cache data. Hereinafter, this difference will be mainly described.

  The flow of the difference update process by the alive monitoring system 1 according to the second embodiment will be described with reference to FIG. FIG. 22 is a sequence diagram illustrating a flow of difference update processing by the alive monitoring system 1 according to the second embodiment. FIG. 22 illustrates a case where the client 20B obtains a cache of the file name “FileA” stored in the master 10A. Then, the case where the cache is differentially updated in accordance with the update of the content of the file name “FileA” by the client 20A is illustrated.

  As shown in FIG. 22, when an acquisition request for acquiring a file with the file name “FileA” is generated from the application 22 (step S1401), the client 20B transmits an acquisition request for “FileA” to the master 10A (step S1401). S1402). Upon receiving the contents of the file corresponding to the acquired acquisition request from the master 10A (step S1403), the client 20B stores the file cache (step S1404). As a result, the client 20B acquires the cache of the file with the file name “FileA”. The contents of the file name “FileA” acquired by the client 20B are, for example, “Line1 aaa, Line2 bbb”.

  Thereafter, every time an acquisition request for acquiring the file with the file name “FileA” is generated from the application 22 (step S1405), the client 20B reads the acquired cache (step S1406) and uses it. .

  When the client 20A transmits an update request for updating the file with the file name “FileA” to the master 10A (step S1407), the master 10A updates the file with the file name “FileA”. For example, when receiving the file update request with the file name “FileA”, the master 10A updates the file with the file name “FileA” (step S1408). For example, if the master 10A is an update request to change the contents of the file with the file name “FileA” to “Line1 aaa, Line2 bbb, Line3 ccc”, the file name “FileA” before update stored in the database 30A. ”Is notified to the generation unit 12. Then, the master 10A notifies the generation unit 12 of the contents of the file specified by the update request, and overwrites the file with the file name “FileA” stored in the database 30A according to the update request (update). When the master 10A updates the file with the file name “FileA”, the master 10A notifies the client 20A of the completion of the file update (step S1409).

  When the master 10A updates the file with the file name “FileA”, the master 10A generates a difference update notification for updating the file with the file name “FileA”. Specifically, the generation unit 12 of the master 10A compares the contents of the file name “FileA” before the update with the contents of the file name “FileA” after the update. Then, the generation unit 12 of the master 10A generates a difference update notification indicating that “Line3 ccc” is inserted after “Line2 bbb” of the content of the file name “FileA” before the update. Then, the master 10A transmits the generated difference update notification to the client 20B that holds the cache (step S1410). As a result, the client 20B updates the contents of the file name “FileA” in the cache (step S1411), and inserts “Line3 ccc” after “Line2 bbb” in the cache data. Then, the client 20B transmits an update completion notification to the master 10A (step S1412).

  Thereafter, every time an acquisition request for acquiring a file with the file name “FileA” is generated from the application 22 (step S1413), the client 20B reads the updated cache (step S1414) and uses it. .

  Thus, according to the second embodiment, the alive monitoring system 1 can also update the cache of the file acquired from the master 10A by difference. For this reason, the alive monitoring system is expected to reduce the communication load required for updating the cache.

[Third Embodiment]
Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the above-described embodiments. Therefore, another embodiment included in the present invention will be described below as a third embodiment.

  For example, in the above-described embodiment, the case where the client 20 performs the cache difference update based on the difference update notification received from the master 10A has been described, but the embodiment is not limited thereto. For example, if the client 20 that transmitted a node addition / deletion request holds a cache, the cache difference may be updated without waiting for a difference update notification from the master 10A.

  A processing procedure when a node addition / deletion request is generated in the client 20 according to the third embodiment will be described with reference to FIG. FIG. 23 is a flowchart for explaining a processing procedure when a client node addition / deletion request is generated according to the third embodiment.

  As shown in FIG. 23, when an addition / deletion request for adding or deleting a node is generated from the application 22 (Yes in step S1501), the client 20 transmits a node addition / deletion request to the master 10A (step S1501). S1502). Then, when the master 10A adds or deletes a node, the client 20 receives a response indicating that the node has been added or deleted from the master 10A (step S1503). Note that the client 20 does not start processing until an addition / deletion request for adding or deleting a node is issued from the application 22 (No in step S1101).

  Then, the client 20 determines whether or not it holds a cache including the added / deleted node (step S1504). If the cache is held (Yes at step S1504), the client 20 executes a differential update for adding / deleting a node to / from the held cache based on the addition / deletion request (step S1505). ), The process is terminated. If the client 20 does not hold the cache (No at step S1504), the process is terminated.

  As described above, if the client 20 that has transmitted the node addition / deletion request holds the cache, the client 20 can update the cache difference without waiting for the difference update notification from the master 10A.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. For example, the event transmission unit 13 and the transmission incomplete event transmission unit 16 may be integrated. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

  In addition, 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-described document and drawings can be arbitrarily changed unless otherwise specified.

  Moreover, the program which described the process which the life-and-death monitoring apparatus 10 demonstrated in the said embodiment performed in the language which a computer can execute can also be created. For example, a difference update program in which processing executed by the life and death monitoring apparatus 10 according to the first embodiment is described in a language that can be executed by a computer can be created. In this case, when the computer executes the difference update program, the same effect as in the above embodiment can be obtained. Further, by recording such a differential update program on a computer-readable recording medium, and reading the differential update program recorded on this recording medium into a computer and executing it, the same processing as in the first embodiment is realized. May be. Below, an example of the computer which performs the difference update program which implement | achieves the function similar to the alive monitoring apparatus 10 shown in FIG. 2 is demonstrated.

  FIG. 24 is a diagram illustrating a computer 1000 that executes a differential update program. As illustrated in FIG. 24, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, and a network interface 1070. These units are connected by a bus 1080. The

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012 as illustrated in FIG. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1031 as illustrated in FIG. The disk drive interface 1040 is connected to the disk drive 1041 as illustrated in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive.

  Here, as illustrated in FIG. 24, the hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the above-described differential update program is stored in, for example, the hard disk drive 1031 as a program module in which a command executed by the computer 1000 is described.

  The various data described in the above embodiment is stored as program data, for example, in the memory 1010 or the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1031 to the RAM 1012 as necessary, and executes each procedure.

  Note that the program module 1093 and the program data 1094 related to the differential update program are not limited to being stored in the hard disk drive 1031, but are stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive or the like. Also good. Alternatively, the program module 1093 and the program data 1094 related to the differential update program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and the network interface 1070 is stored. Via the CPU 1020.

DESCRIPTION OF SYMBOLS 1 Life / death monitoring system 10 Life / death monitoring apparatus 10A Master 10B-10E Replica 11 Update part 12 Generation part 13 Event transmission part 14 Synchronization part 15 Connection part 16 Transmission incomplete event transmission part 17 Storage part 20 Client 21 Client library 21a Session management part 21b Cache update unit 21c Cache storage unit 22 Application

The difference update apparatus according to the embodiment includes a cache storage unit, a connection unit, a reception unit, and an update unit. The cache storage unit stores a cache of data stored in a master server that is one of a plurality of servers. The connection unit, when a failure occurs in the master server and communication with the failed master server is interrupted, a difference update notification for updating a difference between the updated data and the pre-update data; Selected from replica servers other than the master server among the plurality of servers in which the synchronization processing with the transmission completion information indicating whether or not the transmission of the difference update notification has been completed is performed by the master server A new master server is inquired and connected to be communicable with the new master server. The receiving unit receives the difference update notification from the new master server when a failure occurs in the master server, and receives the difference update notification from the master server when no failure occurs in the master server. Receive. The update unit updates the cache using the received difference update notification.

Claims (7)

A cache storage unit that stores a cache of data stored in a master server that is one of a plurality of servers;
When the data stored in the master server has been updated, the difference update notification for updating the difference between the updated data and the data before the update, and whether or not the transmission of the difference update notification has been completed Among the plurality of servers that have been synchronized by the master server with the transmission completion information indicating the master server, or a new master server selected from the replica servers other than the master server, A receiver for receiving the difference update notification;
An update unit comprising: an update unit that updates the cache using the received difference update notification. The cache storage unit stores directory information about data stored in the master server as a cache,
The receiving unit, when the directory information stored in the master server is updated, a directory difference update notification for updating the difference between the updated directory information and the updated directory information, Among the plurality of servers in which the synchronization processing with the directory transmission completion information indicating whether or not the transmission of the directory difference update notification has been completed is performed by the master server, the master server or the replica server Receiving the directory difference update notification from the new master server selected from
The difference update apparatus according to claim 1, wherein the update unit updates the directory cache using the received directory difference update notification. An update request transmitting unit that transmits an update request for updating the data stored in the master server to the master server;
The update unit updates the cache based on the update request if a cache of data corresponding to the update request transmitted by the update request transmission unit is stored in the storage unit. The difference update apparatus according to claim 1. A differential update system comprising a plurality of servers and clients,
Each of the plurality of servers is
A data storage unit for storing the data;
A data update unit that receives a request to update the data stored in the data storage unit and updates the data stored in the data storage unit in response to the received request;
A generation unit that generates a difference update notification for updating the difference between the updated information updated by the data update unit and the information before the update;
A transmission unit that transmits the difference update notification to the client that holds a cache of data stored in the data storage unit;
The difference update notification stored in the master server and transmission completion information indicating whether or not the transmission of the difference update notification has been completed to the client is a server other than the master server among the plurality of servers. A synchronization unit to be stored in the replica server;
When a failure occurs in the master server, a connection unit that connects the new master server selected from the replica server and the client in a communicable manner;
Of the differential update notifications stored in the new master server, a differential update notification that has not been transmitted to the client is identified using the transmission completion information, and the differential update notification that has not been transmitted is transmitted to the client. A transmission incomplete notification transmission unit for transmitting,
The client
A cache storage unit for storing a cache of data stored in the master server;
When the data is updated, the difference update notification is received from the master server or a new master server selected from the replica servers,
A differential update system comprising: a cache update unit that updates the cache using the received differential update notification. A differential update method executed by a differential update device,
A difference update notification for updating the difference between the updated data and the pre-update data when the data stored in the master server that is one of the plurality of servers is updated; and Among the plurality of servers synchronized by the master server with transmission completion information indicating whether or not the transmission of the difference update notification has been completed, the master server or a replica server that is a server other than the master server Receiving a difference update notification from a new master server selected from:
An update process for updating a cache stored in a storage unit for storing a cache of data stored in the master server using the received difference update notification. A difference update notification for updating the difference between the updated data and the pre-update data when the data stored in the master server that is one of the plurality of servers is updated; and Among the plurality of servers synchronized by the master server with transmission completion information indicating whether or not the transmission of the difference update notification has been completed, the master server or a replica server that is a server other than the master server Receiving a difference update notification from a new master server selected from:
A difference update program that causes a computer to execute an update step of updating a cache stored in a storage unit that stores a cache of data stored in the master server, using the received difference update notification. A data storage unit for storing the data;
A data update unit that receives a request to update the data stored in the data storage unit and updates the data stored in the data storage unit in response to the received request;
A generation unit that generates a difference update notification for updating the difference between the updated information updated by the data update unit and the information before the update;
A transmission unit that transmits the difference update notification to a client that holds a cache of data stored in the data storage unit;
A replica that is a server other than the master server among a plurality of servers, including a difference update notification stored in the master server and transmission completion information indicating whether or not the transmission of the difference update notification has been completed to the client. A synchronization unit stored in the server;
When a failure occurs in the master server, a connection unit that connects the new master server selected from the replica server and the client in a communicable manner;
Of the differential update notifications stored in the new master server, a differential update notification that has not been transmitted to the client is identified using the transmission completion information, and the differential update notification that has not been transmitted is transmitted to the client. A differential update server comprising: a transmission incomplete notification transmission unit for transmission.

Images