Microsoft Technology Licensing, LLC

Michael Habben

Qun Guo

Rui Wang

Robin Dhananjay Dhamankar

Peter Byrne

Yixue Zhu

Xiaowei Jiang

Artem A Oks

Vishal Kathuria

Mahesh K Sreenivas

Leigh M Stewart

A method for distributing one or more conflicting data changes. The method includes extracting data changes from the source site log, and applying the data changes to the destination site. The method then includes identifying one or more constraints for each data change and generating a hash value for each identified constraint. The method then dispatches the data changes into a plurality of streams based on the hash values. The hash values are used to identify conflicting data changes and determine how the data changes should be sent through the plurality of streams such that data changes are applied in parallel in the plurality of streams without violating any causal consistency constraints. The method then includes committing data changes in the plurality of streams to the destination site in a single transaction, creating a consistent transactional view.

Dispatching conflicting data changes

Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.

Logical replication in clustered database system with adaptive cloning

Aspects of the subject matter described herein relate to multi-log based replication. In aspects, database fragments are associated with different logs. Each change to a duplicated database record may be recorded in multiple logs. A history data structure is used to determine when duplication schemas are valid. A duplication schema indicates what database fragments duplicate one or more database records. For a particular time range, the duplication schema history is used to determine whether currently available logs include all changes. If multiple logs include the same change, one log may be selected to provide the change. Non-duplicative changes may be placed into a single data stream usable to update a remote database.

De-duplication and completeness in multi-log based replication

Aspects of the subject matter described herein relate to data change ordering in multi-log based replication. In aspects, local seeds are maintained for subtransactions involved in a transaction, where each subtransaction may occur on a different node that hosts one or more database fragments involved in the transaction. When a subtransaction communicates with another subtransaction in a transaction, the subtransaction sends its local seed to the other subtransaction. The receiving subtransaction compares its local seed with the received seed and updates its local seed if the received seed is logically after its local seed. A subtransaction uses a local seed to generate sequence identifiers for changes made by the subtransaction. These identifiers allow data changes of a transaction that are made on multiple nodes to be partially ordered relative to other changes made during the transaction.

Data change ordering in multi-log based replication

A transactional replication system wherein each replicated command applies to a single row as identified by the primary key, replicated commands are dispatched among multiple connections by hashing of primary key from a single command queue to ensure that changes to the same data row are always dispatched to the same connection to maintain the order of commands as originally occurred on publisher. All connections commit their transactions at the same time in a coordinated fashion without a two phase commit. Retry logic based on a logical sequence number is used to reapply commands from any connection that fails to commit.

Growing community of inventors

Sammamish, WA, United States of America

Michael Habben