JP2010128752A - Database system, server, update method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a database system, a server, an update method, and a program for efficiently executing a plurality of update requests to a database. <P>SOLUTION: The server is connected to a database 90 and one or more other servers and includes a data storage part 50 for storing at least part of data obtained by dividing the database 90, a log storage part 62 for storing an update log by an update request concerning the data received from an application 30, a transmission part 88 for copying the update log and transmitting it to the other servers in response to the update request, a replica storage part 82 for storing a replica 110 of the update log by copying received from the other servers, and an execution part 64 for executing a batch update for the database 90 according to the sum of the update log 100 and the replica 110 stored in the log storage part 62 and the replica storage part 82 respectively. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to database technology, and more particularly to a database system, server, update method, and program for efficiently executing a plurality of update requests for a database.

  In recent years, with an increase in the scale of a database system, there is an increasing demand for efficient and high-speed processing of an enormous amount of transactions and data management with high reliability, availability, and fault tolerance.

  In connection with transaction efficiency, there is a known method for improving throughput by temporarily storing the requested update contents and sending multiple updates at once to the database when updating the database. . This is referred to as a batch update, which can reduce network traffic, streamline processing of similar update requests, and optimize disk writes in the database.

  The batch update is normally used when sending requests in a transaction collectively. By sending a plurality of update requests together, it is possible to improve the database processing speed, which is a bottleneck, and to improve the throughput of the entire transaction. However, in the batch update, a waiting time until a certain number of update requests can be committed is generated, and the response time is lowered.

  Similarly, a technique for generating a replica on a main memory is known in relation to the efficiency of transactions. For example, Non-Patent Document 1 discloses a technique for writing a transaction log to the local disk on the transmission side and the main memory of the remote machine at the replication destination. In Non-Patent Document 1, synchronous disk writing is avoided and replacement is performed by synchronous network data transfer to a remote machine, and a log copy is held on the local disk and the main memory of the remote machine. This guarantees the reliability of data until the actual database is written to the magnetic disk asynchronously. Non-Patent Document 1 reports that the transaction throughput can be improved by nearly 100 times by actual measurement by replication on the main memory. As a similar technique, non-patent document 2 reports that a performance improvement of 100 times or more can be obtained.

  In addition, Non-Patent Document 3 describes performance, reliability, and reliability by replicating data in a primary backup configuration using a cluster composed of servers connected by a system area network (SAN) capable of write-through. A system with improved availability is disclosed.

S. Ioannidis, E. P. Markatos, J. Sevaslidou, `` On Using Network Memory to Improve the Performance of Transaction Based System '', Proceedings of International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA'98), (July 1998). D. E. Lowell, P. M. Chen, `` Free Transactions with Rio Vista '', 16th ACM Symposium on Operating Systems Principles, Pages 92-101, (October 1997). C. Amza, A. L. Cox, W. Zwaenepoel, `` Data replication strategies for fault tolerance and availability on commodity clusters '' In Proceedings of the International Conference on Dependable Systems and Networks, pp. 459-467, (2000).

  In a database with a three-tier architecture, if it is difficult to cope with scale-up due to an increase in the size of the database, for example, if processing that is closed to an instance is executed, a cache (or object store) partitioned on the application server ) Is introduced and a method of scaling out is adopted. In such a partitioned system, it is considered efficient to perform batch update asynchronously with transactions by accumulating updates required for each partition. However, when the input load is different for each partition, a problem due to batch size imbalance described below occurs.

  The longest batch update interval in the system, LUI (Longest Update Interval), is the MTTF (Mean Time to Failure; average continuous operation) until the failure state (the primary and all replicas become unavailable) Time) must be shorter. In addition, since the batch update has a large execution overhead, if the batch size is not sufficiently large, there is a possibility that the throughput is reduced.

  FIG. 12 is a diagram schematically showing batch size imbalance. Conventionally, in a batch update with a fixed batch size, when the input load is different for each partition, as shown in FIG. 12 (A), the LUI is determined by a partition with a small load, and therefore, it corresponds to a short MTTF. become unable.

  On the other hand, in the case of batch update in which the update interval is fixed instead of the batch size, as shown in FIG. 12B, the batch size is different between the high load partition and the low one, and many are ideal batch sizes. Will no longer be batch updated. In particular, the maximum throughput value is inversely proportional to the number of partitions due to the overhead described above, such as when a batch update is executed even though the partition with the smaller load contains almost no update. Resulting in.

  The above partitioning is performed in consideration of the load balance between partitions. However, there is a limit, and if the load balance of update requests between partitions is broken for some reason, the set update interval is set. There was a possibility that the log accumulation amount would vary. Alternatively, with a fixed batch size, there is a possibility that the LUI due to a partition with a small load exceeds the MTTF. Furthermore, when replication is applied to such a system, the load due to replication is also proportional to the update load, resulting in variations. That is, in the partitioned distributed system, in order to maximize the benefit of throughput improvement by batch update, it is necessary to solve the problem of batch size imbalance between partitions.

  The present invention has been made in view of the above problems, and the present invention eliminates the problem of batch size imbalance between partitions in a partitioned distributed system, thereby improving throughput by batch update. It is an object of the present invention to provide a database system, a server, an update method, and a program that can be maximized.

  As a result of intensive studies, the present inventors apply a transaction log mutual replication by a plurality of servers to batch update processing, thereby avoiding a problem caused by batch size imbalance between partitions, which has been a problem in the past. Thus, the inventors have found that throughput improvement by batch update can be maximized, and the present invention has been achieved.

  In the present invention, in order to solve the above-mentioned problem, in a database system including a database and a plurality of servers, at least a part of the divided data of the database is stored on each server and updated from the application. Prepare for the request. Then, an update request related to the data is received from the application, the update log is stored, and the update log is duplicated and transmitted to other servers in the system. On the other hand, replicas of update logs by replication received from other servers are stored for batch update and multiplexing. Then, in correspondence with the sum of the update log and the replica, batch updates including the stored update log and the received replica are collectively performed on the database.

  In the above configuration, before executing the update request to the database, the update log is multiplexed on one or more servers independent of the failure, and high durability is ensured. The commit is performed when the multiplexing is successful, and the execution of the actual update request to the database is performed asynchronously with the transaction as the batch update. Furthermore, since the batch update includes a replica of the update log received from another server, that is, it is aggregated among a plurality of servers, the size of the batch update is the sum of the plurality of servers, and is ideal. Batch sizes can be easily realized. The longest update interval (LUI) is determined depending on the update load amount of the higher update load among those that mutually replicate, and it is easy to achieve an LUI that is equal to or less than the average continuous operation time (MTTF).

  In the present invention, it is possible to further include a coordinated server that assigns and notifies a batch update execution subject in correspondence with update load amounts notified from a plurality of servers. In order to allocate the execution subject of batch update among a plurality of servers, the server can measure and notify the update load amount due to the received update request, and the server can perform batch update in response to the allocation. It can be an execution subject. In the configuration described above, it is possible to cause a subject that can be executed efficiently (for example, one with a low update load) to execute batch update in accordance with the update load amount of each server.

  In the present invention, the server can include one or more partitions each corresponding to the divided data of the database. Furthermore, in the present invention, a data storage unit that stores the divided data, a log storage unit that stores the update log, a transmission unit that transmits the replica, a replica storage unit that stores the replica, and the batch update are executed. An execution unit can be configured for each partition. In the present invention, the coordinating server obtains a combination that minimizes the difference between the groups in the total amount of partition update load within the group, and obtains a mutual replication group (replication replication group) composed of partitions that mutually replicate update logs. Group).

  In the above configuration, since the total update load amount in the mutual replication group is controlled to be uniform among the groups, the LUI is determined by the group having the smallest total update load amount, and thus the input load of each partition is determined. Even when uniformization is difficult, it is possible to control the LUI by adjusting the total input load of the group more easily. The batch update throughput can be expected to be maximized when the total input load to the group is evenly balanced and the input load is sufficient. That is, according to the above configuration, throughput can be tuned in addition to easy control of the LUI.

  In the present invention, the coordinating server, in response to a failure of the partition of the execution subject, assigns and notifies the execution subject of the latest lightest load among the non-failed partitions in the mutual replication group. Can do. In the above configuration, even if the server on which the partition that was assigned as the execution subject operates fails, the update logs are mutually replicated within the group, so the execution subject is switched to another partition and batch update is performed. Can be implemented immediately. Therefore, fault tolerance is improved.

  Further, according to the present invention, batch update can be executed regardless of the above total in response to a failure of another partition belonging to the mutual replication group or in response to the elapse of the update interval. With the above configuration, it is possible to ensure that the LUI is equal to or lower than the MTTF, and it is possible to quickly ensure the safety of data from a state in which the persistence level is lowered due to a failure.

  In the present invention, the execution authority of batch update is configured to be acquired from a lease server that manages lending of the execution authority in the mutual replication group or by mutual agreement by all partitions of the mutual replication group. Can do. Further, in response to receipt of receipt of replicas from all partitions in the mutual replication group, processing can be returned to the application in response to an update request. Furthermore, in the present invention, the data storage unit, the log storage unit, and the replica storage unit can be provided by a main memory of a server.

  Hereinafter, although this invention is demonstrated with embodiment, this invention is not limited to embodiment mentioned later.

  In the following embodiment, a database system 10 having a three-tier client / server configuration including a database and a cluster including a plurality of application servers on which applications that access the database operate will be described as an example.

  FIG. 1 shows a schematic diagram of a database system 10 in an embodiment of the present invention. A database system 10 shown in FIG. 1 includes a database server 14 connected to a network 12. The network 12 includes, for example, Gigabit Ethernet (registered trademark). The database server 14 is generally configured as a general-purpose computer device such as a personal computer, workstation, mid-range, or mainframe.

  More specifically, the database server 12 includes a central processing unit (CPU) such as a single core processor or a multicore processor, a cache memory, a RAM, a network interface card (NIC), and the like. The database server 12 is further connected to a disk storage device via a storage interface such as SAS (Serial Attached SCSI), PATA (Parallel ATA), SATA (Serial ATA), and Fiber Channel. This provides a database storage area.

  The database server 14 of the present embodiment is an operating system (hereinafter referred to as an OS) such as WINDOWS (registered trademark) 200X, UNIX (registered trademark), LINUX (registered trademark), z / OS (registered trademark). Implementation of a database management system (RDBMS) that manages relational databases such as DB2 (registered trademark), Oracle (registered trademark) Database, and Microsoft (registered trademark) SQL Server (registered trademark) is doing. The data model of the database is not particularly limited. In another embodiment, the database server 14 includes a DBMS that manages databases of other data models such as an object relational database, an object database, a hierarchical database, a network database, and an XML (eXtensible Markup Language) database. It can also be implemented.

  The database system 10 shown in FIG. 1 further includes an application server (hereinafter referred to as an AP server) 20 that accesses the database server 14 via the network 12. The AP server 20 can also be configured as a general-purpose computer device having the same hardware configuration as the database server 14. The AP server 20 implements an application in which business logic or the like is implemented using Java (registered trademark) EE (Java (registered trademark) Platform, Enterprise Edition) or the like, and receives a request from a client (not shown) received via the network 12. Processing. For example, the AP server 20 can be configured by WebSphere (registered trademark) Application Server, JBoss (registered trademark), Oracle (registered trademark) Application Server, BEA WebLogic Server (registered trademark), or the like.

  The plurality of AP servers 20a to 20c form an AP server cluster 22 (hereinafter referred to as a unit cluster). Each of the AP servers 20a to 20c holds a data storage (Data Store) in which a database managed by the database server 14 is partitioned and arranged, and processes requests from clients while distributing the load. The data storage unit is provided by the storage space of the physical main memory of the AP server 20, operates as a database cache managed by the database server 14, and realizes high-speed transactions.

  The AP servers 20a to 20c read out data in the data storage unit in response to a database update request such as insert, update, or delete that occurs in response to an application operation, and make an update request. Respond and generate an update log and respond. In addition, the update log by the update request is accumulated, and the batch update log is collectively sent (flushed) to the database server 14 to execute a process of reflecting the update in the database asynchronously with the transaction, so-called batch update. .

  Furthermore, the AP servers 20a to 20c according to the present embodiment ensure the durability until the batch update is performed by synchronously replicating the update logs with each other, and succeed in multiplexing the update logs by replication. Commit to improve response time. In addition, when updating the batch, replicas of update logs exchanged with each other are also targeted.

  The database system 10 shown in FIG. 1 further includes a coordinate server 16 and a lease server 18 connected to the network 12. Similarly, the coordinate server 16 and the lease server 18 can be configured as general-purpose computer devices having the same hardware and software configuration as the AP server 20. Details of the functions of the coordination server 16 and the lease server 18 will be described later.

  FIG. 2 shows a functional block diagram implemented on each server in the database system 10 according to the embodiment of the present invention. The function units (details will be described later) included in the database system 10 shown in FIG. 2 each read a program from a computer-readable recording medium in a corresponding server, expand the program on the memory, and execute the program This is realized by controlling the operation of each hardware resource. The functional units arranged in each server communicate with each other using a distributed object technology framework such as EJB (Enterprise Java (registered trademark) Beans).

  One or more application modules (hereinafter simply referred to as modules) 30 are operating on each AP server 20. Further, one or more partitions 40 each including a data storage unit 50 are operating on each AP server 20.

  The data storage unit 50 caches data arranged by partitioning the database 90 managed by the database server 14 according to the rules on the application side, and responds to requests from the module 30 using the held data. The data storage unit 50 is provided by a storage space allocated on the physical main memory of each AP server 20, and holds all or a part of the data of the child table partitioned from the table of the database 90. The data storage unit 50 can hold a so-called materialized view. The data storage unit 50 can be preferably configured as an in-memory relational database.

  Each partition 40 includes a batch processing unit 60 and a replica processing unit 80 in addition to the data storage unit 50. The batch processing unit 60 temporarily stores an update log according to an update request for the database 90 from the module 30. The replica processing unit 80 transmits an update log replica according to an update request to the database 90 to a replica processing unit of a partition operating on another AP server belonging to the same group, which will be described later. The replica reception confirmation is received from the replica processing units of all other partitions of the transmission destination, and the update log is successfully multiplexed. Further, the replica processing unit 80 receives and temporarily stores the update log replica from the replica processing unit of another partition belonging to the same group, and responds with a receipt confirmation.

  When the update log is successfully stored by the batch processing unit 60 and the update log is multiplexed by replica transmission by the replica processing unit 80, the commit is made and a response to the update request is made to the module 30. The update log and replica are provided by the storage space of the physical main memory of the AP server 20, similarly to the data storage unit 50. Since the update log replica only needs to be held in a format that can be retrieved in the event of a primary failure, avoiding disk IO can improve response time compared to database access.

  On the other hand, the batch processing unit 60 reads these update logs corresponding to the total amount of update logs stored by itself and the replicas of received update logs stored by the replica processing unit 80. Then, the batch processing unit 60 performs a batch update to reflect these accumulated update contents in the database 90. The database server 14 that has received the batch update streamlines the update process corresponding to the batch update and reflects it in the database 90 to make the update contents permanent. The update log can be configured as a transaction log that holds data before and after updating the database, contents of operations, and the like, and the update contents accumulated on the AP server 20 side are reflected in the database 90. It is history information for persistence.

  In the database system 10 of the present embodiment, it is configured by partitions that operate on AP servers that are independent from each other, and the update log is referred to as a group (hereinafter referred to as a replication group) that is determined in advance to mutually replicate. ) Is configured. The batch update is not executed by all partitions, but is executed by assigning any one of the partitions belonging to the replication group as an execution subject. From the viewpoint of distributing the load, the partition with the smallest update load amount in the replication group is preferably assigned as the execution subject.

  A group adjustment unit 92 operates on the coordinate server 16. The group adjustment unit 92 organizes and manages the replication group. FIG. 3A shows the data structure of the partition management table 120 held by the coordinated server 16 in the embodiment of the present invention. The partition management table 120 shown in FIG. 3A includes a field 120a in which a partition ID for identifying a partition is input, a field 120b in which a server ID for identifying a server on which the partition operates is input, And a field 120c in which a group ID for identifying the replication group to which the member belongs is input.

  The partition management table 120 further includes a field 120d that holds a value indicating the latest update load amount of the partition. The group adjustment unit 92 periodically receives an update load amount report from each partition 40 and updates the value of the field 120d. The value indicating the update load amount is not particularly limited, but, for example, the number of updates per unit time can be adopted. In the example shown in FIG. 3, the number of updates per hour is input. .

  Further, the group adjustment unit 92 periodically refers to the contents of the field 120d, assigns a partition having the smallest update load amount in the group as an execution subject (hereinafter referred to as an execution partition), and notifies the same. . The partition management table 120 further includes a field 120e into which a value indicating whether the partition is an execution partition is input. The group adjustment unit 92 rewrites the value of the corresponding field 120e in accordance with the execution subject assignment. In addition, when there is a change in the execution subject, the group adjustment unit 92 notifies the partition that is not assigned to the execution partition.

  Further, the partition management table 120 includes a field 120f into which a value indicating the operation status is input. In response to the interruption of the heartbeat from each AP server 20, the group adjustment unit 92 detects the failure and updates the value of the field 120 f in accordance with the operating status. Note that the failure detection method is not limited to, for example, a heartbeat. In other embodiments, the group adjustment unit 92 may perform polling to detect a server failure based on the presence or absence of a response.

  When a failure of the AP server 20 on which the execution partition operates is detected, the group adjustment unit 92 changes the execution partition on the assumption that the execution partition is out of the replication group. Here, the partition that is not the execution subject is a non-execution partition. On the other hand, the group adjustment unit 92 instructs immediate execution of batch update for the execution partition of the group to which the non-execution partition on the AP server 20 on which the failure is detected belongs.

  Further, the group adjustment unit 92 receives an instruction from the operator at the start-up or maintenance of the database system 10 and updates the update within each group based on the latest update load amount for each partition operating on the cluster 22. Partitions are grouped so that the total load is uniform among the groups. As a result, the group adjustment unit 92 can organize a replication group. When the replication group is determined, the group adjustment unit 92 rewrites the value of the field 120c of the partition management table 120.

  FIG. 4 is a flowchart of a replication group organization process executed by the coordination server according to the embodiment of the present invention. The process shown in FIG. 4 is started from step S100 in response to the startup of the database system 10 or an instruction from the operator. In step S101, the group adjustment unit 92 accesses the partition management table 120 and acquires the server ID of the server on which each partition operates and the latest information on the update load amount of each partition from the fields 120b and 120d.

  In step S <b> 102, the group adjustment unit 92 generates a possible combination of groups for each partition. At this time, combinations in which corresponding server IDs are duplicated and included in the same group are excluded. Also, grouping combinations including groups consisting of only one partition are eliminated.

  In step S103, a grouping combination that minimizes the difference between the total sums of the update load amounts in each group is obtained from the possible grouping combinations, and a replication group is organized. For example, a combination that minimizes the sum of absolute values of differences in total update load amounts between groups is obtained.

  In step S104, the assigned group and other partitions belonging to the same group are notified to each partition of the organized replication group, and the process ends in step S105. In step S104, for each replication group, a notification indicating that it is allocated to the execution partition can be simultaneously performed for the partition having the smallest update load amount in the group.

  Further, the method of organizing the replication group is not limited to the above example. For example, in another embodiment, grouping that records the time series of the reported update load for each partition and minimizes the difference between the groups of the average update load for a certain period within each group. You can also organize replication groups for these combinations. Even when the update load amount of each partition differs by the replication group organization process as shown in FIG. 4, the batch update batch size can be made uniform among the groups as described later. Become.

  Referring again to FIG. 2, the lease management unit 94 operates on the lease server 18. At the time of actual batch update, the batch processing unit 60 of the execution partition makes an inquiry to the lease management unit 94 to confirm the execution authority of batch update. The lease management unit 94 receives an inquiry about the execution authority of the batch update from the batch processing unit 60 of the execution partition in each replication group, and leases the execution authority with a time limit. The lease management unit 94 gives the batch update execution authority exclusively to the batch processing unit 60 of the only partition 40 in the group.

  For example, when the AP server 20 of the execution partition is disconnected from the cluster 22 due to a network failure or the like, the group adjustment unit 92 that detects the AP server 20 failure changes the execution partition, so that a plurality of execution partitions are included in the same group. May exist. In such a case, there is a possibility that the execution partition on the AP server 20 separated from the cluster 22 is batch updated in the database 90 via another network. However, by managing the execution authority described above, since the execution authority for batch update is given to a single execution partition at a certain time, it is possible to avoid batch updating at least simultaneously.

  FIG. 3B shows the data structure of the lease management table 130 held by the lease server 18 in the embodiment of the present invention. The lease management table 130 shown in FIG. 3B includes a field 130a in which a group ID is input, a field 130b in which a value indicating a current batch update execution authority assignment state of the group is input, and an execution authority It includes a field 130c for inputting the lease term and a field 130d for inputting the ID of the partition to which the execution authority is given.

  The lease management unit 94 receives an inquiry about the execution authority of batch update from each partition, and reads the value of the corresponding field 130b of the group. If the value is “lock” and the inquired partition is different from the authorized partition, the lease management unit 94 notifies the authority acquisition failure. Upon receiving the inquiry, the lease management unit 94 extends the renewal time limit if the value of the corresponding field 130b of the group is “lock” and the inquiry partition is an authorized partition. 130c is rewritten, and the extended deadline is notified to the inquiry source. In response to the inquiry, if the value of the field 130b is “unlock”, the lease management unit 94 rewrites it to “lock”, notifies the inquiry source of successful acquisition of authority, and rewrites the values of the fields 130c and d. Further, the lease management unit 94 rewrites the value of the field 130b to “unlock” when the lease term has expired.

  In the present embodiment, the lease server 18 is separately provided to manage the execution authority of batch update. However, in other embodiments, mutual agreement by message exchange between the batch processing units 60 of partitions belonging to the same group. Therefore, a configuration may be adopted in which execution authority is granted to the execution partition with a time limit. In that case, from the viewpoint of processing efficiency, it is preferable to perform piggyback when the replica of the update log between the replica processing units 80 is transmitted and received.

  Details of the update log replication process and the batch update process according to the embodiment of the present invention will be described below with reference to FIGS. FIG. 5 is a data flow diagram associated with update log replication and batch updates according to an embodiment of the present invention. The diagram shown in FIG. 5 shows more detailed functional blocks for the batch processing unit 60 and the replica processing unit 80.

  The batch processing unit 60 includes a log storage unit 62, an update execution unit 64, an update timer 66, a threshold comparison unit 68, an update counter 70, and an execution authority acquisition unit 72. The replica processing unit 80 includes a replica storage unit 82, an update counter 84, a replica reception unit 86, and a replica transmission unit 88.

  The data storage unit 50 receives an update request for the database 90 from the module 30 and passes this update request to the batch processing unit 60. The batch processing unit 60 receives an update request from the data storage unit 50, temporarily stores the update log 100 in the log storage unit 62, increments the update counter 70, and returns the process to the data storage unit 50.

  The data storage unit 50 further passes an update request to the replica processing unit 80. The replica processing unit 80 receives the update request from the data storage unit 50, calls the replica transmission unit 88, and operates the replica 41 of the update log by the update request as a partition 41 that operates on another AP server belonging to the same group. To the replica receiving unit (not shown) of the replica processing unit 81. The replica processing unit 80 returns the processing to the data storage unit 50 in response to the reception of the receipt confirmation from all the destination partitions by the replica transmission unit 88. The data storage unit 50 makes a commit by storing the update log in the log storage unit 62 and the reception confirmation response to the replica transmission of the replica transmission unit 88, and sends an update request response to the module 30.

  The replica receiving unit 86 of the replica processing unit 80 receives an update log replica from the replica transmission unit of the replica processing unit 81 of another partition belonging to the same group, and updates the replica of the update log (hereinafter referred to as update log replica). The data is temporarily stored in the replica storage unit 82, and the update counter 84 is incremented. Further, after storing the update log replica, the replica receiving unit 86 transmits the success to the replica transmitting unit of the replica processing unit 81 of the transmission source as a receipt confirmation.

  The threshold comparison unit 68 of the execution partition 40 monitors the values of the update counter 70 of the batch processing unit 60 and the update counter 84 of the replica processing unit 80, and compares the total value with a threshold set in advance as the batch size. . That is, the number of updates received by the entire replication group is counted and compared with the threshold value. When the threshold value comparison unit 68 of the execution partition 40 determines that the total value has exceeded the threshold value, the update execution unit 64 is called. When the update execution unit 64 is called and has the authority to execute batch update, the update execution unit 64 reads the update log 100 from the log storage unit 62, reads the update log replica 110 from the replica storage unit 82, and stores, for example, an SQL statement. Create and execute a batch update on the database 90. If there is no execution authority for batch update, the execution authority acquisition unit 72 is called to execute batch update after acquiring execution authority for batch update.

  The update execution unit 64 can perform batch update regardless of the total value of the update counter 70 and the update counter 84. The update timer 66 of the batch processing unit 60 measures the elapsed time from the last batch update in the group to which it belongs. In response to the elapse of a given time of the update timer 66, the update execution unit 64 is called. This given time is preferably less than or equal to the MTTF of the database system 10. In response to the expiration of the update timer 66, the update execution unit 64 appropriately acquires execution authority, reads the update log 100 and the update log replica 110, and executes batch update on the database 90.

  The group adjustment unit 92 of the coordination server 16 detects the failure of the AP server 20 and immediately executes batch update to the batch processing unit 60 of the execution partition in the non-execution partition group operating on the AP server 20. Instruct. The batch processing unit 60 receives an instruction for immediate execution of batch update, appropriately acquires execution authority, calls the update execution unit 64, and causes the database 90 to execute batch update.

  When the batch update is successful, the update execution unit 64 determines that the corresponding update log and update log replica have been updated and discards them from the log storage unit 62 and the replica storage unit 82, or determines that the update has been executed. Set a flag to indicate. Then, the update execution unit 64 includes a report list for reporting the update requests that have been updated, in order to report the executed update requests to other non-execution partitions. The replica transmission unit 88 piggybacks the report list at the time of the next replica transmission and reports it to other partitions in the group.

  The replica receiving unit 86 acquires a report list from another partition and discards the update log 100 or update log replica 110 that has been updated from the log storage unit 62 and the replica storage unit 82, or indicates that the update has been performed. Set a flag to indicate. The update request with the flag set will be appropriately discarded later.

  The update counter 70 periodically reports the number of updates per unit time to the group adjustment unit 92 of the coordination server 16. The batch processing unit 60 is assigned as an execution partition and calls the execution authority acquisition unit 72. The execution authority acquisition unit 72 periodically inquires the lease management unit 94 on the lease server 18 to acquire and maintain the execution authority while it is an execution partition.

  FIG. 6 shows a flowchart of the processing operation for the update request from the application executed by the AP server 20 according to the embodiment of the present invention. The process shown in FIG. 6 is started from step S200 in response to an update request to the database from the application side. In step S <b> 201, the data storage unit 50 receives an update request for the database from the module 30, and passes this update request to the batch processing unit 60. In step S202, the batch processing unit 60 stores an update log based on the update request in the log storage unit 62, and in step S203, increments the update counter 70 and returns the process to the data storage unit 50.

  In step S204, the update request is passed from the data storage unit 50 to the replica processing unit 80, and the replica processing unit 80 duplicates the update log replica of the update request. In step S205, it is determined whether there is an unreported update execution request listed in the report list. If it is determined in step S205 that there is an unreported update execution request (YES), the process proceeds to step S206. In step S206, the replica processing unit 80 attaches the report list including the update request that has been updated to the replica copied in step S204, and advances the process to step S207.

  On the other hand, if it is determined in step S205 that there is no unreported update request (NO), the process proceeds directly to step S207. In step S207, the replica processing unit 80 calls the replica transmission unit 88 to appropriately piggyback the report list to the replica reception units 86 of all the other partitions 40 belonging to the same group and transmit the replica. In step S208, step S208 is looped and waited until reception confirmation is received from all other partitions 40 belonging to the same group (during NO).

  If it is determined in step S208 that receipt confirmation has been received from all other partitions (YES), the replica processing unit 80 returns the processing to the data storage unit 50 and proceeds to step S209. In step S209, the data storage unit 50 commits the update request by multiplexing the update log, responds to the update request to the module 30, returns the processing to the module 30, and ends the processing operation in step S210. .

  It should be noted that, when waiting in step S208, if it is not possible to receive confirmation of receipt from all partitions within a predetermined time for some reason, error handling can be performed as appropriate. The error handling here is not particularly limited, but, for example, according to the operation policy of the database system 10, a success is made when one or more replicas are multiplexed, and a receipt confirmation of the replica is received later. It can be configured to retransmit a replica to a partition that has not.

  FIG. 7 shows a flowchart of processing operations at the time of receiving a replica transmitted from another server executed by the AP server 20 according to the embodiment of the present invention. The processing shown in FIG. 7 starts from step S300 in response to replica transmission from the replica transmission unit 88 of another server. In step S301, the replica reception unit 86 receives the update log replica from the replica transmission unit 88 of the same group on the other server. The replica processing unit 80 stores the update log replica received in step S302 in the replica storage unit 82, increments the update counter 84 in step S303, and returns a receipt confirmation to the replica transmission unit 88 of the transmission source in step S304. .

  In step S305, it is determined whether or not a report list is attached to the received replica, that is, whether or not an update request that has been updated has been reported. If it is determined in step S305 that an update execution update request has been reported (YES), the process proceeds to step S306. In step S306, the update log and the update log replica corresponding to the update request that has been updated in the report list are discarded from the log storage unit 62 and the replica storage unit 82, respectively, or a flag indicating that the update has been executed is set. In step S307, this processing operation is terminated. On the other hand, if it is determined in step S305 that an update execution update request has not been reported (NO), the process proceeds directly to step S307, and this processing operation is terminated.

  FIG. 8 shows a flowchart of the batch update processing operation executed by the AP server 20 according to the embodiment of the present invention. The process shown in FIG. 8 is started from step S400 in response to the notification that the execution partition is assigned. In step S401, the batch processing unit 60 receives a notification message from the group adjustment unit 92 indicating that it has been assigned as an execution partition. In step S <b> 402, the batch processing unit 60 calls the execution authority acquisition unit 72 to inquire the execution authority of batch update to the lease management unit 94 of the lease server 18.

  In step S403, the batch processing unit 60 determines whether it is still an execution partition. If it is determined in step S403 that it is not already an execution partition, for example, if the execution partition is changed during execution authority inquiry, retrying inquiry, or waiting for an event that triggers batch update (for example, If NO, the process proceeds to step S417, and the process operation is terminated. On the other hand, if it is determined in step S403 that the partition is still an execution partition (YES), the process proceeds to step S404.

  In step S404, the batch processing unit 60 acquires the execution authority as a result of the inquiry in step S402, and determines whether or not the execution authority has a valid authority before the lease expiration date. If it is determined in step S404 that the acquisition of authority has failed or the lease time limit has been exceeded while waiting for an event that triggers batch update and it is determined that the user does not have valid authority (NO) Advances the process to step S405. In step S405, the process waits for a certain time, loops again to step S402, and re-executes an inquiry about execution authority.

  If it is determined in step S404 that the user has valid authority (YES), the process proceeds to step S406. In step S406, the batch processing unit 60 determines whether or not the group adjustment unit 92 has instructed immediate execution of batch update when a non-execution partition failure occurs. If it is determined in step S406 that immediate execution of batch update is not instructed (NO), the process proceeds to step S407. In step S407, the batch processing unit 60 determines whether or not the update timer 66 has expired. If it is determined in step S407 that the update timer 66 has not yet expired (NO), the process proceeds to step S408.

  In step S408, the batch processing unit 60 calls the threshold comparison unit 68 to acquire the total value of the update counter 70 of the batch processing unit 60 and the update counter 84 of the replica processing unit 80. In step S409, the total value is a predetermined value. It is determined whether or not the threshold is exceeded. If it is determined in step S409 that the total value does not exceed the threshold value (NO), the process is looped again to step S403, and at least the execution partition is instructed for immediate execution during the execution partition, Until the update timer expires or the total value of the update counter 70 and the update counter 84 exceeds the threshold value, the processing of steps S402 to S409 is repeated, and the occurrence of an event that triggers batch update is awaited.

  If it is determined in step S406 that immediate execution is instructed (S406: YES), if it is determined in step S407 that the update timer 66 has expired (S407: YES), or updated in step S409. If it is determined that the total value of the counter 70 and the update counter 84 exceeds the threshold (S409: YES), the process branches to step S410.

  In step S <b> 410, the batch processing unit 60 calls the update execution unit 64 to acquire update logs and update log replicas that have not been updated and are stored in the log storage unit 62 and the replica storage unit 82. In step S411, the update execution unit 64 inquires of the database 90 and confirms the validity of the version ID that enables update version management such as a time stamp attached at the time of batch update described later. If it is determined in step S411 that the version ID is valid (YES), the process proceeds to step S412.

  In step S <b> 412, the update execution unit 64 creates an SQL statement for requesting persistence by batch update to the database 90 and executes batch update. At this time, the update execution unit 64 also requests a version ID update such as a time stamp attached to the master on the database 90 within the same transaction in order to determine the validity of the version later. In the database 90 that has received the batch update, a plurality of update requests included in the batch update are optimized and processed, and the update contents are made permanent.

  In step S413, it is determined whether or not the batch update in step S412 has been successfully completed. In step S413, if a batch update completion response is received from the database 90 and it is determined that the batch update is successful (YES), the process proceeds to step S414. In step S414, the update execution unit 64 adds the update request that has been updated by executing the batch update to the report list. When an immediate execution at the time of failure is instructed, the report list can be transmitted immediately without waiting for the next replica transmission.

  The report list can include a batch update execution time stamp as a version ID. In the determination processing of the validity of the version ID in step S411, the version ID indicating the execution time of the previous batch update included in the notification list is compared with the version ID acquired from the database 90, and the version acquired from the database 90 It becomes valid when the ID matches that of the previous batch update, and the validity of the version ID can be determined from the context.

  In step S415, the batch processing unit 60 resets the update timer 66, the update counter 70, and the update counter 84, loops the process to step S403, and prepares for the next batch update. On the other hand, if it is determined in step S411 that the version is not valid (S411: NO) or if it is determined in step S413 that the batch update has not been completed successfully (S413: NO), step S416 is performed. Branch processing to

  In step S416, error processing is executed, and the process loops to step S403 to prepare for the next batch update. In the error processing in step S416, for example, error handling can be performed such as outputting an error warning to notify the administrator of the error and notifying the partitioning coordinator of the failure. In this case, for example, the group adjustment unit 92 responds by assigning another partition as an execution partition.

  Further, it is assumed that the version ID invalid error occurs when batch update has already been performed by a partition other than the execution partition. More specifically, the version ID invalid error indicates that the heartbeat of the AP server 20 on which the execution partition operates is not transmitted to the coordination server for some reason, and the group adjustment unit 92 assigns another partition as the execution partition. If (i) the new execution partition has performed a batch update first, or (ii) after the new execution partition has been assigned, the old execution partition detected the failure first. It is assumed that batch update has been performed. In the process of step S416, in the case of a version ID invalid error, a flag indicating deletion or update of a batch updated update request is set so as to inquire the database 90 and maintain consistency with the database 90, Error handling such as decrementing the update counters 70 and 84 by the corresponding number of updates can also be performed.

  FIG. 9 is a sequence diagram showing processing operations of the database system 10 when the execution partition fails according to the embodiment of the present invention. In FIG. 9, a case where the first partition 40-1 is an execution partition and the fourth partition 40-4 is a non-execution partition of the same group will be described as an example.

  As shown in step S500 and step S501, the first partition 40-1 and the fourth partition 40-4 periodically perform operation notification to the group adjustment unit 92 as part beats, respectively. For example, when the group adjustment unit 92 receives the operation notification from the fourth partition 40-4 in step S502 but does not receive the operation notification from the first partition 40-1 that is the execution partition for a certain period of time, in step S503, A failure of the first partition 40-1 is detected.

  In step S504, the group adjustment unit 92 assigns the fourth partition 40-4 belonging to the same group as the first partition 40-1 in which the failure is detected as a new execution partition, and notifies that fact. In step S505, the fourth partition 40-4 newly assigned as the execution partition immediately inquires the lease management unit 94 about the execution authority of the batch update. The lease management unit 94 waits for the expiration of the lease period of the execution authority given to the first partition 40-1 in step S506, and confirms the expiration. In step S507, the lease management unit 94 gives execution authority to the fourth partition 40-4.

  In this case, either the update log or one or more replicas exist on the one or more AP servers 20, while the persistence level due to the multiplexing of the update logs is lowered. For this reason, in step S508, the fourth partition 40-4, which is a new execution partition, executes batch update on the database 90 quickly and makes it permanent on the database 90. In response to the successful completion of the batch update, in step S509, the fourth partition 40-4 immediately reports a batch update executed update request to the other first partition 40-1 of the same group. Can try.

  After the failure, after the batch update is successfully completed, the operation according to the operational policy in the database system 10 can be performed, and there is no particular limitation. For example, the service may be resumed at a low persistence level without waiting for the failure server to return. In addition, the service may be resumed at the intended home attribute level after the failure server is restored. Alternatively, the partition may be redistributed to the spare AP server, and the service may be resumed at the intended persistence level. In the operation that does not continue the service at the low persistence level, when the execution partition is reassigned in step S504, the service stop can be instructed to all the partitions. In this case, each partition 40 in the group does not receive a new update request from the module 30, and all updates are reflected in the database 90, and the service is resumed after waiting for the restoration of the persistence level. It will be.

  FIG. 10 is a sequence diagram showing processing operations of the database system 10 when a non-execution partition fails according to an embodiment of the present invention. 10, as in FIG. 9, the case where the first partition 40-1 is an initial execution partition and the fourth partition 40-4 is an initial non-execution partition of the same group will be described as an example.

  As shown in step S600 and step S601, the first partition 40-1 and the fourth partition 40-4 periodically perform operation notification to the group adjustment unit 92 as part beats, respectively. For example, if the group adjustment unit 92 receives an operation notification from the first partition 40-1 that is the execution partition in step S602, but does not receive an operation notification from the fourth partition 40-4 for a certain period of time, the process proceeds to step S603. The failure of the fourth partition 40-4 that is a non-execution partition is detected.

  In step S604, the group adjustment unit 92 instructs the first partition 40-1 that is an execution partition belonging to the same group as the fourth partition 40-4 that has detected the failure, to execute batch update immediately. In step S605, the first partition 40-1, which is an execution partition, executes batch update for the database 90 promptly and makes it permanent on the database 90. In response to the successful completion of the batch update, in step S606, the first partition 40-1 immediately reports a batch update executed update request to the other fourth partition 40-4 of the same group. Can try. If there is no execution authority at step S605, the lease management unit 94 is inquired about the execution authority.

  After the failure, after the batch update is successfully completed, the operation according to the operational policy in the database system 10 can be performed, and the execution partition is not particularly limited as described above. Absent.

  FIG. 11 shows the relationship between the batch size of batch update in the execution partition and the LUI (longest update interval) according to the embodiment of the present invention. As described above, in the related art, when the load balance of update requests between partitions is broken due to some factor, the amount of accumulated logs at a fixed update interval varies or is fixed. In the case of the batch size, there is a possibility that the LUI due to the partition having a small load exceeds the MTTF.

  On the other hand, in the batch update according to the embodiment of the present invention, the update log by the update request received by each partition is shared and accumulated in the replication group to which it belongs. Preferably, the partition with the smallest load in the group is assigned as the execution subject of the batch update, and the accumulated update requests are transmitted and reflected in the database 90 in a lump.

  The accumulation amount of update requests increases with the total amount of update loads in the organized group, regardless of the update load amount of each partition. Therefore, when the batch size is fixed, the LUI in the group is determined depending on the partition having the maximum update load in the group even in the worst case. The total LUI is determined by the replication group having the minimum amount of update load.

  Therefore, in the batch update according to the embodiment of the present invention, even if it is difficult to balance the input load of the update between partitions, the total input load can be controlled to a desired value less than MTTF by the easier replication group organization. The LUI can be controlled. Furthermore, since the replication group can be reconfigured according to the update load amount of each partition, the total update load between the groups can be made uniform.

  Further, in the conventional technique, when the variation in input load is large, if the LUI is limited according to MTTF, as shown in FIG. 12B, a batch update that hardly includes an update request is performed in a partition with a small input load. There was a case. While batch update greatly contributes to efficiency, the overhead of execution itself is large. Therefore, in this conventional batch update, when there are n replication group members due to batch size imbalance, at worst, The maximum throughput is estimated to be about 1 / n of the maximum.

  On the other hand, in the embodiment of the present invention, as described above, since the update request for the entire replication group is batch-updated in batch, the batch update can be executed in the most concentrated state within the LUI, and the batch size can be reduced. It can be increased. In particular, when the input load between the replication groups is evenly distributed and the input load is sufficiently large, the highest throughput can be obtained.

  As described above, according to the embodiments of the present invention, in a partitioned distributed system, it is possible to solve the problem due to batch size imbalance between partitions and thereby maximize throughput improvement by batch update. Possible database systems, servers, update methods and programs can be provided.

  Although the present invention has been described in order to facilitate understanding of the invention, each function unit and the process of each function unit have been described. However, the present invention is not limited to the above-described specific function unit executing a specific process. A function for executing the above-described processing can be assigned to any functional unit in consideration of efficiency such as programming for implementation and implementation.

  The above-described functions of the present invention include an object-oriented programming language such as C ++, Java (registered trademark), Java (registered trademark) Beans, Java (registered trademark) Applet, Java (registered trademark) Script, Perl, and Ruby, and a database such as SQL. It can be realized by a device executable program described in a language or the like, and can be stored in a device-readable recording medium and distributed or transmitted and distributed.

  Although the present invention has been described with specific embodiments, the present invention is not limited to the embodiments, and other embodiments, additions, changes, deletions, and the like can be conceived by those skilled in the art. It can be changed within the range, and any embodiment is included in the scope of the present invention as long as the effects and effects of the present invention are exhibited.

1 is a schematic diagram of a database system in an embodiment of the present invention. The functional block diagram implement | achieved on each server in the database system by embodiment of this invention. The figure which shows the data structure of the (A) partition management table which a coordination server hold | maintains, (B) the lease management table which a lease server holds in embodiment of this invention. 6 is a flowchart of replication group organization processing executed by the coordinated server according to the embodiment of the present invention. FIG. 3 is a data flow diagram related to update log replication and batch update according to an embodiment of the present invention. The flowchart of the processing operation with respect to the update request from the application side which AP server by embodiment of this invention performs. The flowchart of the processing operation at the time of reception of the replica transmitted from the other server which AP server by embodiment of this invention performs. The flowchart of the batch update process operation which AP server by embodiment of this invention performs. The sequence diagram which shows the processing operation of the database system 10 at the time of the failure of the execution partition by embodiment of this invention. The sequence diagram which shows the processing operation of the database system at the time of failure of the non-execution partition by embodiment of this invention The figure which shows the relationship between batch size and LUI of the batch update in the execution partition by embodiment of this invention. The figure which shows roughly the batch size imbalance by a prior art.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Database system, 12 ... Network, 14 ... Database server, 16 ... Coordinate server, 18 ... Lease server, 20 ... AP server, 22 ... Cluster, 30 ... Module, 40, 41 ... Partition, 50 ... Data storage , 60 ... batch processing unit, 62 ... log storage unit, 64 ... update execution unit, 66 ... update timer, 68 ... threshold comparison unit, 70 ... update counter, 72 ... execution authority acquisition unit, 80, 81 ... replica processing unit , 82: Replica storage unit, 84: Update counter, 86 ... Replica reception unit, 88 ... Replica transmission unit, 90 ... Database, 92 ... Group adjustment unit, 94 ... Lease management unit, 100 ... Update log, 110 ... Update log Replica, 120 ... partition management table, 130 ... lease management table

Claims (20)

A database system including a database and a plurality of servers, the server comprising:
A data storage unit for storing data of at least a part of the database divided;
A log storage unit for storing an update log according to an update request related to the data received from the application;
In response to the update request, a transmission unit that copies the update log and transmits it to another server;
A replica storage unit for storing a replica of an update log by replication received from another server;
An execution unit that executes batch update on the database in correspondence with the sum of the update log and the replica stored in the log storage unit and the replica storage unit.   The database system according to claim 1, further comprising a coordinated server that assigns an execution subject of the batch update in response to an update load amount notified from a plurality of servers and notifies the execution unit.   The server includes one or more partitions corresponding to the divided data of the database, and the data storage unit, the log storage unit, the transmission unit, the replica storage unit, and the execution unit are provided for each partition. The database system of claim 2, wherein the database system is configured.   The coordinating server organizes a mutual replication group including partitions that mutually replicate update logs for a combination that minimizes a difference between groups in a total of the partition update load amounts in the group. The database system described in.   The execution unit acquires the execution authority of the batch update from a lease server that manages lending of the execution authority in the mutual replication group or by mutual agreement by all partitions of the mutual replication group. Item 5. The database system according to Item 4.   The coordinating server, in response to a failure of a partition of an execution subject, allocates and notifies the most recently loaded partition having no failure among the non-failed partitions in the mutual replication group as an execution subject. The database system described.   The database according to claim 6, wherein the execution unit executes the batch update regardless of the sum in response to a failure of another partition belonging to the mutual replication group or in response to an update interval. ·system.   8. The database system according to claim 7, wherein the transmission unit returns processing to the application in response to the update request in response to receipt of receipt of replicas from all partitions in the mutual replication group. . A server connected to a database and one or more other servers, the server comprising:
A data storage unit for storing data of at least a part of the database divided;
A log storage unit for storing an update log according to an update request related to the data received from the application;
In response to the update request, a transmission unit that copies the update log and transmits it to another server;
A replica storage unit for storing a replica of an update log by replication received from another server;
An execution unit that executes batch update on the database in correspondence with the sum of the update log and the replica stored in the log storage unit and the replica storage unit.   The server further includes a load measuring unit that measures and notifies an update load amount according to the received update request in order to allocate the execution subject of the batch update among a plurality of servers, and the execution unit corresponds to the allocation The server according to claim 9, which becomes an execution subject of the batch update.   Each of the servers includes one or more partitions corresponding to divided data of the database and belonging to any mutual replication group that mutually replicates update logs, the data storage unit, the log storage unit, The server according to claim 10, wherein the transmission unit, the replica storage unit, and the execution unit are configured for each partition.   The server according to claim 11, wherein the execution unit executes the batch update regardless of the sum in response to a failure of another partition belonging to the mutual replication group or in response to an update interval. . A method of updating a database, comprising: a server connected to the database and one or more other servers;
Receiving, from an application, an update request related to at least a portion of the data in the database;
In response to the update request, storing an update log according to the received update request, and copying the update log and sending it to another server;
Receiving a replica receipt confirmation from the other server at the destination, and causing the application to respond in response to the update request, and further comprising:
Receiving and storing replicas of replicated update logs from other servers;
Executing a batch update on the database in correspondence with the stored update log and the total of the replicas.   The server further measures and notifies the update load amount of the received update request in order to allocate the execution subject of the batch update among a plurality of servers; The update method according to claim 13, wherein the step as an execution subject is executed.   The update according to claim 14, further comprising the step of realizing one or more partitions each belonging to a mutual replication group that corresponds to the divided data of the database and that replicates update logs to each other. Method.   The server further performs a step of executing the batch update regardless of the sum in response to a notification of a failure of another partition belonging to the mutual replication group or in response to an elapse of an update interval; The update method according to claim 15. A computer executable program for causing a computer to function as a server connected to a database and one or more other servers, the program comprising:
A data storage unit for storing data of at least a part of the database divided;
A log storage unit for storing an update log according to an update request related to the data received from the application;
In response to the update request, a transmission unit that copies the update log and transmits it to another server,
A replica storage unit that stores a replica of an update log by replication received from another server, and the database corresponding to a total of the update log and the replica stored in the log storage unit and the replica storage unit A computer-executable program that functions as an execution unit that executes batch updates.   The server further functions as a load measuring unit that measures and notifies an update load amount according to the received update request in order to allocate an execution subject of the batch update among a plurality of servers, and the execution unit The program according to claim 17, wherein the program is made to function as an execution subject of the batch update.   Causing the server to generate one or more partitions corresponding to the divided data of the database and belonging to any mutual replication group that mutually replicates update logs, the data storage unit, the log storage unit, and the transmission The program according to claim 18, wherein the storage unit, the replica storage unit, and the execution unit are configured for each partition. A database system including a database, a coordinating server, and a plurality of servers, the server comprising:
A data storage unit for storing data of at least a part of the database divided;
A log storage unit for storing an update log according to an update request related to the data received from the application;
In response to the update request, a transmission unit that copies the update log and transmits it to another server;
A replica storage unit for storing a replica of an update log by replication received from another server;
An execution unit that executes batch update on the database in correspondence with the total of the update log and the replica stored in the log storage unit and the replica storage unit, and
The coordinating server allocates an execution subject of batch update corresponding to the update load amount notified from a plurality of servers, and notifies the execution unit,
The server includes one or more partitions corresponding to the divided data of the database, and the data storage unit, the log storage unit, the transmission unit, the replica storage unit, and the execution unit are provided for each partition. Configured,
The coordinated server seeks a combination that minimizes the difference between the groups in the total of the partition update load amount, and organizes a mutual replication group including partitions that mutually replicate the update logs.
The execution unit acquires the execution authority of the batch update from a lease server that manages lending of the execution authority in the mutual replication group, or by mutual agreement by all partitions of the mutual replication group,
In response to the failure of the execution subject partition, the coordinating server assigns and notifies the execution unit of the latest and lowest load among the non-failed partitions in the mutual replication group,
The execution unit executes the batch update regardless of the sum in response to a failure of another partition belonging to the mutual replication group or in response to the elapse of an update interval,
In response to receipt of receipt of replicas from all partitions in the mutual replication group, the transmission unit returns processing to the application in response to the update request.
Database system.

Images