Liste de vérification de haute disponibilité et de récupération d’urgence Azure SQL Database

  • Article

S’applique à Azure SQL Database

Le service Azure SQL Database garantit automatiquement que toutes les bases de données sont en ligne, saines et s’efforce constamment d’atteindre le contrat 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é :

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 vérification 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.
    • 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 de la 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.
  • 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 une récupération de succès dans 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 le 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 la même région élimine le coût du trafic supplémentaire pendant les opérations de géorestauration.
  • 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 nécessaires pour permettre aux utilisateurs d’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 de l’audit sur la base de données primaire actuelle.

Contenu connexe