Limites, notes et recommandations relatives au déploiement multi-AZ de Microsoft SQL Server

Voici certaines limites liées à l'utilisation de déploiements multi-AZ sur des instances de base de données RDS de SQL serveur :

• Le Multi-AZ entre régions n'est pas pris en charge.

• L'arrêt d'une instance de base de données RDS for SQL Server dans un déploiement multi-AZ n'est pas pris en charge.

• Vous ne pouvez pas configurer l'instance de base de données secondaire pour accepter l'activité de lecture de base de données.

• Le mode Multi-AZ avec Always On Availability Groups (AGs) prend en charge l'optimisation en mémoire.

• Le mode Multi-AZ avec groupes de disponibilité Always On (AGs) ne prend pas en charge l'authentification Kerberos pour l'écouteur des groupes de disponibilité. Cela est dû au fait que l'écouteur n'a pas de nom principal de service (SPN).

• Vous ne pouvez pas renommer une base de données sur une instance de base de données de SQL serveur faisant partie d'un déploiement SQL Server Multi-AZ. Si vous devez renommer une base de données sur une telle instance, vous devez d'abord désactiver le déploiement multi-AZ pour l'instance de base de données, puis renommer la base de données. Réactivez ensuite le déploiement multi-AZ pour l'instance de base de données.

• Vous pouvez uniquement restaurer des instances de base de données multi-AZ sauvegardées en utilisant le modèle de récupération « Full ».

• Les déploiements multi-AZ sont limités à 10 000 tâches d'agent SQL serveur.

  Si vous avez besoin d'une limite plus élevée, demandez une augmentation en contactant AWS Support. Ouvrez la page du Centre AWS Support, connectez-vous si nécessaire, puis choisissez Create case (Créer une demande de support). Sélectionnez Service Limit increase (Augmentation des limites de service). Remplissez et envoyez le formulaire.

• Vous ne pouvez pas avoir de base de données hors ligne sur une instance de base de données de SQL serveur faisant l'objet d'un déploiement multiAZ de SQL serveurs.

Voici quelques remarques concernant l'utilisation de déploiements multi-AZ sur des instances de base de données RDS de SQL serveur :

• Amazon RDS expose le point de terminaison Always On AGs Availability Group Listener. Le point de terminaison est visible dans la console et est renvoyé par l'DescribeDBInstancesAPIopération sous forme d'entrée dans le champ points de terminaison.

• Amazon RDS prend en charge les basculements multisous-réseaux entre groupes de disponibilité.

• Pour utiliser SQL Server Multi-AZ avec une instance de base de données de SQL serveur dans un cloud privé virtuel (VPC), créez d'abord un groupe de sous-réseaux de base de données comportant des sous-réseaux dans au moins deux zones de disponibilité distinctes. Attribuez ensuite le groupe de sous-réseaux de base de données à la réplique principale de l'instance de base de données SQL du serveur.

• Quand une instance de base de données est transformée en déploiement multi-AZ, pendant la modification, son état est modifying (modification). Amazon RDS crée l'instance de secours et effectue une sauvegarde de l'instance de base de données principale. Une fois le processus terminé, le statut de l'instance de base de données principale devient disponible.

• Les déploiements Multi-AZ maintiennent toutes les bases de données sur le même nœud. En cas de défaillance d'une base de données sur l'hôte principal, toutes les bases de données de votre SQL serveur basculent en tant qu'unité atomique vers votre hôte de secours. Amazon RDS approvisionne un nouvel hôte sain et remplace l'hôte défaillant.

• Multi-AZ avec DBM ou AGs prend en charge une seule réplique de secours.

• Les utilisateurs, les ID de connexion et les autorisations sont automatiquement répliqués pour vous sur l'instance secondaire. Vous n'avez pas besoin de les recréer. Les rôles de serveur définis par l'utilisateur ne sont répliqués que dans les instances de base de données qui utilisent Always On AGs pour les déploiements multi-AZ.

• Dans les déploiements multi-AZ, RDS for SQL Server crée des connexions au serveur pour autoriser SQL Always On AGs ou la mise en miroir de bases de données. RDScrée des connexions avec le modèle suivant, db_<dbiResourceId>_node1_logindb_<dbiResourceId>_node2_login, etdb_<dbiResourceId>_witness_login.

• RDSfor SQL Server crée un identifiant de connexion au SQL serveur pour autoriser l'accès aux répliques en lecture. RDScrée un identifiant avec le modèle suivant,db_<readreplica_dbiResourceId>_node_login.

• Dans les déploiements multi-AZ, les tâches de l'agent SQL serveur sont répliquées de l'hôte principal vers l'hôte secondaire lorsque la fonctionnalité de réplication des tâches est activée. Pour de plus amples informations, veuillez consulter Activation de la réplication des tâches de l'agent SQL serveur.

• Il est possible que vous observiez des temps de latence élevés par rapport à un déploiement d'instance de base de données standard (dans une zone de disponibilité unique) en raison de la réplication synchrone des données.

• Les délais de basculement sont affectés par le temps nécessaire à la réalisation du processus de récupération. Le délai de basculement est allongé pour les transactions de volume important.

• Dans les déploiements multi-AZ de SQL serveurs, le redémarrage avec basculement redémarre uniquement l'instance de base de données principale. Après le basculement, l'instance de base de données principale devient la nouvelle instance de base de données secondaire. Les paramètres peuvent ne pas être mis à jour pour les instances multi-AZ. Pour le redémarrage sans basculement, les instances de base de données principale et secondaire redémarrent, et les paramètres sont mis à jour après le redémarrage. Si l'instance de base de données ne répond pas, nous vous recommandons de procéder à un redémarrage sans basculement.

Voici quelques recommandations relatives à l'utilisation de déploiements multi-AZ sur des instances de base de données RDS Microsoft SQL Server :

• Pour les bases de données utilisées en production ou préproduction, nous vous recommandons les options suivantes :

  • Déploiements multi-AZ pour une haute disponibilité

  • « Provisionné IOPS » pour des performances rapides et constantes

  • « Mémoire optimisée » plutôt que « Usage général »

• Vous ne pouvez pas sélectionner la zone de disponibilité (AZ) pour l'instance secondaire. Tenez-en compte lorsque vous déployez les hôtes d'application. Votre base de données peut basculer vers une autre zone de disponibilité et les hôtes d'application peuvent ne pas se trouver dans la même zone de disponibilité que la base de données. Pour cette raison, nous vous recommandons d'équilibrer les hôtes de vos applications AZs dans l'ensemble de la AWS région donnée.

• Pour de meilleures performances, n'activez pas la mise en miroir de base de données ou Always On AGs lors d'une opération de chargement de données volumineuse. Pour optimiser la vitesse de chargement de vos données, terminez le chargement des données avant de convertir votre instance de base de données en déploiement multi-AZ.

• Les applications qui accèdent aux bases de données du SQL serveur doivent disposer d'un système de gestion des exceptions capable de détecter les erreurs de connexion. L'exemple de code suivant illustre un bloc try/catch qui identifie une erreur de communication. Dans cet exemple, l'instruction break quitte la boucle while si la connexion réussit, mais relance jusqu'à 10 tentatives si une exception est déclenchée.

  int RetryMaxAttempts = 10;
  int RetryIntervalPeriodInSeconds = 1;
  int iRetryCount = 0;
  while (iRetryCount < RetryMaxAttempts)
  {
     using (SqlConnection connection = new SqlConnection(DatabaseConnString))
     {
        using (SqlCommand command = connection.CreateCommand())
        {
           command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
           try
           {
              connection.Open();
              command.ExecuteNonQuery();
              break;
           }
           catch (Exception ex) 
           {
              Logger(ex.Message);
              iRetryCount++;
           }
           finally {
              connection.Close();
           }
        }
     }
     Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
  }

• N'utilisez pas la commande Set Partner Off lorsque vous travaillez avec des instances multi-AZ. Par exemple, n'effectuez pas les opérations suivantes :

  --Don't do this
  ALTER DATABASE db1 SET PARTNER off   
  

• Ne définissez pas le mode de récupération sur simple. Par exemple, n'effectuez pas les opérations suivantes :

  --Don't do this
  ALTER DATABASE db1 SET RECOVERY simple   
  

• N'utilisez pas le paramètre DEFAULT_DATABASE lors de la création de nouveaux ID de connexion sur des instances de bases de données multi-AZ car ces paramètres ne peuvent pas être appliqués au miroir de secours. Par exemple, n'effectuez pas les opérations suivantes :

  --Don't do this
  CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]   
  

  En outre, n'effectuez pas les opérations suivantes :

  --Don't do this
  ALTER LOGIN [test_dba] SET DEFAULT_DATABASE=[db3]