1

I'm using active geo-replication on a production Azure SQL Database for failover scenario's. (https://learn.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview)

Soon we'll be performing an upgrade of our application that uses this database, and some DDL updates are required to the primary database, which leads to a few questions. Answers to any\all would be appreciated!

  1. Do I need to disable geo-replication to perform db updates against the primary?

  2. If I don't disable geo-replication, would the DDL statements performed against the primary automatically change the secondary db as well?

  3. When performing these updates, if we wanted to keep the "secondary" database around for a rollback scenario, I assume we can disable geo-replication to keep that database temporarily "stale". Is there a means to use that database as a restore point for the primary database?

ewitkows
  • 3,528
  • 3
  • 40
  • 62

1 Answers1

1
  1. No
  2. Yes, this is how it keeps an RPO < 5 seconds as per this link
  3. This is a complex question. Essentially, you could break the geo-replication and then perform the updates. If you need to switch to the secondary, you would simply need to update your connection strings and do that. Bringing the primary back in sync could be as simple as enabling geo-replication on the now primary and point it back to the old primary. Eventually you can switch the "primary" back to the old primary using this cmdlet. You can also do a geo-restore. Ultimately, you can also restore a snapshot of the primary database in the primary region and then fail to that one if something goes wrong. Re-enable geo-replication as required after that.
CtrlDot
  • 2,463
  • 14
  • 11
  • Is #3 also essentially the process when you have failed over to a secondary due to primary outtage, and then when the primary comes back up you need to bring it back in sync? – AaronLS Dec 15 '18 at 19:53
  • That should happen automatically – CtrlDot Dec 15 '18 at 20:11