Abstract: A data processing system implements techniques for operating and recovering databases that includes a plurality of replicas. The plurality of replicas includes a primary replica, a secondary replica, and a delta replica. The primary replica handles read and write operations, the secondary replica is a backup of the primary replica capable of read-only operations. The delta replica comprising a copy of the transactional log information of the primary replica but not the data. The system detects a failure of the primary and secondary replicas. The system instantiates a recovery workflow using the delta replica that includes initializing a second secondary replica; causing the second secondary replica to download backup data that represents a state of the primary replica prior to failure of the primary replica; updating the secondary replica using the backup data; and promoting the secondary replica to the primary replica.

Abstract: A data processing system implements techniques for provisioning and operating databases including receiving a request to provision a new database that includes multiple replicas. The data processing system provisions the new database including the plurality of replicas. The plurality of replicas includes a primary replica, one or more secondary replicas, and one or more delta replicas. The primary replica is configured to handle read and write operations. The one or more secondary replicas include a copy of data and transactional log information of the primary replica and are unable to handle write operations. The one or more delta replicas are a copy of the transactional log information of the primary replica and are unable to handle read operations or write operations.

Abstract: Reliable feature deployment is provided. Features are evaluated for their readiness to be graduated and features that are ready to be graduated are added to a graduation list. When features are added to the graduation list, evaluation of the features is discontinued, thereby reducing the performance and runtime costs associated with deploying features. Furthermore, engineers can consult the graduation list to identify features that are ready for graduation, thereby reducing the risk of premature flight graduation. Data associated with features is analyzed to map the features to corresponding flights. In this way, when an engineer identifies a feature for graduation, the engineer is able to identify the corresponding flight (or flights) from the mapping. Even when a feature is selected for graduation, the present systems provide additional safeguards to ensure that corresponding flights are not improperly or prematurely graduated, thereby preventing a subpar customer experience.

Abstract: A data processing system implements techniques for provisioning and operating databases including receiving a request to provision a new database that includes multiple replicas. The data processing system provisions the new database including the plurality of replicas. The plurality of replicas includes a primary replica, one or more secondary replicas, and one or more delta replicas. The primary replica is configured to handle read and write operations. The one or more secondary replicas include a copy of data and transactional log information of the primary replica and are unable to handle write operations. The one or more delta replicas are a copy of the transactional log information of the primary replica and are unable to handle read operations or write operations.

Abstract: A system for persistently storing metadata associated with a backup of data in a source database. The system includes a cloud storage system and a source database. The source database includes a memory including data and a first electronic processor. The first electronic processor is configured to write a backup of the data included in the memory of the source database to the cloud storage system. The first electronic processor is also configured to write metadata associated with the backup of the data (“backup metadata”) to a table included in the memory of the source database. The backup metadata is used to retrieve the data when a target database is restored to a previous state of the source database.

Abstract: A computing system comprises a controller configured to detect a reassignment input to reassign all computing resources from a source server farm to a target server farm, a resource capacity reassignment component configured to incrementally reassign all of the computing resources from the source server farm to the target server farm, in a plurality of fixed increments, and a database move component configured to, after reassigning each fixed increment of the computing resources to the target server farm, move a set of databases, corresponding to a previously reassigned fixed increment of computing resources, from the source server farm to the target server farm, for servicing at the target server farm.

Abstract: The techniques disclosed herein enable systems to deploy upgrade events in a controlled manner to different resource units that provide a service utilizing predefined rollout policies. To deploy an upgrade event, a system determines a risk factor for the upgrade event and presents predefined rollout policies to a feature group for selection based on the risk factor. Upon selection of a rollout policy, the system can deploy the upgrade event according to parameters defined by the selected rollout policy. The system is further configured to analyze telemetry data received from the resource units to determine an updated risk factor and determine whether the updated risk factor crosses a risk factor threshold. If the updated risk factor crosses the threshold, the system can identify another rollout policy to replace the selected policy. In addition, the system can receive an override workflow request to expedite upgrade event deployment.

Abstract: Reliable feature deployment is provided. Features are evaluated for their readiness to be graduated and features that are ready to be graduated are added to a graduation list. When features are added to the graduation list, evaluation of the features is discontinued, thereby reducing the performance and runtime costs associated with deploying features. Furthermore, engineers can consult the graduation list to identify features that are ready for graduation, thereby reducing the risk of premature flight graduation. Data associated with features is analyzed to map the features to corresponding flights. In this way, when an engineer identifies a feature for graduation, the engineer is able to identify the corresponding flight (or flights) from the mapping. Even when a feature is selected for graduation, the present systems provide additional safeguards to ensure that corresponding flights are not improperly or prematurely graduated, thereby preventing a subpar customer experience.

Abstract: Issues may arise when customers that are highly engaged with application services do not receive reliable feature updates on a predictable schedule. For instance, releasing and updating features may burden cloud infrastructure and/or may not perform properly. Not only are unpredictable feature updates associated with inconsistent customer messaging and potential service disruptions, such unpredictable updates may cause a random end user experience and customer dissatisfaction with the product. The methods and systems address these issues by dynamically ranking tenants and distributing updates and releases to tenants with lower feature usage before distributing to tenants with higher feature usage. The ranking of the tenants may dynamically change based on current usage. In this way, higher ranked tenants receive access to new and updated features after additional regression testing.

Abstract: A request input indicative of a request to deploy computing resources in a target server farm is received, and a fixed increment of the computing resources to be removed from a source server farm and deployed in the target server farm is identified. The fixed increment of computing resources is removed from the source server farm, and deployed to the target server farm. Based on deploying the fixed increment of computing resources to the target server farm, it is determined whether the target server farm has deployed adequate resource capacity to service a fixed increment of databases. If so, the fixed increment of databases is moved from the source server farm to the target server farm, and, if not, additional computing resources is reassigned from the source server farm to the target server farm.

Abstract: In one embodiment, a network file management system 120 may use a persistent metadata store 410 and an access control list 420 to facilitate a batch rollout. The network file management system 120 may maintain a content database 312. A network file management system 120 may store a metadata set for the content database 312 in a separate persistent metadata store 410.

Abstract: A computing system comprises a controller configured to detect a reassignment input to reassign all computing resources from a source server farm to a target server farm, a resource capacity reassignment component configured to incrementally reassign all of the computing resources from the source server farm to the target server farm, in a plurality of fixed increments, and a database move component configured to, after reassigning each fixed increment of the computing resources to the target server farm, move a set of databases, corresponding to a previously reassigned fixed increment of computing resources, from the source server farm to the target server farm, for servicing at the target server farm.

Abstract: A request input indicative of a request to deploy computing resources in a target server farm is received, and a fixed increment of the computing resources to be removed from a source server farm and deployed in the target server farm is identified. The fixed increment of computing resources is removed from the source server farm, and deployed to the target server farm. Based on deploying the fixed increment of computing resources to the target server farm, it is determined whether the target server farm has deployed adequate resource capacity to service a fixed increment of databases. If so, the fixed increment of databases is moved from the source server farm to the target server farm, and, if not, additional computing resources is reassigned from the source server farm to the target server farm.

Abstract: In order to upgrade a source farm to a target farm, the target farm is created with an initial increment of resource capacity that is a fraction of a final resource capacity of the target farm. A corresponding increment of the databases attached to the source farm are then switched from the source farm to the target farm. The resource capacity at the source farm, that was used to service the moved databases, is then removed from the source farm and added to the target farm, and another increment of the databases are switched from the source farm to the target farm. This continues until a full capacity of resources is deployed at the target farm, and the databases are fully moved from the source farm to the target farm.

Abstract: Technologies are described for updating a live system with static changes. According to some examples, changes such as installing and/or removing features may be applied to a cloud based service in live environment without disrupting the service. New software may be patched and installed on an upgraded machine (i.e., server). New features, diagnostics, and language packs may be added. Existing features and certificates may be removed. To accomplish these, new software to be installed and existing software to be removed may be detected. Removal and additions may be performed without preparation and activation of replacement farms.

Abstract: In one example, a server farm updater may schedule application of a software change to a server farm based on a farm temperature value representing a dynamically determined level of customer interaction with the server farm. A server farm updater may maintain a customer profile for the server farm describing a customer interaction with the server farm. The server farm updater may apply a farm temperature describing a server farm usage based on the customer profile. The server farm updater may apply the software change to the server farm based on the farm temperature.

Abstract: Disclosed herein are systems, methods, and software to enhance the upgrade process with respect to software service deployments. In at least one implementation, a user interface to an administrative portal for administering an initial deployment of a software service is presented and a notification that an upgrade is available is surfaced therein. In response to a selection of the notification in the user interface, upgrade controls are surfaced in the user interface for controlling a pace of the upgrade with respect to service components of the initial deployment. The upgrade is then applied incrementally to the service components based least in part on the pace of the upgrade specified via the upgrade controls.

Abstract: Technologies are described for updating a live system with static changes. According to some examples, changes such as installing and/or removing features may be applied to a cloud based service in live environment without disrupting the service. New software may be patched and installed on an upgraded machine (i.e., server). New features, diagnostics, and language packs may be added. Existing features and certificates may be removed. To accomplish these, new software to be installed and existing software to be removed may be detected. Removal and additions may be performed without preparation and activation of replacement farms.

Abstract: Disclosed herein are systems, methods, and software to enhance the upgrade process with respect to software service deployments. In at least one implementation, a user interface to an administrative portal for administering an initial deployment of a software service is presented and a notification that an upgrade is available is surfaced therein. In response to a selection of the notification in the user interface, upgrade controls are surfaced in the user interface for controlling a pace of the upgrade with respect to service components of the initial deployment. The upgrade is then applied incrementally to the service components based least in part on the pace of the upgrade specified via the upgrade controls.

Abstract: In order to upgrade a source farm to a target farm, the target farm is created with an initial increment of resource capacity that is a fraction of a final resource capacity of the target farm. A corresponding increment of the databases attached to the source farm are then switched from the source farm to the target farm. The resource capacity at the source farm, that was used to service the moved databases, is then removed from the source farm and added to the target farm, and another increment of the databases are switched from the source farm to the target farm. This continues until a full capacity of resources is deployed at the target farm, and the databases are fully moved from the source farm to the target farm.