Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server
<a name="USER_SQLServerMultiAZ"></a>

Les déploiements Multi-AZ améliorent la disponibilité, la durabilité des donnés et la tolérance aux pannes pour les instances de bases de données. En cas de maintenance planifiée de la base de données ou d'interruption de service imprévue, Amazon RDS bascule automatiquement vers l'instance de base de données up-to-date secondaire. Cette fonctionnalité permet aux opérations de la base de données de reprendre rapidement sans intervention manuelle. Les instances principales et de secours utilisent le même point de terminaison, l'adresse réseau physique de celui-ci étant transférée vers le réplica secondaire dans le cadre du processus de basculement. Vous n’avez pas à reconfigurer votre application lorsqu’un basculement se produit.

Amazon RDS prend en charge les déploiements multi-AZ pour Microsoft SQL Server en utilisant soit la mise en miroir de bases de données SQL Server (DBM), soit les groupes de disponibilité Always On (AGs), soit la réplication au niveau des blocs. Amazon RDS surveille et maintient l'état de votre déploiement Multi-AZ. En cas de survenue de problèmes, RDS répare automatiquement les instances de bases de données non saines, rétablit la synchronisation et démarre le basculement. Le basculement n'a lieu que si les instances de secours et principales sont parfaitement synchronisées. Vous ne devez rien gérer.

Lorsque vous configurez SQL Server Multi-AZ, RDS configure automatiquement toutes les bases de données de l'instance pour utiliser le DBM ou la réplication au niveau des AGs blocs. Amazon RDS gère pour vous l'instance de base de données principale, témoin et secondaire lorsque vous configurez DBM ou. AGs Pour la réplication au niveau des blocs, RDS gère les instances de base de données principales et secondaires. La configuration étant automatique, RDS sélectionne la réplication DBM, Always On AGs ou au niveau des blocs en fonction de la version de SQL Server que vous déployez.

Amazon RDS prend en charge le mode multi-AZ avec Always On AGs pour les versions et éditions de SQL Server suivantes :
+ SQL Server 2022 :
  + Standard Edition
  + Enterprise Edition
+ SQL Server 2019 :
  + Standard Edition 15.00.4073.23 et versions ultérieures
  + Enterprise Edition
+ SQL Server 2017 :
  + Standard Edition 14.00.3401.7 et versions ultérieures
  + Enterprise Edition 14.00.3049.1 et versions ultérieures
+ SQL Server 2016: Enterprise Edition version 13.00.5216.0 et supérieure

Amazon RDS prend en charge les déploiements Multi-AZ avec la mise en miroir (DBM) pour les versions et éditions suivantes de SQL Server, à l'exception des versions précédemment indiquées :
+ SQL Server 2019 : Standard Edition 15.00.4043.16
+ SQL Server 2017 : Standard Edition et Enterprise Edition
+ SQL Server 2016 : Standard Edition et Enterprise Edition 

Amazon RDS prend en charge le mode multi-AZ avec réplication au niveau des blocs pour SQL Server 2022 Web Edition 16.00.4215.2 et versions ultérieures.

**Note**  
Seules les nouvelles instances de base de données créées avec la version 16.00.4215.2 ou supérieure prennent en charge les déploiements multi-AZ avec réplication au niveau des blocs. Les restrictions suivantes s'appliquent aux instances existantes de SQL Server 2022 Web Edition :  
Pour les instances existantes sur la version 16.00.4215.2, vous devez restaurer un instantané sur une nouvelle instance avec la même version mineure ou une version ultérieure pour permettre la réplication au niveau des blocs.
Les instances Web de SQL Server 2022 dotées d'une ancienne version mineure peuvent être mises à niveau vers la version mineure 16.00.4215.2 ou supérieure pour permettre la réplication au niveau des blocs.

Vous pouvez utiliser la requête SQL suivante pour déterminer si votre instance de base de données SQL Server est mono-AZ, multi-AZ avec DBM ou multi-AZ avec Always On. AGs Cette requête ne s'applique pas aux déploiements multi-AZ sur SQL Server Web Edition.

```
SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
    WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
    ELSE 'Single-AZ'
    END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';
```

La sortie est semblable à la suivante :

```
high_availability
Multi-AZ (AlwaysOn)
```

## Ajout d'un déploiement multi-AZ à une instance de base de données Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Adding"></a>

Lorsque vous créez une nouvelle instance de base de données SQL Server à l'aide de AWS Management Console, vous pouvez ajouter le mode multi-AZ avec mise en miroir de base de données (DBM), Always On AGs ou la réplication au niveau des blocs. Pour ce faire, sélectionnez **Yes (Mirroring/Always On/Block Level Replication) dans Déploiement** **multi-AZ**. Pour de plus amples informations, veuillez consulter [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).

Lorsque vous modifiez une instance de base de données SQL Server existante à l'aide de la console, vous pouvez ajouter une réplication multi-AZ avec DBM AGs, ou une réplication au niveau des blocs en choisissant **Oui (mise en miroir/ Always On/Block Level Replication)** dans **Déploiement multi-AZ** sur la page **Modifier** l'instance de base de données. Pour de plus amples informations, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).

**Note**  
Si votre instance de base de données exécute la mise en miroir de bases de données (DBM), et non Always On Availability Groups (AGs), il se peut que vous deviez désactiver l'optimisation en mémoire avant d'ajouter Multi-AZ. Désactivez l’optimisation en mémoire avec la mise en miroir de bases de données avant d’ajouter un déploiement multi-AZ si votre instance de base de données exécute SQL Server 2016 ou 2017 Enterprise Edition et que l’optimisation en mémoire est activée.   
Si votre instance de base de données exécute AGs une réplication au niveau des blocs pour SQL Server Web Editions, cette étape n'est pas requise. 

## Suppression de Multi-AZ d'une instance de base de données Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Removing"></a>

Lorsque vous modifiez une instance de base de données SQL Server existante à l'aide de AWS Management Console, vous pouvez supprimer le mode multi-AZ avec DBM ou la réplication AGs au niveau des blocs. Vous pouvez le faire en choisissant **Non (mise en miroir/ Always On/Block Level Replication)** dans **Déploiement multi-AZ** sur la page **Modifier l'instance** de base de données. Pour de plus amples informations, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).

# Notes, limitations et recommandations concernant le déploiement multi-AZ de Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Recommendations"></a>

Voici quelques limitations lorsque vous travaillez avec des déploiements multi-AZ pour les instances de bases de données RDS for 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).
+ Le mode multi-AZ avec réplication au niveau des blocs n'est actuellement pris 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 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](https://console.aws.amazon.com/support/home#/), 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 une base de données hors ligne sur une instance de base de données SQL Server située dans un déploiement multi-AZ SQL Server.
+ RDS for 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.
+ 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.

Voici quelques notes sur l'utilisation des déploiements multi-AZ pour les instances de bases de données RDS for SQL Server :
+ Amazon RDS expose le point de terminaison Always On AGs [Availability Group Listener](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover). 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é](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover).
+ 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.
+ La réplication multi-AZ avec DBM AGs, ou réplication au niveau des blocs, 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 sont répliqués dans des instances de base de données qui utilisent la réplication Always On AGs ou au niveau des blocs 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 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`.
+ 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](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
+ 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.

Voici quelques recommandations sur l'utilisation des déploiements multi-AZ pour les instances de bases de données RDS for 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é
  + IOPS provisionnés pour des performances rapides et cohérentes
  + « 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 bases de données, Always On ou la réplication au niveau des blocs lors d'une opération de chargement de données importante. AGs 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 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 instances multi-AZ à l'aide de DBM ou. AGs 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 instances de base de données multi-AZ, 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]
  ```

# Détermination de l'emplacement du réplica secondaire
<a name="USER_SQLServerMultiAZ.Location"></a>

Vous pouvez déterminer l'emplacement du réplica secondaire à l'aide d AWS Management Console. Vous devez connaître l'emplacement du réplica secondaire si vous configurez votre instance de base de données principale dans un VPC. 

![\[Secondary AZ (zone de disponibilité pour réplica secondaire)\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/SQLSvr-MultiAZ.png)


Vous pouvez également afficher la zone de disponibilité du secondaire à l'aide de la AWS CLI commande `describe-db-instances` ou de l'opération `DescribeDBInstances` de l'API RDS. Le résultat indique la zone de disponibilité secondaire où se situe le miroir de secours. 

# Migration de la mise en miroir de bases de données (DBM) vers les groupes de disponibilité AlwaysOn
<a name="USER_SQLServerMultiAZ.Migration"></a>

Dans la version 14.00.3049.1 de Microsoft SQL Server Enterprise Edition, les groupes de disponibilité Always On sont activés par défaut.

Pour migrer de la mise en miroir de bases de données vers les groupes de disponibilité, commencez par vérifier votre version. Lorsque vous utilisez une instance de base de données de version antérieure à 13.00.5216.0, modifiez l'instance pour la faire passer à la version 13.00.5216.0 ou une version ultérieure. Lorsque vous utilisez une instance de base de données de version antérieure à 14.00.3049.1, modifiez-la pour la faire passer à la version 14.00.3049.1 ou une version ultérieure.

Si vous souhaitez mettre à niveau une instance de base de données en miroir afin d'utiliser des groupes de disponibilité, exécutez d'abord la mise à niveau, modifiez l'instance pour supprimer le multi-AZ, puis modifiez-la à nouveau afin d'ajouter le multi-AZ. Cette opération convertit votre instance en vue de l'utilisation des groupes de disponibilité Always On.