Microsoft Technology Licensing, LLC

Sujit Vattathil Kuruvilla

Dharma Kiritkumar Shukla

Karthik Raman

Momin Mahmoud Al-Ghosien

Ji Huang

Shireesh Kumar Thota

Pankaj Sharma

Madhan Gajendran

Atul Katiyar

Ankur Savailal Shah

Shreshth Singhal

Ovidiu Constantin Platon

Bhalakumaaran Erode Ranganathan

Mikhail Mikhailovich Koltachev

Digvijaysinh Govindbhai Makwana

Subramanyam Pattipaka

Arsalan Ahmad

Hari Sudan Sundar

Hemant Kumar

Liang Li

Rajeev Sudhakar Bhopi

Kiran Kumar Kolli

Padma Priya Aradhyula Bhavani

Junyan Guo

Venkata Sivaramakrishna Ramadugu

Mohammad Derakhshani

Denis Rystsov

Swarnim Vyas

A server set for a data set may designate a subset of 'master' servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Merging conflict resolution for multi-master distributed databases

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Multi-master architectures for distributed databases

Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Conflict resolution for multi-master distributed databases

Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result. The transaction may also be applied over collections of replica sets using a second-level quorum to achieve nested consensus.

Resource-governed protocol and runtime for distributed databases with consistency models

Data services are often provided with consistency guarantees of either strong consistency models, comprising uniform wall-clock consistency, or eventual consistency models, where temporary logical inconsistency is guaranteed to be resolved only after full data propagation. However, the performance characteristics of contemporary services often require an intermediate consistency model, where some aspects of the service have specific consistency expectations and other aspects of the service are flexible, such as bounded staleness (e.g., a maximum delay in reaching consistency); session consistency (e.g., individual sessions remain logically consistent, but ordering may vary across sessions); and prefix consistency (e.g., each view during a session is logically consistent, but ordering may vary between session views). Service guarantees may involve a selection within a range of consistency models that includes one or more intermediate consistency levels, and server configurations may be selected and applied to fulfill the intermediate consistency level selected in the service level agreement.

Intermediate consistency levels for database configuration

Growing community of inventors

Redmond, WA, United States of America

Sujit Vattathil Kuruvilla