Partager via

Liste de contrôle haute disponibilité et récupération d'urgence - Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Le service Azure SQL Managed Instance 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 niveaux de service d’Azure SQL Managed Instance.

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 le SQL managed instance afin de garantir la résilience en cas de défaillance d'une zone.

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

Bien que Azure SQL Managed Instance 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 d'Azure SQL Managed Instance peut vous obliger à lancer une récupération d'urgence.

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

  • Activez les groupes de basculement pour une instance.
    • 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 à l'instance principale, quelle qu'elle soit.
    • Définissez la stratégie de basculement sur gérée par le client.
  • Vérifiez que l’instance géo-secondaire est créée avec le même niveau de service, la génération de matériel et la taille de calcul que l’instance principale.
  • 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 la région primaire et la région 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 n’est pas possible, envisagez de définir l’option de redondance du stockage de sauvegarde sur le stockage de sauvegarde géo-redondant 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 réussir une restauration vers une autre région de données à l'aide de groupes de basculement ou d'une géo-restauration, vous devez préparer une instance secondaire Azure SQL Managed Instance dans une autre région. Cette instance secondaire peut devenir la nouvelle instance principale 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 :

  • Pour la géo-restauration, identifiez l'instance dans une autre région pour qu'elle devienne la nouvelle instance primaire. Il s'agit généralement d'une instance dans la région jumelée à la région dans laquelle se trouve votre instance principale. L'utilisation d'une instance dans une région jumelée à la région primaire élimine le coût du trafic supplémentaire pendant les 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, la configuration du NSG et de la table de routage dont les utilisateurs ont besoin pour accéder à la nouvelle base de données primaire sur le nouveau 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.
  • Documentez la configuration de l'audit sur l'instance primaire actuelle et la rendre identique sur l'instance secondaire.

Contenu connexe

Pour en savoir plus, consultez :