Partager via

Exécution d’exercices de récupération d’urgence - Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Vous devez tester et valider régulièrement que les applications sont prêtes pour un flux de travail de récupération. La vérification du comportement de l'application et des implications en matière de pertes de données et/ou d'interruptions en cas de basculement constitue une bonne pratique d’ingénierie. Il s’agit également d’une exigence de la plupart des normes du secteur dans le cadre de la certification de continuité d’activité.

L'exécution d'un exercice de récupération d'urgence comprend :

  • la simulation d'une défaillance des couches de données
  • la récupération
  • la validation de l'intégrité des applications après la récupération
  • Revenir à l'instance d'origine (facultatif)

Le flux de travail à exécuter peut varier en fonction de la conception de votre application pour la continuité des activités. Cet article décrit les bonnes pratiques pour effectuer une récupération d'urgence après sinistre dans le contexte Azure SQL Managed Instance.

La géorestauration

Pour éviter toute perte potentielle de données lors d’un exercice de récupération d’urgence, effectuez la simulation dans un environnement de test en créant une copie de l’environnement de production et en l’utilisant pour vérifier le workflow de basculement de l’application.

Simulation d'une défaillance

Pour simuler la défaillance, vous pouvez renommer la base de données source. Ce changement de nom provoque des échecs de connexion d’application.

Récupération

Vérification

Complétez l'exercice en vérifiant l'intégrité de l'application après récupération (y compris les chaînes de connexion, les connexions, les tests de fonctionnalités de base ou d'autres validations faisant partie des procédures standard de validation d'application).

Effectuer une restauration automatique

Avec la géorestauration, la restauration automatique consiste à repointer l’application vers l’instance d’origine.

Groupes de basculement

Pour une instance protégée par des groupes de basculement, l'exercice consiste en un basculement planifié vers l'instance secondaire. Le basculement planifié garantit que les instances primaire et secondaire dans le groupe de basculement restent synchronisées quand les rôles sont permutés. Contrairement à la reprise après sinistre non planifiée, cette opération n’entraîne pas de perte de données, ce qui permet de réaliser la simulation dans un environnement de production.

Configurez votre groupe de basculement avec la stratégie de basculement qui correspond aux besoins de votre entreprise, et testez le basculement quelle que soit la configuration de votre stratégie de basculement. Pour plus d’informations, consultez tester le basculement. Il est recommandé d’utiliser une stratégie de basculement gérée par le client pour vous permettre de contrôler le processus de basculement.

Important

Les bases de données système n’étant pas répliquées entre les instances d’un groupe de basculement, recréez manuellement les objets système sur l’instance secondaire, puis testez les environnements dépendant des objets système pour vous assurer qu’ils continuent à fonctionner correctement après un basculement.

Simulation d'une défaillance

Pour simuler la défaillance, vous pouvez désactiver l’application web ou une machine virtuelle connectée à la base de données. Cette simulation de défaillance se traduit par des échecs de connectivité pour les clients web.

Récupération

  • Vérifiez que la configuration de l’application dans la région de récupération d’urgence pointe vers l’ancienne base de données secondaire qui devient la nouvelle base de données primaire entièrement accessible.
  • Lancez un basculement planifié du groupe de basculement sur l’instance secondaire.
  • Suivez le guide Configure a database after recovery pour effectuer la restauration.

Vérification

Terminez l’exercice en vérifiant l’intégrité de l’application après la récupération (notamment la connectivité, le test des fonctionnalités de base ou d’autres validations nécessaire pour les autorisations de l’exercice).

Effectuer une restauration automatique

Pour effectuer une restauration automatique, effectuez un basculement planifié du groupe de basculement vers l’instance principale d’origine. Étant donné que l’application est déjà configurée pour pointer vers le point de terminaison du groupe de basculement, aucune autre modification n’est nécessaire. Le point de terminaison du groupe de basculement achemine automatiquement le trafic vers la nouvelle instance principale après le basculement.

La restauration automatique est facultative. Si vous n’avez pas besoin de restaurer automatiquement, vous pouvez conserver l’instance secondaire comme nouvelle instance principale.

Il est possible d’utiliser un lien Managed Instance pour la récupération d’urgence.

Le basculement bidirectionnel est pris en charge uniquement entre :

SQL Server 2019 et versions antérieures prennent uniquement en charge le basculement unidirectionnel et la restauration automatique vers SQL Server n’est pas prise en charge.

Cette section explique comment effectuer une simulation de reprise après sinistre avec SQL Server 2022 ou SQL Server 2025. Lorsque vous utilisez un lien Managed Instance pour la récupération d’urgence, l’exercice d’extraction implique un basculement planifié vers l’instance secondaire. Le basculement planifié garantit que les instances primaires et secondaires dans le lien Managed Instance restent synchronisées lorsque les rôles sont basculés. Contrairement à la reprise après sinistre non planifiée, cette opération n’entraîne pas de perte de données, ce qui permet de réaliser la simulation dans un environnement de production.

Simulation d'une défaillance

Pour simuler la panne, désactivez les connexions des clients au réplica principal de la base de données répliquée par le biais d’un lien. Cette simulation de panne entraîne des défaillances de connectivité pour les clients de base de données (applications).

Récupération

Pour la récupération, procédez comme suit :

  1. Lancez un basculement de lien planifié vers l’instance secondaire.
  2. Repointez les applications impactées vers la nouvelle instance principale.

Vérification

Pour la validation, procédez comme suit :

  1. Effectuez des tests de connectivité d’application et de lecture/écriture sur la nouvelle instance principale.
  2. Si vous le souhaitez, vérifiez que les données de test écrites pendant l'exercice sont répliquées sur l'instance secondaire.

Effectuer une restauration automatique

Pour effectuer une restauration automatique, effectuez un basculement planifié du lien Managed Instance vers l’instance principale d’origine. Après le basculement, l’application doit être repointée vers l’instance principale d’origine.

La restauration automatique est facultative. Si vous n’avez pas besoin de restaurer automatiquement, vous pouvez conserver l’instance secondaire comme nouvelle instance principale.

Contenu connexe

Pour en savoir plus, consultez :

  • Last updated on