Liste de contrôle haute disponibilité et récupération d'urgence - base de données Azure SQL

S’applique à : Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

Le service base de données Azure SQL garantit automatiquement que toutes les bases de données sont en ligne, saines et s’efforce constamment d’atteindre le SLA publié.

Ce guide fournit un examen détaillé des étapes proactives que vous pouvez prendre pour optimiser la disponibilité, garantir la récupération et préparer les pannes Azure. Ces conseils s’appliquent à tous les modèles d’achat et niveaux de service Azure SQL Database.

Liste de contrôle de disponibilité

Voici les configurations recommandées pour optimiser la disponibilité :

• Incorporez la logique de nouvelle tentative dans l’application pour gérer les erreurs temporaires.
• Tirez parti des fenêtres de maintenance pour rendre prévisibles et moins perturbants les événements de maintenance impactants.
• Testez la résilience face aux erreurs de l’application en déclenchant manuellement un basculement pour voir la résilience en action.

Liste de contrôle de haute disponibilité

Voici la configuration recommandée pour obtenir une haute disponibilité :

• Activez la redondance de zone lorsqu’elle est disponible pour la base de données ou le pool élastique pour garantir la résilience pour les défaillances d’une zone.

Liste de contrôle de la récupération d’urgence

Bien que la base de données Azure SQL conserve automatiquement la disponibilité, il existe des cas où même la haute disponibilité (redondance de zone) peut ne pas garantir la résilience car la panne impactante s’étend sur toute une région. Une panne régionale de la base de données Azure SQL peut vous obliger à lancer la récupération d'urgence.

Pour mieux préparer la récupération d’urgence, suivez ces recommandations :

• Activez des groupes de basculement pour un groupe de bases de données.
  • Utilisez les points d’écoute en lecture-écriture et en lecture seule dans votre chaîne de connexion d’application afin que les applications se connectent automatiquement au serveur et à la base de données primaires actuelle.
  • Définissez la stratégie de basculement sur gérée par le client.
• En alternative à l’activation des groupes de basculement, vous pouvez activer la géoréplication active pour disposer d’une base de données secondaire accessible en lecture dans une autre région Azure.
• Vérifiez que la base de données géosecondaire est créée avec le même niveau de service, le même niveau de calcul (approvisionné ou serverless) et la même taille de calcul (DTU ou vCores) que la base de données primaire.
• Lors du scale-up, commencez par la base de données géosecondaire, puis terminez par la base de données primaire.
• Lors du scale-down, inversez l’ordre : commencez par la base de données primaire, puis terminez par la base de données secondaire.
• La récupération d’urgence, par nature, est conçue pour utiliser la réplication asynchrone des données entre les régions primaire et secondaire. Pour classer par ordre de priorité la disponibilité des données par rapport à une latence de validation plus élevée, envisagez d’appeler la procédure stockée sp_wait_for_database_copy_sync immédiatement après la validation d’une transaction. L’appel de sp_wait_for_database_copy_sync bloque le thread appelant jusqu’à ce que la dernière transaction validée ait été transmise et renforcée dans le journal des transactions de la base de données secondaire.
• Surveillez le décalage par rapport à l’objectif de point de récupération (RPO) à travers l’utilisation de la colonne replication_lag_sec de la vue de gestion dynamique (DMV) sys.dm_geo_replication_link_status sur la base de données primaire. La vue de gestion dynamique (DMV) affiche le décalage en secondes entre les transactions validées sur la base de données primaire et les transactions renforcées dans le journal des transactions sur la base de données secondaire. Par exemple, supposons que le décalage est d’une seconde à un moment donné, si la base de données primaire est affectée par une panne et qu’un géobasculement est lancé à ce stade dans le temps, les transactions validées au cours de la dernière seconde sont perdues.
• Si l’activation des groupes de basculement ou de la géoréplication active n’est pas possible, envisagez de définir l’option de redondance du stockage de sauvegarde sur le stockage de sauvegarde géoredondant pour utiliser la fonctionnalité de géorestauration.
  • Cette option n’est pas disponible dans les régions sans jumelage de régions.
• Planifiez et exécutez fréquemment des exercices de récupération d’urgence pour être mieux préparé en cas de panne réelle.

Préparer le secondaire pour une panne

Pour réussir une récupération vers une autre région de données à l’aide de la géoréplication active, des groupes de basculement ou de la géorestauration, vous devez préparer un serveur logique de base de données Azure SQL secondaire dans une autre région. Ce serveur secondaire peut devenir le nouveau serveur principal si nécessaire. Vous devez également disposer d’étapes bien définies documentées et testées pour garantir une récupération fluide. Les étapes de préparation sont les suivantes :

• Identifiez un serveur dans une autre région qui deviendra le nouveau serveur principal. Il s’agit généralement d’un serveur dans la région jumelée de la région dans laquelle se trouve votre base de données primaire. L'utilisation d'un serveur dans une région jumelée au primaire élimine le surcoût du trafic lors des opérations de géo-restauration.
• Déterminez comment vous allez rediriger les utilisateurs vers le nouveau serveur principal. Vous pouvez rediriger les utilisateurs en modifiant manuellement les chaînes de connexion d’application ou les entrées DNS. Si vous avez configuré les groupes de basculement et que vous utilisez l’écouteur en lecture et en écriture et en lecture seule dans les chaînes de connexion de l’application, aucune autre action n’est nécessaire, car les connexions sont automatiquement dirigées vers la nouvelle instance primaire à la suite du basculement.
• Identifiez, et éventuellement définissez, les règles de pare-feu dont les utilisateurs ont besoin pour accéder à la nouvelle base de données primaire.
• Identifiez, et éventuellement créez, les connexions d’accès qui doivent être présentes dans la base de données master sur le nouveau serveur principal, puis vérifiez que ces connexions disposent des autorisations appropriées dans la base de données master, le cas échéant. Pour plus d’informations, consultez Sécurité Azure SQL Database après la récupération d’urgence.
• Identifiez les règles d’alerte qui doivent être mises à jour pour le mappage à la nouvelle base de données primaire.
• Documentez la configuration d’audit sur le serveur primaire actuel et la rendre identique sur le serveur secondaire.

Contenu connexe

• Évaluez l’aide sur la récupération d'urgence Azure SQL Database.
• Évaluez le SLA pour Azure SQL Database.
• Pour en savoir plus sur les sauvegardes automatisées d’une base de données Azure SQL, consultez Sauvegardes automatisées d’une base de données SQL.
• Pour en savoir plus sur la conception de la continuité des activités et les scénarios de récupération, consultez Scénarios de continuité.
• Pour en savoir plus sur l’utilisation des sauvegardes automatisées pour la récupération, consultez Restaurer une base de données à partir des sauvegardes initiées par le service.
• En savoir plus sur la géoréplication active.
• En savoir plus sur les groupes de basculement.
• En savoir plus sur la géorestauration.
• En savoir plus sur les bases de données avec redondance interzone.