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

Applies to :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’efforcent constamment d’atteindre le contrat SLA publié.

Ce guide fournit un examen détaillé des étapes proactives que vous pouvez effectuer pour optimiser la disponibilité, garantir la récupération et préparer les pannes de Azure. Cette aide s’applique à tous les niveaux de service de 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 après sinistre

Bien que Azure SQL Managed Instance maintienne automatiquement la disponibilité, il existe des cas où même une haute disponibilité (redondance de zone) ne garantit pas la résilience car la panne affecte toute une région. Une panne régionale Azure SQL Managed Instance peut nécessiter la reprise après sinistre.

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

  • Activez les groupes de basculement pour une instance.
    • Utilisez les points de terminaison d’écouteur en lecture-écriture et en lecture seule dans votre chaîne de connexion à l’application afin que les applications se connectent automatiquement à l’instance principale.
    • Réglez la stratégie de basculement 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.
  • Lorsque vous effectuez une montée en charge, commencez par étendre 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 DMV affiche le décalage en secondes entre les transactions validées sur la base de données principale et les transactions renforcées dans le journal des transactions sur la base de données secondaire. Par exemple, supposons que le délai soit d’une seconde à un moment donné, si le primaire est affecté par une panne et qu’un géo-basculement est déclenché à ce moment-là, les transactions engagées à la dernière seconde seront 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 système secondaire pour une panne

Pour effectuer une récupération avec succès dans une autre région de données Azure à l’aide de groupes de basculement ou de géorestauration, vous devez préparer une instance gérée Azure SQL secondaire 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. Si votre région primaire a une région jumelée, il est courant d’utiliser la région jumelée comme région secondaire. En procédant ainsi, vous réduisez généralement la latence des opérations de réplication et 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-écriture et en lecture seule dans les chaînes de connexion de l’application, aucune autre action n’est nécessaire, car les connexions seront automatiquement dirigées vers la nouvelle instance principale après le 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 SQL Server Audit sur le serveur principal actuel et faites-le identique sur l’instance secondaire.

Contenu connexe

Pour en savoir plus, consultez :

  • Last updated on