Notes, limitations et recommandations concernant le déploiement multi-AZ de Microsoft SQL Server

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é. En effet, l'écouteur ne possède pas de nom de principal de service (SPN).

Vous ne pouvez pas renommer une base de données sur une instance de base de données SQL Server située dans un déploiement multi-AZ SQL Server. 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 SQL Server Agent.

Si vous avez besoin d'une limite plus élevée, demandez une augmentation en contactant 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 SQL Server faisant partie d'un déploiement SQL Server Multi-AZ.

RDS pour SQL Server ne réplique pas les autorisations de base de données MSDB sur l'instance secondaire. Si vous avez besoin de ces autorisations sur l'instance secondaire, vous devez les recréer manuellement.

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'opération d'API DescribeDBInstances en tant qu'entrée dans le champ des points de terminaison.

Amazon RDS prend en charge les basculements à plusieurs sous-réseaux du groupe de disponibilité.

Pour utiliser les déploiements multi-AZ SQL Server avec une instance de base de données SQL Server 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. Affectez ensuite le groupe de sous-réseaux de base de données au réplica principal de l'instance de base de données SQL Server.

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. Si une base de données sur l'hôte principal bascule, toutes vos bases de données SQL Server 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 non sain.

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 pour SQL Server crée des connexions SQL Server pour autoriser Always On ou la mise en miroir de bases de données. AGs RDS crée des connexions selon le modèle suivant, db_<dbiResourceId>_node1_logindb_<dbiResourceId>_node2_login, et. db_<dbiResourceId>_witness_login

RDS for SQL Server crée un identifiant SQL Server pour autoriser l'accès aux répliques en lecture. RDS crée une connexion avec le modèle suivant,db_<readreplica_dbiResourceId>_node_login.

Dans les déploiements Multi-AZ, les tâches de l'agent SQL Server sont répliquées de l'hôte principal vers l'hôte secondaire lorsque la fonction 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 Server.

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 SQL Server, 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.

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

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 ont accès aux bases de données SQL Server doit disposer d'une gestion des exceptions qui identifie 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]