Jul 17, 2018 8:20:00 AM by Denny Cherry
A really great feature in Azure SQL DB went GA today. That feature gives you and SQL DB the ability to automatically fail databases over to a Secondary replia, without having to configure your application to handle that failover. You point your application at a VIP and that VIP will automatically handle failover of the resource.
Say for example you have a database in US West named db1-west.database.windows.net and the DR copy of it in US East named db1-east.database.windows.net. This feature lets you create the VIP db1-vip.database.windows.net which automatically points to whichever database is currently active. In the event of a failover of US West, the VIP is going to failover to the database in US East, the database in US East become writable and when the US West is back up, the data will sync back.
Another cool thing which this feature does is something that most features won’t do, it’ll trigger a failover that allows for data loss. Now, this normally would be a very dangerous thing, but the Azure team has come up with a safe way of doing it. When you figure the service to do the failover, you decide how long you want to wait for there to be no data loss. If you want the system back up as soon as it allows for, select the smallest number, otherwise select a larger number. This allows you, and the business unit that you support, to decide what level of protection you want to have built into the system.
If you are thinking about moving to PaaS, not being able to have a DR option may have been stopping you. This is no longer a blocking point, you now have an easy to configure DR, that you can manually failover is need be.
Tags: SQL Server
Written by Denny Cherry
I am a Senior SQL Server DBA at CDW with 10 years of IT experience, mostly as a software developer building web and windows based applications (VB, VB.NET, C#, C++ and a smidge of Java). I have always found database design and set based logic interesting, so 3 years ago I took the plunge and became a DBA, soon after I discovered people would tell anyone who would listen all about the SQL Server internals. I was hooked. I have not looked back since. The things I say represent my opinion and in no way represent the views or opinions of my employer or coworkers.