Hi,
Thanks for posting here.
Typical scenarios of a planned failover event include:
- Redeployment of an application to a different geographical region.
- Creation of a copy of a database to start up new development.
- Creation of a temporary copy of a database during application upgrade.
Typical scenarios of an unplanned failover event include:
- Loss of the interlink connectivity between the datacenters.
- Prolonged loss of connectivity to the primary database or active secondary.
- Quorum loss on the primary database or active secondary.
- A datacenter-wide outage in the primary or secondary region.
For more information on designing disaster recovery solutions, see Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication
Refer: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Hope this helps you.
Girish Prajwal
- Marked as answer by Manu RekharMicrosoft contingent staff, Moderator Monday, January 26, 2015 5:58 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
Hi,
Thanks for posting here.
Typical scenarios of a planned failover event include:
- Redeployment of an application to a different geographical region.
- Creation of a copy of a database to start up new development.
- Creation of a temporary copy of a database during application upgrade.
Typical scenarios of an unplanned failover event include:
- Loss of the interlink connectivity between the datacenters.
- Prolonged loss of connectivity to the primary database or active secondary.
- Quorum loss on the primary database or active secondary.
- A datacenter-wide outage in the primary or secondary region.
For more information on designing disaster recovery solutions, see Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication
Refer: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Hope this helps you.
Girish Prajwal
- Marked as answer by Manu RekharMicrosoft contingent staff, Moderator Monday, January 26, 2015 5:58 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
Hi,
Thanks for posting here.
Typical scenarios of a planned failover event include:
- Redeployment of an application to a different geographical region.
- Creation of a copy of a database to start up new development.
- Creation of a temporary copy of a database during application upgrade.
Typical scenarios of an unplanned failover event include:
- Loss of the interlink connectivity between the datacenters.
- Prolonged loss of connectivity to the primary database or active secondary.
- Quorum loss on the primary database or active secondary.
- A datacenter-wide outage in the primary or secondary region.
For more information on designing disaster recovery solutions, see Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication
Refer: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Hope this helps you.
Girish Prajwal
- Marked as answer by Manu RekharMicrosoft contingent staff, Moderator Monday, January 26, 2015 5:58 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
Hi,
Thanks for posting here.
Typical scenarios of a planned failover event include:
- Redeployment of an application to a different geographical region.
- Creation of a copy of a database to start up new development.
- Creation of a temporary copy of a database during application upgrade.
Typical scenarios of an unplanned failover event include:
- Loss of the interlink connectivity between the datacenters.
- Prolonged loss of connectivity to the primary database or active secondary.
- Quorum loss on the primary database or active secondary.
- A datacenter-wide outage in the primary or secondary region.
For more information on designing disaster recovery solutions, see Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication
Refer: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Hope this helps you.
Girish Prajwal
- Marked as answer by Manu RekharMicrosoft contingent staff, Moderator Monday, January 26, 2015 5:58 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
Thanks a lot its very helpful!
Seems like there is no way to do an automatic failover between geo replicated dbs, and it has to be manual process?
Correct, failover is a manual task.
- Proposed as answer by Joseph IdziorekMicrosoft employee Saturday, January 24, 2015 7:27 PM
- Marked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
Correct, failover is a manual task.
- Proposed as answer by Joseph IdziorekMicrosoft employee Saturday, January 24, 2015 7:27 PM
- Marked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
Correct, failover is a manual task.
- Proposed as answer by Joseph IdziorekMicrosoft employee Saturday, January 24, 2015 7:27 PM
- Marked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
Correct, failover is a manual task.
- Proposed as answer by Joseph IdziorekMicrosoft employee Saturday, January 24, 2015 7:27 PM
- Marked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Unmarked as answer by kannu123 Tuesday, January 27, 2015 12:19 AM
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
So if we implement Traffic Manager for Failover in our Application can we automate the failover of the database?
Also is the SQL Server Alias feasible way to achieve this on the application end where we update the alias from SQL A to SQL B where SQL B is your failover server?
The execution of a Traffic Manager failover is independent of an Azure SQL Database failover. Based on your application's SLA and the application state, one could monitor the is_interlink_connected column of the sys.dm_database_copies or sys.dm_continuous_copy_status view [link] with an Azure Automation runbook [link] to programmatically invoke a failover with the Stop-AzureSqlDatabaseCopy cmdlet after the interlink connection has been down for a specified period of time.
For more guidance, please Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication.
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
The execution of a Traffic Manager failover is independent of an Azure SQL Database failover. Based on your application's SLA and the application state, one could monitor the is_interlink_connected column of the sys.dm_database_copies or sys.dm_continuous_copy_status view [link] with an Azure Automation runbook [link] to programmatically invoke a failover with the Stop-AzureSqlDatabaseCopy cmdlet after the interlink connection has been down for a specified period of time.
For more guidance, please Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication.
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
The execution of a Traffic Manager failover is independent of an Azure SQL Database failover. Based on your application's SLA and the application state, one could monitor the is_interlink_connected column of the sys.dm_database_copies or sys.dm_continuous_copy_status view [link] with an Azure Automation runbook [link] to programmatically invoke a failover with the Stop-AzureSqlDatabaseCopy cmdlet after the interlink connection has been down for a specified period of time.
For more guidance, please Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication.
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
The execution of a Traffic Manager failover is independent of an Azure SQL Database failover. Based on your application's SLA and the application state, one could monitor the is_interlink_connected column of the sys.dm_database_copies or sys.dm_continuous_copy_status view [link] with an Azure Automation runbook [link] to programmatically invoke a failover with the Stop-AzureSqlDatabaseCopy cmdlet after the interlink connection has been down for a specified period of time.
For more guidance, please Designing Cloud Solutions for Disaster Recovery Using Active Geo-Replication.
- Marked as answer by kannu123 Tuesday, January 27, 2015 7:27 AM
Does MSFT have plans to add automatic failover to Azure SQL?
One of the advantages of PaaS over Iaas is that high availability (99.99% SLA) is built into the service requiring zero configuration.
We understand your scenario and will continue to invest BCDR capabilities. Please stay tuned for more improvements in this space.


