Recovery in Multitenant Applications:

 

This is a continuation of the detailed article on Azure Monitor and Azure Monitor Logs.  Azure Monitor and Azure Monitor Logs are different services and Logs are incredibly useful for troubleshooting and notifications.

This article talks about Recovery

The example used here is a full disaster recovery scenario for a multitenant SaaS application implemented with the database per tenant model. In this case, a geo-restore can be used to recover the catalog and tenant databases from automatically maintained geo-redundant backups into an alternate recovery region. After the outage is resolved, georeplicate can be used to repatriate the changed databases to their original region.

Geo-restore is about recovering any database from a backup in Azure SQL Database, including Hyperscale databases. We can restore a database from a backup in Azure SQL Managed Instance.

Backups can also be taken on a scheduled basis and this helps to protect databases from user and application errors, accidental database deletion, and prolonged outages. This built-in capability is available for all service tiers and compute sizes of Azure SQL Managed instances. The automated recovery helps in these cases: 1. Recovering to a specific point in time within the retention period, 2. Recovering to the deletion time for a deleted database. 3. Recovering to the time of a recent backup and 4. Recovering to the point of the most recent replicated backups.

If Long-term retention is configured, even the long-term retention backup can be used to restore databases.

Several factors affect the recovery time. These include: the size of the database, the compute size of the database, the number of transaction logs involved, the amount of activity that needs to be replayed to recover to the restore point, the network bandwidth if restoring to a different region, the number of concurrent restore requests that are processed in the target region.

GeoReplication helps to create a continuously synchronized readable secondary database for a primary database. It is preferable although not required to have the secondary database in a different region. Since this kind of secondary database is merely readable, it is called a georeplica. This option serves to perform quick recovery of individual databases in case of a regional disaster or a large-scale outage. Once georeplication is setup, a geo-failover helps maintain continuity of business. It can be initiated programmatically or manually. If a stable connection endpoint is required with automatic geo-failover, an Auto-failover group can be used. It provides endpoint redirection. Auto-failover groups provide read-write and read-only listener endpoints. The connection string for the application does not change.