Limites, remarques et recommandations relatives au Multi-AZ déploiement de Microsoft SQL Server

Cross-Region Multi-AZ 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.

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

Multi-AZ with Always On Availability Groups (AG) 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).

Multi-AZ avec réplication au niveau des blocs n'est actuellement prise en charge que pour les instances de SQL Server Web Edition.

Vous ne pouvez pas renommer une base de données sur une instance de base de données SQL Server faisant partie d'un Multi-AZ déploiement SQL Server. Si vous devez renommer une base de données sur une telle instance, désactivez d'abord l'instance de base Multi-AZ de données, puis renommez la base de données. Enfin, Multi-AZ réactivez l'instance de base de données.

Vous ne pouvez restaurer que les Multi-AZ instances de base de données sauvegardées à l'aide du modèle de restauration complète.

Multi-AZ les déploiements 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 qui est déployée dans le cadre d'un Multi-AZ déploiement de SQL Server.

Les métriques de volume ne sont pas disponibles pour l'hôte secondaire de l'instance utilisant la réplication au niveau des blocs.

Amazon RDS expose le point de terminaison de l'écouteur des groupes de disponibilité Always On. 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 SQL Server Multi-AZ 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.

Lorsqu'une instance de base de données est modifiée pour être un Multi-AZ déploiement, elle a le statut de modification pendant la 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.

Multi-AZ les déploiements 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, AG ou la réplication au niveau des blocs prend en charge une seule réplique de secours.

Lors Multi-AZ des déploiements, RDS for SQL Server crée des connexions SQL Server pour autoriser les AG Always On ou la mise en miroir de bases de données. RDS crée une connexion avec le modèle suivant, db_<dbiResourceId>_node1_login, db_<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éplicas en lecture. RDS crée une connexion avec le modèle suivant, db_<readreplica_dbiResourceId>_node_login.

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 Multi-AZ déploiements de 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 Multi-AZ les instances. 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 entre toutes les zones de disponibilité de la AWS région donnée.

Pour de meilleures performances, n'activez pas la mise en miroir de bases de données, les AG Always On ou la réplication au niveau des blocs lors d'une opération de chargement de données volumineuse. Si vous souhaitez que le chargement des données soit aussi rapide que possible, terminez le chargement des données avant de convertir votre instance de base de données en Multi-AZ déploiement.

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 montre un try/catch bloc qui détecte 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 Set Partner Off commande lorsque vous travaillez avec des Multi-AZ instances utilisant DBM ou AG. Cette commande n'est pas prise en charge sur les instances utilisant la réplication au niveau des blocs. 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 DEFAULT_DATABASE paramètre lors de la création de nouvelles connexions sur des Multi-AZ instances de base de données, sauf si vous utilisez la réplication au niveau des blocs pour une haute disponibilité, 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] WITH DEFAULT_DATABASE=[db3]