JP5079561B2 - Database system and replica data updating method in database system - Google Patents

Description

  The present invention relates to a technique for copying master data at a certain point in a master site to a slave site and storing it as replica data, and in particular, processing load for copying replica data in a plurality of nodes arranged at the master site and the slave site. It is related to the technology of dispersion.

  Conventionally, there is a database system that stores master data at a master site and stores master data at a point in time at a slave site as replica data. When this is realized in the ORACLE (registered trademark) database, a materialized view (hereinafter referred to as M-View) can be used.

  In this M-View, replica data is updated (refreshed) according to the procedure shown in FIG. That is, when replica node 600 issues a refresh request for replica data (replica A) in table A to master node 500 (S510), log A indicating the update history of master data (master A) in table A is issued by master node 500. (S520). Then, the master node 500 identifies data updated after the previous refresh based on the log A, and acquires data updated after the previous refresh from the master A (S530). The master node 500 notifies the replica node 600 of the data acquired from the master A (S540), and the replica node 600 updates the replica A (S550).

  Here, as the scale of the system increases, the load of refresh processing also increases. Therefore, we want to implement the refresh process by distributing the load among multiple nodes.

  However, particularly in M-View, there is a problem that the node is fixed due to the specifications of ORACLE (registered trademark).

  Accordingly, an object of the present invention is to distribute the load of refresh processing for copying master data at a master site as replica data at a slave site.

  A database system according to an embodiment of the present invention includes a plurality of master nodes that manage master data, a plurality of replica nodes that manage replica data obtained by copying the master data, and a load balancer. The load balancer includes: a first selection unit that selects one replica node that issues a refresh request for the replica data from the plurality of replica nodes; and the replica node selected by the first selection unit When receiving the refresh request issued by the first, the second selecting means for selecting one master node responding to the accepted refresh request from the plurality of master nodes, the first selecting means When the selected replica node issues a refresh request, the master data is acquired from the master node selected by the second selection means, and the replica data is updated based on the acquired master data.

  In a preferred embodiment, when the load balancer receives a replica node selection request from any of the plurality of replica nodes, the first selection unit selects the refresh from the plurality of replica nodes. One replica node that issues a request may be selected.

  In a preferred embodiment, each of the plurality of replica nodes includes a monitoring unit that monitors other replica nodes, and the monitoring unit of the first replica node issues a second replica to which the replica node selection request should be issued. When it is detected that a node cannot issue the replica node selection request, the first replica node may issue the replica node selection request.

  In a preferred embodiment, the plurality of replica nodes are assigned in advance the priority of the replica node selection request issuance, and the priority assigned to the first replica node is the second priority. When the priority is the second highest priority assigned to the replica node, the monitoring means of the first replica node causes the second replica node to issue the replica node selection request to issue the replica node selection request. When it is detected that it cannot be issued, the first replica node may issue the replica node selection request.

  In a preferred embodiment, the first replica node has a first process for issuing the replica node selection request in a first period, and is longer than the first period after the replica data is refreshed. And a second process for making a replica node selection request to the load balancer when the second time has elapsed.

  In a preferred embodiment, the first process is a process on an OS (Operating System) of each replica node, and the second process is a process on a database management system that manages the replica data. Also good.

  Hereinafter, a database system according to an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a configuration diagram of a database system according to the present embodiment. This system includes a master site 10, a slave site 30, and a load distribution device 50.

  Each master node 11 and each replica node 31 are each configured by, for example, a general-purpose computer system, and each component or function in each node 11, 31 described below executes, for example, a computer program. It is realized by. Furthermore, both the master database 15 and the replica database 35 are realized on a storage device of a computer system. In particular, in the present embodiment, data realized by a database system such as an ORACLE (registered trademark) database may be used.

  The master site 10 includes a plurality of master nodes 11 and a master database 15 that stores master data 151. In this embodiment, the master node 11 has a four-unit configuration (11a to 11d), but the number of master nodes 11 can be arbitrarily determined. Each master node 11 has the same configuration. The master database 15 stores master data 151 divided into a plurality of data tables and log data 153 indicating an update history of each data table. In the example of FIG. 1, the master database 15 includes logs A, B, and C that are log data 153 of masters A, B, and C and masters A, B, and C that are master data 151 of tables A, B, and C. Is stored.

  The masters A, B, and C stored in the master database 15 are referred to and updated by a predetermined application program (not shown). When the masters A, B, and C are updated, the updated contents are added to the corresponding logs A, B, and C, respectively. Logs corresponding to master data sent to the slave site 30 in response to a refresh request to be described later are deleted from the logs A, B, and C.

  The slave site 30 includes a plurality of replica nodes 31 and a replica database 35 that stores replica data 351 that is a copy of master data at a certain point in time. In this embodiment, the number of replica nodes 31 is also four (31a to 31d), but the number of replica nodes 31 can be arbitrarily determined. Each replica node 31 has the same configuration. In the replica database 35, replica data 351, a refresh time 37, and a management table 39 are stored.

  The replica data 351 stores replicas A, B, and C, which are replica data of the masters A, B, and C, respectively. In the present embodiment, the replica data 351 is generated using M-View of the ORACLE (registered trademark) database.

  The refresh time 37 indicates the time when the replica data 351 is updated. The refresh time 37 includes an update time for each data table of the replica data 351.

  The management table 39 has a configuration as shown in FIG. 2, for example. That is, as shown in the figure, the management table 39 has a node ID 391, a time stamp 393, and a priority 395 as data items. The time stamp 393 is a time stamp periodically written by each replica node 31 in order to confirm that each replica node 31 is operating normally. The priority order 395 is a priority order assigned to each replica node 31 for processing performed by any one replica node 31. Here, priority 3951 of replica node selection processing is registered.

  FIG. 3 is a detailed configuration diagram of the slave site 30.

  Since the replica nodes 31 (31a to 31d) all have a common configuration, first, the common configuration will be described. That is, the replica node 31 monitors a database database management system (DBMS) 32 (32a to 32d) that manages the replica database 35, a replica node selection request process 33 (33a to 33d), and other replica nodes 31. Process 34 (34a-d). Here, the replica node selection request process 33 and the monitoring process 34 are processes that operate on the OS (Operating System).

  On the database management system 32, a copy processing unit 321 (321a to 321d), a database processing unit 323 (323a to 323d), and an automatic job execution unit 325 (325a to 325d) operate.

  The copy processing unit 321 issues a refresh request. The refresh request is an update request for synchronizing the replica data 351 with the latest master data 151. The refresh request includes information indicating a data table to be refreshed. In the present embodiment, the refresh request is issued to the load balancer 50. As a response to the refresh request, the copy processing unit 321 acquires master data of the data table specified by the refresh request from the master node 11. The master data acquired by the copy processing unit 321 is difference data from the previous refresh of the replica data.

  The copy processing unit 321 issues a refresh request when receiving a refresh request issuance instruction from the load balancer 50. That is, the load balancer 50 determines which replica node 31 issues the refresh request. Thereby, load distribution of the replica nodes 11a to 11d is realized. The copy processing unit 321 includes information indicating the data table to be refreshed included in the refresh request issuance instruction in the refresh request.

  The database processing unit 323 stores the difference data of the master data acquired by the copy processing unit 321 in the replica database 35, and updates (refreshes) the replica data 351. When updating the replica data 351, the database processing unit 323 also updates the refresh time 37 of the updated data table.

  The automatic job execution unit 325 executes a job registered in advance at a predetermined cycle. For example, in this embodiment, the automatic job execution unit 325 monitors the time when the replica data 351 is refreshed, and when a predetermined time (automatic job execution time) elapses from the last refresh time, the load balancer A replica node selection request is issued to 50. In the replica node selection request issued by the automatic job execution unit 325, the entire data table of the replica data 351 may be specified as a target. Here, in this embodiment, as will be described later, the issuance of a replica node selection request by the automatic job execution unit 325 is a backup position of processing performed by the replica node selection request process 33 described below.

  The automatic job execution unit 325 can be executed by any of the replica nodes 11a to 11d. However, the automatic job execution unit 325 may be operated by any one of the replica nodes 11 by adjusting between the database management systems 32a to 32d. Good.

  The replica node selection request process 33 issues a replica node selection request to the load balancer 50 at a predetermined cycle. For example, in this embodiment, the replica node selection request process 33 holds the previous replica node selection request issuance time, and when a predetermined time (refresh time) has elapsed from that time, the replica node selection request process 33 Issue. The replica node selection request includes information indicating one or more data tables belonging to the same refresh group. A refresh group is a group of data tables that are refreshed at the same cycle. In this embodiment, a plurality of refresh groups having different refresh times can be registered, and the replica node selection request process 33 issues a replica node selection request for each refresh group in accordance with each cycle.

  Here, the refresh time of any refresh group is shorter than the automatic job execution time of the automatic job execution unit 325. In other words, as long as the replica node selection request process 33 operates normally, the automatic job execution unit 325 does not issue a replica node selection request. When a replica node selection request is not issued from the replica node selection request process 33 for some reason and the replica data 351 is not refreshed, the automatic job execution unit 325 issues a replica node selection request, and the replica data 351 Refreshed.

  The monitoring process 34 monitors other replica nodes 31. For example, the monitoring process 34 periodically writes the current time (time stamp 393) in the time stamp 393 of the management table 39. At this time, by confirming the time stamp 393 written by the other replica node 31, it is confirmed whether or not the other replica node 31 is operating normally. That is, if there is a replica node 31 in which a predetermined time or more has elapsed from the time stored in the time stamp 393, it is considered that the replica node 31 has some trouble. The monitoring process 34 may update the time stamp 393 when it is confirmed that a specific process (for example, the replica node selection request process 33) is operating normally in the same node. Thereby, even if only the specific process is down, the other replica nodes 31 can detect the down of the specific process.

  As described above, each replica node 31 has a common configuration, but may operate differently due to a difference in some settings. For example, the replica node selection request process 33 operates only on any one replica node 31. The replica node 31 on which the replica node selection request process 33 operates is determined by the priority order 395. That is, among the active replica nodes 31, the replica node selection request process 33 operates on the one with the highest priority in the “replica node selection” of the priority 395. The monitoring process 34 of each replica node 31 refers to the management table 39 to check the priority 395 of its own node. When a higher-order node is not operating, the replica node selection request process of its own node 33 may be activated.

  For example, in the example of FIG. 3, at the normal time, only the replica node selection request process 33a of the replica node 31a operates. When the monitoring process 34b of the replica node 31b refers to the management table 39 and detects that the time stamp 393 of the replica node 31a has not been updated, the replica node selection request process 33b is activated, and the replica node 31b Issue a replica node selection request.

  Next, returning to FIG. 1, the load distribution apparatus 50 includes a replica selection unit 52 that selects any one of the replica nodes 31 a to 31 d when receiving a replica node selection request issued by any replica node 31. Then, the replica selection unit 52 instructs the selected replica node 31 to issue a refresh request. This refresh request issuance instruction includes information specifying a table included in the replica node selection request.

  In addition, the load distribution apparatus 50 includes a master selection unit 54 that selects one of the master nodes 11a to 11d when receiving a refresh request issued in response to a refresh request issuance instruction by the selected replica node 31. Then, the master selection unit 54 transmits a refresh request to the selected master node 11. This refresh request includes information for specifying a table to be refreshed.

  Note that any algorithm can be used for the replica selection unit 52 and the master selection unit 54 to select the replica node 31 or the master node 11, and for example, selection by round robin or pseudo-random numbers may be used.

  When the load balancer 50 acquires the difference data related to the refresh request from any of the master nodes 11, the load balancer 50 transmits it to the replica node 11 that issued the refresh request.

  The master nodes 11 (11a to 11d) all have a common configuration. In the master site 10, any one replica node 11 selected by the load balancer 50 receives the refresh request. The selected master node 11 refers to the log data 153 of the data table specified by the refresh request. Here, if the log data 153 exists, it means that the master data 151 has been updated since the previous refresh. Therefore, the master node 11 that has received the refresh request refers to the log data 153 of the data table specified in the refresh request, and acquires the corresponding master data 151 if the update history is included. Then, the selected master node 11 transmits the acquired master data of the difference to the load balancer 50. At this time, the log data 153 of the designated data table is deleted.

  Next, FIG. 4 shows a flowchart relating to the procedure for refreshing table A (replica A). This refresh process will be described with reference to FIG. 1, FIG. 3, and FIG.

  First, in this example, the replica node selection request process 33a is operating in the replica node 31a. Therefore, the replica node selection request process 33a determines whether or not the refresh time has elapsed from the previous refresh time (previous replica node selection request issue time) (S10). When the refresh time elapses from the previous refresh time (S10: Yes), the replica node selection request process 33a issues a replica node selection request to the load balancer 50 (S11).

  In the load balancer 50, when the replica selection unit 52 receives this replica node selection request, the replica selection unit 52 selects any one replica node 31 from the replica nodes 31a to 31d and sends a refresh request issue instruction to the selected replica node 31. (S12). In this example, it is assumed that the replica node 31b is selected.

  In accordance with the refresh request issuance instruction from the load balancer 50, the replica node 31b issues a refresh request to the load balancer 50 (S13).

  In the load balancer 50, when the master selection unit 54 receives this refresh request, the transmission destination of the refresh request is selected from the master nodes 11a to 11d (S14). In this example, it is assumed that the master node 11c is selected. Then, the load distribution apparatus 50 transmits a refresh request to the selected master node 11c (S15).

  The master node 11c refers to the log data 153 of the data table (here, B table) designated by the refresh request, and determines whether there is difference data. If there is difference data, the master node 11c acquires the master data 151 of the difference (S16). Then, the master node 11 c transmits the difference master data to the load balancer 50. Further, the load distribution apparatus 50 transmits the master data of the difference transmitted from the master node 11c to the replica node 31b that is the refresh request issuing source (S17).

  In the replica node 31b, the database processing unit 323b updates the replica data 351 (S18). At this time, the database processing unit 323b also updates the refresh time 37.

  As a result, load distribution can be performed in the replica data refresh processing using M-View.

  Next, FIG. 5 is a flowchart showing a procedure of backup processing of a replica data selection request by the monitoring process 34 of each replica node 31. The process of FIG. 6 is started at a predetermined time (monitoring time) cycle.

  The monitoring process 34 updates the time stamp 393 of the management table 39 to the current time (S20). Further, the monitoring process 34 confirms the priority order of “replica node selection” of the own node (S21).

  Here, the monitoring process 34 determines whether or not the replica node selection request process 33 has already been activated on its own node (S22).

  If the replica node selection request process 33 has already been started on the own node (S22: Yes), the process is terminated.

  On the other hand, when the replica node selection request process 33 is not started on the own node (S22: No), the node having a higher priority than the own node operates normally with respect to the priority 3951 for selecting the replica node. It is determined whether or not (S23). This determination is made based on whether or not the difference between the time stamp 393 of the node having higher priority than the current node and the current time is within a certain time (for example, twice the monitoring time).

  Then, when the replica node 31 having a higher priority than the local node is operating normally (S23: Yes), the process is terminated.

  On the other hand, when a node having a higher priority than the own node is not operating normally (S23: No), the monitoring process 34 starts the replica node selection request process 33 of the own node (S24).

  As a result, the replica node selection request process 33 can be operated on any one of the replica nodes 31 in accordance with the priority order set in the management table 39.

  The above-described embodiments of the present invention are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.

  For example, in the present embodiment, any replica node issues a replica node selection request. However, a replica node selection request may be issued by a non-replica node such as any master node or other system.

It is a block diagram of the database system which concerns on one Embodiment of this invention. 4 is an example of a data configuration of a management table 39. 2 is a detailed configuration diagram of a slave site 30. FIG. It is a flowchart which concerns on the procedure which refreshes the replica A. 4 is a flowchart showing a backup process procedure of a replica data selection request by a monitoring process 34 of each replica node 31. The replica data refresh process in a prior art is shown.

Explanation of symbols

10 master site 11a-d master node 15 master database 30 slave site 31a-d replica node 32 database management system 33 replica node selection request process 34 monitoring process 35 replica database 37 refresh time 39 management table 50 load balancer 52 replica selection unit 54 Master selector

Claims (7)

Multiple master nodes that manage the master data;
A plurality of replica nodes that manage replica data obtained by copying the master data;
A load balancer,
The load balancer is:
A first selection means for selecting one replica node for issuing a refresh request for the replica data from the plurality of replica nodes;
Upon receiving a refresh request issued by the replica node selected by the first selection means, second selection means for selecting one master node responding to the accepted refresh request from the plurality of master nodes. And comprising
The replica node selected by the first selection unit issues a refresh request to acquire the master data from the master node selected by the second selection unit, and based on the acquired master data, A database system for updating the replica data.   When the load balancer receives a replica node selection request from any of the plurality of replica nodes, the first selection unit causes the refresh request to be issued from the plurality of replica nodes. 2. The database system according to claim 1, wherein a replica node is selected. Each of the plurality of replica nodes includes monitoring means for monitoring other replica nodes,
When the monitoring means of the first replica node detects that the second replica node that should issue the replica node selection request cannot issue the replica node selection request, the first replica node requests the replica node selection request. The database system according to claim 1, wherein the database system is issued. Priorities of the replica node selection request issuance are assigned to the plurality of replica nodes in advance,
When the priority assigned to the first replica node is the next higher priority than the priority assigned to the second replica node, the monitoring means of the first replica node provides the replica 4. The database system according to claim 3, wherein when detecting that a second replica node that should issue a node selection request cannot issue the replica node selection request, the first replica node issues the replica node selection request. The first replica node is
A first process for issuing the replica node selection request in a first period;
And a second process for making a replica node selection request to the load balancer when a second time longer than the first period has elapsed since the replica data was refreshed. The database system according to claim 1 or 2. The first process is a process on the OS (Operating System) of each replica node;
6. The database system according to claim 5, wherein the second process is a process on a database management system that manages the replica data. In a database system comprising a plurality of master nodes for managing master data, a plurality of replica nodes for managing replica data copied from the master data, and a load balancer,
The load balancer selects one replica node that issues a refresh request for the replica data from the plurality of replica nodes,
The selected replica node issues a refresh request;
When the load distribution apparatus accepts the issued refresh request, the master distribution node selects one master node that responds to the accepted refresh request from the plurality of master nodes, and then refreshes the selected master node. Send a request,
Replica data in a database system in which the selected replica node acquires the master data from the selected master node via the load balancer and updates the replica data based on the acquired master data Update method.

Images