[This article was contributed by the SQL Azure team.]
You could be completely oblivious to the SQL Azure patching process and successfully use SQL Azure – however if you are curious here are some details. The Microsoft SQL Azure team is responsible for patching SQL Azure – you do not need to download, install, or worry about the availability of your data during patching. A SQL Server DBA usually has concerns when updating SQL Server, usually around successful installation and post installation data accessibility. We are going to try to address these concerns and how they relate to SQL Azure in this article.
SQL Azure is a completely fail-tolerant system designed to allow for rolling updates without interruption to the service. This means that when the updates are applied there is no interruption in your ability to access your data.
We apply two types of patches to SQL Azure, operating system updates and service updates. Both types of updates can cause an established SQL connection to be dropped. For this reason, and others, you need to make sure that your code is designed to try to reestablish a connection to SQL Azure and handle the connection pool correctly on connection loss. We will be following up with another blog post on how to accomplish this.
Operating System Patches
Operating system updates are updates to the underlying Windows operating system. They are the same as the operating system updates issued by Microsoft worldwide via Windows/Microsoft Update.
We regularly deploy operating system updates. Critical updates are given the highest priority and are deployed immediately.
Users of SQL Azure never notice these updates because their service is never interrupted (except for established SQL connections as mentioned before) and the updates do not cause a change in the SQL Azure feature set like service updates.
Service updates are patches, enhancements and bugs fixes applied directly to the SQL Azure platform running on top of Windows. Service updates enhance and provide additional features to the SQL Azure platform.
Data Loss from Updates
There is no risk for data or schema loss for either service updates or operating system updates.
There is no need to backup your data before a scheduled service update.
You trust us to keep your data safe and we take this trust very seriously.
Long before updates are deployed into production, our dedicated testing team extensively tests the updates and their deployment. We have many dedicated testing clusters and many servers to test deploy our service release. We don’t take chances on the production servers.
SQL Azure is designed to keep your data accessible across many different kinds of downtime events like hardware failures and power loss. Included in that design is the deployment of service updates in a rolling fashion to keep your data available.
SQL Azure always keeps three replicas running to protect your data in the event of a failover (a primary replica and two secondary replicas). We never reduce the replica count to update SQL Azure. When a rolling update happens, we signal all the replicas on the server that we want to update to failover to other servers in the datacenter. Once the replicas are safely running on other servers, we update the server and then put it back into production.
This is very different than the SQL Server production environments where SQL Server DBAs manage offline failover systems to update each server in turn. For example, a DBA with two SQL Servers with the same databases for redundancy will take one of them offline to update it – leaving themselves vulnerable to the remaining server failing during that time. With a larger budget these DBAs could replicate the redundancy features of SQL Azure by adding additional machines to handle failover during updates.
One of the great things about SQL Azure is we maintain our failover capabilities during updates and this is provided to as part of the service
Service updates do not update your data, and data availability over rolling service updates is guaranteed.
Service updates only add features to Transact SQL. This means if your transact-SQL is working on SQL Azure currently, it will continue to work after a service update. Additional features, syntaxes and semantics could be added to the language on a service update; however, none of these will affect the execution of your stored procedures or currently running queries. In other words, we will not break you code with a service update.
We want to be open about how we patch SQL Azure and welcome a thorough discussion. Do you have questions, concerns, comments? Post them below and we will address them.