Microsoft Technology Licensing, LLC

Qun Guo

Rui Wang

Michael Habben

Ajay Kalhan

Robin Dhananjay Dhamankar

Peter Byrne

Shize Xu

Yixue Zhu

Xiaowei Jiang

Richard W Tom

Kaushik Choudhury

Pradeep Mani

Tomas Talius

Pankaj Arora

Peter Alan Carlin

Artem A Oks

Willis Lang

Dennis Tighe

Vishal Kathuria

Mahesh K Sreenivas

Karthik Saligrama Ramachandra

Peng Song

Leigh M Stewart

David Johns DeWitt

Gopal Ashok

Managing databases implemented in a cloud computing environment. A method includes detecting that a database implemented in the cloud computing environment is in a state of non-use. The method further includes as a result of detecting that a database implemented in the cloud computing environment is in a state of non-use, instantiating a workload in the cloud computing environment to deactivate the database. The workload is configured to store metadata for the database and database data remotely in cloud storage such that the database can be reactivated at a later time.

Dynamic deactivation of cold database in database service

Managing cluster resources for a cluster. The method includes identifying a plurality of quiescence policies. Each of the quiescence policies define one or more conditions for cluster entities which when met, identify that cluster resources should be reclaimed from cluster entities by quiescing cluster entities. The method further includes, for each quiescence policy, identifying an amount of reclaimed capacity defining the amount of cluster resources that will be reclaimed by implementing the quiescence policy. The method further includes, for each quiescence policy, identifying an amount of reserve capacity defining the amount of cluster resources that should be reserved for resuming quiesced cluster entities. The method further includes; selecting a quiescence policy based on comparing the reclaimed capacities and reserve capacities for the quiescence policies. The method further includes, booking cluster resources for cluster entities on the cluster according to the selected quiescence policy.

Modeling and forecasting reserve capacity for overbooked clusters

Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Dynamically varying the number of database replicas

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

Systems and methods that supply changes on-the-fly and without breaking execution of codes for schema changes in a peer-to-peer environment. The modification component supplies changes to peers or nodes in a topology by initially identifying dependencies (e.g., multiple level) that can be affected by the schema change, followed by performing the schema change to the codes or stored procedures. Accordingly, dependencies in an entire system can be refreshed, wherein multiple levels of dependencies can exist.

Multiphase topology-wide code modifications for peer-to-peer systems

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.

System and method of distributing replication commands

A well-known transactions feature in data replication that takes the 'last seen' transaction watermark, stores the watermark for each source in a topology, and tags each transaction with information associated with its origin. The tagged data is called Originator Information, and contains, but is not limited to, information on the originating server, originating database, and the originating transaction. This technology provides users with a method to scale out (keep more than two nodes in synchronism with updates at all nodes), increase availability of data during limited network failures (multiple replication pathways), and improve recovery strategies (redeliver transactions upon restore).

Growing community of inventors

Bellevue, WA, United States of America

Qun Guo