^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
```
------
## Étape 5 : création ou modification d’une instance de base de données SQL Server
Créez ou modifiez une instance de base de données RDS Custom for SQL Server en vue de son utilisation avec votre annuaire. Vous pouvez utiliser la console, la CLI ou l’API RDS pour associer une instance de base de données à un annuaire. Vous pouvez effectuer cette opération de différentes manières :
+ Créez une instance de base de données SQL Server à l'aide de la console, de la commande de CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) ou de l'opération d'API RDS [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html).
Pour obtenir des instructions, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données SQL Server existante à l'aide de la console, de la commande de CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) ou de l'opération d'API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html).
Pour obtenir des instructions, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ Restaurez une instance de base de données SQL Server à partir d'un instantané de bases de données à l'aide de la console, de la commande de CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) ou de l'opération d'API RDS [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html).
Pour obtenir des instructions, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
+ Restaurez une instance de base de données SQL Server à un instant dans le passé en utilisant la console, la commande de CLI [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) ou l'opération d'API RDS [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html).
Pour obtenir des instructions, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
**Note**
Si votre instance RDS Custom pour SQL Server est déjà jointe manuellement à un AD, vérifiez les paramètres de [Règles relatives aux ports de configuration réseau](custom-sqlserver-WinAuth.NWConfigPorts.md)[Validation du réseau](custom-sqlserver-WinAuth.NWValidation.md), et effectuez les étapes 1 à 4. Mettez à jour `--domain-fqdn`, `--domain-ou` et `--domain-auth-secret-arn` sur votre annuaire AD, afin que les informations d’identification et les configurations de jonction de domaine soient enregistrées auprès de RDS Custom pour surveiller, enregistrer le CNAME et prendre des mesures de récupération.
Lorsque vous utilisez AWS CLI, les paramètres suivants sont obligatoires pour que l’instance de base de données puisse utiliser l’annuaire que vous avez créé :
+ Pour le paramètre `--domain-fqdn`, utilisez le nom de domaine entièrement qualifié de votre annuaire AD autogéré.
+ Pour le paramètre `--domain-ou`, utilisez l’unité d’organisation que vous avez créée dans votre annuaire AD autogéré.
+ Pour le paramètre `--domain-auth-secret-arn`, utilisez la valeur de l’**ARN du secret** que vous avez créé dans une étape précédente.
**Important**
Si vous modifiez une instance de base de données pour la joindre à un domaine AD autogéré ou AWS Managed Microsoft AD ou pour l’en supprimer, un redémarrage de l’instance de base de données est requis pour que la modification prenne effet. Vous pouvez choisir d’appliquer les modifications immédiatement ou d’attendre la prochaine fenêtre de maintenance. Le choix de l’option **Appliquer immédiatement** entraînera une durée d’indisponibilité pour l’instance de base de données mono-AZ. Un cluster de bases de données multi-AZ effectuera un basculement avant de terminer le redémarrage. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
La commande de l’interface de ligne de commande (CLI) suivante crée une nouvelle instance de base de données RDS Custom for SQL Server et la joint à un domaine autogéré ou AWS Managed Microsoft AD.
Pour Linux, macOS ou Unix :
```
aws rds create-db-instance \
--engine custom-sqlserver-se \
--engine-version 15.00.4312.2.v1 \
--db-instance-identifier my-custom-instance \
--db-instance-class db.m5.large \
--allocated-storage 100 --storage-type io1 --iops 1000 \
--master-username my-master-username \
--master-user-password my-master-password \
--kms-key-id my-RDSCustom-key-id \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
--db-subnet-group-name my-DB-subnet-grp \
--vpc-security-group-ids my-securitygroup-id \
--no-publicly-accessible \
--backup-retention-period 3 \
--port 8200 \
--region us-west-2 \
--no-multi-az
```
Pour Windows :
```
aws rds create-db-instance ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4312.2.v1 ^
--db-instance-identifier my-custom-instance ^
--db-instance-class db.m5.large ^
--allocated-storage 100 --storage-type io1 --iops 1000 ^
--master-usernamemy-master-username ^
--master-user-password my-master-password ^
--kms-key-id my-RDSCustom-key-id ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
--db-subnet-group-name my-DB-subnet-grp ^
--vpc-security-group-ids my-securitygroup-id ^
--no-publicly-accessible ^
--backup-retention-period 3 ^
--port 8200 ^
--region us-west-2 ^
--no-multi-az
```
**Important**
Si votre NetBIOS pour AWS Managed Microsoft AD est **corpexample**, il apparaît lui-même sous la forme d’une unité organisationnelle. Toute nouvelle unité organisationnelle créée précédemment apparaîtra sous la forme d’une unité organisationnelle imbriquée. Pour AWS Managed Microsoft AD, réglez `--domain-ou` sur `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`.
La commande de l’interface de ligne de commande (CLI) suivante modifie une instance de base de données RDS Custom for SQL Server existante afin d’utiliser un domaine Active Directory.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
```
La commande de l’interface de ligne de commande (CLI) suivante supprime une instance de base de données RDS Custom for SQL Server d’un domaine Active Directory.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--disable-domain
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--disable-domain
```
Lorsque vous utilisez la console pour créer ou modifier votre instance, cliquez sur **Activer l’authentification Microsoft SQL Server Windows** pour voir les options suivantes.
![\[Annuaire d’authentification Windows à Microsoft SQL Server\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png)
Il est de votre responsabilité de vous assurer que le nom de domaine complet de votre domaine correspond aux adresses IP de contrôleur de domaine. Si les adresses IP de contrôleur de domaine ne sont pas résolues, les opérations de jointure de domaine échouent, mais la création de l’instance RDS Custom for SQL Server réussit. Pour plus d’informations sur le dépannage, consultez [Dépannage d’Active Directory](custom-sqlserver-WinAuth.Troubleshoot.md).
## Étape 6 : création de connexions SQL Server pour l’authentification Windows
Utilisez les informations d’identification de l’utilisateur principal Amazon RDS pour vous connecter à l’instance de base de données SQL Server de la même manière qu’à n’importe quelle instance de base de données. Étant donné que l’instance de base de données est jointe au domaine AD, vous pouvez allouer les connexions et utilisateurs SQL. Pour ce faire, utilisez l’utilitaire Utilisateurs et groupes de l’annuaire AD de votre domaine AD. Les autorisations pour la base de données sont gérées via des autorisations SQL Server standard accordées et révoquées en fonction des connexions Windows.
Pour qu’un utilisateur d’annuaire AD puisse s’authentifier à SQL Server, une connexion Windows SQL Server doit exister pour l’utilisateur ES ou un groupe Active Directory dont l’utilisateur est membre. Un contrôle précis des accès est géré par l’attribution ou la révocation d’autorisations pour ces connexions SQL Server. Un utilisateur d’annuaire AD qui n’a pas de connexion SQL Server ou qui n’appartient pas à un groupe AD avec une telle connexion ne peut pas accéder à l’instance de base de données SQL Server.
L’autorisation `ALTER ANY LOGIN` est requise pour créer une connexion SQL Server à l’annuaire AD. Si vous n’avez pas créé de connexions avec cette autorisation, connectez vous en tant qu’utilisateur principal de l’instance de base de données à l’aide de l’authentification SQL Server et créez vos connexions SQL Server à l’annuaire AD dans le contexte de l’utilisateur principal.
Vous pouvez exécuter une commande DDL (Data Definition Language) telle que la suivante afin de créer une connexion SQL Server pour un utilisateur ou un groupe d’annuaire AD.
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
Les utilisateurs (personnes et applications) de votre domaine peuvent désormais se connecter à l’instance RDS Custom for SQL Server à partir d’un ordinateur client joint au domaine à l’aide de l’authentification Windows.
## Étape 7 : utilisation de l’authentification Kerberos ou NTLM
### Authentification NTLM à l’aide du point de terminaison RDS
Chaque instance de base de données Amazon RDS possède un point de terminaison. Chaque point de terminaison possède un nom DNS et un numéro de port de l’instance de base de données. Pour connecter votre instance de base de données à l’aide d’une application cliente SQL, vous avez besoin du nom DNS et du numéro de port de votre instance de base de données. Pour vous authentifier à l’aide de l’authentification NTLM, vous devez vous connecter au point de terminaison RDS.
Lors d’une maintenance de base de données programmée ou d’une interruption non programmée du service, Amazon RDS bascule automatiquement vers la base de données secondaire à jour afin que les opérations puissent reprendre rapidement, sans intervention manuelle. Les instances principales et secondaires utilisent le même point de terminaison, dont l’adresse réseau physique est transférée vers l’instance secondaire dans le cadre du processus de basculement. Vous n’avez pas à reconfigurer votre application lorsqu’un basculement se produit.
### Authentification Kerberos
L’authentification basée sur Kerberos pour RDS Custom for SQL Server nécessite l’établissement de connexions à un nom principal de service (SPN) spécifique. Cependant, après un événement de basculement, il est possible que l’application ne connaisse pas le nouveau SPN. Pour résoudre ce problème, RDS Custom pour SQL Server propose un point de terminaison basé sur Kerberos.
Le point de terminaison basé sur Kerberos suit un format spécifique. Si votre point de terminaison RDS est `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`, le point de terminaison basé sur Kerberos correspondant est `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`.
Par exemple, si le point de terminaison RDS est `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com` et que le nom de domaine est `corp-ad.company.com`, le point de terminaison basé sur Kerberos est `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`.
Ce point de terminaison basé sur Kerberos peut être utilisé pour s’authentifier auprès de l’instance SQL Server à l’aide de Kerberos, même après un événement de basculement, car le point de terminaison est automatiquement mis à jour pour pointer vers le nouveau SPN de l’instance SQL Server principale.
### Trouver votre CNAME
Pour trouver votre CNAME, connectez-vous à votre contrôleur de domaine et ouvrez le **Gestionnaire DNS**. Accédez à **Forward Lookup Zones** et à votre FQDN.
Parcourez **awsrds**, **aws-region** et le **hachage spécifique au compte et à la région**.
Si vous connectez l’instance RDS Custom EC2 et que vous essayez de vous connecter à la base de données localement à l’aide de CNAME, votre connexion utilisera l’authentification NTLM au lieu de Kerberos.
Si, après avoir connecté le CNAME à partir d’un client distant, une connexion NTLM est renvoyée, vérifiez si les ports requis sont autorisés.
Pour vérifier que votre connexion utilise Kerberos, exécutez la requête suivante :
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
# Gestion d'une instance de base de données dans un domaine
Vous pouvez utiliser la console, l'AWS CLI ou l'API Amazon RDS pour gérer votre instance de base de données et sa relation avec votre domaine. Par exemple, vous pouvez déplacer l'instance de base de données dans, hors ou entre des domaines.
Par exemple, l'API Amazon RDS vous permet d'effectuer les actions suivantes :
+ Pour tenter à nouveau une jonction de domaines pour une appartenance ayant échoué, utilisez l'opération d'API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) et spécifiez l'ID d'annuaire de l'appartenance actuelle.
+ Pour mettre à jour le nom du rôle IAM de l'appartenance, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'ID d'annuaire de l'appartenance actuelle et le nouveau rôle IAM.
+ Pour supprimer une instance de base de données d'un domaine, utilisez l'opération d'API `ModifyDBInstance` et spécifiez `none` pour le paramètre de domaine.
+ Pour déplacer une instance de base de données d'un domaine à un autre, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'identifiant du nouveau domaine en tant que paramètre de domaine.
+ Pour répertorier l'appartenance pour chaque instance de base de données, utilisez l'opération d'API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html).
## Restauration d’une instance de base de données RDS Custom for SQL Server et ajout de cette instance à un domaine Active Directory
Vous pouvez restaurer un instantané de base de données ou effectuer une reprise ponctuelle (PITR) pour une instance de base de données SQL Server, puis l’ajouter à un domaine Active Directory. Une fois que l’instance de base de données est restaurée, modifiez l’instance à l’aide du processus expliqué dans [Étape 5 : création ou modification d’une instance de base de données SQL Server](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) afin d’ajouter l’instance de base de données à un domaine AD.
# Présentation de l'appartenance au domaine
Après la création ou la modification de votre instance de base de données, l'instance devient un membre du domaine. La console AWS indique le statut de l'appartenance au domaine pour l'instance de base de données. Le statut de l'instance de base de données peut avoir les valeurs suivantes :
+ **joined**–L'instance est membre du domaine.
+ **joining**–L'instance est en train de devenir membre du domaine.
+ **pending-join** – L'appartenance de l'instance est en attente.
+ **pending-maintenance-join** – AWS va tenter de faire de l'instance un membre du domaine pendant la prochaine fenêtre de maintenance planifiée.
+ **pending-removal**–La suppression de l'instance du domaine est en attente.
+ **pending-maintenance-removal** – AWS va tenter de supprimer l'instance du domaine pendant la prochaine fenêtre de maintenance planifiée.
+ **failed**–Un problème de configuration a empêché l'instance d'effectuer la jonction du domaine. Vérifiez et corrigez votre configuration avant d'émettre à nouveau la commande de modification de l'instance.
+ **removing**–La suppression de l'instance du domaine est en cours.
Une demande visant à devenir membre d'un domaine peut échouer à cause d'un problème de connectivité réseau ou d'un rôle IAM incorrect. Par exemple, vous pouvez créer une instance de base de données ou modifier une instance existante et faire échouer la tentative pour que l'instance de base de données devienne membre d'un domaine. Dans ce cas, émettez à nouveau la commande pour créer ou modifier l'instance de base de données, ou modifiez l'instance nouvellement créée pour rejoindre le domaine.
# Dépannage d’Active Directory
Vous pouvez rencontrer les problèmes suivants lors de la configuration ou de la modification d’un annuaire AD autogéré.
| Code d’erreur | Description | Causes courantes | Suggestions de dépannage |
| --- | --- | --- | --- |
| Erreur 2 / 0x2 | Le fichier spécifié est introuvable. | Le format ou l’emplacement de l’unité organisationnelle (UO) spécifiée avec le paramètre `—domain-ou` est non valide. Le compte de service de domaine spécifié via AWS Secrets Manager ne possède pas les autorisations requises pour rejoindre l’unité organisationnelle. | Passez en revue le paramètre `—domain-ou`. Assurez-vous que le compte de service de domaine dispose des autorisations appropriées pour accéder à l’unité d’organisation. |
| Erreur 5 / 0x5 | Accès refusé. | Autorisations mal configurées pour le compte de service de domaine, ou le compte d'ordinateur existe déjà dans le domaine. | Passez en revue les autorisations du compte de service de domaine dans le domaine et vérifiez que le compte d’ordinateur RDS n’est pas dupliqué dans le domaine. Vous pouvez vérifier le nom du compte d’ordinateur RDS en exécutant `SELECT @@SERVERNAME` sur votre instance de base de données RDS Custom for SQL Server. Si vous utilisez un déploiement multi-AZ, essayez un redémarrage avec basculement, puis vérifiez à nouveau que le compte d’ordinateur RDS est actif. Pour plus d’informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md). |
| Erreur 87 / 0x57 | Le paramètre est incorrect. | Le compte de service de domaine spécifié via AWS Secrets Manager ne dispose pas des autorisations appropriées. Le profil utilisateur est peut-être également endommagé. | Passez en revue les exigences relatives au compte de service de domaine. |
| Erreur 234 / 0xEA | L’unité d’organisation (OU) spécifiée n’existe pas. | L’unité organisationnelle spécifiée avec le paramètre `—domain-ou` n’existe pas dans votre annuaire AD. | Vérifiez le paramètre `—domain-ou` et assurez-vous que l’unité organisationnelle spécifiée existe dans votre annuaire AD. |
| Erreur 1326 / 0x52E | Le nom d'utilisateur ou le mot de passe est incorrect. | Les informations d’identification du compte de service de domaine fournies dans AWS Secrets Manager contiennent un nom d’utilisateur inconnu ou un mot de passe incorrect. Le compte de domaine peut également être désactivé dans votre annuaire AD. | Assurez-vous que les informations d’identification fournies dans AWS Secrets Manager sont correctes et que le compte de domaine est activé dans votre annuaire Active Directory. |
| Erreur 1355 / 0x54B | Le domaine spécifié n'existe pas ou n'a pas pu être contacté. | Le domaine est hors service, les adresses IP DNS spécifiées sont inaccessibles ou le nom FQDN spécifié est inaccessible. | Vérifiez les paramètres `—domain-dns-ips` et `—domain-fqdn` pour vous assurer qu’ils sont corrects. Passez en revue la configuration réseau de votre instance de base de données RDS Custom for SQL Server et assurez-vous que votre annuaire AD est accessible. |
| Erreur 1722 / 0x6BA | Le serveur RPC n’est pas disponible. | Un problème est survenu lors de l'accès au service RPC de votre domaine AD. Il peut s’agir d’un problème de service ou de réseau. | Vérifiez que le service RPC s’exécute sur vos contrôleurs de domaine et que les ports TCP `135` et `49152-65535` sont accessibles dans votre domaine à partir de votre instance de base de données RDS Custom for SQL Server. |
| Erreur 2224 / 0x8B0 | Le compte d’utilisateur existe déjà. | Le compte d’ordinateur qui tente d’être ajouté à votre annuaire AD existe déjà. | Identifiez le compte d’ordinateur en exécutant `SELECT @@SERVERNAME` sur votre instance de base de données RDS Custom for SQL Server, puis supprimez-le avec précaution de votre annuaire AD. |
| Erreur 2242 / 0x8c2 | Le mot de passe de cet utilisateur a expiré. | Le mot de passe du compte de service de domaine spécifié via AWS Secrets Manager a expiré. | Mettez à jour le mot de passe du compte de service de domaine utilisé pour joindre votre instance de base de données RDS Custom for SQL Server à votre annuaire AD. |
# Gestion d'un déploiement multi-AZ pour RDS Custom for SQL Server
Dans un déploiement d'instance de base de données multi-AZ pour RDS Custom for SQL Server, Amazon RDS alloue et maintient automatiquement un réplica de secours synchrone dans une zone de disponibilité (AZ) différente. L'instance de base de données primaire est répliquée de manière synchrone dans les zones de disponibilité sur un réplica de secours afin d'assurer une redondance des données.
**Important**
Un déploiement multi-AZ pour RDS Custom for SQL Server est différent d'un déploiement multi-AZ pour RDS for SQL Server. Contrairement à un déploiement multi-AZ pour RDS for SQL Server, vous devez configurer les conditions préalables pour RDS Custom for SQL Server avant de créer votre instance de base de données multi-AZ, car RDS Custom s'exécute dans votre propre compte, qui nécessite des autorisations.
Si vous ne remplissez pas les conditions préalables, votre instance de base de données multi-AZ risque de ne pas s'exécuter ou de revenir automatiquement à une instance de base de données mono-AZ. Pour plus d'informations sur les conditions préalables, consultez [Conditions préalables pour un déploiement multi-AZ pour RDS Custom for SQL Server](custom-sqlserver-multiaz.prerequisites.md).
L'exécution d'une instance de base de données en haute disponibilité peut améliorer la disponibilité pendant la maintenance planifiée du système. En cas de maintenance planifiée de la base de données ou d’interruption imprévue du service, Amazon RDS bascule automatiquement vers l’instance de base de données secondaire à jour. 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.
![\[RDS Custom for SQL Server prend en charge le déploiement multi-AZ.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/custom-sqlserver-multiaz-architecture.png)
Vous pouvez créer un déploiement multi-AZ RDS Custom for SQL Server en indiquant multi-AZ lors de la création d'une instance de base de données RDS Custom. Vous pouvez utiliser la console pour convertir les instances de base de données RDS Custom for SQL Server existantes en déploiements multi-AZ en modifiant l'instance de base de données et en spécifiant l'option multi-AZ. Vous pouvez également spécifier un déploiement d'instance de base de données multi-AZ avec l'interface de ligne de commande AWS ou l'API Amazon RDS.
La console RDS affiche la zone de disponibilité du réplica de secours (la zone de disponibilité secondaire). Vous pouvez également utiliser la commande d'interface de ligne de commande `describe-db-instances` ou l'opération d'API `DescribeDBInstances` pour rechercher la zone de disponibilité secondaire.
Les instances de base de données RDS Custom for SQL Server qui utilisent des déploiements multi-AZ peuvent avoir une latence d'écriture et de validation accrue par rapport à un déploiement mono-AZ. Cette augmentation peut se produire en raison de la réplication de données synchrone entre les instances de base de données. La latence peut évoluer si votre déploiement bascule vers le réplica de secours, même si AWS est conçu avec une connectivité réseau à faible latence entre les zones de disponibilité.
**Note**
Pour les charges de travail de production, nous vous recommandons d'utiliser une classe d'instance de base de données avec l'option IOPS provisionnés (opérations d'entrée/sortie par seconde) pour plus de rapidité et de constance sur le plan des performances. Pour plus d’informations sur les classes d’instance de base de données, consultez [Conditions requises et limitations d'Amazon RDS Custom for SQL Server](custom-reqs-limits-MS.md).
**Topics**
+ [Disponibilité des régions et des versions](#custom-sqlserver-multiaz.regionversion)
+ [Limites d'un déploiement multi-AZ pour RDS Custom for SQL Server](#custom-sqlserver-multiaz.limitations)
+ [Conditions préalables pour un déploiement multi-AZ pour RDS Custom for SQL Server](custom-sqlserver-multiaz.prerequisites.md)
+ [Création d'un déploiement multi-AZ RDS Custom for SQL Server](#custom-sqlserver-multiaz.creating)
+ [Modification d'un déploiement mono-AZ RDS Custom for SQL Server en un déploiement multi-AZ](custom-sqlserver-multiaz.modify-saztomaz.md)
+ [Modification d'un déploiement multi-AZ RDS Custom for SQL Server en un déploiement mono-AZ](custom-sqlserver-multiaz.modify-maztosaz.md)
+ [Processus de basculement pour un déploiement multi-AZ RDS Custom for SQL Server](custom-sqlserver-multiaz.failover.md)
## Disponibilité des régions et des versions
Les déploiements multi-AZ pour RDS Custom for SQL Server sont pris en charge pour les éditions de SQL Server suivantes :
+ SQL Server 2022 et 2019 : Enterprise, Standard, Web et Developer Editions
**Note**
Les déploiements multi-AZ pour RDS Custom for SQL Server ne sont pas pris en charge sur SQL Server 2019 CU8 (15.00.4073.23) ou les versions antérieures.
Les déploiements multi-AZ pour RDS Custom for SQL Server sont disponibles dans toutes les régions où RDS Custom for SQL Server est disponible. Pour plus d'informations sur la disponibilité des déploiements multi-AZ dans les régions pour RDS Custom for SQL Server, consultez [Régions et moteurs de base de données pris en charge pour RDS Custom for SQL Server](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md#Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.sq).
## Limites d'un déploiement multi-AZ pour RDS Custom for SQL Server
Les déploiements multi-AZ avec RDS Custom for SQL Server ont les limites suivantes :
+ Les déploiements multi-AZ entre régions ne sont 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.
+ Lorsque vous utilisez une version de moteur personnalisé (CEV) avec un déploiement multi-AZ, votre instance de base de données secondaire utilise également la même CEV. L'instance de base de données secondaire ne peut pas utiliser d'autre CEV.
# Conditions préalables pour un déploiement multi-AZ pour RDS Custom for SQL Server
Si vous disposez déjà d'un déploiement mono-AZ RDS Custom for SQL Server, les conditions préalables supplémentaires suivantes sont requises avant de le modifier en déploiement multi-AZ. Vous pouvez choisir de remplir les conditions préalables manuellement ou à l'aide du modèle CloudFormation fourni. Le dernier modèle CloudFormation contient les conditions préalables pour les déploiements mono-AZ et multi-AZ.
**Important**
Pour simplifier la configuration, nous vous recommandons d'utiliser le dernier fichier modèle CloudFormation fourni dans les instructions de configuration du réseau pour créer les conditions préalables. Pour de plus amples informations, consultez [Configuration avec CloudFormation](custom-setup-sqlserver.md#custom-setup-sqlserver.cf).
**Note**
Lorsque vous modifiez un déploiement mono-AZ RDS Custom for SQL Server existant en déploiement multi-AZ, vous devez remplir ces conditions préalables. Si vous ne remplissez pas les conditions préalables, la configuration multi-AZ échouera. Pour remplir toutes les conditions préalables, suivez les étapes dans [Modification d'un déploiement mono-AZ RDS Custom for SQL Server en un déploiement multi-AZ](custom-sqlserver-multiaz.modify-saztomaz.md).
+ Mettez à jour les règles entrantes et sortantes du groupe de sécurité RDS pour autoriser le port 1120.
+ Ajoutez une règle dans la liste de contrôle d'accès (ACL) de votre réseau privé qui autorise les ports TCP `0-65535` pour le VPC de l'instance de base de données.
+ Créez de nouveaux points de terminaison d'un VPC Amazon SQS qui permettent à l'instance de base de données RDS Custom for SQL Server de communiquer avec SQS.
+ Mettez à jour les autorisations SQS dans le rôle de profil d'instance.
## Création d'un déploiement multi-AZ RDS Custom for SQL Server
Pour créer un déploiement multi-AZ RDS Custom for SQL Server, suivez les étapes dans [Création et connexion à une instance de base de données pour Amazon RDS Custom for SQL Server](custom-creating-sqlserver.md).
**Important**
Pour simplifier la configuration, nous vous recommandons d'utiliser le dernier fichier modèle CloudFormation fourni dans les instructions de configuration du réseau. Pour plus d’informations, consultez [Configuration avec CloudFormation](custom-setup-sqlserver.md#custom-setup-sqlserver.cf).
La création d'un déploiement multi-AZ dure quelques minutes.
# Modification d'un déploiement mono-AZ RDS Custom for SQL Server en un déploiement multi-AZ
Vous pouvez modifier une instance de base de données RDS Custom for SQL Server existante d'un déploiement mono-AZ en un déploiement multi-AZ. Lorsque vous modifiez l'instance de base de données, Amazon RDS effectue plusieurs actions :
+ Prend un instantané de l'instance de base de données primaire.
+ Crée de nouveaux volumes pour le réplica en attente à partir de l'instantané. Ces volumes s'initialisent en arrière-plan, et les performances maximales du volume sont atteintes après l'initialisation complète des données.
+ Active la réplication synchrone au niveau des blocs entre les instances de base de données primaire et secondaire.
**Important**
Nous vous recommandons d'éviter de modifier votre instance de base de données RDS Custom for SQL Server pour passer d'un déploiement mono-AZ à un déploiement multi-AZ sur une instance de base de données de production pendant les périodes de pointe.
AWS utilise un instantané pour créer l'instance de secours afin d'éviter les temps d'arrêt lors de la conversion du mode mono-AZ au mode multi-AZ, mais les performances peuvent être affectées pendant et après la conversion au mode multi-AZ. Cet impact peut être significatif pour les charges de travail sensibles à la latence d'écriture. Bien que cette fonctionnalité permette de restaurer rapidement de gros volumes à partir de snapshots, elle peut entraîner une augmentation de la latence des I/O opérations en raison de la réplication synchrone. Cette latence peut avoir un impact sur les performances de votre base de données.
**Note**
Si vous avez créé votre instance de base de données RDS Custom for SQL Server avant le 29 août 2024, appliquez un correctif à la dernière version mineure avant de la modifier.
Pour les instances SQL Server 2019, mettez à niveau la version du moteur de base de données vers la version `15.00.4410.1.v1` ou une version ultérieure.
Pour les instances SQL Server 2022, mettez à niveau la version du moteur de base de données vers la version `16.00.4150.1.v1` ou une version ultérieure.
**Topics**
+ [Configuration des conditions requises pour modifier un déploiement mono-AZ en déploiement multi-AZ à l'aide de CloudFormation](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.cf)
+ [Configuration des conditions préalables pour modifier manuellement un déploiement mono-AZ en un déploiement multi-AZ](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.manual)
+ [Modifiez à l'aide de la console RDS, de la AWS CLI ou de l'API RDS.](#custom-sqlserver-multiaz.modify-saztomaz-afterprereqs)
## Configuration des conditions requises pour modifier un déploiement mono-AZ en déploiement multi-AZ à l'aide de CloudFormation
Pour utiliser un déploiement multi-AZ, vous devez vous assurer que vous avez appliqué le dernier CloudFormation modèle avec les prérequis, ou configurer manuellement les derniers prérequis. Si vous avez déjà appliqué le dernier modèle CloudFormation prérequis, vous pouvez ignorer ces étapes.
Pour configurer les conditions préalables au déploiement multi-AZ de RDS Custom pour SQL Server à l'aide de CloudFormation
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Pour démarrer l'assistant Créer une pile, sélectionnez la pile existante que vous avez utilisée pour créer un déploiement mono-AZ et choisissez **Mettre à jour**.
La page **Mettre à jour la pile** s'affiche.
1. Pour **Prérequis - Préparer le modèle**, choisissez **Le modèle est prêt**.
1. Pour **Specify template** (Spécifier un modèle), procédez comme suit :
1. Téléchargez le dernier fichier CloudFormation modèle. Ouvrez le menu contextuel (clic droit) du lien [custom-sqlserver-onboard.zip](samples/custom-sqlserver-onboard.zip) et choisissez **Enregistrer le lien sous**.
1. Enregistrez et extrayez le fichier `custom-sqlserver-onboard.json` de votre ordinateur.
1. Pour **Source du modèle**, choisissez **Charger un fichier de modèle**.
1. Pour **Choose file** (Choisir un fichier), accédez à `custom-sqlserver-onboard.json` et sélectionnez ce fichier.
1. Choisissez **Suivant**.
La page **Specify stack details** (Spécifier les détails de la pile) s'affiche.
1. Pour conserver les options par défaut, choisissez **Next** (Suivant).
La page **Options avancées** s'affiche.
1. Pour conserver les options par défaut, choisissez **Next** (Suivant).
1. Pour conserver les options par défaut, choisissez **Next** (Suivant).
1. Sur la page **Vérifier les modifications**, procédez comme suit :
1. Sous **Capacités**, cochez la case ****Je sais qu' CloudFormation peut créer des ressources IAM avec des noms personnalisés****.
1. Sélectionnez **Soumettre**.
1. Vérifiez que la mise à jour est réussie. Le statut d'une opération réussie affiche `UPDATE_COMPLETE`.
Si la mise à jour échoue, toute nouvelle configuration spécifiée dans le processus de mise à jour sera annulée. La ressource existante sera toujours utilisable. Par exemple, si vous ajoutez des règles ACL réseau numérotées 18 et 19, mais que certaines règles existantes portent les mêmes numéros, la mise à jour renverra l'erreur suivante : `Resource handler returned message: "The network acl entry identified by 18 already exists.` (L'entrée ACL réseau numérotée 18 existe déjà). Dans ce scénario, vous pouvez modifier les règles ACL existantes pour utiliser un nombre inférieur à 18, puis réessayez la mise à jour.
## Configuration des conditions préalables pour modifier manuellement un déploiement mono-AZ en un déploiement multi-AZ
**Important**
Pour simplifier la configuration, nous vous recommandons d'utiliser le dernier fichier CloudFormation modèle fourni dans les instructions de configuration réseau. Pour de plus amples informations, veuillez consulter [Configuration des conditions requises pour modifier un déploiement mono-AZ en déploiement multi-AZ à l'aide de CloudFormation](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.cf).
Si vous choisissez de configurer les conditions préalables manuellement, exécutez les tâches suivantes.
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **Point de terminaison**. La page **Créer un point de terminaison** s’affiche.
1. Pour **Catégorie de service**, choisissez **Services AWS **.
1. Dans **Services**, recherchez *SQS*
1. Dans **VPC**, choisissez le VPC dans lequel votre instance de base de données RDS Custom for SQL Server est déployée.
1. Dans **Sous-réseaux**, choisissez les sous-réseaux dans lesquels votre instance de base de données RDS Custom for SQL Server est déployée.
1. Dans **Groupes de sécurité**, choisissez le *-vpc-endpoint-sg* groupe.
1. Pour **Politique**, choisissez **Personnalisé**
1. Dans votre politique personnalisée, remplacez *AWS partition*, *Region*, *accountId* et *IAM-Instance-role* par vos propres valeurs.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-sqlserver"
}
},
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": "arn:aws:sqs:us-east-1:111122223333:do-not-delete-rds-custom-*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/{IAM-Instance-role}"
}
}
]
}
```
------
1. Mettez à jour le **Profil d'instance** avec l'autorisation d'accéder à Amazon SQS. Remplacez *AWS partition*, *Region* et *accountId* par vos propres valeurs.
```
{
"Sid": "SendMessageToSQSQueue",
"Effect": "Allow",
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": [
{
"Fn::Sub": "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:do-not-delete-rds-custom-*"
}
],
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-sqlserver"
}
}
}
>
```
1. Mettez à jour les règles entrantes et sortantes du groupe de sécurité Amazon RDS pour autoriser le port 1120.
1. Dans **Groupes de sécurité**, choisissez le *-rds-custom-instance-sg* groupe.
1. Pour les **règles entrantes**, créez une règle **TCP personnalisée** pour autoriser le port *1120* depuis le groupe source*-rds-custom-instance-sg*.
1. Pour les **règles sortantes**, créez une règle **TCP personnalisée** pour autoriser le port *1120* vers le groupe de destination*-rds-custom-instance-sg*.
1. Ajoutez une règle dans la liste de contrôle d'accès (ACL) de votre réseau privé qui autorise les ports TCP `0-65535` pour le sous-réseau source de l'instance de base de données.
**Note**
Lorsque vous créez une **Règle entrante** et une **Règle sortante**, prenez note du **Numéro de règle** existant le plus élevé. Les nouvelles règles que vous créez doivent avoir un **Numéro de règle** inférieur à 100 et ne correspondre à aucun **Numéro de règle** existant.
1. Dans **Réseau ACLs**, choisissez le *-private-network-acl* groupe.
1. Pour les **règles entrantes**, créez une règle **entièrement TCP** pour autoriser les ports TCP dont la source `0-65535` provient de et. *privatesubnet1* *privatesubnet2*
1. Pour les **règles sortantes**, créez une règle **All TCP** pour autoriser les ports TCP `0-65535` à destination et. *privatesubnet1* *privatesubnet2*
## Modifiez à l'aide de la console RDS, de la AWS CLI ou de l'API RDS.
Une fois les conditions requises remplies, vous pouvez modifier une instance de base de données personnalisée RDS pour SQL Server d'un déploiement mono-AZ à un déploiement multi-AZ à l'aide de la console RDS, de la AWS CLI ou de l'API RDS.
### Console
**Pour modifier un déploiement mono-AZ RDS Custom for SQL Server existant en un déploiement multi-AZ**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans la console Amazon RDS, choisissez **Bases de données**.
Le volet **Bases de données** s’affiche.
1. Choisissez l'instance de base de données RDS Custom for SQL Server que vous souhaitez modifier.
1. Dans **Actions**, choisissez **Convertir en déploiement multi-AZ**.
1. Sur la page **Confirmation**, choisissez **Appliquer immédiatement** pour appliquer les modifications immédiatement. Le choix de cette option n'entraîne pas d'interruption de service, mais il existe un impact possible sur les performances. Vous pouvez également choisir d'appliquer la mise à jour pendant le créneau de maintenance suivant. Pour de plus amples informations, veuillez consulter [Utilisation du paramètre de planification des modifications](USER_ModifyInstance.ApplyImmediately.md).
1. Sur la page **Confirmation**, choisissez **Convertir en Multi-AZ**.
### AWS CLI
Pour passer à un déploiement d'instance de base de données multi-AZ à l'aide de AWS CLI, appelez la [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande et définissez l'`--multi-az`option. Spécifiez l'identifiant d'instance de base de données et les valeurs des autres options que vous souhaitez modifier. Pour plus d’informations sur chaque option, consultez [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).
**Example**
Le code suivant modifie `mycustomdbinstance` en incluant l'option `--multi-az`. Les modifications sont appliquées pendant le créneau de maintenance suivant à l’aide de `--no-apply-immediately`. Pour appliquer les modifications immédiatement, utilisez `--apply-immediately`. Pour plus d’informations, consultez [Utilisation du paramètre de planification des modifications](USER_ModifyInstance.ApplyImmediately.md).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--multi-az \
--no-apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--multi-az \ ^
--no-apply-immediately
```
### API RDS
Pour passer à un déploiement d'instance de base de données multi-AZ avec l'API RDS, appelez l'DBInstanceopération [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) et définissez le `MultiAZ` paramètre sur true.
# Modification d'un déploiement multi-AZ RDS Custom for SQL Server en un déploiement mono-AZ
Vous pouvez modifier une instance de base de données RDS Custom for SQL Server existante d'un déploiement multi-AZ en un déploiement mono-AZ.
## Console
**Pour modifier une instance de base de données RDS Custom for SQL Server d'un déploiement multi-AZ en un déploiement mono-AZ.**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans la console Amazon RDS, choisissez **Bases de données**.
Le volet **Bases de données** s’affiche.
1. Choisissez l'instance de base de données RDS Custom for SQL Server que vous souhaitez modifier.
1. Pour **Déploiement multi-AZ**, choisissez **Non**.
1. Sur la page **Confirmation**, choisissez **Appliquer immédiatement** pour appliquer les modifications immédiatement. Le choix de cette option n'entraîne pas d'interruption de service, mais il existe un impact possible sur les performances. Vous pouvez également choisir d'appliquer la mise à jour pendant le créneau de maintenance suivant. Pour plus d’informations, consultez [Utilisation du paramètre de planification des modifications](USER_ModifyInstance.ApplyImmediately.md).
1. Sur la page **Confirmation**, choisissez **Modifier l'instance de base de données**.
## AWS CLI
Pour modifier un déploiement multi-AZ en déploiement mono-AZ à l'aide de l'AWS CLI, appelez la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) et incluez l'option `--no-multi-az`. Spécifiez l'identifiant d'instance de base de données et les valeurs des autres options que vous souhaitez modifier. Pour plus d’informations sur chaque option, consultez [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).
**Example**
Le code suivant modifie `mycustomdbinstance` en incluant l'option `--no-multi-az`. Les modifications sont appliquées pendant le créneau de maintenance suivant à l’aide de `--no-apply-immediately`. Pour appliquer les modifications immédiatement, utilisez `--apply-immediately`. Pour plus d’informations, consultez [Utilisation du paramètre de planification des modifications](USER_ModifyInstance.ApplyImmediately.md).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--no-multi-az \
--no-apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--no-multi-az \ ^
--no-apply-immediately
```
## API RDS
Pour modifier un déploiement multi-AZ en déploiement mono-AZ à l'aide de l'API RDS, appelez l'opération [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) et définissez le paramètre `MultiAZ` sur `false`.
# Processus de basculement pour un déploiement multi-AZ RDS Custom for SQL Server
Si une interruption prévue ou imprévue de votre instance de base de données est le résultat d'une anomalie de l'infrastructure, Amazon RDS bascule automatiquement sur le réplica de secours d'une autre zone de disponibilité si vous avez activé l'option Multi-AZ. La durée du basculement dépend de l'activité de la base de données et d'autres conditions au moment où l'instance de base de données primaire est devenue indisponible. Les temps de basculement oscillent généralement entre 60 et 120 secondes. Cependant, les transactions importantes ou les processus de récupération longs peuvent augmenter le temps de basculement. Lorsque le basculement est terminé, un temps supplémentaire peut être nécessaire pour que la console RDS affiche la nouvelle zone de disponibilité.
**Note**
Vous pouvez forcer le basculement manuellement lorsque vous redémarrez une instance de base de données avec basculement. Pour plus d'informations sur le redémarrage d'une instance de base de données, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
Étant donné qu'Amazon RDS gère automatiquement les basculements, vous pouvez reprendre les opérations de base de données aussi rapidement que possible sans intervention administrative. L'instance de base de données primaire bascule automatiquement vers le réplica de secours si l'une des conditions décrites dans le tableau suivant se produit : Vous pouvez consulter les raisons du basculement dans le journal des événements RDS.
****
| Raison du basculement | Description |
| --- | --- |
| `The operating system for the RDS Custom for SQL Server Multi-AZ DB instance is being patched in an offline operation` | Un basculement a été déclenché pendant la fenêtre de maintenance d'un correctif du système d'exploitation ou d'une mise à jour de sécurité. Pour de plus amples informations, consultez [Entretien d’une instance de base de données](USER_UpgradeDBInstance.Maintenance.md). |
| `The primary host of the RDS Custom for SQL Server Multi-AZ DB instance is unhealthy.` | Le déploiement d'instance de base de données multi-AZ a détecté une instance de base de données primaire déficiente et a opéré un basculement. |
| `The primary host of the RDS Custom for SQL Server Multi-AZ DB instance is unreachable due to loss of network connectivity.` | La surveillance RDS a détecté une défaillance de la capacité d'accessibilité du réseau à l'instance de base de données primaire et a déclenché un basculement. |
| `The RDS Custom for SQL Server Multi-AZ DB instance was modified by the customer.` | Une modification d'instance de base de données a déclenché un basculement. Pour de plus amples informations, consultez [Modification d'une instance de base de données RDS Custom for SQL Server](custom-managing.modify-sqlserver.md). |
| `The storage volume of the primary host of the RDS Custom for SQL Server Multi-AZ DB instance experienced a failure.` | Le déploiement d'instance de base de données multi-AZ a détecté un problème de stockage sur l'instance de base de données primaire et a opéré un basculement. |
| `The user requested a failover of the RDS Custom for SQL Server Multi-AZ DB instance.` | L'instance de base de données multi-AZ RDS Custom for SQL Server a été redémarrée avec basculement. Pour de plus amples informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md). |
| `The RDS Custom for SQL Server Multi-AZ primary DB instance is busy or unresponsive.` | L'instance de base de données primaire ne répond pas. Nous vous recommandons d'essayer les étapes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/custom-sqlserver-multiaz.failover.html) |
Pour déterminer si votre instance de base de données Multi-AZ a basculé, voici ce que vous pouvez faire :
+ Configurez les abonnements aux événements de base de données de sorte qu'ils vous notifient par e-mail ou SMS qu'un basculement a été initié. Pour plus d'informations sur les événements, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Examinez vos événements de base de données à l'aide de la console RDS ou d'opérations d'API.
+ Examinez l'état actuel de votre déploiement d'instance de base de données multi-AZ RDS Custom for SQL Server à l'aide de la console RDS, de l'interface de ligne de commande ou d'opérations d'API.
## Paramètres de durée de vie (TTL) avec des applications utilisant un déploiement multi-AZ RDS Custom for SQL Server
Le mécanisme de basculement modifie automatiquement l'enregistrement DNS de l'instance de base de données pour pointer vers l'instance de base de données en attente. Par conséquent, vous devez rétablir toutes les connexions existantes à votre instance de base de données. Veillez à ce que toute valeur de configuration de durée de vie (TTL) du cache DNS soit basse et à ce que votre application ne mette pas le DNS en cache pendant une période prolongée. Une valeur de durée de vie élevée peut empêcher votre application de se reconnecter rapidement à l'instance de base de données après un basculement.
# Sauvegarde et restauration d'une instance de base de données Amazon RDS Custom for SQL Server
Comme Amazon RDS, RDS Custom crée et enregistre des sauvegardes automatiques de votre instance de base de données RDS Custom for SQL Server lorsque la rétention des sauvegardes est activée. Vous pouvez également sauvegarder votre instance de base de données manuellement. Les sauvegardes automatiques comprennent des sauvegardes d’instantanés et des sauvegardes des journaux de transactions. Des sauvegardes d’instantanés sont effectuées pour l’ensemble du volume de stockage de l’instance de base de données pendant la fenêtre de sauvegarde spécifiée. Des sauvegardes des journaux de transactions sont effectuées pour les bases de données éligibles au PITR à intervalles réguliers. RDS Custom enregistre les sauvegardes automatiques de votre instance de base de données selon la période de rétention des sauvegardes que vous spécifiez. Vous pouvez utiliser les sauvegardes automatiques pour récupérer votre instance de base de données pendant la période de conservation des sauvegardes.
Vous pouvez également effectuer des sauvegardes d’instantanés manuelles. Vous pouvez créer une instance de base de données à partir de ces sauvegardes d’instantanés à n’importe quel moment. Pour plus d’informations sur la création manuelle d’un instantané de base de données, consultez [Création d'un instantané de RDS Custom for SQL Server](custom-backup-sqlserver.creating.md).
Bien que les sauvegardes d’instantanés soient opérationnelles comme des sauvegardes complètes, vous n’êtes facturée que pour l’utilisation incrémentielle du stockage. Le premier instantané d'une instance de base de données RDS Custom contient les données de l'instance de base de données complète. Les instantanés suivants de la même base de données sont incrémentiels, ce qui signifie que seules les données qui ont changé depuis l’instantané le plus récent sont enregistrées.
**Topics**
+ [Création d'un instantané de RDS Custom for SQL Server](custom-backup-sqlserver.creating.md)
+ [Restauration à partir d'un instantané de base de données RDS Custom for SQL Server](custom-backup-sqlserver.restoring.md)
+ [Restauration d'une instance de RDS Custom for SQL Server à un point dans le temps](custom-backup.pitr-sqs.md)
+ [Suppression d'un instantané de RDS Custom for SQL Server](custom-backup-sqlserver.deleting.md)
+ [Suppression des sauvegardes automatisées RDS Custom for SQL Server](custom-backup-sqlserver.deleting-backups.md)
# Création d'un instantané de RDS Custom for SQL Server
RDS Custom for SQL crée un instantané du volume de stockage de votre instance de base de données, en sauvegardant l'intégralité de cette dernière et non pas seulement des bases de données individuelles. Lorsque vous créez un instantané, spécifiez l'instance de base de données RDS Custom for SQL Server à sauvegarder. Nommez votre instantané afin que vous puissiez restaurer ultérieurement à partir de ce dernier.
Lorsque vous créez un instantané, RDS Custom for SQL Server crée un instantané Amazon EBS pour le volume `(D:)`, qui est le volume de base de données attaché à l’instance de base de données. Pour que les instantanés soient faciles à associer à une instance de base de données spécifique, ils sont labelisés `DBSnapshotIdentifier`, `DbiResourceId` et `VolumeType`.
La création d'un instantané de base de données entraîne une brève suspension des I/O. Cette suspension peut durer de quelques secondes à quelques minutes, en fonction de la taille et de la classe de votre instance de base de données. Le temps de création d’instantanés varie en fonction du nombre total et de la taille de vos bases de données. Pour plus d’informations sur le nombre de bases de données éligibles à une opération de restauration ponctuelle (PITR), consultez [Nombre de bases de données éligibles au PITR par type de classe d’instance](custom-backup.pitr-sqs.md#custom-backup.pitr.sqlserver.eligiblecountperinstance).
Étant donné que l'instantané inclut l'intégralité du volume de stockage, la taille de fichiers comme les fichiers temporaires a également une incidence sur le temps nécessaire à la création de l'instantané. Pour en savoir plus sur la création des instantanés, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
Créez un instantané de RDS Custom for SQL Server en utilisant la console ou AWS CLI.
## Console
**Pour créer un instantané RDS Custom**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans la panneau de navigation, choisissez **Bases de données**.
1. Dans la liste d'instances de base de données RDS Custom, choisissez l'instance pour laquelle vous souhaitez prendre un instantané.
1. Sous **Actions**, choisissez **Take snapshot (Prendre un instantané)**.
La fenêtre **Capture d'un instantané DB** apparaît.
1. Dans **Snapshot name (Nom de l'instantané)**, saisissez le nom de l'instantané.
1. Choisissez **Prendre un instantané**.
## AWS CLI
Vous créez un instantané d'une instance de base de données RDS Custom à l'aide de la commande de AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html).
Spécifiez les options suivantes :
+ `--db-instance-identifier` – Identifie l'instance de base de données RDS Custom que vous allez sauvegarder
+ `--db-snapshot-identifier` – Nomme votre instantané RDS Custom afin que vous puissiez restaurer ultérieurement à partir de ce dernier
Dans cet exemple, vous créez un instantané de base de données appelé *`my-custom-snapshot`* pour une instance de base de données RDS Custom appelée `my-custom-instance`.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds create-db-snapshot \
2. --db-instance-identifier my-custom-instance \
3. --db-snapshot-identifier my-custom-snapshot
```
Pour Windows :
```
1. aws rds create-db-snapshot ^
2. --db-instance-identifier my-custom-instance ^
3. --db-snapshot-identifier my-custom-snapshot
```
# Restauration à partir d'un instantané de base de données RDS Custom for SQL Server
Lorsque vous restaurez une instance de base de données RDS Custom for SQL Server, vous indiquez le nom de l'instantané de base de données et un nom pour la nouvelle instance. Vous ne pouvez pas restaurer à partir d'un instantané vers une instance de base de données RDS Custom existante. Une nouvelle instance de base de données RDS Custom for SQL Server est créée lors de la restauration.
La restauration à partir d’un instantané rétablit le volume de stockage au moment où l’instantané a été pris. Cela inclut toutes les bases de données et tous les autres fichiers présents sur le volume `(D:)`.
## Console
**Pour restaurer une instance de base de données RDS Custom à partir d'un instantané de base de données**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Snapshots**.
1. Choisissez l'instantané de base de données à partir duquel vous voulez restaurer.
1. Pour **Actions**, choisissez **Restaurer l’instantané**.
1. Sur la page **Restore DB Instance** (Restituer l'instance de base de données), pour **DB instance identifier** (Identifiant d'instance de base de données), saisissez le nom de votre instance de base de données RDS Custom restaurée.
1. Choisissez **Restore DB Instance (Restaurer une instance de base de données)**.
## AWS CLI
Vous restaurez un instantané de base de données RDS Custom à l'aide de la commande de AWS CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Si l'instantané à partir duquel vous restaurez est destiné à une instance de base de données privée, assurez-vous de spécifier le `db-subnet-group-name` correct et `no-publicly-accessible`. Sinon, l'instance de base de données est accessible par défaut au public. Les options suivantes sont requises :
+ `db-snapshot-identifier` – Identifie l'instantané à partir duquel restaurer
+ `db-instance-identifier` – Spécifie le nom de l'instance de base de données RDS Custom à créer à partir de l'instantané de base de données
+ `custom-iam-instance-profile` : spécifie le profil d'instance associé à l'instance Amazon EC2 sous-jacente d'une instance de base de données RDS Custom.
Le code suivant restaure l'instantané nommé `my-custom-snapshot` pour `my-custom-instance`.
**Example**
Pour Linux, macOS ou Unix :
```
aws rds restore-db-instance-from-db-snapshot \
--db-snapshot-identifier my-custom-snapshot \
--db-instance-identifier my-custom-instance \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--no-publicly-accessible
```
Pour Windows :
```
aws rds restore-db-instance-from-db-snapshot ^
--db-snapshot-identifier my-custom-snapshot ^
--db-instance-identifier my-custom-instance ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--no-publicly-accessible
```
# Restauration d'une instance de RDS Custom for SQL Server à un point dans le temps
Vous pouvez restaurer une instance de base de données à un point donné dans le temps (PITR), et créer ainsi une nouvelle instance de base de données. Pour prendre en charge le PITR, la rétention des sauvegardes de vos instances de base de données doit être activée.
La dernière date de restauration d'une instance de base de données RDS Custom for SQL Server dépend de plusieurs facteurs, mais se situe généralement dans les cinq minutes qui précèdent l'heure actuelle. Pour connaître l'heure de restauration la plus récente pour une instance de base de données, utilisez la AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande et examinez la valeur renvoyée dans le `LatestRestorableTime` champ correspondant à l'instance de base de données. Pour afficher l'heure de restauration la plus récente pour chaque instance de base de données dans la console Amazon RDS, choisissez **Automated backups (Sauvegardes automatisées)**.
Vous pouvez procéder à une restauration à n'importe quel moment dans le passé au cours de la période de rétention des sauvegardes. Pour afficher l’heure de restauration la plus ancienne pour chaque instance de base de données, choisissez **Automated backups (Sauvegardes automatisées)** dans la console Amazon RDS.
Pour obtenir des informations générales sur le PITR, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
**Topics**
+ [Considérations PITR pour RDS Custom for SQL Server](#custom-backup.pitr.sqlserver)
+ [Nombre de bases de données éligibles au PITR par type de classe d’instance](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [Rendre les bases de données inéligibles au PITR](#custom-backup.pitr.sqlserver.ineligible)
+ [Journaux de transactions dans Amazon S3](#custom-backup.pitr.sqlserver.tlogs)
+ [Restauration PITR à l'aide de l'AWS Management ConsoleAPIAWS CLI, de ou de l'API RDS.](#custom-backup.pitr-sqs-concli)
## Considérations PITR pour RDS Custom for SQL Server
Dans RDS Custom for SQL Server, le PITR diffère de la manière suivante du PITR dans Amazon RDS :
+ Le PITR restaure uniquement les bases de données de l'instance de base de données. Il ne restaure pas le système d'exploitation ou les fichiers du lecteur C:.
+ Pour une instance de base de données RDS Custom for SQL Server, une base de données est automatiquement sauvegardée et n'est éligible au PITR que dans les conditions suivantes :
+ La base de données est en ligne.
+ Son modèle de récupération est défini sur `FULL`.
+ Elle est inscriptible.
+ Ses fichiers physiques sont sur le lecteur D:.
+ Elle n'est pas répertoriée dans le tableau `rds_pitr_blocked_databases`. Pour plus d’informations, consultez [Rendre les bases de données inéligibles au PITR](#custom-backup.pitr.sqlserver.ineligible).
+ Les bases de données éligibles au PITR sont déterminées par l’ordre de leur ID de base de données. RDS Custom for SQL Server autorise jusqu'à 5 000 bases de données par instance de base de données. Toutefois, le nombre maximal de bases de données restaurées par une opération de PITR pour une instance de base de données RDS Custom for SQL Server dépend du type de classe d’instance. Pour plus d’informations, consultez [Nombre de bases de données éligibles au PITR par type de classe d’instance](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
Les autres bases de données qui ne font pas partie du PITR peuvent être restaurées à partir d’instantanés de base de données, y compris les sauvegardes d’instantanés automatiques utilisées pour le PITR.
+ L'ajout d'une nouvelle base de données, le changement de nom d'une base de données ou la restauration d'une base de données éligible au PITR déclenche un instantané de l'instance de base de données.
+ Le nombre maximum de bases de données éligibles au PITR change lorsque l’instance de base de données est soumise à une opération de calcul à l’échelle, en fonction du type de classe d’instance cible. Si l’instance augmente verticalement, permettant à un plus grand nombre de bases de données de l’instance d’être éligibles au PITR, un nouvel instantané est pris.
+ Les bases de données restaurées portent le même nom que dans l'instance de base de données source. Vous ne pouvez pas spécifier un autre nom.
+ `AWSRDSCustomSQLServerIamRolePolicy`nécessite l'accès à d'autres AWS services. Pour de plus amples informations, veuillez consulter [Ajoutez une politique d'accès à AWSRDSCustom SQLServer InstanceRole](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy).
+ Les modifications de fuseau horaire ne sont pas prises en charge pour RDS Custom for SQL Server. Si vous modifiez le fuseau horaire du système d'exploitation ou de l'instance de base de données, le PITR (et toute autre automatisation) ne fonctionne pas.
## Nombre de bases de données éligibles au PITR par type de classe d’instance
Le tableau suivant indique le nombre maximal de bases de données éligibles au PITR en fonction du type de classe d’instance.
| Type de classe d’instance | Nombre maximal de bases de données éligibles au PITR |
| --- | --- |
| db.\$1.large | 100 |
| db.\$1.xlarge à db.\$1.2xlarge | 150 |
| db.\$1.4xlarge à db.\$1.8xlarge | 300 |
| db.\$1.12xlarge à db.\$1.16xlarge | 600 |
| db.\$1.24xlarge, db.\$132xlarge | 1 000 |
`*` *Représente les différents types de classes d’instance.*
Le nombre maximum de bases de données éligibles au PITR sur une instance de base de données dépend du type de classe d’instance. Ce nombre est compris entre 100 pour les plus petits et 1 000 pour les types de classes d’instance les plus importants pris en charge par RDS Custom for SQL Server. Les bases de données système SQL Server `(master, model, msdb, tempdb)` ne sont pas incluses dans cette limite. Lorsqu’une instance de base de données est augmentée ou réduite verticalement, selon le type de classe d’instance cible, RDS Custom met automatiquement à jour le nombre de bases de données éligibles au PITR. RDS Custom for SQL Server envoie `RDS-EVENT-0352` lorsque le nombre maximal de bases de données éligibles au PITR change sur une instance de base de données. Pour plus d’informations, consultez [Événements de version du moteur personnalisés](USER_Events.Messages.md#USER_Events.Messages.CEV).
**Note**
La prise en charge du PITR pour plus de 100 bases de données n’est disponible que sur les instances de base de données créées après le 26 août 2023. Pour les instances créées avant le 26 août 2023, le nombre maximum de bases de données éligibles au PITR est de 100, quelle que soit la classe d’instance. Pour activer la prise en charge du PITR pour plus de 100 bases de données sur des instances de base de données créées avant le 26 août 2023, vous pouvez effectuer l’action suivante :
Mettre à niveau la version du moteur de base de données vers la version 15.00.4322.2.v1 ou supérieure
Au cours d’une opération de PITR, RDS Custom restaure toutes les bases de données qui faisaient partie du PITR sur l’instance de base de données source au moment de la restauration. Une fois que l’instance de base de données cible a terminé les opérations de restauration, si la rétention des sauvegardes est activée, l’instance de base de données commence à sauvegarder en fonction du nombre maximum de bases de données éligibles au PITR sur l’instance de base de données cible.
Par exemple, si votre instance de base de données s’exécute sur une `db.*.xlarge` contenant 200 bases de données :
1. RDS Custom for SQL Server choisira les 150 premières bases de données, classées par ID de base de données, pour la sauvegarde PITR.
1. Vous modifiez l’instance pour l’augmenter verticalement jusqu’à db.\$1.4xlarge.
1. Une fois l’opération de calcul de l’échelle terminée, RDS Custom for SQL Server choisira les 300 premières bases de données, classées par ID de base de données, pour la sauvegarde du PITR. Chacune des 200 bases de données répondant aux exigences du PITR sera désormais éligible au PITR.
1. Vous modifiez maintenant l’instance pour la réduire verticalement jusqu’à db.\$1.xlarge.
1. Une fois l’opération de calcul de l’échelle terminée, RDS Custom for SQL Server sélectionnera à nouveau les 150 premières bases de données, classées par ID de base de données, pour la sauvegarde du PITR.
## Rendre les bases de données inéligibles au PITR
Vous pouvez choisir d’exclure des bases de données individuelles du PITR. Pour ce faire, mettez leurs valeurs `database_id` dans un tableau `rds_pitr_blocked_databases`. Utilisez le script SQL suivant pour créer la table.
**Pour créer la table rds\$1pitr\$1blocked\$1databases**
+ Exécutez le script SQL suivant.
```
create table msdb..rds_pitr_blocked_databases
(
database_id INT NOT NULL,
database_name SYSNAME NOT NULL,
db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(),
db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER,
PRIMARY KEY (database_id)
);
```
Pour obtenir la liste des bases de données éligibles et non éligibles, consultez le fichier `RI.End`dans le répertoire `RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata` du compartiment Amazon S3 `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`. Pour plus d'informations sur le fichier `RI.End`, consultez [Journaux de transactions dans Amazon S3](#custom-backup.pitr.sqlserver.tlogs).
Vous pouvez également déterminer la liste des bases de données éligibles au PITR à l’aide du script SQL suivant. Définissez la variable `@limit` sur le nombre maximum de bases de données éligibles au PITR pour la classe d’instance. Pour plus d’informations, consultez [Nombre de bases de données éligibles au PITR par type de classe d’instance](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
**Définition de la liste des bases de données éligibles au PITR sur une classe d’instance de base de données**
+ Exécutez le script SQL suivant.
```
DECLARE @Limit INT;
SET @Limit = (insert-database-instance-limit-here);
USE msdb;
IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'rds_pitr_blocked_databases'))
WITH TABLE0 AS (
SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
FROM sys.dm_hadr_database_replica_states hdrs
INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0)
OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
),
TABLE1 as (
SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason,
CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable
FROM msdb.dbo.rds_pitr_blocked_databases dbs
INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id
WHERE sysdbs.database_id > 4
),
TABLE2 as (
SELECT
db.name AS DatabaseName,
db.create_date AS CreateDate,
db.state_desc AS DatabaseState,
db.database_id AS DatabaseId,
rs.database_guid AS DatabaseGuid,
rs.last_log_backup_lsn AS LastLogBackupLSN,
rs.recovery_fork_guid RecoveryForkGuid,
rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
db.recovery_model_desc AS RecoveryModel,
db.is_auto_close_on AS IsAutoClose,
db.is_read_only as IsReadOnly,
NEWID() as FileName,
CASE WHEN(db.state_desc = 'ONLINE'
AND db.recovery_model_desc != 'SIMPLE'
AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1))
AND db.is_read_only != 1
AND db.user_access = 0
AND db.source_database_id IS NULL
AND db.is_in_standby != 1
THEN 1 ELSE 0 END AS IsPartOfSnapshot,
CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
FROM sys.databases db
INNER JOIN sys.database_recovery_status rs
ON db.database_id = rs.database_id
WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
),
TABLE3 as(
Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
)
SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1
ORDER BY TABLE2.DatabaseID ASC
ELSE
WITH TABLE0 AS (
SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
FROM sys.dm_hadr_database_replica_states hdrs
INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0)
OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
),
TABLE1 as (
SELECT
db.name AS DatabaseName,
db.create_date AS CreateDate,
db.state_desc AS DatabaseState,
db.database_id AS DatabaseId,
rs.database_guid AS DatabaseGuid,
rs.last_log_backup_lsn AS LastLogBackupLSN,
rs.recovery_fork_guid RecoveryForkGuid,
rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
db.recovery_model_desc AS RecoveryModel,
db.is_auto_close_on AS IsAutoClose,
db.is_read_only as IsReadOnly,
NEWID() as FileName,
CASE WHEN(db.state_desc = 'ONLINE'
AND db.recovery_model_desc != 'SIMPLE'
AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1))
AND db.is_read_only != 1
AND db.user_access = 0
AND db.source_database_id IS NULL
AND db.is_in_standby != 1
THEN 1 ELSE 0 END AS IsPartOfSnapshot,
CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
FROM sys.databases db
INNER JOIN sys.database_recovery_status rs
ON db.database_id = rs.database_id
WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
),
TABLE2 as(
SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
)
select top(select TotalNumberOfDatabases from TABLE2) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1
ORDER BY TABLE1.DatabaseID ASC
```
**Note**
Les bases de données qui ne sont que des liens symboliques sont également exclues des bases de données éligibles aux opérations du PITR. La requête ci-dessus ne filtre pas en fonction de ces critères.
## Journaux de transactions dans Amazon S3
La période de rétention des sauvegardes détermine si les journaux de transactions pour les instances de base de données RDS Custom for SQL Server sont automatiquement extraits et chargés dans Amazon S3. Une valeur non nulle signifie que des sauvegardes automatiques sont créées et que l'agent RDS Custom charge les journaux de transactions dans S3 toutes les 5 minutes.
Les journaux des transactions sur S3 sont chiffrés au repos à l'aide de la AWS KMS key que vous avez fournie lors de la création de votre instance de base de données. Pour plus d’informations, consultez [Protection des données à l’aide du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
Les journaux de transactions de chaque base de données sont chargés dans un compartiment S3 nommé `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`. Le répertoire `RDSCustomForSQLServer/Instances/DB_instance_resource_ID` dans le compartiment S3 contient deux sous-répertoires :
+ `TransactionLogs` – Contient les journaux de transactions de chaque base de données et leurs métadonnées respectives.
Le nom du fichier journal des transactions suit le modèle `yyyyMMddHHmm.database_id.timestamp`, par exemple :
```
202110202230.11.1634769287
```
Le même nom de fichier avec le suffixe `_metadata` contient des informations sur le journal des transactions telles que les numéros de séquence de journaux, le nom de la base de données et `RdsChunkCount`. `RdsChunkCount` détermine le nombre de fichiers physiques qui représentent un fichier journal de transactions unique. Vous pouvez voir des fichiers contenant des suffixes `_0001`,`_0002`, et ainsi de suite, ce qui correspond aux morceaux physiques d'un fichier journal de transactions. Si vous souhaitez utiliser un fichier journal de transactions en morceaux, veillez à fusionner les morceaux après les avoir téléchargés.
Imaginons un scénario dans lequel vous disposez des fichiers suivants :
+ `202110202230.11.1634769287`
+ ` 202110202230.11.1634769287_0001`
+ ` 202110202230.11.1634769287_0002 `
+ ` 202110202230.11.1634769287_metadata`
Le `RdsChunkCount` est `3`. L'ordre de fusion des fichiers est le suivant : `202110202230.11.1634769287`, ` 202110202230.11.1634769287_0001`, `202110202230.11.1634769287_0002`.
+ `TransactionLogMetadata` – Contient des informations de métadonnées sur chaque itération de l'extraction du journal de transactions.
Le fichier `RI.End` contient des informations sur toutes les bases de données dont les journaux de transactions ont été extraits, et toutes les bases de données existantes mais dont les journaux de transactions n'ont pas été extraits. Le nom de fichier `RI.End` suit le modèle `yyyyMMddHHmm.RI.End.timestamp`, par exemple :
```
202110202230.RI.End.1634769281
```
## Restauration PITR à l'aide de l'AWS Management ConsoleAPIAWS CLI, de ou de l'API RDS.
Vous pouvez restaurer une instance de base de données RDS Custom pour SQL Server à un moment donné à l'aide de l'API AWS Management Console RDS ou de l'API RDS. AWS CLI
### Console
**Pour restaurer une instance de base de données RDS personnalisée à un moment spécifié**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Automated backups** (Sauvegardes automatisées).
1. Choisissez l'instance de base de données RDS Custom que vous souhaitez restaurer.
1. Sous **Actions**, sélectionnez **Restaurer à un moment donné**.
La fenêtre **Restaurer à un instant dans le passé** s’affiche.
1. Choisissez **Dernière heure de restauration possible** pour restaurer à la dernière heure possible, ou choisissez **Personnalisé** pour choisir une heure.
Si vous choisissez **Custom** (Personnalisé), saisissez la date et l'heure auxquelles vous souhaitez restaurer l'instance.
Les heures sont exprimées dans votre fuseau horaire local, qui est indiqué par son décalage par rapport à l’heure UTC. Par exemple, UTC-5 correspond à l' Time/Central heure avancée normale de l'Est.
1. Pour **DB instance identifier** (Identifiant d'instance de base de données), saisissez le nom de l'instance de base de données RDS Custom restaurée. Le nom doit être unique.
1. Choisissez d'autres options selon vos besoins, comme la classe d'instance de base de données.
1. Choisissez **Restaurer à un instant dans le passé**.
### AWS CLI
Vous restaurez une instance de base de données à une heure spécifiée en utilisant la point-in-time AWS CLI commande [ restore-db-instance-to-](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) pour créer une nouvelle instance de base de données personnalisée RDS.
Utilisez l'une des options suivantes pour spécifier la sauvegarde à partir de laquelle effectuer la restauration :
+ `--source-db-instance-identifier mysourcedbinstance`
+ `--source-dbi-resource-id dbinstanceresourceID`
+ `--source-db-instance-automated-backups-arn backupARN`
L’option `custom-iam-instance-profile` est obligatoire.
L'exemple suivant restaure `my-custom-db-instance` vers une nouvelle instance de base de données nommée `my-restored-custom-db-instance` au moment spécifié.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds restore-db-instance-to-point-in-time \
2. --source-db-instance-identifier my-custom-db-instance\
3. --target-db-instance-identifier my-restored-custom-db-instance \
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
5. --restore-time 2022-10-14T23:45:00.000Z
```
Pour Windows :
```
1. aws rds restore-db-instance-to-point-in-time ^
2. --source-db-instance-identifier my-custom-db-instance ^
3. --target-db-instance-identifier my-restored-custom-db-instance ^
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
5. --restore-time 2022-10-14T23:45:00.000Z
```
# Suppression d'un instantané de RDS Custom for SQL Server
Vous pouvez supprimer les instantanés de base de données gérés par RDS Custom for SQL Server lorsque vous n'en avez plus besoin. La procédure de suppression est la même pour les instances de base de données Amazon RDS et RDS Custom.
Les instantanés Amazon EBS des volumes binaires et racine restent dans votre compte plus longtemps, car ils peuvent être liés à certaines instances exécutées dans votre compte ou à d'autres instantanés RDS Custom for SQL Server. Ces instantanés EBS sont automatiquement supprimés dès qu'ils ne sont plus liés à des ressources RDS Custom for SQL Server existantes (instances ou sauvegardes de base de données).
## Console
**Pour supprimer un instantané d'une instance de base de données RDS Custom**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Snapshots**.
1. Choisissez l'instantané de base de données à supprimer.
1. Pour **Actions**, choisissez **Delete snapshot** (Supprimer la pile).
1. Dans la page de confirmation, sélectionnez **Supprimer**.
## AWS CLI
Pour supprimer un instantané RDS Custom, utilisez la commande AWS CLI [delete-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-snapshot.html).
L'option suivante est requise :
+ `--db-snapshot-identifier` – L'instantané à supprimer
L'exemple suivant supprime l'instantané de base de données `my-custom-snapshot`.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds delete-db-snapshot \
2. --db-snapshot-identifier my-custom-snapshot
```
Pour Windows :
```
1. aws rds delete-db-snapshot ^
2. --db-snapshot-identifier my-custom-snapshot
```
# Suppression des sauvegardes automatisées RDS Custom for SQL Server
Vous pouvez supprimer les sauvegardes automatisées conservées de RDS Custom for SQL Server quand elles ne sont plus nécessaires. La procédure est la même que la procédure de suppression des sauvegardes Amazon RDS.
## Console
**Pour supprimer une sauvegarde automatisée conservée**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Automated backups** (Sauvegardes automatisées).
1. Choisissez **Retained (Conservées)**.
1. Choisissez la sauvegarde automatisée conservée que vous souhaitez supprimer.
1. Pour **Actions**, choisissez **Supprimer**.
1. Dans la page de confirmation, entrez **delete me** et choisissez **Delete (Supprimer)**.
## AWS CLI
Vous pouvez supprimer une sauvegarde automatisée conservée à l'aide de la commande de l'AWS CLI [delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html).
L'option suivante est utilisée pour supprimer une sauvegarde automatisée conservée.
+ `--dbi-resource-id` – L'identifiant de la ressource de l'instance de base de données RDS Custom source.
Vous pouvez rechercher l'identifiant ressource de l'instance de base de données source d'une sauvegarde automatisée conservée en utilisant la commande de AWS CLI [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html).
L’exemple suivant supprime la sauvegarde automatisée conservée avec l’identifiant de ressource d’instance de base de données `custom-db-123ABCEXAMPLE`.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds delete-db-instance-automated-backup \
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
Pour Windows :
```
1. aws rds delete-db-instance-automated-backup ^
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
# Copie d’un instantané de base de données Amazon RDS Custom for SQL Server
Avec RDS Custom for SQL Server, vous pouvez copier des sauvegardes automatisées et des instantanés de base de données manuels. Après avoir copié un instantané, la copie créée est un instantané manuel. Vous pouvez effectuer plusieurs copies d’une sauvegarde automatisée ou d’un instantané manuel, mais chaque copie doit avoir un identifiant unique.
Vous ne pouvez copier un instantané d'un même AWS compte que sur différents sites Régions AWS où RDS Custom for SQL Server est disponible. Les opérations suivantes ne sont actuellement pas prises en charge :
+ Copie d’instantanés de base de données dans la même Région AWS.
+ Copier des instantanés de base de données entre AWS comptes.
RDS Custom for SQL Server prend en charge la copie d’instantané incrémentielle. Pour plus d’informations, consultez [Considérations relatives à la copie d’instantanés incrémentielle](USER_CopySnapshot.md#USER_CopySnapshot.Incremental).
**Topics**
+ [Limitations](#custom-copying-snapshot-sqlserver.Limitations)
+ [Gestion du chiffrement](#custom-copying-snapshot-sqlserver.Encryption)
+ [Copie entre régions](#custom-copying-snapshot-sqlserver.XRCopy)
+ [Instantanés d’instances de base de données créés avec des versions de moteur personnalisées (CEV)](#custom-copying-snapshot-sqlserver.CEVSnap)
+ [Accorder les autorisations requises à votre principal IAM](#custom-copying-snapshot-sqlserver.GrantPermIAM)
+ [Copie d’un instantané de base de données](#custom-copying-snapshot-sqlserver.CopyingDBSnapshot)
## Limitations
Les limites suivantes s’appliquent à la copie d’un instantané de base de données pour RDS Custom for SQL Server :
+ Si vous supprimez un instantané source avant que l’instantané cible ne soit disponible, la copie d’instantané peut échouer. Vérifiez que l’instantané cible a le statut `AVAILABLE` avant de supprimer l’instantané source.
+ Vous ne pouvez pas spécifier un nom de groupe d’options ou copier un groupe d’options dans votre demande de copie d’instantané de base de données.
+ Si vous supprimez des AWS ressources dépendantes de l'instantané de base de données source avant ou pendant le processus de copie, votre demande de capture instantanée de copie peut échouer de manière asynchrone.
+ Si vous supprimez le fichier de sauvegarde SMK (Service Master Key) de votre instance de base de données source stockée dans le compartiment S3 géré par RDS Custom de votre compte, la copie de l’instantané de base de données se fait de manière asynchrone. Cependant, les fonctionnalités de SQL Server qui dépendent de SMK, telles que les bases de données compatibles TDE, rencontrent des problèmes. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés à l’état PENDING\$1RECOVERY pour les bases de données compatibles TDE dans RDS Custom for SQL Server](custom-troubleshooting-sqlserver.md#custom-troubleshooting-sqlserver.pending_recovery).
+ La copie d'instantanés de base de données au sein d'une même base de données n' Région AWS est actuellement pas prise en charge.
+ La copie d'instantanés de base de données entre AWS comptes n'est actuellement pas prise en charge.
Les limites de la copie d’un instantané de base de données pour Amazon RDS s’appliquent également à RDS Custom for SQL Server. Pour plus d’informations, consultez [Limitations](USER_CopySnapshot.md#USER_CopySnapshot.Limitations).
## Gestion du chiffrement
Toutes les instances et tous les instantanés de base de données RDS Custom for SQL Server sont chiffrés à l’aide de clés KMS. Vous ne pouvez copier un instantané chiffré que sur un instantané chiffré. Vous devez donc spécifier une clé KMS valide dans la destination Région AWS pour votre demande de copie d'instantané de base de données.
L’instantané source reste chiffré pendant tout le processus de copie. Amazon RDS utilise le chiffrement d’enveloppe pour protéger les données pendant l’opération de copie avec la clé KMS de la Région AWS de destination spécifiée. Pour plus d’informations, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) dans le *Guide du développeur AWS Key Management Service *.
## Copie entre régions
Vous pouvez copier les instantanés de base de données entre Régions AWS. Toutefois, il existe certaines contraintes et considérations en ce qui concerne la copie d’instantanés entre régions.
### Autoriser RDS à communiquer entre eux pour la copie d' Régions AWS instantanés
Après qu’une demande de copie d’instantané de base de données entre régions a été traitée avec succès, RDS démarre la copie. Une demande d’autorisation permettant à RDS d’accéder à l’instantané source est créée. Cette demande d’autorisation associe l’instantané de base de données source à l’instantané de base de données cible. Cela permet à RDS de ne copier que vers l’instantané cible spécifié.
RDS vérifie l’autorisation à l’aide de l’autorisation `rds:CrossRegionCommunication` dans le rôle IAM lié au service. Si la copie est autorisée, RDS peut communiquer avec la région source et terminer la copie.
RDS n'a pas accès aux instantanés de base de données qui n'étaient pas autorisés auparavant par une demande de copieDBSnapshot . L’autorisation est révoquée lorsque la copie est terminée.
RDS utilise le rôle lié au service afin de vérifier l’autorisation dans la région source. La copie échoue si vous supprimez le rôle lié au service pendant le processus de copie.
Pour plus d’informations, consultez [Utilisation des rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *.
### Utilisation des AWS Security Token Service informations d'identification
Les jetons de session provenant du point de terminaison global AWS Security Token Service (AWS STS) ne sont valides Régions AWS que s'ils sont activés par défaut (régions commerciales). Si vous utilisez les informations d'identification issues de l'opération d'`assumeRole`API dans AWS STS, utilisez le point de terminaison régional si la région source est une région optionnelle. Sinon, la demande échoue. Vos informations d'identification doivent être valides dans les deux régions, ce qui n'est vrai pour les régions optionnelles que lorsque vous utilisez le point de AWS STS terminaison régional.
Pour utiliser le point de terminaison global, assurez-vous qu’il est activé dans les opérations pour les deux régions. Définissez le point de terminaison global sur « `Valid` in all » Régions AWS dans les paramètres du AWS STS compte.
Pour plus d’informations, consultez [Gestion de AWS STS dans une Région AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *.
## Instantanés d’instances de base de données créés avec des versions de moteur personnalisées (CEV)
Pour un instantané de base de données d’une instance de base de données utilisant une [version de moteur personnalisée (CEV)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-cev-sqlserver.html), RDS associe la CEV à l’instantané de base de données. Pour copier un instantané de base de données source associé à un CEV Régions AWS, RDS copie le CEV ainsi que le cliché de base de données source dans la région de destination.
Si vous copiez plusieurs instantanés de base de données associés à la même CEV vers la même région de destination, la première demande de copie copie la CEV associée. Le processus de copie des demandes suivantes trouve la CEV initialement copiée et l’associe aux copies d’instantanés de base de données suivantes. La copie de la CEV existante doit être à l’état `AVAILABLE` pour être associée aux copies d’instantanés de base de données.
Pour copier un instantané de base de données associé à une CEV, la politique IAM du demandeur doit disposer des autorisations nécessaires pour autoriser à la fois la copie de l’instantané de base de données et la copie de la CEV associée. Les autorisations suivantes sont nécessaires dans la politique IAM de votre demandeur pour autoriser la copie de la CEV associée :
+ `rds:CopyCustomDBEngineVersion` : le principal IAM de votre demandeur doit avoir l’autorisation de copier la CEV source dans la région cible avec l’instantané de base de données source. La demande de copie d’instantané échoue en raison d’erreurs d’autorisation si le principal IAM de votre demandeur n’est pas autorisé à copier la CEV source.
+ `ec2:CreateTags` : l’AMI EC2 sous-jacente de la CEV source est copiée dans la région cible dans le cadre de la copie de la CEV. RDS Custom tente de baliser l’AMI avec la balise `AWSRDSCustom` avant de copier l’AMI. Assurez-vous que le principal IAM du demandeur est autorisé à créer la balise par rapport à l’AMI sous-jacente à la CEV source dans la région source.
Pour plus d’informations sur les autorisations de copie de la CEV, consultez [Accorder les autorisations requises à votre principal IAM](#custom-copying-snapshot-sqlserver.GrantPermIAM).
## Accorder les autorisations requises à votre principal IAM
Assurez-vous de disposer d’un accès suffisant pour copier un instantané de base de données RDS Custom for SQL Server. Le rôle ou l’utilisateur IAM (appelé principal IAM) chargé de copier un instantané de base de données à l’aide de la console ou de l’interface de ligne de commande doit disposer de l’une des politiques suivantes pour que la création d’instance de base de données réussisse :
+ La politique `AdministratorAccess` ou
+ La politique `AmazonRDSFullAccess` avec les autorisations supplémentaires suivantes :
```
s3:CreateBucket
s3:GetBucketPolicy
s3:PutBucketPolicy
kms:CreateGrant
kms:DescribeKey
ec2:CreateTags
```
RDS Custom utilise ces autorisations lors de la copie d’instantanés entre plusieurs Régions AWS. Ces autorisations configurent les ressources de votre compte qui sont requises pour les opérations RDS Custom. Pour plus d'informations sur l'autorisation `kms:CreateGrant`, consultez [AWS KMS key gestion](Overview.Encryption.Keys.md).
L’exemple de politique JSON suivant accorde les autorisations requises en plus de la politique `AmazonRDSFullAccess`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateS3BucketAndReadWriteBucketPolicy",
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketPolicy",
"s3:GetBucketPolicy"
],
"Resource": "arn:aws:s3:::do-not-delete-rds-custom-*"
},
{
"Sid": "CreateKmsGrant",
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "CreateEc2Tags",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "*"
}
]
}
```
------
**Note**
Assurez-vous que les autorisations répertoriées ne sont pas limitées par les politiques de contrôle des services (SCPs), les limites d'autorisation ou les politiques de session associées au principal IAM.
Si vous utilisez des conditions comportant des clés de contexte dans la politique IAM du demandeur, certaines conditions peuvent provoquer l’échec de la demande. Pour plus d’informations sur les pièges courants liés aux conditions de la politique IAM, consultez [Demander une copie d'instantané de bases de données entre régions](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions.Policy).
## Copie d’un instantané de base de données
Procédez comme suit pour copier un instantané de base de données. Pour chaque AWS compte, vous pouvez copier jusqu'à 20 instantanés de base de données à la fois de l'un Région AWS à l'autre. Si vous copiez un instantané de base de données vers un autre Région AWS, vous créez un instantané de base de données manuel qui y est conservé Région AWS. La copie d'un instantané de base de données depuis la source Région AWS entraîne des frais de transfert de données Amazon RDS. Pour plus d’informations sur la tarification du transfert des données, consultez [Tarification d’Amazon RDS](https://aws.amazon.com/rds/pricing/).
Une fois que la copie instantanée de base de données a été créée dans le nouveau Région AWS, elle se comporte de la même manière que tous les autres instantanés de base de données qu'elle contient. Région AWS
Vous pouvez copier un instantané de base de données à l'aide de AWS Management Console AWS CLI, ou de l'API Amazon RDS.
------
#### [ Console ]
La procédure suivante copie un instantané de base de données RDS Custom for SQL Server à l’aide de la AWS Management Console.
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Snapshots (Instantanés)**.
1. Sélectionnez l’instantané de base de données RDS Custom for SQL Server que vous voulez copier.
1. Dans le menu déroulant **Actions**, choisissez **Copier un instantané**.
![\[La page Copie d’instantanés dans la console Amazon RDS. Les paramètres sont chargés dans la page.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/XRSC-Snapshot-Copy.png)
1. Pour copier le snapshot de base de données vers un autre Région AWS, définissez **Destination Region** sur la valeur requise.
**Note**
La destination Région AWS doit disposer de la même version de moteur de base de données disponible que la source Région AWS.
1. Pour **Nouvel identifiant d’instantané de base de données**, saisissez un nom unique pour l’instantané de base de données. Vous pouvez effectuer plusieurs copies d’une sauvegarde automatisée ou d’un instantané manuel, mais chaque copie doit avoir un identifiant unique.
1. (Facultatif) Pour copier les balises et les valeurs de l'instantané vers la copie de cet instantané, choisissez **Copier les balises**.
1. Pour **Chiffrement**, spécifiez l’identifiant de clé KMS à utiliser pour chiffrer la copie de l’instantané de base de données.
**Note**
RDS Custom for SQL Server chiffre tous les instantanés de base de données. Vous ne pouvez pas créer d’instantané de base de données non chiffré.
1. Choisissez **Copier un instantané**.
RDS Custom for SQL Server crée une copie d’instantané de base de données de votre instance de base de données dans la Région AWS de votre choix.
------
#### [ AWS CLI ]
Vous pouvez copier un instantané de base de données RDS Custom pour SQL Server à l'aide de la AWS CLI commande [https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html). Si vous copiez le cliché dans un nouveau Région AWS, exécutez la commande dans le nouveau Région AWS. Les options suivantes sont utilisées pour copier un instantané de base de données. Toutes les options ne sont pas requises pour tous les scénarios.
+ `--source-db-snapshot-identifier` : identifiant de l’instantané de base de données source.
+ Si l'instantané source se trouve dans un emplacement différent Région AWS de celui de la copie, spécifiez un ARN d'instantané de base de données valide. Par exemple, `arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678`.
+ `--target-db-snapshot-identifier` : identifiant de la nouvelle copie de l’instantané de base de données.
+ `--kms-key-id` : identifiant de clé KMS pour un instantané de base de données chiffré. L’identifiant de clé KMS est l’ARN (Amazon Resource Name), l’identifiant de clé ou l’alias de clé pour la clé KMS.
+ Si vous copiez un instantané chiffré vers une autre Région AWS, vous devez spécifier une clé KMS pour la Région AWS de destination. Les clés KMS sont spécifiques à l'endroit dans Région AWS lequel elles ont été créées et vous ne pouvez pas utiliser les clés de chiffrement les unes Région AWS des autres, Région AWS sauf si une clé multirégionale est utilisée. Pour plus d’informations sur les clés KMS multi-régions, consultez [Utilisation de clés multi-régions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html).
+ `--copy-tags` : inclut les balises et les valeurs de l’instantané source vers la copie de cet instantané.
Les options suivantes ne sont pas prises en charge pour copier un instantané de base de données RDS Custom for SQL Server :
+ `--copy-option-group `
+ `--option-group-name`
+ `--pre-signed-url`
+ `--target-custom-availability-zone`
L’exemple de code suivant copie un instantané de base de données chiffré à partir de la région USA Ouest (Oregon) vers la région USA Est (Virginie du Nord). Exécutez la commande dans la région de destination (us-east-1).
Pour Linux, macOS ou Unix :
```
aws rds copy-db-snapshot \
--region us-east-1 \
--source-db-snapshot-identifier arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678 \
--target-db-snapshot-identifier mydbsnapshotcopy \
--kms-key-id a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
```
Pour Windows :
```
aws rds copy-db-snapshot ^
--region us-east-1 ^
--source-db-snapshot-identifier arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678 ^
--target-db-snapshot-identifier mydbsnapshotcopy ^
--kms-key-id a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
```
------
#### [ RDS API ]
[Vous pouvez copier un instantané de base de données personnalisé RDS pour SQL Server à l'aide de l'opération Copy de l'API Amazon RDS. DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CopyDBSnapshot.html) Si vous copiez l'instantané dans une nouvelle Région AWS, exécutez l'action dans cette nouvelle Région AWS. Les paramètres suivants sont utilisés pour copier un instantané de base de données. Tous les paramètres ne sont pas requis :
+ `SourceDBSnapshotIdentifier` : identifiant de l’instantané de base de données source.
+ Si l'instantané source se trouve dans un emplacement différent Région AWS de celui de la copie, spécifiez un ARN d'instantané de base de données valide. Par exemple, `arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678`.
+ `TargetDBSnapshotIdentifier` : identifiant de la nouvelle copie de l’instantané de base de données.
+ `KmsKeyId` : identifiant de clé KMS pour un instantané de base de données chiffré. L’identifiant de clé KMS est l’ARN (Amazon Resource Name), l’identifiant de clé ou l’alias de clé pour la clé KMS.
+ Si vous copiez un instantané chiffré vers une autre Région AWS, vous devez spécifier une clé KMS pour la Région AWS de destination. Les clés KMS sont spécifiques à l'endroit dans Région AWS lequel elles ont été créées et vous ne pouvez pas utiliser les clés de chiffrement les unes Région AWS des autres, Région AWS sauf si une clé multirégionale est utilisée. Pour plus d’informations sur les clés KMS multi-régions, consultez [Utilisation de clés multi-régions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html).
+ `CopyTags` : affectez à ce paramètre la valeur `true` pour copier les balises et les valeurs de l’instantané source vers la copie de cet instantané. La valeur par défaut est `false`.
Les options suivantes ne sont pas prises en charge pour copier un instantané de base de données RDS Custom for SQL Server :
+ `CopyOptionGroup`
+ `OptionGroupName`
+ `PreSignedUrl`
+ `TargetCustomAvailabilityZone`
Le code suivant crée une copie d’instantané, avec le nouveau nom `mydbsnapshotcopy`, dans la région USA Est (Virginie du Nord).
```
https://rds.us-east-1.amazonaws.com/
?Action=CopyDBSnapshot
&KmsKeyId=a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
&SourceDBSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-west-2%3A123456789012%3Asnapshot%3Ainstance1-snapshot-12345678
&TargetDBSnapshotIdentifier=mydbsnapshotcopy
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20161117T221704Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=da4f2da66739d2e722c85fcfd225dc27bba7e2b8dbea8d8612434378e52adccf
```
------
# Migration d'une base de données sur site vers Amazon RDS Custom for SQL Server
Vous pouvez utiliser le processus suivant pour migrer une base de données Microsoft SQL Server sur site vers Amazon RDS Custom for SQL Server à l'aide de la sauvegarde et de la restauration natives :
1. Effectuez une sauvegarde complète de la base de données sur l'instance de base de données sur site.
1. Chargez le fichier de sauvegarde sur Amazon S3.
1. Téléchargez le fichier de sauvegarde depuis S3 dans votre instance de base de données RDS Custom for SQL Server.
1. Restaurez une base de données à l'aide du fichier de sauvegarde téléchargé sur l'instance de base de données RDS Custom for SQL Server.
Ce processus explique la migration d'une base de données sur site vers RDS Custom for SQL Server en utilisant la sauvegarde et la restauration complètes natives. Pour réduire le temps de basculement pendant le processus de migration, vous pouvez également envisager d'utiliser des sauvegardes différentielles ou de journaux.
Pour obtenir des informations générales sur la sauvegarde et la restauration natives pour RDS for SQL Server, consultez [Importation et exportation de bases de données SQL Server à l'aide de la sauvegarde et de la restauration natives](SQLServer.Procedural.Importing.md).
**Topics**
+ [Prérequis](#custom-migrating.prereqs)
+ [Sauvegarde en cours de la base de données sur site](#custom-migrating.backup)
+ [Chargement du fichier de sauvegarde sur Amazon S3.](#custom-migrating.upload)
+ [Téléchargement du fichier de sauvegarde à partir d'Amazon S3](#custom-migrating.upload)
+ [Restauration du fichier de sauvegarde sur l'instance de base de données RDS Custom for SQL Server](#custom-migrating.restore)
## Prérequis
Avant de migrer la base de données, effectuez les tâches suivantes :
1. Configurez la connexion Bureau à distance (RDP) pour votre instance de base de données RDS Custom for SQL Server. Pour de plus amples informations, veuillez consulter [Connexion à votre instance de base de données RDS Custom à l'aide de RDP](custom-creating-sqlserver.rdp.md).
1. Configurez l'accès à Amazon S3 afin de pouvoir charger et télécharger le fichier de sauvegarde de la base de données.
## Sauvegarde en cours de la base de données sur site
Vous utilisez la sauvegarde native de SQL Server pour effectuer une sauvegarde complète de la base de données sur l'instance de base de données sur site.
L'exemple suivant montre une sauvegarde d'une base de données appelée `mydatabase`, avec l'option `COMPRESSION` spécifiée pour réduire la taille du fichier de sauvegarde.
**Pour sauvegarder la base de données sur site**
1. À l'aide de SQL Server Management Studio (SSMS), connectez-vous à l'instance SQL Server sur site.
1. Exécutez la commande T-SQL suivante :
```
backup database mydatabase to
disk ='C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\mydb-full-compressed.bak'
with compression;
```
## Chargement du fichier de sauvegarde sur Amazon S3.
Vous utilisez la AWS Management Console pour charger le fichier de sauvegarde `mydb-full-compressed.bak` sur Amazon S3.
**Chargez le fichier de sauvegarde sur S3**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Sous **Compartiments**, sélectionnez le nom du compartiment sur lequel vous souhaitez charger le fichier.
1. Sélectionnez **Charger**.
1. Dans la fenêtre **Charger**, procédez de l'une des manières suivantes :
+ Faites glisser `mydb-full-compressed.bak` dans la fenêtre **Charger**.
+ Sélectionnez **Ajouter un fichier**, `mydb-full-compressed.bak`, puis **Ouvrir**.
Amazon S3 charge votre fichier de sauvegarde en tant qu'objet S3. Lorsque le chargement est terminé, un message de succès s’affiche sur la page **Load: status** (Charger : statut).
## Téléchargement du fichier de sauvegarde à partir d'Amazon S3
Vous utilisez la console pour télécharger le fichier de sauvegarde depuis S3 dans votre instance de base de données RDS Custom for SQL Server.
**Pour télécharger le fichier de sauvegarde à partir de S3**
1. Connectez-vous à votre instance de base de données RDS Custom for SQL Server à l'aide de RDP.
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon S3 à l’adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Dans la liste **Compartiments**, choisissez le nom du compartiment qui contient votre fichier de sauvegarde.
1. Sélectionnez le fichier de sauvegarde `mydb-full-compressed.bak`.
1. Dans **Actions**, sélectionnez **Télécharger en tant que**.
1. Ouvrez le menu contextuel (clic droit) pour le lien fourni, puis choisissez **Enregistrer sous**.
1. Enregistrez `mydb-full-compressed.bak` dans le répertoire `D:\rdsdbdata\BACKUP`.
## Restauration du fichier de sauvegarde sur l'instance de base de données RDS Custom for SQL Server
Vous utilisez la restauration native SQL Server pour restaurer le fichier de sauvegarde sur votre instance de base de données RDS Custom for SQL Server.
Dans cet exemple, l'option `MOVE` est spécifiée, car les répertoires de données et de fichiers journaux sont différents de l'instance de base de données sur site.
**Pour restaurer le fichier de sauvegarde**
1. Connectez-vous à votre instance de base de données RDS Custom for SQL Server à l'aide de SSMS.
1. Exécutez la commande T-SQL suivante :
```
restore database mydatabase from disk='D:\rdsdbdata\BACKUP\mydb-full-compressed.bak'
with move 'mydatabase' to 'D:\rdsdbdata\DATA\mydatabase.mdf',
move 'mydatabase_log' to 'D:\rdsdbdata\DATA\mydatabase_log.ldf';
```
# Mises à jour du système d'exploitation RDS Custom for SQL Server
RDS Custom pour SQL Server fournit les méthodes suivantes pour appliquer les mises à jour du système d'exploitation à vos instances RDS Provisided Engine Version (RPEV) :
+ *actions de maintenance liées aux mises à jour du système*
+ *mises à niveau des versions mineures de la base*
+ Les mises à niveau des versions mineures du moteur de base de données à l'aide de RPEV incluent des mises à jour du système d'exploitation. Cette approche est particulièrement utile si vous souhaitez combiner les mises à jour du système d'exploitation avec les mises à niveau des versions mineures de SQL Server. Pour de plus amples informations, veuillez consulter [Mise à niveau d’une instance de base de données pour Amazon RDS Custom for SQL Server](custom-upgrading-sqlserver.md).
## Scénarios de mise à jour du système d'exploitation
Il existe deux méthodes pour gérer les mises à jour du système d'exploitation pour vos instances RDS Custom for SQL Server :
+ Pour les instances mono-AZ, l'instance n'est pas disponible lors de la mise à jour du système d'exploitation.
+ Pour les déploiements multi-AZ, RDS applique les mises à jour du système d'exploitation de la manière suivante :
+ RDS effectue d'abord une mise à jour du système d'exploitation sur l'instance de secours.
+ RDS bascule vers l'instance de base de données de secours mise à niveau, ce qui en fait la nouvelle instance de base de données principale.
+ Enfin, RDS effectue une mise à jour du système d'exploitation sur la nouvelle instance de base de données de secours.
Le temps d'arrêt pour les déploiements multi-AZ correspond au temps nécessaire au basculement.
## Appliquer les mises à jour du système d'exploitation à l'aide d'actions de maintenance liées aux mises à jour
Pour appliquer les mises à jour du système d'exploitation à vos instances Amazon RDS RPEV, vous pouvez utiliser l'API AWS Management Console AWS CLI, ou RDS. Pour de plus amples informations, veuillez consulter [Mises à jour du système d’exploitation pour les instances de base de données RDS](USER_UpgradeDBInstance.Maintenance.md#OS_Updates).
**Example**
Pour Linux, macOS ou Unix :
**Étape 1 : Vérifiez les mises à jour disponibles**
Utilisez la `describe-pending-maintenance-actions` commande pour voir si des mises à jour du système d'exploitation sont disponibles pour vos instances :
```
aws rds describe-pending-maintenance-actions
```
Exemple de réponse :
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
Le type d'action `system-update` indique qu'une mise à jour du système d'exploitation est disponible pour votre instance.
**Étape 2 : appliquer la mise à jour du système d'exploitation**
Utilisez la `apply-pending-maintenance-action` commande pour planifier la mise à jour :
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance \
--apply-action system-update \
--opt-in-type immediate
```
L'`opt-in-type`entrée comporte les options suivantes :
+ `immediate`: Appliquez la mise à jour immédiatement
+ `next-maintenance`: appliquez la mise à jour lors de la prochaine fenêtre de maintenance planifiée
+ `undo-opt-in`: Annuler une mise à jour planifiée précédemment
Exemple de réponse :
```
{
"ResourcePendingMaintenanceActions": {
"ResourceIdentifier": "arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"AutoAppliedAfterDate": "2024-04-10T20:41:01.695000+00:00",
"ForcedApplyDate": "2024-04-10T20:41:01.694000+00:00",
"CurrentApplyDate": "2024-04-10T20:41:01.695000+00:00",
"Description": "New Operating System update is available"
}
]
}
}
```
## notifications de mise à jour du système
Pour être averti de la disponibilité d’un nouveau correctif du système d’exploitation facultatif, vous pouvez vous inscrire à [RDS-EVENT-0230](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html#RDS-EVENT-0230) dans la catégorie des événements d’application de correctifs de sécurité. Pour plus d'informations sur l'abonnement aux événements RDS, consultez la section [S'abonner aux notifications d'événements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html).
## Considérations
Les considérations et limitations suivantes s'appliquent aux mises à jour du système d'exploitation :
+ Les personnalisations du système d'exploitation apportées au lecteur C : \$1 ne sont pas conservées lors des mises à jour du système d'exploitation.
+ Nous vous recommandons de prendre un instantané manuel avant d'appliquer les mises à jour.
# Mise à niveau d’une instance de base de données pour Amazon RDS Custom for SQL Server
Vous pouvez mettre à niveau une instance de base de données Amazon RDS Custom for SQL Server en la modifiant pour qu’elle utilise une nouvelle version du moteur de base de données. Pour obtenir des informations générales sur la mise à niveau des instances de base de données, consultez [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
**Topics**
+ [Présentation des mises à niveau dans RDS Custom for SQL Server](#custom-upgrading-sqlserver.Overview)
+ [Mise à niveau des versions mineures et majeures de moteur](#custom-upgrading-sqlserver.Upgrade)
+ [Niveau de compatibilité de base de données](#custom-upgrading-sqlserver.Major.Compatibility)
## Présentation des mises à niveau dans RDS Custom for SQL Server
Amazon RDS Custom for SQL Server prend en charge les mises à niveau des versions mineures et majeures. Les mises à niveau mineures peuvent inclure des correctifs de sécurité, des correctifs de bogues et des améliorations du moteur. Microsoft publie ces mises à jour sous forme de mises à jour cumulatives (CU). Les mises à niveau des versions majeures introduisent de nouvelles fonctionnalités et des modifications du moteur entre les versions, comme la mise à niveau de SQL Server 2019 vers 2022. Vous pouvez appliquer les deux mises à niveau immédiatement ou pendant les fenêtres de maintenance planifiées. Pour éviter d’éventuels problèmes de rétrocompatibilité, nous vous recommandons de tester vos applications dans un environnement hors production avant de procéder à la mise à niveau.
RDS Custom for SQL Server vous permet de mettre à niveau une version de moteur fournie par RDS (RPEV) ou une version de moteur personnalisée (CEV).
+ Les versions de moteur fournies par RDS (RPEV) contiennent des correctifs de système d’exploitation (OS) à jour et des mises à jour cumulatives (CU) de SQL Server.
+ Pour une version de moteur personnalisée (CEV), vous devez suivre un processus en deux étapes. Créez d’abord une nouvelle CEV avec votre version cible de SQL Server, consultez [Préparation à la création d'une version CEV pour RDS Custom pour SQL Server](custom-cev-sqlserver.preparing.md). Cette version cible doit être égale ou plus récente que votre version actuelle. Une fois la nouvelle CEV créée, modifiez votre instance de base de données pour utiliser cette nouvelle version. Pour plus d’informations, consultez [Mise à niveau de la version mineure de la CEV Amazon RDS Custom for SQL Server avec Multi-AZ](https://aws.amazon.com/blogs/database/performing-a-minor-version-upgrade-for-amazon-rds-custom-for-sql-server-cev-with-multi-az/).
N’appliquez pas de mises à jour cumulatives de SQL Server sur place à votre instance RDS Custom en cours d’exécution. Une fois que vous avez créé une CEV avec une version spécifique de SQL Server (par exemple, SQL Server 2022 CU16), l’application d’une nouvelle mise à jour cumulative directement à l’instance la fait sortir du périmètre de prise en charge et signale l’erreur `SP-S3006`. Pour appliquer un correctif à une instance SQL Server existante à l’aide d’une CEV, créez une nouvelle CEV incluant la mise à jour cumulative souhaitée, puis modifiez votre instance existante pour passer à la nouvelle CEV.
Si vous mettez à niveau une instance de base de données RDS Custom for SQL Server dans un déploiement multi-AZ, RDS Custom for SQL Server effectue des mises à niveau propagées pour votre instance. Cette approche minimise la durée d’indisponibilité en mettant à niveau une instance à la fois. RDS exécute les actions suivantes pour effectuer des mises à niveau propagées :
1. Mise à niveau de l’instance de base de données de secours.
1. Basculement vers l’instance de base de données de secours mise à niveau, ce qui en fait la nouvelle instance de base de données principale.
1. Mise à niveau de la nouvelle instance de base de données de secours.
La durée d’indisponibilité de l’instance de base de données pour les déploiements multi-AZ correspond au temps nécessaire au basculement.
Les limitations suivantes s’appliquent à la modification d’une instance de base de données RDS Custom for SQL Server :
+ Les options de base de données personnalisées et les groupes de paramètres ne sont pas pris en charge.
+ Tous les volumes de stockage supplémentaires que vous attachez à votre instance de base de données RDS Custom for SQL Server ne sont pas attachés après la mise à niveau.
+ Pour les CEV, l’application sur place des mises à jour cumulatives de SQL Server n’est pas prise en charge et entraîne le retrait de l’instance du périmètre de support.
## Mise à niveau des versions mineures et majeures de moteur
Les mises à niveau mineures et majeures de moteur sont irréversibles et doivent toujours être effectuées vers une version plus récente. Pour identifier les versions cibles disponibles, utilisez la AWS Management Console et choisissez parmi les versions disponibles lors de la modification de votre instance de base de données. Vous pouvez également utiliser la commande de la CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) ou la commande d’API RDS [DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine custom-sqlserver-se \
--engine-version 15.00.4322.2.v1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" \
--output table
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4322.2.v1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output table
```
Le résultat indique les versions de moteur cible disponibles :
```
--------------------------
|DescribeDBEngineVersions|
+------------------------+
| EngineVersion |
+------------------------+
| 15.00.4410.1.v1 |
| 15.00.4415.2.v1 |
| 15.00.4430.1.v1 |
| 16.00.4165.4.v1 |
| 16.00.4175.1.v1 |
| 16.00.4185.3.v1 |
+------------------------+
```
Après avoir identifié votre version cible, utilisez la AWS Management Console et suivez les instructions figurant dans [Modification d'une instance de base de données RDS Custom for SQL Server](custom-managing.modify-sqlserver.md). Vous pouvez également utiliser la commande de l’interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) ou la commande d’API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier DB_INSTANCE_IDENTIFIER \
--engine-version ENGINE_VERSION \
--allow-major-version-upgrade \
--region Region \
--no-apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier DB_INSTANCE_IDENTIFIER ^
--engine-version ENGINE_VERSION ^
--allow-major-version-upgrade ^
--region Region ^
--no-apply-immediately
```
**Note**
Vous devez inclure le paramètre `--allow-major-version-upgrade` pour effectuer des mises à niveau de version majeure.
## Niveau de compatibilité de base de données
Vous pouvez utiliser les niveaux de compatibilité de base de données Microsoft SQL Server afin de régler certains comportements de base de données pour imiter les versions précédentes de SQL Server. Pour plus d’informations, consultez [Niveau de compatibilité](https://msdn.microsoft.com/en-us/library/bb510680.aspx) dans la documentation de Microsoft.
Lorsque vous mettez à niveau votre instance de base de données, toutes les bases de données existantes restent à leur niveau de compatibilité initial. Par exemple, si vous mettez à niveau SQL Server 2019 vers SQL Server 2022, toutes les bases de données existantes auront le niveau de compatibilité 150. Toute nouvelle base de données créée après la mise à niveau a le niveau de compatibilité 160.
Vous pouvez modifier le niveau de compatibilité d’une base de données en utilisant la commande ALTER DATABASE. Par exemple, pour modifier une base de données nommée `customeracct` afin qu’elle soit compatible avec SQL Server 2022, exécutez la commande suivante :
```
1. ALTER DATABASE customeracct SET COMPATIBILITY_LEVEL = 160
```
# Résolution des problèmes de base de données pour Amazon RDS Custom for SQL Server
Le modèle de responsabilité partagée de RDS Custom fournit un accès au niveau du shell du système d'exploitation et un accès administrateur de base de données. RDS Custom exécute les ressources de votre compte, contrairement à Amazon RDS qui exécute les ressources d'un compte système. Un meilleur accès s'accompagne de responsabilités plus importantes. Dans les sections suivantes, vous apprendrez à résoudre les problèmes liés aux instances de base de données Amazon RDS Custom for SQL Server.
**Note**
Cette section explique comment résoudre les problèmes de RDS Custom for SQL Server. Pour la résolution des problèmes liés à RDS Custom for Oracle, consultez [Résolution des problèmes de base de données pour Amazon RDS Custom for Oracle](custom-troubleshooting.md).
**Topics**
+ [Affichage des événements RDS Custom](#custom-troubleshooting-sqlserver.support-perimeter.viewing-events)
+ [Souscription à des événements RDS Custom](#custom-troubleshooting-sqlserver.support-perimeter.subscribing)
+ [Résolution des erreurs de version CEV pour RDS Custom for SQL Server](#custom-troubleshooting-sqlserver.cev)
+ [Correction des configurations non prises en charge dans RDS Custom for SQL Server](#custom-troubleshooting-sqlserver.fix-unsupported)
+ [Résolution des problèmes liés à `Storage-Full` dans RDS Custom for SQL Server](#custom-troubleshooting-storage-full)
+ [Résolution des problèmes liés à l’état PENDING\$1RECOVERY pour les bases de données compatibles TDE dans RDS Custom for SQL Server](#custom-troubleshooting-sqlserver.pending_recovery)
## Affichage des événements RDS Custom
La procédure d'affichage est la même pour les instances de base de données RDS Custom et Amazon RDS. Pour de plus amples informations, veuillez consulter [Affichage d’événements Amazon RDS](USER_ListEvents.md).
Pour afficher la notification d'événement personnalisée RDS à l'aide de AWS CLI, utilisez la `describe-events` commande. RDS Custom s'accompagne de plusieurs nouveaux événements. Les catégories d'événements sont les mêmes que pour Amazon RDS. Pour obtenir la liste des événements, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
L'exemple suivant récupère les détails des événements qui se sont produits pour l'instance de base de données RDS Custom spécifiée.
```
1. aws rds describe-events \
2. --source-identifier my-custom-instance \
3. --source-type db-instance
```
## Souscription à des événements RDS Custom
La procédure d'abonnement à des événements est la même pour les instances de base de données RDS Custom et Amazon RDS. Pour de plus amples informations, veuillez consulter [Abonnement à la notification d’événement Amazon RDS](USER_Events.Subscribing.md).
Pour vous abonner à la notification d'événements RDS Custom à l'aide de l'interface de ligne de commande, utilisez la commande `create-event-subscription`. Incluez les paramètres requis suivants :
+ `--subscription-name`
+ `--sns-topic-arn`
L'exemple suivant montre comment créer un abonnement pour les événements de sauvegarde et de restauration d'une instance de base de données RDS Custom dans le compte AWS actuel. Les notifications sont envoyées à une rubrique Amazon Simple Notification Service (Amazon SNS) spécifiée par `--sns-topic-arn`.
```
1. aws rds create-event-subscription \
2. --subscription-name my-instance-events \
3. --source-type db-instance \
4. --event-categories '["backup","recovery"]' \
5. --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events
```
## Résolution des erreurs de version CEV pour RDS Custom for SQL Server
Lorsque vous essayez de créer une version CEV, il se peut que cela échoue. Dans ce cas, RDS Custom émet le message d'événement `RDS-EVENT-0198`. Pour plus d'informations sur l'affichage des événements RDS, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
Utilisez les informations suivantes pour vous aider à traiter les causes possibles.
****
| Message | Suggestions de dépannage |
| --- | --- |
| `Custom Engine Version creation expected a Sysprep’d AMI. Retry creation using a Sysprep’d AMI.` | Exécutez Sysprep sur l'instance EC2 que vous avez créée à partir de l'AMI. Pour plus d'informations sur la préparation d'une AMI à l'aide de Sysprep, consultez [Créer une Amazon Machine Image (AMI) standardisée à l'aide de Sysprep](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#sysprep-using-ec2launchv2). |
| `EC2 Image permissions for image (AMI_ID) weren't found for customer (Customer_ID). Verify customer (Customer_ID) has valid permissions on the EC2 Image.` | Vérifiez que le compte et le profil utilisés pour la création disposent des autorisations requises sur `create EC2 Instance` et `Describe Images` pour l'AMI sélectionnée. |
| `Failed to rebuild databases with server collation (collation name) due to missing setup.exe file for SQL Server.` | Vérifiez que le fichier `setup` est disponible à l'emplacement `C:\Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\SQLnnnn\setup.exe`. |
| `Image (AMI_ID) doesn't exist in your account (ACCOUNT_ID). Verify (ACCOUNT_ID) is the owner of the EC2 image.` | Assurez-vous que l'AMI existe dans le même compte client. |
| `Image id (AMI_ID) isn't valid. Specify a valid image id, and try again.` | Le nom de l'AMI est incorrect. Assurez-vous que l'ID d'AMI correct est fourni. |
| `Image (AMI_ID) operating system platform isn't supported. Specify a valid image, and try again.` | Choisissez une AMI prise en charge dotée de Windows Server avec SQL Server édition Enterprise, Standard ou Web. Choisissez une AMI avec l'un des codes d'opération d'utilisation suivants sur EC2 Marketplace : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/custom-troubleshooting-sqlserver.html) |
| `SQL Server Web Edition isn't supported for creating a Custom Engine Version using Bring Your Own Media. Specify a valid image, and try again.` | Utilisez une image AMI qui contient une édition prise en charge de SQL Server. Pour de plus amples informations, veuillez consulter [Support de version pour RDS Custom pour SQL Server CEVs](custom-cev-sqlserver.preparing.md#custom-cev-sqlserver.preparing.VersionSupport). |
| `The custom engine version can't be the same as the OEV engine version. Specify a valid CEV, and try again.` | Les versions classiques du moteur RDS Custom for SQL Server ne sont pas prises en charge. Par exemple, la version **15.00.4073.23.v1**. Utilisez un numéro de version pris en charge. |
| `The custom engine version isn't in an active state. Specify a valid CEV, and try again.` | La version CEV doit être dans un état `AVAILABLE` pour terminer l'opération. Modifiez la version CEV de `INACTIVE` à `AVAILABLE`. |
| `The custom engine version isn't valid for an upgrade. Specify a valid CEV with an engine version greater or equal to (X), and try again.` | La version CEV cible n'est pas valide. Vérifiez les exigences relatives à un chemin de mise à niveau valide. |
| `The custom engine version isn't valid. Names can include only lowercase letters (a-z), dashes (-), underscores (_), and periods (.). Specify a valid CEV, and try again.` | Respectez la convention de dénomination de version CEV requise. Pour de plus amples informations, veuillez consulter [Exigences relatives à RDS Custom pour SQL Server CEVs](custom-cev-sqlserver.preparing.md#custom-cev-sqlserver.preparing.Requirements). |
| `The custom engine version isn't valid. Specify valid database engine version, and try again. Example: 15.00.4073.23-cev123.` | Une version de moteur de base de données non prise en charge a été fournie. Utilisez une version de moteur de base de données prise en charge. |
| `The expected architecture is (X) for image (AMI_ID), but architecture (Y) was found.` | Utilisez une AMI basée sur l'architecture **x86\$164**. |
| `The expected owner of image (AMI_ID) is customer account ID (ACCOUNT_ID), but owner (ACCOUNT_ID) was found.` | Créez l'instance EC2 à partir de l'AMI pour laquelle vous disposez d'une autorisation. Exécutez Sysprep sur l'instance EC2 pour créer et enregistrer une image de base. |
| `The expected platform is (X) for image (AMI_ID), but platform (Y) was found.` | Utilisez une AMI créée avec la plateforme Windows. |
| `The expected root device type is (X) for image %s, but root device type (Y) was found.` | Créez l'AMI avec le type de périphérique EBS. |
| `The expected SQL Server edition is (X), but (Y) was found.` | Choisissez une AMI prise en charge dotée de Windows Server avec SQL Server édition Enterprise, Standard ou Web. Choisissez une AMI avec l'un des codes d'opération d'utilisation suivants sur EC2 Marketplace : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/custom-troubleshooting-sqlserver.html) |
| `The expected state is (X) for image (AMI_ID), but the following state was found: (Y).` | Assurez-vous que l'AMI est dans l'état `AVAILABLE`. |
| `The provided Windows OS name (X) isn’t valid. Make sure the OS is one of the following: (Y).` | Utilisez un système d'exploitation Windows pris en charge. |
| `Unable to find bootstrap log file in path.` | Vérifiez que le fichier journal est disponible à l'emplacement `C:\Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\Log\Summary.txt`. |
| `RDS expected a Windows build version greater than or equal to (X), but found version (Y).`. | Utilisez une AMI avec une version de build de système d'exploitation minimale de **14393**. |
| `RDS expected a Windows major version greater than or equal to (X), but found version (Y).`. | Utilisez une AMI avec une version majeure de système d'exploitation minimale de **10.0** ou supérieure. |
## Correction des configurations non prises en charge dans RDS Custom for SQL Server
En raison du modèle de responsabilité partagée, il vous incombe de corriger les problèmes de configuration qui redonnent à votre instance de base de données RDS Custom for SQL Server le statut `unsupported-configuration`. Si le problème est lié à l' AWS infrastructure, vous pouvez utiliser la console ou le AWS CLI pour le résoudre. Si le problème concerne le système d’exploitation ou la configuration de la base de données, vous pouvez vous connecter à l’hôte pour le résoudre.
**Note**
Cette section explique comment corriger les configurations non prises en charge dans RDS Custom for SQL Server. Pour obtenir des informations sur RDS Custom for Oracle, consultez [Correction des configurations non prises en charge dans RDS Custom for Oracle](custom-troubleshooting.md#custom-troubleshooting.fix-unsupported).
Les tableaux suivants présentent des descriptions des notifications et des événements envoyés par le périmètre de prise en charge et expliquent comment les corriger. Ces notifications et le périmètre de prise en charge sont susceptibles d'être modifiés. Pour en savoir plus sur le périmètre de prise en charge, consultez [Périmètre de prise en charge RDS Custom](custom-concept.md#custom-troubleshooting.support-perimeter). Pour les descriptions des événements, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
| Code de l’événement | Zone de configuration | Message d'événement RDS | Processus de validation |
| --- | --- | --- | --- |
| `SP-S0000` | Configuration manuelle non prise en charge | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : `X`. | Pour résoudre ce problème, créez un dossier d’assistance. |
**AWS ressource (infrastructure)**
| Code de l’événement | Zone de configuration | Message d'événement RDS | Processus de validation |
| --- | --- | --- | --- |
| `SP-S1001` | État de l’instance EC2 | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : l’instance EC2 sous-jacente %s a été arrêtée sans arrêter l’instance RDS. Vous pouvez résoudre ce problème en démarrant l’instance EC2 sous-jacente et en vous assurant que les volumes binaires et de données sont attachés. Si vous avez l’intention d’arrêter l’instance RDS, assurez-vous d’abord que l’instance EC2 sous-jacente est à l’état DISPONIBLE, puis utilisez la console RDS ou l’interface de ligne de commande (CLI) pour arrêter l’instance RDS. | Pour vérifier le statut d’une instance de base de données, utilisez la console ou exécutez la commande AWS CLI suivante : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceStatus
|
| `SP-S1002` | État de l’instance EC2 | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le statut de l’instance de base de données RDS est défini sur `STOPPED`, mais l’instance EC2 sous-jacente %s a été démarrée. Vous pouvez résoudre ce problème en arrêtant l’instance EC2 sous-jacente. Si vous avez l’intention de démarrer l’instance RDS, utilisez la console ou l’interface de ligne de commande (CLI). | Utilisez la AWS CLI commande suivante pour vérifier l'état d'une instance de base de données : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceStatus
Vous pouvez également vérifier le statut de l’instance EC2 à l’aide de la console EC2. Pour démarrer une instance de base de données, utilisez la console ou exécutez la commande AWS CLI suivante : aws rds start-db-instance \
--db-instance-identifier db-instance-name
|
| `SP-S1003` | Classe d’instance EC2 | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : il existe une incompatibilité entre la classe d’instance de base de données attendue et la classe d’instance de base de données configurée de l’hôte EC2. Vous pouvez résoudre ce problème en modifiant la classe d’instance de base de données pour lui réaffecter son type de classe d’origine. | Utilisez la commande suivante de l’interface de ligne de commande (CLI) pour vérifier la classe d’instance de base de données attendue : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceClass
|
| `SP-S1004` | Volume de stockage EBS non accessible | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le volume de stockage EBS %s d’origine associé à l’instance EC2 n’est actuellement pas accessible. | |
| `SP-S1005` | Volume de stockage EBS détaché | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le volume de stockage EBS « volume-id » d’origine n’est pas attaché. Vous pouvez résoudre ce problème en attachant le volume EBS associé à l’instance EC2. | Après avoir rattaché le volume EBS, utilisez les commandes suivantes de l’interface de ligne de commande (CLI) pour vérifier si le volume EBS « volume-id » est correctement attaché à l’instance RDS : aws ec2 describe-volumes \
--volume-ids volume-id |grep InstanceId
|
| `SP-S1006` | Taille du volume de stockage EBS | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : il existe une incompatibilité entre les paramètres attendus et configurés du volume de stockage EBS « volume-id ». La taille du volume a été modifiée manuellement au niveau EC2 par rapport à sa ou ses valeurs d’origine [%s]. Pour résoudre ce problème, créez un dossier d’assistance. | Utilisez la commande suivante l’interface de ligne de commande (CLI) pour comparer la taille du volume EBS « volume-id » avec les détails de l’instance RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep AllocatedStorage
Utilisez la commande suivante de l’interface de ligne de commande (CLI) pour afficher la taille réelle du volume alloué : aws ec2 describe-volumes \
--volume-ids |grep Size
|
| `SP-S1007` | Configuration du volume de stockage EBS | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : il existe une incompatibilité entre les paramètres attendus et configurés du volume de stockage EBS « volume-id ». Vous pouvez résoudre ce problème en modifiant la configuration du volume de stockage EBS [IOPS, débit, type de volume] afin de rétablir sa ou ses valeurs d’origine [IOPS : %s, débit : %s, type de volume : %s] au niveau EC2. Pour les futures modifications du stockage, utilisez la console RDS ou l’interface de ligne de commande (CLI). La taille du volume a également été modifiée manuellement au niveau EC2 par rapport à sa ou ses valeurs d’origine [%s]. Pour résoudre ce problème, créez un dossier d’assistance. | Utilisez la commande suivante de l’interface de ligne de commande (CLI) pour comparer le type de volume EBS « volume-id » avec les détails de l’instance RDS. Assurez-vous que les valeurs au niveau EBS correspondent aux valeurs au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageType
Pour obtenir la valeur attendue pour le débit de stockage au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageThroughput
Pour obtenir la valeur attendue pour le volume IOPS au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Iops
Pour obtenir le type de stockage actuel au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep VolumeType
Pour obtenir la valeur actuelle pour le débit de stockage au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep Throughput
Pour obtenir la valeur actuelle pour le volume IOPS au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep Iops
|
| `SP-S1008` | Taille et configuration du volume de stockage EBS | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : il existe une incompatibilité entre les paramètres attendus et configurés du volume de stockage EBS « volume-id ». Vous pouvez résoudre ce problème en modifiant la configuration du volume de stockage EBS [IOPS, débit, type de volume] afin de rétablir sa ou ses valeurs d’origine [IOPS : %s, débit : %s, type de volume : %s] au niveau EC2. Pour les futures modifications du stockage, utilisez la console RDS ou l’interface de ligne de commande (CLI). La taille du volume a également été modifiée manuellement au niveau EC2 par rapport à sa ou ses valeurs d’origine [%s]. Pour résoudre ce problème, créez un dossier d’assistance. | Utilisez la commande suivante de l’interface de ligne de commande (CLI) pour comparer le type de volume EBS « volume-id » avec les détails de l’instance RDS. Assurez-vous que les valeurs au niveau EBS correspondent aux valeurs au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageType
Pour obtenir la valeur attendue pour le débit de stockage au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageThroughput
Pour obtenir la valeur attendue pour le volume IOPS au niveau RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Iops
Pour obtenir le type de stockage actuel au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep VolumeType
Pour obtenir la valeur actuelle pour le débit de stockage au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep Throughput
Pour obtenir la valeur actuelle pour le volume IOPS au niveau EC2 : aws ec2 describe-volumes \
--volume-ids |grep Iops
Pour obtenir la taille attendue du volume alloué : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep AllocatedStorage
Pour obtenir la taille réelle du volume alloué : aws ec2 describe-volumes \
--volume-ids |grep Size
|
| `SP-S1009` | Autorisations SQS | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : les autorisations Amazon Simple Queue Service (SQS) sont manquantes pour le profil d’instance IAM. Vous pouvez résoudre ce problème en vous assurant que le profil IAM associé à l'hôte dispose des autorisations suivantes : ["SQS : «, "SQS : SendMessage «, "SQS : ReceiveMessage «, "SQS : DeleteMessage «]. GetQueueUrl | |
| `SP-S1010` | Point de terminaison d’un VPC SQS | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : une politique de point de terminaison d’un VPC bloque les opérations Amazon Simple Queue Service (SQS). Vous pouvez résoudre ce problème en modifiant votre politique de point de terminaison d’un VPC afin d’autoriser les actions SQS requises. | |
| `SP-S1011` | Politique de bus d’événements | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : La politique basée sur les ressources pour votre bus d'événements arn:aws:events:region- 1:123456789012:event-bus/default refuse Amazon events : actions. CloudWatch PutEvents Résolvez ce problème en modifiant votre politique basée sur les ressources afin d'autoriser les événements : PutEvents actions pour EventBus %s. | |
| `SP-S1012` | CloudWatch Autorisations VPC | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : une politique de point de terminaison VPC ne permet pas d'accéder aux événements Amazon. CloudWatch Résolvez ce problème en modifiant la politique de point de terminaison de votre VPC pour autoriser les événements : PutEvents on EventBus arn:aws:events:region- 1:123456789012:event-bus/default. | |
| `SP-S1013` | Politique de contrôle des services | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : une politique de contrôle des services de votre part ne AWS Organizations permet pas d'accéder aux événements Amazon CloudWatch . Résolvez ce problème en modifiant votre politique de contrôle des services pour autoriser les événements : PutEvents on EventBus arn:aws:events:region- 1:123456789012:event-bus/default. | |
| `SP-S1014` | Profil d'instance IAM | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : les autorisations %s de votre profil d'instance IAM refusent les événements Amazon. CloudWatch Résolvez ce problème en réglant ["events : PutEvents «] sur « Autoriser » et en autorisant les événements : PutEvents on EventBus arn:aws:events:region- 1:123456789012:event-bus/default dans votre profil IAM associé à l'instance. | |
| `SP-S1015` | Profil d'instance IAM | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : votre profil d'instance IAM %s ne dispose pas des autorisations d'événement Amazon CloudWatch . Résolvez ce problème en incluant les autorisations ["events : PutEvents «] et en autorisant les événements : PutEvents on EventBus arn:aws:events:region- 1:123456789012:event-bus/default dans votre profil IAM associé à l'instance. | |
| `SP-S1016` | Limite des autorisations IAM | Le statut de l'instance de base de données personnalisée RDS est défini sur [Configuration non prise en charge] pour les raisons suivantes : votre profil d'instance IAM %s possède une limite d'autorisations qui refuse les événements Amazon. CloudWatch Résolvez ce problème en réglant ["events : PutEvents «] sur « Autoriser » pour EventBus arn:aws:events:region- 1:123456789012:event-bus/default dans la limite des autorisations de votre profil d'instance IAM. | |
**Système d’exploitation**
| Code de l’événement | Zone de configuration | Message d'événement RDS | Processus de validation |
| --- | --- | --- | --- |
| `SP-S2001` | Statut du service SQL | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le service SQL Server n’est pas démarré. Vous pouvez résoudre ce problème en redémarrant le service SQL Server sur l’hôte. Si cette instance de base de données est une instance de base de données multi-AZ et que le redémarrage échoue, arrêtez et redémarrez l’hôte pour lancer un basculement. | |
| `SP-S2002` | Statut de l’agent RDS Custom | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le service Agent RDS Custom n’est pas installé ou n’a pas pu être démarré. Vous pouvez résoudre ce problème en consultant le journal des événements Windows pour déterminer pourquoi le service ne démarre pas et en prenant les mesures appropriées pour résoudre le problème. Pour obtenir une assistance supplémentaire, créez un dossier d’assistance. | Connectez-vous à l'hôte et assurez-vous que l'agent RDS Custom est en cours d'exécution. Vous pouvez utiliser les commandes suivantes pour consulter le statut de l’agent. $name = "RDSCustomAgent"
$service = Get-Service $name
Write-Host $service.Status
Si le statut n'est pas `Running`, vous pouvez démarrer le service avec la commande suivante : Start-Service $name
Si l’agent ne peut pas démarrer, consultez les événements Windows pour savoir pourquoi il ne peut pas démarrer. L’agent a besoin d’un utilisateur Windows pour démarrer le service. Assurez-vous qu’un utilisateur Windows existe et dispose des privilèges nécessaires pour exécuter le service. |
| `SP-S2003` | Statut de l’agent SSM | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le service Agent Amazon SSM est inaccessible. Vous pouvez résoudre ce problème en vérifiant l'état du service à l'aide de la `Get-Service AmazonSSMAgent` PowerShell commande ou en démarrant le service avec`Start-Service AmazonSSMAgent`. Assurez-vous que le trafic sortant HTTPS (port 443) vers les points de terminaison régionaux **ssm**, **ssmmessages** et **ec2messages** est autorisé. | Pour plus d’informations, consultez [Résolution des problèmes de SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html). Pour résoudre les problèmes liés aux points de terminaison SSM, voir [Impossible de se connecter aux points de terminaison SSM et [Utiliser ssm-cli](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-cli.html#agent-ts-ssm-cli)](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html#systems-manager-ssm-agent-troubleshooting-endpoint-access) pour résoudre les problèmes de disponibilité des nœuds gérés. |
| `SP-S2004` | Connexion à l’agent RDS Custom | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : une erreur inattendue s’est produite avec la connexion SQL `"$HOSTNAME/RDSAgent”`. Pour résoudre ce problème, créez un dossier d’assistance. | |
| `SP-S2005` | Fuseau horaire | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le fuseau horaire de l’instance Amazon EC2 [%s] a été modifié. Vous pouvez résoudre ce problème en modifiant le fuseau horaire pour revenir au paramètre spécifié lors de la création de l’instance. Si vous souhaitez créer une instance avec un fuseau horaire spécifique, consultez la documentation RDS Custom. | Exécutez la `Get-Timezone` PowerShell commande pour confirmer le fuseau horaire. Pour de plus amples informations, veuillez consulter [Fuseau horaire local pour les instances de base de données RDS Custom for SQL Server](custom-reqs-limits-MS.TimeZone.md). |
| `SP-S2006` | Version de la solution logicielle à haute disponibilité | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : la solution logicielle à haute disponibilité de l’instance actuelle est différente de la version attendue. Pour résoudre ce problème, créez un dossier d’assistance. | |
| `SP-S2007` | Configuration de la solution logicielle à haute disponibilité | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : les paramètres de configuration de la solution logicielle à haute disponibilité ont été modifiés pour atteindre des valeurs inattendues sur l’instance %s. Pour résoudre ce problème, redémarrez l’instance EC2. Lorsque vous redémarrez l’instance EC2, elle met automatiquement à jour les paramètres selon la configuration requise pour la solution logicielle à haute disponibilité. | |
| SP-S2008 | Service SQL Server | L'instance de base de données personnalisée RDS est définie sur [Configuration non prise en charge] : SQLServer (MSSQLServer) le service n'existe pas sur l'hôte. Pour résoudre ce problème, créez un dossier d’assistance. | Vous pouvez utiliser les commandes suivantes pour consulter le statut de l’agent. $name = "MSSQLServer"
$service = Get-Service $name
Write-Host $service.Status
|
| SP-S2009 | Certificat SSL | L’instance de base de données RDS Custom est définie sur [Configuration non prise en charge] pour les raisons suivantes : des certificats SSL non autosignés perturbent RDS. Pour résoudre ce problème, supprimez le ou les certificats non autosignés du magasin de certificats racine approuvé. | Exécutez la PowerShell commande suivante pour vérifier les certificats non auto-signés. Get-ChildItem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject -and $_.Issuer -notlike "*RDSCustomAgentCA*"} Pour plus d’informations, consultez [Erreur HTTP 403.16 lorsque vous essayez d’accéder à un site Web hébergé sur IIS](https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/site-behavior-performance/http-403-forbidden-access-website). |
| SP-S2010 | Statut du stockage du volume racine | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour les raisons suivantes : l’espace de stockage du volume racine est plein. Pour résoudre ce problème, libérez au moins 500 Mio d’espace de stockage dans le volume EBS racine « volume-id » ou augmentez la taille du volume et redimensionnez le lecteur C sur l’instance EC2 « instance-id ». Les modifications de taille du volume racine ne sont pas conservées lorsque vous remplacez l’instance EC2. | Utilisez la commande suivante pour afficher le stockage disponible sur le volume racine (C:). (Get-PSDrive -Name C).Free / 1MB
Pour plus d’informations sur la modification du volume racine EBS, consultez [Comment](https://forums.aws.amazon.com/knowledge-center/expand-ebs-root-volume-windows) |
**Base de données**
| Code de l’événement | Zone de configuration | Message d'événement RDS | Processus de validation |
| --- | --- | --- | --- |
| `SP-S3001` | Protocole de mémoire partagée SQL Server | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le protocole de mémoire partagée SQL Server est désactivé. Vous pouvez résoudre ce problème en activant le protocole de mémoire partagée dans le gestionnaire de configuration SQL Server. | Vous pouvez le valider en vérifiant : **Gestionnaire de configuration SQL Server > Configuration réseau SQL Server > Protocoles pour MSSQLSERVER> Mémoire partagée** activée. Une fois le protocole activé, redémarrez le processus SQL Server. |
| `SP-S3002` | Service Master Key | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : RDS Automation n’est pas en mesure de sauvegarder SMK (Service Master Key) dans le cadre de la nouvelle génération de SMK. Pour résoudre ce problème, créez un dossier d’assistance. | |
| `SP-S3003` | Service Master Key | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : les métadonnées relatives à la SMK (Service Master Key) sont manquantes ou incomplètes. Pour résoudre ce problème, créez un dossier d’assistance. | |
| `SP-S3004` | Version et édition du moteur de base de données | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : il existe une incompatibilité entre la version et l’édition de SQL Server attendues et installées : la modification de l’édition SQL Server n’est pas prise en charge sur RDS Custom for SQL Server. En outre, la modification manuelle de la version de SQL Server sur l’instance EC2 RDS Custom n’est pas prise en charge. Pour résoudre ce problème, créez un dossier d’assistance. | Exécutez la requête suivante pour obtenir la version SQL : select @@version
Exécutez la AWS CLI commande suivante pour obtenir la version et l'édition du moteur SQL RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep EngineVersion
aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Engine
Pour plus d’informations, consultez [Modification d'une instance de base de données RDS Custom for SQL Server](custom-managing.modify-sqlserver.md) et [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md). |
| `SP-S3005` | Édition du moteur de base de données | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : l’édition actuelle de SQL Server ne correspond pas à l’édition attendue de SQL Server [%s] : la modification de l’édition de SQL Server n’est pas prise en charge sur RDS Custom for SQL Server. Pour résoudre ce problème, créez un dossier d’assistance. | Exécutez la requête suivante pour obtenir l’édition SQL :
**Example**
```
select @@version
``` Exécutez la AWS CLI commande suivante pour obtenir l'édition du moteur RDS SQL : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Engine
|
| `SP-S3006` | Version du moteur de base de données | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : la version actuelle de SQL Server ne correspond pas à la version attendue de SQL Server [%s] : vous ne pouvez pas modifier manuellement la version de SQL Server sur l’instance EC2 RDS Custom. Pour résoudre ce problème, créez un dossier d’assistance. Pour toute modification future de la version de SQL Server, vous pouvez modifier l'instance depuis la console AWS RDS ou via la commande modify-db-instance CLI. | Exécutez la requête suivante pour obtenir la version SQL :
**Example**
```
select @@version
``` Exécutez la AWS CLI commande suivante pour obtenir la version du moteur SQL RDS : aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep EngineVersion
Pour plus d’informations, consultez [Modification d'une instance de base de données RDS Custom for SQL Server](custom-managing.modify-sqlserver.md) et [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md). |
| `SP-S3007` | Emplacement du fichier de base de données | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : les fichiers de base de données sont configurés en dehors du lecteur D:\$1. Vous pouvez résoudre ce problème en vous assurant que tous les fichiers de base de données, y compris ROW, LOG, FILESTREAM, etc., sont stockés sur le lecteur D:\$1. | Exécutez la requête suivante pour répertorier l’emplacement des fichiers de base de données qui ne figurent pas dans le chemin par défaut : USE master;
SELECT physical_name as files_not_in_default_path
FROM sys.master_files
WHERE SUBSTRING(physical_name,1,3)!='D:\';
|
| `SP-S3008` | Nombre limite de base de données dépassé | Le statut de l’instance de base de données RDS Custom est défini sur [Configuration non prise en charge] pour la raison suivante : le nombre total de bases de données sur l’instance de base de données dépasse la limite maximale de 5 000. Pour résoudre ce problème, réduisez le nombre de bases de données en dessous de la limite maximale prise en charge. | Utilisez la commande suivante pour consulter le nombre total de base de données : SELECT COUNT(name) as databaseCount
FROM sys.databases
WHERE name not in ('tempdb','master','model','msdb','DWDiagnostics','DWConfiguration','DWQueue');
|
## Résolution des problèmes liés à `Storage-Full` dans RDS Custom for SQL Server
RDS Custom surveille également le volume racine (C:). L’instance de base de données RDS Custom for SQL Server passe à l’état `unsupported-configuration` lorsque le volume racine dispose de moins de 500 Mio d’espace disque disponible. Consultez `Event SP-S2010` dans [Correction des configurations non prises en charge dans RDS Custom for SQL Server](#custom-troubleshooting-sqlserver.fix-unsupported).
## Résolution des problèmes liés à l’état PENDING\$1RECOVERY pour les bases de données compatibles TDE dans RDS Custom for SQL Server
Les bases de données SQL Server sur lesquelles le chiffrement transparent des données (TDE) est activé peuvent rester à l’état `PENDING_RECOVERY` si le déchiffrement automatique rencontre des problèmes. Cela se produit généralement après la restauration d’une instance de base de données si le fichier de sauvegarde SMK (Service Master Key) de l’instance de base de données source stocké dans le compartiment S3 géré par RDS Custom de votre compte a été supprimé avant la fin de la restauration.
Pour activer le déchiffrement automatique et mettre en ligne les bases de données compatibles TDE, vous devez ouvrir la DMK (Database Master Key) avec son mot de passe et crypter la DMK à l’aide de la SMK.
Utilisez les commandes SQL Server suivantes à titre de référence :
```
-- Identify PENDING_RECOVERY TDE databases
USE MASTER;
GO
SELECT name, is_encrypted, state_desc FROM sys.databases;
GO
-- Open DMK using password
OPEN MASTER KEY DECRYPTION BY PASSWORD = '';
GO
-- Encrypt DMK using SMK
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
GO
-- Close SMK
CLOSE MASTER KEY;
GO
-- Bring the TDE databases online
ALTER DATABASE SET ONLINE;
GO
-- Verify TDE databases are now in ONLINE state
SELECT name, is_encrypted, state_desc FROM sys.databases;
GO
```