Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server

SQL Server 2022 :

SQL Server 2019 :

SQL Server 2017 :

SQL Server 2016: Enterprise Edition version 13.00.5216.0 et supérieure

SQL Server 2019 : Standard Edition version 15.00.4043.16

SQL Server 2017 : Standard Edition et Enterprise Edition

SQL Server 2016 : Standard Edition et Enterprise Edition

SQL Server 2014 : Standard Edition et Enterprise Edition

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 déploiement multi-AZ avec les groupes de disponibilité Always On prend en charge l'optimisation en mémoire.

Le déploiement multi-AZ avec les groupes de disponibilité Always On ne prend pas en charge l'authentification Kerberos pour l'écouteur du groupe 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 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.

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 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.

Le Multi-AZ avec DBM ou AG prend en charge un réplica de secours unique.

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 les AG Always On pour les déploiements Multi-AZ.

Dans les déploiements multi-AZ, RDS pour 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 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 plus d’informations, consultez 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 entre toutes les zones de disponibilité de la AWS région donnée.

Pour optimiser les performances, n'activez pas la mise en miroir ou les groupes de disponibilité Always On pendant une opération de chargement d'un volume important de données. 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]