DESC:TECHNICAL FIELD

[001] The present subject matter described herein, in general, relates to distributed computing systems, and more particularly, to a system and method for multi-master synchronous replication optimization.

BACKGROUND

[002] A database is an electronic filing system that stores data in a structured way. The primary storage structure in a database is a table. A database may contain multiple tables and each table may hold information of a specific type. Database tables store and organize data in horizontal rows and vertical columns Rows typically correspond to real-world entities or relationships that represent individual records in a table. Columns may denote specific attributes of those entities or relationships, such as “name,” “address” or “phone number.” For example, Company X may have a database containing a “customer” table listing the names, addresses and phone numbers of its customers. Each row may represent a single customer and the columns may represent each customer's name, address and phone number.

[003] Database Replication is a process of ensuring a copy of data exists on a different machine to provide high availability. Database replication is generally the frequent electronic copying data from a database in one computer or server to a database in another so that all users share the same level of information.

[004] As well known in the prior-art, the replication can either be physical (log-shipping) or logical (command-shipping). It can also be synchronous, where in the application wait time includes changes in the originator node and time to safely commit in the replica, or it can be asynchronous, where application gets response immediately after the data is safely committed in the originator node. The replicas are generally read-only. Further, master-master replication is a deployment scenario where-in both nodes can accept write queries. Also, it can be understood that, an originator node is always a single node however there can be multiple replica nodes.

[005] Conventionally available techniques generally work by applying the changes to queries received on the originator node, sending these changes to the replica, waiting for these changes to be committed on the replica nodes, and then commit the changes in originator node. However, a conflict resolution for the transactions that are received from the replica node and the ones that are happening in the current node is the main challenge of multi-master synchronous replication. Conflict resolution is a way to handle different types of conflicts -update conflicts (two transactions update same row at same time), uniqueness constraint conflicts (two transactions try to update/insert same unique key in the table), deletion conflicts (deletion of a row by one transaction and updating/deletion of the same by another transaction). For a master-master replication, during update on the nodes (other than the originator node), locks are obtained on the record to check if there is a conflict. These locks are held until the transaction is committed or rolled-back. This kind of locking reduces the scalability and throughput of the overall system.

SUMMARY

[006] This summary is provided to introduce concepts related to system and method for multi-master synchronous replication optimization which is further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

[007] A main objective of the present invention is to solve the technical problem as recited above by providing a system and method for optimizing multi-master synchronous replication.

[008] Another objective of the present invention is to increase the scalability and throughput of the system in case of multi-master synchronous replication. The present invention considers an availability of a flow controller at the application level which will route the distinct range of queries to different masters based on the application logic.

[009] Another objective of the present invention is to provide a system and method that uses optimistic concurrency based replication to achieve improved scalability and throughput of the system.

[0010] In one implementation, a system for multi-master replication is disclosed. The system includes at least one first master device and at least one second master device, wherein the first master device has a first database and the second master device has a second database. The first master device is configured to receive at least one query; allocate at least one row from the first database to insert at least one record corresponding to the at least one query, wherein each of the at least one row comprise a distinct row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to the second master device for a conflict check. The second master device is configured to receive the row_id of the at least one row in the first database and the at least one record corresponding to the at least one query; and check the conflict based on the row_id and the at least one record corresponding to the at least one query, wherein if the conflict is not detected, insert the at least one record in at least a row of the second database, or if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database.

[0011] In one implementation, a first master device having a first database is disclosed. The first master device is configured to receive at least one query; allocate at least one row from the first database to insert at least one record corresponding to the at least one query, wherein each of the at least one row comprise a distinct row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0012] In one implementation, a second master device having a second database is disclosed. The second master device is configured to receive row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device, the first database is in the first master device; and check a conflict based on the row_id and the at least one record corresponding to the at least one query, wherein if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

[0013] In one implementation, there is disclosed a device comprising a processor, coupled to a memory, for executing a plurality of modules present in the memory, the processor on execution of the modules is configured to receive at least one query to insert at least one record in a database; allocate at least an empty write set for the record corresponding to the at least one query, the row is allocated on basis of a row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0014] In contrast to the prior-art techniques, available if any, the present invention instead of using a pessimistic approach, the replicated records can be updated optimistically. In present invention no locks are obtained during actual operation. The actual conflict checking happens during the commit on the master side. So even though query succeeds in originator node, it can fail during commit.

[0015] Further, according to the present invention, during insert, one of the masters will be chosen as insert leader. The insert leader will allocate a range of row_id to the incoming query. If the query inserts more records than the range, it will be rolled back. During commit, the row_id range and the new records are sent to other replicas for conflict checking. The present invention is true for update query, wherein row_id can change for insert across different replicas.

[0016] The various options and preferred embodiments referred to above in relation to the first implementation are also applicable in relation to the other implementations.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

[0017] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

[0018] Figure 1 illustrates a system for multi-master replication, in accordance with an embodiment of the present subject matter.

[0019] Figure 2 illustrates a block diagram for database replication, in accordance with an embodiment of the present subject matter.

[0020] Figure 3 illustrates a method for multi-master replication, in accordance with an embodiment of the present subject matter.

[0021] It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

[0022] Illustrative embodiments will now be described more fully herein with reference to the accompanying drawings, in which exemplary embodiments are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of this disclosure to those skilled in the art. In the description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, the use of the terms “a”, “an”, etc., do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items. It will be further understood that the terms “comprises” and/or “comprising”, or “includes” and/or “including”, when used in this specification, specify the presence of stated features, regions, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, regions, integers, steps, operations, elements, components, and/or groups thereof.

[0024] In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0025] While aspects are described for system and method for multi-master synchronous replication optimization, the present invention may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, apparatus, and methods.

[0026] In one implementation, the present invention instead of using a pessimistic approach, the replicated records can be updated optimistically. The present invention does not use any locks i.e., locks are not obtained, during actual operation. Actual conflict checking happens during the commit on the replica side. So even though query succeeds in the originator node, it may fail during commit.

[0027] The present invention is also applicable for update query, whereas row_id may change for insert across different masters. During insert, one of the masters may be chosen as an insert leader. The insert leader may allocate a range of row_ids to the incoming query. If the query inserts more records than the range, it will be rolled back. During commit, the row id range and the new records are sent to other replica for conflict checking.

[0028] In one implementation, as compared to the existing replication operations, in the present invention, when a log is sent for the replication, it contains row_id of the record with the updated data. The row_id may be treated as a physical offset of the record from the 0th record of the table. Whenever the logs for a row_id are received, that row_id is marked as dirty, and update for the record corresponding to the row id is started. This update can be atomic operation and does not need any locks.

[0029] In one implementation, as compared to the existing operations during update on the originator node, in the present invention, during an update operation on the node, row_id of the specific record is marked as dirty. This may be an atomic operation. If the row_id is marked dirty already due to the replica update, the current update operation may fail at this stage. It can be seen obviously that in this implementation, conflict checking is moved to the commit time of the originator node.

[0030] In one implementation, as compared to the existing operations during commit, in the present invention, during commit of each transaction, a message is sent to all the replicas. Each of the replica checks for the conflict based row_id of the log sent by the originator node, and at least one row_id of current transactions in progress. If there is a conflict, they return an error to the originator node, and the transaction fails. If there is no conflict, both originator and the replica nodes apply the records in parallel. User may have to wait only till the record is applied in originator node to make sure that there are no more conflicts in the replicas.

[0031] Referring now to figure 1 a system for multi-master replication is illustrated, in accordance with an embodiment of the present subject matter. In one implementation, the system 100 comprises plurality of master devices holding replicated data and communicably coupled with each other. Referring now to figure 1, a system 100 for multi-master replication is disclosed, the system 100 comprises at least one first master device 102 and a first database 104 at a first replication site; and at least one second master device 106 and a second database 108 at a second replication site. Although the present subject matter is explained considering that the present invention is implemented in the first master device 102 and/or the second master device 106, it may be understood that the first master device 102 and/or the second master device 106 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the first master device 102 and/or the second master device 106 may be accessed by multiple users, or applications residing on the first master device 102 and/or the second master device 106. Examples of the first master device 102 and/or the second master device 106 may include, but are not limited to, a portable computer (computer system), a personal digital assistant, a handheld device, sensors, routers, gateways and a workstation. The first master device 102 and/or the second master device 106 are communicatively coupled to each other or other devices or nodes or apparatuses to form a network (not shown). Description of the second master device 106 is just the same as description of the first master device 102, the description of the first master device 106 can be referred to make the description of the second master device 106 clear, and the description of the second master device 106 is not repeated any more to avoid unnecessary confusion and complexities in understanding the present invention.

[0032] In one implementation, the network (not shown) may be a wireless network, a wired network or a combination thereof. The network can be implemented as one of the different types of networks, such as GSM, CDMA, LTE, UMTS, intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

[0033] The first master device 102 and/or the second master device 106 as illustrated in accordance with an embodiment of the present subject matter may include a processor (not shown), an interface (not shown), and a memory (not shown). The processor may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor is configured to fetch and execute computer-readable instructions or modules stored in the memory.

[0034] The interface (I/O interface) may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface may allow the first master device 102 and/or the second master device 106 to interact with a user directly. Further, the I/O interface may enable the first master device 102 and/or the second master device 106 to communicate with other devices or nodes, computing devices, such as web servers and external data servers (not shown). The I/O interface can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, GSM, CDMA, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface may include one or more ports for connecting a number of devices to one another or to another server. The I/O interface may provide interaction between the user and the first master device 102 and/or the second master device 106 via, a screen provided for the interface.

[0035] The memory may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM), and/or non-volatile random access memory (NVRAM), such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, or magnetic tapes. The memory may include plurality of instructions or modules or applications to perform various functionalities. The memory includes routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types.

[0036] In one implementation, a system 100 for multi-master replication is disclosed. The system 100 comprises at least one first master device 102 and a first database 104 at a first replication site, and at least one second master device 106 and a second database 108 at a second replication site.

[0037] In one implementation, a system for multi-master replication is disclosed. The system includes at least one first master device and at least one second master device, wherein the first master device has a first database and the second master device has a second database. The first master device is configured to receive at least one query; allocate at least one row from the first database to insert at least one record corresponding to the at least one query, wherein each of the at least one row comprise a distinct row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to the second master device for a conflict check. The second master device is configured to receive the row_id of the at least one row in the first database and the at least one record corresponding to the at least one query; and check the conflict based on the row_id and the at least one record corresponding to the at least one query, wherein if the conflict is not detected, insert the at least one record in at least a row of the second database, or if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database.

[0038] In one implementation, a first master device 102 is disclosed. The first master device 102 is configured to receive at least one query; allocate at least one row from the first database to insert at least one record corresponding to the at least one query, wherein each of the at least one row comprise a distinct row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0039] In one implementation, a second master device 106 is disclosed. The second master device 106 is configured to receive row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device 102, the first database is in the first master device; and check a conflict based on the row_id and the at least one record corresponding to the at least one query, wherein if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

[0040] In one implementation, after allocating the at least one row from the first database to insert the at least one record corresponding to the at least one query, the first master device is further configured to mark the at least one row in the first database dirty; and thereby insert the at least one record corresponding to the at least one query to the at least one row in the first database.

[0041] In one implementation, wherein after receiving the row_id of the at least one row and the at least one record corresponding to the at least one query, the second master device is further configured to: allocate the at least a row from the second database to insert the at least one record corresponding to the at least one query received, each of the at least one row comprises a distinct row_id; mark each of the at least a row in the second database dirty; check the conflict based on the row_id and the at least one record corresponding to the at least one query received with the at least a row in the second database; and thereby if the conflict is not detected, insert the at least one record corresponding to the at least one query in the at least a row in the second database marked dirty.

[0042] In one implementation, if the conflict is not detected, wherein the second master device is further configured to: detect the at least one row in the first database based on the row_id received for updating the at least one record corresponding to the at least one query; and check if the at least one row in the first database is marked dirty, wherein if the at least one row in the first database is marked dirty, updating of the at least one record corresponding to the at least one query is failed, or if the at least one row in the first database is not marked dirty, then the at least one record corresponding to the at least one query is updated in the at least one row in the first database.

[0043] In one implementation, upon updating the at least one record corresponding to the at least one query in the at least one row in the first database, the second master device is further configured to moving at least a conflict resolution to commit.

[0044] In one implementation, if the conflict is detected at the at least a row in the second database, the commit is stopped and the first master device is further configured to display an error.

[0045] In one implementation, whenever logs for a row_id are received, that row_id is marked as dirty, and update for the next record is started. This update may be an atomic operation and does not need any locks.

[0046] In one implementation, during an update operation on the node, row_id of the specific record is marked as dirty. If the row_id is marked dirty already due to the replica update, the current update operation fails at this stage. If the update of the record, in the current node succeeds, conflict resolution is moved to the commit time.

[0047] In one implementation, upon updating the next record in the row, moving at least a conflict resolution to commit.

[0048] In one implementation, a first master device having a first database is disclosed. The first master device is configured to receive at least one query; allocate at least one row from the first database to insert at least one record corresponding to the at least one query, wherein each of the at least one row comprise a distinct row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0049] In one implementation, after allocating the at least one row from the first database to insert at least one record corresponding to the at least one query. The first master device is configured to mark the at least one row in the first database dirty; and thereby insert the at least one record corresponding to the at least one query to the at least one row in the first database.

[0050] In one implementation, a second master device having a second database is disclosed. The second master device is configured to receive row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device, the first database is in the first master device; and check a conflict based on the row_id and the at least one record corresponding to the at least one query, wherein if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

[0051] In one implementation, after receiving the row_id and the record corresponding to the query. The second master device is further configured to allocate at least a row from the second database to insert the at least one record corresponding to the at least one query received, each of the at least one row comprise a distinct row_id; mark each of the at least a row in the second database dirty; check the conflict based on the row_id and the at least one record corresponding to the at least one query received with the at least a row in the second database; and thereby if the conflict is not detected, insert the at least one record corresponding to the at least one query in the at least a row in the second database marked dirty.

[0052] In one implementation, the second master device is further configured to detect the at least one row in the first database based on the row_id received for updating the at least one record corresponding to the at least one query; and check if the at least one row in the first database is marked dirty, wherein if the at least one row in the first database is marked dirty, updating of the at least one record corresponding to the at least one query is failed, or if the at least one row in the first database is not marked dirty, then the at least one record corresponding to the at least one query is updated in the at least one row in the first database.

[0053] In one implementation, upon updating the at least one record corresponding to the at least one query in the at least one row in the first database, the second master device is further configured to move at least a conflict resolution to commit.

[0054] In one implementation, there is disclosed a device comprising a processor, coupled to a memory, for executing a plurality of modules present in the memory, the processor on execution of the modules is configured to receive at least one query to insert at least one record in a database; allocate at least an empty write set for the record corresponding to the at least one query, the row is allocated on basis of a row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmit the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0055] Referring now to figure 2, a block diagram for database replication is illustrated, in accordance with an embodiment of the present subject matter. Consider two update queries (A, B) at application. An application flow controller, upon receipt of these queries, may realize that the queries are updating distinct ranges, even though they update the same table t1, and sends query A to Master1 and query B to Master2. The Master1 upon receiving query (A1), creates an empty write set, updates the table locally (A2), populates the write set and tries to commit (A3). During commit, it sends write set containing row_ids of the updated records to other masters (Master2 in this case). The Master2 upon the receipt of message from Master1, checks if there is any conflict for the records in a local storage on Master2, and sends the conflict check / resolution result to the originator node (Master1) as A5, If there is no conflict, the row is committed in Master2 before sending A5, i..e, the record is inserted in the row. Based on the results of conflict check, and if there is no conflict, the Master1 goes ahead and commits the records (A6) i.e., the record is inserted at the first database. Similar operations are done for other update (B) with Master2 being the originator node and Master1 as the replica.

[0056] Figure 3 illustrates a method for multi-master replication, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

[0057] The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the protection scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described system 100.

[0058] In one implementation, method, performed by at least one first primary device, for multi-master replication is disclosed.

[0059] At block 302, the first primary device receives at least one query instructing the insertion/update of a record in a particular row of the database.

[0060] At block 304, the first primary device initiates/starts a transaction for the query received.

[0061] At block 306, an empty write set considering a maximum number of records to be updated is allocated the first primary device for the transaction.

[0062] At block 308, the first primary device determines if the record to be updated has a conflict.

[0063] In one implementation, whenever a row has to be updated, that row_id is marked as dirty, and update for the next record is started. This update may be atomic operation and may not need any locks.

[0064] In one implementation, during an update operation on the node, row_id of the specific record is marked as dirty. This again can be atomic operation. If the row_id is marked dirty already due to the replica update, the current update operation fails at this stage. If the update of the record, in the current node succeeds, conflict resolution is moved to the commit time.

[0065] At block 310, the transaction is rolled back or information is transmitted to other replicas based on results in 308. In one implementation, during commit, if a size of the at least one row exceeds than or is equal to a size of the at least one record corresponding to the at least one query, then transmit the row_id of the at least one row and the at least one record corresponding to the at least one query to at least one second master device for a conflict check.

[0066] At block 312, if the conflict is detected at the row in the second database, the commit is stopped and an error is displayed on the first master device, the commit is at the first database and the second database. Optionally, if the conflict is not detected, the record is inserted at the first database and the second database simultaneously.

[0067] In one implementation, the method is a row (row_id) based multi-master replication.

[0068] In one implementation, a method of multi-master replication, performed by at least one first master device for multi-master replication is disclosed. The method includes receiving at least one query; allocating at least one row to insert at least one record corresponding to the at least one query, the row is allocated on basis of a row_id; and during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, transmitting the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

[0069] In one implementation, a method of multi-master replication, performed by at least one second master device for multi-master replication is disclosed. The method includes receiving row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device, the first database is in the first master device; and checking a conflict based on the row_id and the at least one record corresponding to the at least one query; wherein if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

[0070] Apart from what is explained above, the present invention also include the below mentioned advantages:
? The present invention increases scalability and throughput of the system because of optimistic concurrency based replication.
? The present invention provides a row id based multi master replication.

[0071] A person skilled in the art may understand that any known or new algorithms by be used for the implementation of the present invention. However, it is to be noted that, the present invention provides a method to be used during back up operation to achieve the above mentioned benefits and technical advancement irrespective of using any known or new algorithms.

[0072] A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present invention.

[0073] It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

[0074] In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0075] When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disc.

[0076] Although implementations for system and method for multi-master synchronous replication optimization have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of the system and method for multi-master synchronous replication optimization.
,CLAIMS:1. A system for multi-master replication, the system comprising:
at least one first master device and at least one second master device, the first master device has a first database and the second master device has a second database;
wherein the first master device is configured to:
receive at least one query;
allocate at least one row from the first database to insert at least one record corresponding to the at least one query, each of the at least one row comprise a distinct row_id;
transmit, during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, the row_id of the at least one row and the at least one record corresponding to the at least one query, to the second master device for a conflict check; and
wherein the second master device is configured to:
receive the row_id of the at least one row in the first database and the at least one record corresponding to the at least one query; and
check the conflict based on the row_id and the at least one record corresponding to the at least one query; and
if the conflict is not detected, insert the at least one record in at least a row of the second database; or
if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database.

2. The system as claimed in claim 1, wherein after allocating the at least one row from the first database to insert the at least one record corresponding to the at least one query, the first master device is further configured to:
mark the at least one row in the first database dirty; and thereby
insert the at least one record corresponding to the at least one query to the at least one row in the first database.

3. The system as claimed in claim 1, wherein after receiving the row_id of the at least one row and the at least one record corresponding to the at least one query, the second master device is further configured to:
allocate the at least a row from the second database to insert the at least one record corresponding to the at least one query received, each of the at least one row comprises a distinct row_id;
mark each of the at least a row in the second database dirty;
check the conflict based on the row_id and the at least one record corresponding to the at least one query received with the at least a row in the second database; and thereby
if the conflict is not detected, insert the at least one record corresponding to the at least one query in the at least a row in the second database marked dirty.

4. The system as claimed in claim 1, wherein if the conflict is not detected, the second master device is further configured to:
detect the at least one row in the first database based on the row_id received for updating the at least one record corresponding to the at least one query; and
check if the at least one row in the first database is marked dirty, wherein:
if the at least one row in the first database is marked dirty, updating of the at least one record corresponding to the at least one query is failed, or
if the at least one row in the first database is not marked dirty, then the at least one record corresponding to the at least one query is updated in the at least one row in the first database.

5. The system as claimed in any of claims 1-4, wherein upon updating the at least one record corresponding to the at least one query in the at least one row in the first database, the second master device is further configured to:
moving at least a conflict resolution to commit.

6. The system as claimed in any of claims 1-5, wherein if the conflict is detected at the at least a row in the second database, the commit is stopped and the first master device is further configured to display an error.

7. A first master device having a first database, the first master device is configured to:
receive at least one query;
allocate at least one row from the first database to insert at least one record corresponding to the at least one query, each of the at least one row comprise a distinct row_id;
transmit, during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

8. The first master device as claimed in claim 7, wherein after allocating the at least one row from the first database to insert at least one record corresponding to the at least one query, the first master device is configured to:
mark the at least one row in the first database dirty; and thereby
insert the at least one record corresponding to the at least one query to the at least one row in the first database.

9. A second master device having a second database, the second master device configured to:
receive row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device, the first database is in the first master device;
check a conflict based on the row_id and the at least one record corresponding to the at least one query; wherein:
if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or
if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

10. The second master device as claimed in claim 9, wherein after receiving the row_id and the record corresponding to the query, the second master device is further configured to:
allocate at least a row from the second database to insert the at least one record corresponding to the at least one query received, each of the at least one row comprise a distinct row_id;
mark each of the at least a row in the second database dirty;
check the conflict based on the row_id and the at least one record corresponding to the at least one query received with the at least a row in the second database; and thereby
if the conflict is not detected, insert the at least one record corresponding to the at least one query in the at least a row in the second database marked dirty.

11. The second master device as claimed in claim 9, wherein the second master device is further configured to:
detect the at least one row in the first database based on the row_id received for updating the at least one record corresponding to the at least one query; and
check if the at least one row in the first database is marked dirty, wherein:
if the at least one row in the first database is marked dirty, updating of the at least one record corresponding to the at least one query is failed, or
if the at least one row in the first database is not marked dirty, then the at least one record corresponding to the at least one query is updated in the at least one row in the first database.

12. The second master device as claimed in any of the preceding claims, wherein upon updating the at least one record corresponding to the at least one query in the at least one row in the first database, the second master device is further configured to:
move at least a conflict resolution to commit.

13. A method of multi-master replication, performed by at least one first master device for multi-master replication, the method comprising:
receiving at least one query;
allocating at least one row to insert at least one record corresponding to the at least one query, the row is allocated on basis of a row_id;
transmitting, during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.

14. The method as claimed in claim 13, wherein after allocating the at least one row, the method further comprises:
marking the at least one row in the first database dirty; and thereby
inserting the at least one record corresponding to the at least one query to the at least one row in the first database.

15. A method of multi-master replication, performed by at least one second master device for multi-master replication, the method comprising:
receiving row_id of at least one row in a first database and at least one record corresponding to at least one query from a first master device, the first database is in the first master device;
checking a conflict based on the row_id and the at least one record corresponding to the at least one query; wherein:
if the conflict is detected, commit is stopped, wherein the commit is at the first database and the second database; or
if the conflict is not detected, insert the at least one record in the at least the first database residing at the first master device and the second database simultaneously.

16. The method as claimed in claim 15, wherein after receiving the row_id and the record corresponding to the query, the method further comprising:
allocating at least a row from the second database to insert the at least one record corresponding to the at least one query received, each of the at least one row comprise a distinct row_id;
marking each of the at least a row in the second database dirty;
checking the conflict based on the row_id and the at least one record corresponding to the at least one query received with the at least a row in the second database; and thereby
if the conflict is not detected, inserting the at least one record corresponding to the at least one query in the at least a row in the second database marked dirty.

17. The method as claimed in claim 15, the method further comprising:
detecting the at least one row in the first database based on the row_id received for updating the at least one record corresponding to the at least one query; and
checking if the at least one row in the first database is marked dirty, wherein:
if the at least one row in the first database is marked dirty, updating of the at least one record corresponding to the at least one query is failed, or
if the at least one row in the first database is not marked dirty, then the at least one record corresponding to the at least one query is updated in the at least one row in the first database.

18. The method as claimed in any one of claims 15-17, wherein upon updating the at least one record corresponding to the at least one query in the at least one row in the first database, the method further comprising:
moving at least a conflict resolution to commit.

19. A device comprising processor, coupled to a memory, for executing a plurality of modules present in the memory, the processor on execution of the modules is configured to:
receive at least one query to insert at least one record in a database;
allocate at least an empty write set for the record corresponding to the at least one query, the row is allocated on basis of a row_id;
transmit, during commit, if a size of the at least one row from the first database is equal to or greater than a size of the at least one record corresponding to the at least one query, the row_id of the at least one row and the at least one record corresponding to the at least one query, to at least one second master device for a conflict check.