CODEWITHSUNDEEP
azureazure-sql-databaseazure-service-fabricfailover
MikeS
MikeS

Reputation: 1764

Implementing database failover in Azure Service Fabric

My company's application experienced database connection issues this morning resulting in me having to failover to our secondary database. Within our Azure App Services, this was an easy step of changing the connection string in the configuration, however I could not find an easy way of changing these settings on our Service Fabric services without redeploying.

I'm considering options to allow failover at runtime for these services to a secondary database but don't know what the 'best practices' would be. A couple options I have:

  1. I could create a dns entry for our database server that i manage and then just switch that to the new server name when I need to fail over.

  2. I could have some sort of rest api to call on my app services that would return whether or not to go to the secondary database.

Any other ideas? I'd like to make failover to the secondary as seamless as possible so it can be done quickly.

Upvotes: 1

Views: 231

Answers (2)

MikeS
MikeS

Reputation: 1764

Just to post an update to my issue here. SQL Azure now has automatic failover groups. This is described here

Upvotes: 0

Vaclav Turecek
Vaclav Turecek

Reputation: 9050

Have you considered putting both your primary and secondary database connection strings into your application's config and writing some code that automatically switches between them if it detects a problem? Both of the options you presented puts a human in the path, which means your users are going to experience downtime until the human fixes the problem (maybe the human is asleep, or on vacation, or on vacation and asleep).

In Service Fabric, Application (and system) upgrades are always rolling upgrades. Rolling upgrades have the advantage of preventing global outages. For example, suppose at some point you updated your config with the wrong connection string. A global config change might be quick and easy, but now you have a global outage and some upset customers. A rolling upgrade would have caught the error in the first upgrade domain and then rolled back, so only a fraction of your application would have been affected.

You can do a config-only rolling upgrade. This is where you make a change to your config package and then create a differential upgrade package so that only the config changes go out and your service process doesn't have to restart.

Upvotes: 1

Related Questions