Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Gestion d'Amazon Aurora MySQL
Les sections suivantes expliquent comment gérer un cluster de base de données Amazon Aurora MySQL DB.
**Topics**
+ [Gestion des performances et dimensionnement pour Amazon Aurora MySQL](AuroraMySQL.Managing.Performance.md)
+ [Retour en arrière d’un cluster de bases de données Aurora](AuroraMySQL.Managing.Backtrack.md)
+ [Test d’Amazon Aurora MySQL à l’aide de requêtes d’injection d’erreurs](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [Modification de tables dans Amazon Aurora à l’aide de Fast DDL](AuroraMySQL.Managing.FastDDL.md)
+ [Affichage du statut du volume pour un cluster de base de données Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md)
# Gestion des performances et dimensionnement pour Amazon Aurora MySQL
## Dimensionnement des instances de bases de données Aurora MySQL
Vous pouvez dimensionner les instances de bases de données Aurora MySQL de deux façons : le dimensionnement d’instance et le dimensionnement en lecture. Pour plus d’informations sur le dimensionnement en lecture, consultez [Dimensionnement en lecture](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Vous pouvez mettre à l’échelle votre cluster de bases de données Aurora MySQL en modifiant la classe d’instance de base de données pour chaque instance du cluster de bases de données. Aurora MySQL prend en charge plusieurs classes d’instance de base de données optimisées pour Aurora. N’utilisez pas les classes d’instance db.t2 ou db.t3 pour des clusters Aurora d’une taille supérieure à 40 To. Pour obtenir les spécifications des classes d’instance de base de données prises en charge par Aurora MySQL, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md).
**Note**
Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez [Utilisation de classes d’instance T pour le développement et les tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
## Nombre maximal de connexions à une instance de base de données Aurora MySQL
Le nombre maximal de connexions autorisées à une instance de base de données Aurora MySQL est déterminé par le paramètre `max_connections` du groupe de paramètres de niveau instance de l’instance de base de données.
Le tableau ci-dessous répertorie la valeur par défaut résultante de `max_connections` pour chaque classe d’instance de base de données disponible dans Aurora MySQL. Vous pouvez accroître le nombre maximal de connexions à votre instance de base de données Aurora MySQL en définissant une classe d’instance de base de données qui offre davantage de mémoire à l’instance ou en attribuant au paramètre `max_connections` une valeur supérieure (jusqu’à 16 000) dans le groupe de paramètres de base de données de votre instance.
**Astuce**
Si vos applications ouvrent et ferment fréquemment des connexions, ou si elles ont ouvert un grand nombre de connexions de longue durée, nous vous recommandons d’utiliser Proxy Amazon RDS. RDS Proxy est un proxy de base de données entièrement géré et hautement disponible qui utilise le regroupement de connexions pour partager les connexions de base de données de manière sécurisée et efficace. Pour en savoir plus sur RDS Proxy, consultez [Proxy Amazon RDS pour Aurora](rds-proxy.md).
Pour obtenir plus de détails sur la façon dont les instances Aurora Serverless v2 gèrent ce paramètre, consultez [Nombre maximal de connexions pour Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
| Classe d’instance | Valeur par défaut de max\$1connections |
| --- | --- |
| db.t2.small | 45 |
| db.t2.medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1 000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1 000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6000 |
| db.r5.large | 1000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6 000 |
| db.r5.16xlarge | 6 000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6 000 |
| db.r6g.16xlarge | 6000 |
| db.r6i.large | 1 000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6 000 |
| db.r6i.16xlarge | 6 000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1 000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6 000 |
| db.r7g.16xlarge | 6 000 |
| db.r7i.large | 1 000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6 000 |
| db.r7i.16xlarge | 6 000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1 000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6 000 |
| db.r8g.16xlarge | 6 000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6 000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**Astuce**
Le calcul du paramètre `max_connections` utilise le log base 2 (qui est différent du logarithme naturel) et la valeur `DBInstanceClassMemory` en octets pour la classe d’instance Aurora MySQL sélectionnée. Ce paramètre accepte uniquement les valeurs entières. Les parties décimales sont tronquées lors des calculs. Cette formule implémente des limites de connexion comme suit :
Incrément de 1 000 connexions pour les instances R3, R4 et R5
Incrément de 45 connexion pour les variantes de mémoire d’instance T2 et T3
Exemple : pour db.r6g.large, alors que la formule calcule 1 069,2, le système implémente 1 000 pour maintenir des modèles incrémentiels cohérents.
Si vous créez un groupe de paramètres dans le but de personnaliser votre limite de connexions par défaut, vous constaterez que cette limite est dérivée d’une formule basée sur la valeur de `DBInstanceClassMemory`. Comme le montre le tableau précédent, la formule produit des limites de connexion qui augmentent de 1 000 à mesure que la mémoire double à chaque nouvel échelon pour les instances R3, R4 et R5, et de 45 pour les différentes tailles de mémoire des instances T2 et T3.
Consultez [Spécification des paramètres de base de données](USER_ParamValuesRef.md) pour obtenir plus de détails sur le mode de calcul de `DBInstanceClassMemory`.
Aurora MySQL et les instances de bases de données RDS pour MySQL ont des niveaux de surcharge mémoire différents. Par conséquent, la valeur `max_connections` peut être différente pour Aurora MySQL et les instances de bases de données RDS for MySQL qui utilisent la même classe d’instance. Les valeurs de la table s’appliquent uniquement aux instances de base de données Aurora MySQL.
**Note**
Les limites de connectivité bien inférieures des instances T2 et T3 s’expliquent par le fait qu’avec Aurora, ces classes d’instance sont destinées uniquement à des scénarios de développement et de test, et non à des charges de travail de production.
Les limites de connexion par défaut sont adaptées aux systèmes qui utilisent les valeurs par défaut des autres gros consommateurs de mémoire, comme les pools de mémoires tampons et les caches de requêtes. Si vous modifiez ces autres paramètres pour votre cluster, pensez à ajuster la limite de connexion pour prendre en compte l’augmentation ou la diminution de la mémoire disponible sur les instances de base de données.
## Limites de stockage temporaires pour Aurora MySQL
Aurora MySQL stocke les tables et les index dans le sous-système de stockage Aurora. Aurora MySQL utilise un stockage temporaire ou local séparé pour les tables temporaires autres qu’InnoDB et les fichiers temporaires non persistants. Le stockage local inclut notamment des fichiers qui sont utilisés à des fins telles que le tri de grands jeux de données pendant le traitement des requêtes ou les opérations de génération d’index. Il n’inclut pas les tables temporaires InnoDB.
Pour plus d’informations sur les tables temporaires dans Aurora MySQL version 3, consultez [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md). Pour plus d’informations sur les tables temporaires dans la version 2, consultez [Comportement d’espace de table temporaire dans Aurora MySQL version 2](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57).
Les données et les fichiers temporaires de ces volumes sont perdus lors du démarrage et de l’arrêt de l’instance de base de données, ainsi que lors du remplacement de l’hôte.
Ces volumes de stockage locaux sont basés sur Amazon Elastic Block Store (EBS) et peuvent être étendus en utilisant une classe d’instance de base de données plus grande. Pour plus d’informations sur le stockage, consultez [Stockage Amazon Aurora](Aurora.Overview.StorageReliability.md).
Le stockage local est également utilisé pour importer des données depuis Amazon S3 à l’aide de `LOAD DATA FROM S3` ou `LOAD XML FROM S3`, et pour exporter des données vers S3 à l’aide de SELECT INTO OUTFILE S3. Pour plus d’informations sur l’importation à partir de S3 et l’exportation vers S3, consultez les détails suivants :
+ [Chargement de données dans un cluster de bases de données Amazon Aurora MySQL à partir de fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Enregistrement de données d’un cluster de bases de données Amazon Aurora MySQL dans des fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md)
Aurora MySQL utilise un stockage permanent distinct pour les journaux d’erreurs, les journaux généraux, les journaux de requêtes lentes et les journaux d’audit pour la plupart des classes d’instance de base de données Aurora MySQL (à l’exception des types de classes d’instance à performances évolutives tels que db.t2, db.t3 et db.t4g). Les données de ce volume sont conservées lors du démarrage et de l’arrêt de l’instance de base de données, ainsi que lors du remplacement de l’hôte.
Ce volume de stockage permanent est également basé sur Amazon EBS et a une taille fixe en fonction de la classe d’instance de base de données. Il ne peut pas être étendu en utilisant une classe d’instance de base de données plus grande.
Le tableau suivant indique la quantité maximale de stockage temporaire et permanent disponible pour chaque classe d’instance de base de données Aurora MySQL. Pour plus d’informations sur la prise en charge d’une classe d’instance de base de données pour Aurora, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md).
| Classe d’instance de base de données | Stockage temporaire/local maximal disponible (Gio) | Stockage maximal supplémentaire disponible pour les fichiers journaux (Gio) |
| --- | --- | --- |
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**Important**
Ces valeurs représentent la quantité maximale théorique de stockage disponible sur chaque instance de base de données. Le stockage local réel à votre disposition pourrait être inférieur. Aurora utilise du stockage local pour ses processus de gestion, et l’instance de base de données utilise du stockage local avant même que vous chargiez des données. Vous pouvez surveiller le stockage temporaire disponible pour une instance de base de données spécifique à l’aide de la métrique `FreeLocalStorage` CloudWatch décrite dans [CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Vous pouvez vérifier la quantité de stockage disponible à l’heure actuelle. Vous pouvez également représenter la quantité de stockage disponible au fil du temps. La surveillance du stockage disponible au fil du temps vous aide à déterminer si la valeur augmente ou diminue, mais aussi à trouver les valeurs minimales, maximales ou moyennes.
(Cela ne s’applique pas à Aurora Serverless v2).
# Retour en arrière d’un cluster de bases de données Aurora
Édition compatible avec Amazon Aurora MySQL vous permet d’effectuer un retour en arrière d’un cluster de bases de données à une heure spécifique, sans restaurer les données à partir d’une sauvegarde.
**Contents**
+ [Présentation du retour en arrière](#AuroraMySQL.Managing.Backtrack.Overview)
+ [Fenêtre de retour en arrière](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [Heure de retour en arrière](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [Limites du retour en arrière](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [Disponibilité des régions et des versions](#AuroraMySQL.Managing.Backtrack.Availability)
+ [Considérations relatives aux mises à niveau pour les clusters compatibles avec le retour en arrière](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Configuration du retour en arrière d’un cluster de bases de données Aurora MySQL](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Exécution d’un retour en arrière pour un cluster de bases de données MySQL](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Surveillance du retour en arrière pour un cluster de bases de données Aurora MySQL](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [Abonnement à un événement de retour en arrière avec la console](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [Extraction de retours sur trace existants](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Désactivation du retour en arrière pour un cluster de bases de données Aurora MySQL](AuroraMySQL.Managing.Backtrack.Disabling.md)
## Présentation du retour en arrière
Le retour en arrière permet de « faire revenir en arrière » le cluster de bases de données à l’heure que vous spécifiez. Le retour en arrière ne remplace pas une sauvegarde de votre cluster de bases de données afin de pouvoir la restaurer à un instant dans le passé. Toutefois, le retour en arrière fournit les avantages suivants par rapport aux fonctions traditionnelles de sauvegarde et de restauration :
+ Vous pouvez facilement annuler des erreurs. Si vous effectuez par erreur une action destructrice, comme une opération DELETE sans clause WHERE, vous pouvez exécuter un retour en arrière pour faire revenir le cluster de bases de données à une heure précédant l’action destructrice sans aucune interruption minimale du service.
+ Vous pouvez effectuer rapidement un retour en arrière d’un cluster de bases de données. La restauration d’un cluster de bases de données à un instant dans le passé lance un nouveau cluster de bases de données et restaure celui-ci à partir des données de sauvegarde ou d’un instantané de cluster de bases de données ; cette opération peut prendre plusieurs heures. Le retour en arrière d’un cluster de bases de données ne nécessite pas de nouveau cluster de bases de données et fait revenir en arrière le cluster de bases de données en quelques minutes.
+ Vous pouvez explorer les précédentes modifications de données. Vous pouvez effectuer des retours en arrière d’un cluster de bases de données de manière répétée en arrière et en avant dans le temps afin de déterminer le moment où une modification particulière a eu lieu. Par exemple, vous pouvez effectuer un retour en arrière d’un cluster de bases de données de trois heures, puis effectuer un autre retour en arrière en avant d’une heure. Dans ce cas, l’heure du retour en arrière est antérieure de deux heures par rapport à l’heure d’origine.
**Note**
Pour plus d’informations sur la restauration d’un cluster de bases de données à un instant dans le passé, consultez [Présentation de la sauvegarde et de la restauration d’un cluster de bases de données Aurora](Aurora.Managing.Backups.md).
### Fenêtre de retour en arrière
Avec le retour en arrière, il y a une fenêtre de retour en arrière cible et une fenêtre de retour en arrière réelle :
+ La *fenêtre de retour en arrière cible* correspond au laps de temps pendant lequel vous souhaitez pouvoir effectuer un retour en arrière de votre cluster de bases de données. Lorsque vous activez le retour en arrière, vous spécifiez une *fenêtre de retour en arrière cible*. Par exemple, vous pouvez spécifier une fenêtre de retour en arrière cible de 24 heures si vous souhaitez pouvoir effectuer un retour en arrière d’une journée du cluster de bases de données.
+ La *fenêtre de retour en arrière réelle* correspond au laps de temps réel pendant lequel vous pouvez effectuer un retour en arrière de votre cluster de bases de données ; sa valeur peut être inférieure à celle de la fenêtre de retour en arrière cible. La fenêtre de retour en arrière réelle est basée sur votre charge de travail et sur le stockage disponible pour les informations sur les modifications de la base de données, appelées *enregistrements de modification.*
À mesure que vous effectuez des mises à jour de votre cluster de bases de données Aurora avec le retour en arrière activé, vous générez des enregistrements de modifications. Aurora conserve les enregistrements de modifications pour la fenêtre de retour en arrière cible, et leur stockage vous est facturé sur une base horaire. La fenêtre de retour en arrière cible et la charge de travail sur votre cluster de bases de données déterminent le nombre d’enregistrements de modification que vous stockez. La charge de travail correspond au nombre de modifications que vous apportez au cluster de bases de données sur un laps de temps donné. Si votre charge de travail est lourde, vous stockez davantage d’enregistrements dans votre fenêtre de retour en arrière que si votre charge de travail est légère.
Vous pouvez considérer votre fenêtre de retour en arrière cible comme étant l’objectif du laps de temps maximal pendant lequel vous souhaitez pouvoir faire un retour en arrière de votre cluster de bases de données. Dans la plupart des cas, vous pouvez effectuer un retour en arrière correspondant au laps de temps maximal spécifié. Toutefois, dans certains cas, le cluster de bases de données ne peut pas stocker suffisamment d’enregistrements de modification pour effectuer un retour en arrière correspondant au laps de temps maximal, et votre fenêtre de retour en arrière réelle est plus petite que votre fenêtre de retour en arrière cible. Généralement, la fenêtre de retour en arrière réelle est plus petite que la fenêtre de retour en arrière cible lorsque la charge de travail est particulièrement lourde sur votre cluster de bases de données. Lorsque votre fenêtre de retour en arrière réelle est plus petite que votre fenêtre de retour en arrière cible, nous vous envoyons une notification.
Lorsque le retour en arrière est activé pour un cluster de bases de données, et que vous supprimez une table stockée dans ce cluster, Aurora conserve cette table dans les enregistrements de modification du retour en arrière. Ainsi, vous pouvez revenir en arrière à une heure antérieure à celle où vous avez supprimé la table. Si vous ne disposez pas de suffisamment d’espace dans votre fenêtre de retour en arrière pour stocker la table, il est possible que celle-ci soit supprimée des enregistrements de modification du retour en arrière.
### Heure de retour en arrière
Aurora procède toujours au retour en arrière à une heure cohérente pour le cluster de bases de données. Cela élimine la possibilité de transactions non validées une fois le retour en arrière terminé. Lorsque vous spécifiez une heure de retour en arrière, Aurora choisit automatiquement l’heure cohérente la plus proche possible. Cette approche signifie que le retour en arrière terminé peut ne pas correspondre exactement à l'heure que vous spécifiez, mais vous pouvez déterminer l'heure exacte d'un retour en arrière à l'aide de la commande [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI. Pour de plus amples informations, veuillez consulter [Extraction de retours sur trace existants](#AuroraMySQL.Managing.Backtrack.Retrieving).
### Limites du retour en arrière
Les limites suivantes s’appliquent à un retour en arrière :
+ Le retour en arrière est disponible uniquement pour les clusters de bases de données créés avec la fonction de retour en arrière activée. Vous ne pouvez pas modifier un cluster de bases de données pour activer le retour en arrière. Vous pouvez activer la fonction de retour en arrière lorsque vous créez un nouveau cluster de bases de données, restaurez un instantané de cluster de bases de données.
+ La limite pour une fenêtre de retour en arrière est de 72 heures.
+ Le retour en arrière affecte l’ensemble du cluster de bases de données. Par exemple, vous ne pouvez pas effectuer un retour en arrière sélectif sur une seule table ou une seule mise à jour de données.
+ Vous ne pouvez pas créer de réplicas lecture entre régions à partir d’un cluster compatible avec le retour en arrière, mais vous pouvez toujours activer la réplication des journaux binaires (binlog) sur le cluster. Si vous essayez d’effectuer un retour en arrière sur un cluster de bases de données pour lequel la journalisation binaire est activée, une erreur se produit généralement, sauf si vous avez choisi de forcer le retour en arrière. Toute tentative visant à forcer un retour en arrière interrompra les répliques de lecture en aval et interférera avec d'autres opérations telles que blue/green les déploiements.
+ Vous ne pouvez pas effectuer un retour en arrière d’un clone de base de données à une heure antérieure à l’heure à laquelle le clone a été créé. Toutefois, vous pouvez utiliser la base de données d’origine pour effectuer un retour en arrière à une heure antérieure à l’heure à laquelle le clone a été créé. Pour plus d’informations sur le clonage de base de données, consultez [Clonage d’un volume pour un cluster de bases de données Amazon Aurora](Aurora.Managing.Clone.md).
+ Le retour en arrière entraîne une brève interruption de l’instance de base de données. Vous devez arrêter ou mettre en pause vos applications avant de démarrer une opération de retour en arrière, afin de vous assurer qu’il n’y a aucune nouvelle demande en lecture ou en écriture. Au cours de l’opération de retour en arrière, Aurora met en pause la base de données, ferme les connexions ouvertes et annule toutes les lectures et écritures non enregistrées. Il attend ensuite que l’opération de retour en arrière se termine.
+ Vous ne pouvez pas restaurer un instantané interrégional d'un cluster compatible avec le retour en arrière dans une AWS région qui ne prend pas en charge le retour en arrière.
+ Si vous effectuez une mise à niveau sur place de la version 2 vers la version 3 d’Aurora MySQL pour un cluster prenant en charge le retour en arrière, vous ne pouvez pas effectuer un retour en arrière à une heure antérieure à celle où la mise à jour a eu lieu.
## Disponibilité des régions et des versions
Le retour en arrière n’est pas disponible pour Aurora PostgreSQL.
Voici les moteurs pris en charge et la disponibilité des régions pour le retour en arrière avec Aurora MySQL.
| Région | Aurora MySQL version 3 | Aurora MySQL version 2 |
| --- | --- | --- |
| USA Est (Virginie du Nord) | Toutes les versions | Toutes les versions |
| USA Est (Ohio) | Toutes les versions | Toutes les versions |
| USA Ouest (Californie du Nord) | Toutes les versions | Toutes les versions |
| USA Ouest (Oregon) | Toutes les versions | Toutes les versions |
| Afrique (Le Cap) | – | – |
| Asie-Pacifique (Hong Kong) | – | – |
| Asie-Pacifique (Jakarta) | – | – |
| Asie-Pacifique (Malaisie) | – | – |
| Asie-Pacifique (Melbourne) | – | – |
| Asie-Pacifique (Mumbai) | Toutes les versions | Toutes les versions |
| Asie-Pacifique (Nouvelle-Zélande) | – | – |
| Asie-Pacifique (Osaka) | Toutes les versions | Versions 2.07.3 et ultérieures |
| Asie-Pacifique (Séoul) | Toutes les versions | Toutes les versions |
| Asie-Pacifique (Singapour) | Toutes les versions | Toutes les versions |
| Asie-Pacifique (Sydney) | Toutes les versions | Toutes les versions |
| Asie-Pacifique (Taipei) | – | – |
| Asie-Pacifique (Thaïlande) | – | – |
| Asie-Pacifique (Tokyo) | Toutes les versions | Toutes les versions |
| Canada (Centre) | Toutes les versions | Toutes les versions |
| Canada-Ouest (Calgary) | – | – |
| Chine (Pékin) | – | – |
| China (Ningxia) | – | – |
| Europe (Francfort) | Toutes les versions | Toutes les versions |
| Europe (Irlande) | Toutes les versions | Toutes les versions |
| Europe (Londres) | Toutes les versions | Toutes les versions |
| Europe (Milan) | – | – |
| Europe (Paris) | Toutes les versions | Toutes les versions |
| Europe (Espagne) | – | – |
| Europe (Stockholm) | – | – |
| Europe (Zurich) | – | – |
| Israël (Tel Aviv) | – | – |
| Mexique (Centre) | – | – |
| Middle East (Bahrain) | – | – |
| Moyen-Orient (EAU) | – | – |
| Amérique du Sud (São Paulo) | – | – |
| AWS GovCloud (USA Est) | – | – |
| AWS GovCloud (US-Ouest) | – | – |
## Considérations relatives aux mises à niveau pour les clusters compatibles avec le retour en arrière
Vous pouvez mettre à niveau un cluster de bases de données prenant en charge le retour en arrière d’Aurora MySQL version 2 vers la version 3, car toutes les versions mineures d’Aurora MySQL version 3 sont prises en charge pour le retour en arrière.
# Configuration du retour en arrière d’un cluster de bases de données Aurora MySQL
Pour utiliser le retour sur trace, vous devez activez la fonction et spécifier une fenêtre de retour sur trace cible. Dans le cas contraire, le retour sur trace est désactivé.
Pour la fenêtre de retour sur trace cible, spécifiez le laps de temps pendant lequel vous souhaitez pouvoir faire revenir en arrière votre base de données en utilisant le retour sur trace. Aurora tente de conserver suffisamment d’enregistrements de modification pour prendre en charge cette fenêtre de temps.
## Console
Vous pouvez utiliser la console pour configurer le retour en arrière lorsque vous créez un nouveau cluster de bases de données. Vous pouvez également modifier un cluster de bases de données pour modifier la fenêtre de retour en arrière d’un cluster compatible avec le retour en arrière. Si vous désactivez entièrement le retour sur trace pour un cluster en définissant la fenêtre de retour sur trace sur 0, vous ne pouvez pas activer le retour sur trace à nouveau pour ce cluster.
**Topics**
+ [Configuration du retour en arrière avec la console lors de la création d’un cluster de bases de données](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [Configuration du retour en arrière avec la console lors de la modification d’un cluster de bases de données](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### Configuration du retour en arrière avec la console lors de la création d’un cluster de bases de données
Lorsque vous créez un cluster de bases de données Aurora MySQL, la configuration du retour en arrière consiste à choisir **Enable Backtrack (Activer le retour en arrière)** et à spécifier pour **Target Backtrack window (Fenêtre de retour en arrière cible)** une valeur supérieure à zéro dans la section **Retour en arrière**.
Pour créer un cluster de bases de données, suivez les instructions de [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). L’image suivante montre la section **Retour en arrière**.
![\[Activation du retour en arrière pendant la création d’un cluster de bases de données à partir de la console\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
Lorsque vous créez un nouveau cluster de bases de données, Aurora n’a aucune donnée pour la charge de travail du cluster de bases de données. Il ne peut donc pas estimer de coût spécifique pour le nouveau cluster de bases de données. Cependant, la console présente un coût utilisateur classique pour la fenêtre de retour sur trace cible spécifiée, basé sur une charge de travail habituelle. Le coût classique permet de fournir une référence générale pour le coût de la fonction de retour sur trace.
**Important**
Votre coût réel peut être différent du coût classique, puisqu’il est basé sur la charge de travail de votre cluster de bases de données.
### Configuration du retour en arrière avec la console lors de la modification d’un cluster de bases de données
Vous pouvez modifier le retour en arrière pour un cluster de bases de données à l’aide de la console.
**Note**
Actuellement, vous pouvez modifier le retour en arrière uniquement pour un cluster de bases de données dont la fonction de retour en arrière est activée. La section **Retour en arrière** n’apparaît pas pour un cluster de bases de données créé avec la fonction de retour en arrière désactivée ou si cette fonction a été désactivée pour le cluster de bases de données.
**Pour modifier le retour en arrière pour un cluster de bases de données à l’aide de la 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. Choisissez **Bases de données**.
1. Choisissez le cluster que vous souhaitez modifier, puis choisissez **Modifier**.
1. Pour **Target Backtrack window (Fenêtre de retour sur trace cible)**, modifiez le laps de temps pendant lequel vous souhaitez pouvoir effectuer un retour sur trace. La limite est de 72 heures.
![\[Modification du retour sur trace avec la console\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
La console indique le coût estimé pour le laps de temps que vous avez spécifié, basé sur la charge de travail précédente du cluster de bases de données :
+ Si le retour en arrière a été désactivé sur le cluster de bases de données, l'estimation des coûts est basée sur la `VolumeWriteIOPS` métrique du cluster de bases de données sur Amazon CloudWatch.
+ Si le retour en arrière a été activé précédemment sur le cluster de bases de données, l'estimation des coûts est basée sur la `BacktrackChangeRecordsCreationRate` métrique du cluster de bases de données sur Amazon CloudWatch.
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez une des options suivantes :
+ **Appliquer lors de la prochaine fenêtre de maintenance planifiée** : attend la prochaine fenêtre de maintenance avant d’appliquer la modification de **Target Backtrack window (Fenêtre de retour en arrière cible)**.
+ **Apply immediately (Appliquer immédiatement)** – Applique la modification de **Target Backtrack window (Fenêtre de retour sur trace cible)** dès que possible.
1. Choisissez **Modifier le cluster**.
## AWS CLI
Lorsque vous créez un nouveau cluster de base de données Aurora MySQL à l'aide de la commande [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI, le retour en arrière est configuré lorsque vous spécifiez une `--backtrack-window` valeur supérieure à zéro. La valeur `--backtrack-window` spécifie la fenêtre de retour sur trace cible. Pour de plus amples informations, veuillez consulter [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
Vous pouvez également spécifier la `--backtrack-window` valeur à l'aide des commandes AWS CLI suivantes :
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-instantané](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
La procédure suivante explique comment modifier la fenêtre de retour en arrière cible pour un cluster de bases de données à l’aide de l AWS CLI.
**Pour modifier la fenêtre de retour cible d'un cluster de bases de données à l'aide du AWS CLI**
+ Appelez la commande [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
+ `--backtrack-window` : nombre maximal de secondes pendant lesquelles vous souhaitez pouvoir faire un retour en arrière de cluster de bases de données.
L’exemple suivant définit la fenêtre de retour en arrière cible pour `sample-cluster` à une journée (86 400 secondes).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Pour Windows :
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**Note**
Actuellement, vous pouvez activer le retour en arrière uniquement pour un cluster de bases de données créé avec la fonction de retour en arrière activée.
## API RDS
Lorsque vous créez un nouveau cluster de base de données Aurora MySQL à l'aide de l'opération [Create DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API, le retour en arrière est configuré lorsque vous spécifiez une `BacktrackWindow` valeur supérieure à zéro. La valeur `BacktrackWindow` spécifie la fenêtre de retour en arrière cible pour le cluster de bases de données spécifié dans la valeur `DBClusterIdentifier`. Pour plus d’informations, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
Vous pouvez également spécifier la valeur `BacktrackWindow` à l’aide des opérations d’API suivantes :
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Restaurer DBCluster depuis S3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [RestaurerDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [RestaurerDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**Note**
Actuellement, vous pouvez activer le retour en arrière uniquement pour un cluster de bases de données créé avec la fonction de retour en arrière activée.
# Exécution d’un retour en arrière pour un cluster de bases de données MySQL
Vous pouvez effectuer un retour en arrière pour un cluster de bases de données à un horodatage de retour en arrière spécifié. Si l’horodatage de retour en arrière n’est pas antérieur à l’heure de retour en arrière la plus ancienne possible et ne se situe pas dans le futur, le retour en arrière du cluster de bases de données est effectué à cet horodatage.
Dans le cas contraire, une erreur se produit généralement. Par ailleurs, si vous essayez d’effectuer un retour en arrière sur un cluster de bases de données pour lequel la journalisation binaire est activée, une erreur se produit généralement, sauf si vous avez choisi de forcer l’exécution du retour en arrière. Forcer un retour en arrière peut interférer avec d’autres opérations utilisant la journalisation binaire.
**Important**
Le retour en arrière ne génère aucune entrée binlog pour les modifications qu’il effectue. Si la journalisation binaire est activée pour le cluster de bases de données, il est possible que le retour en arrière ne soit pas compatible avec votre implémentation binlog.
**Note**
Pour les clones de base de données, vous ne pouvez pas effectuer un retour en arrière du cluster de bases de données à une heure antérieure à l’heure à laquelle le clone a été créé. Pour plus d’informations sur le clonage de base de données, consultez [Clonage d’un volume pour un cluster de bases de données Amazon Aurora](Aurora.Managing.Clone.md).
## Console
La procédure suivante explique comment effectuer une opération de retour en arrière pour un cluster de bases de données à l’aide de la console.
**Pour effectuer une opération de retour en arrière à l’aide de la console**
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 **Instances**.
1. Choisissez l’instance principale du cluster de bases de données pour lequel vous souhaitez effectuer un retour en arrière.
1. Pour **Actions**, choisissez **Backtrack DB cluster (Retour en arrière de cluster de bases de données)**.
1. Sur la page **Backtrack DB cluster (Retour en arrière de cluster de bases de données)**, entrez l’horodatage de retour en arrière à appliquer au retour en arrière de cluster de bases de données.
![\[Retour en arrière de cluster de bases de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. Choisissez **Backtrack DB cluster (Retour en arrière de cluster de bases de données)**.
## AWS CLI
La procédure suivante explique comment effectuer un retour en arrière de cluster de bases de données à l’aide de l AWS CLI.
**Pour effectuer un retour en arrière de cluster de bases de données à l’aide de l AWS CLI**
+ Appelez la commande [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
+ `--backtrack-to` – Horodatage de retour en arrière de cluster de bases de données, spécifié au format ISO 8601.
L’exemple suivant effectue un retour en arrière du cluster de bases de données `sample-cluster` à 10 h, le 19 mars 2018.
Pour Linux, macOS ou Unix :
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Pour Windows :
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## API RDS
Pour effectuer un retour en arrière de cluster de bases de données à l’aide de l’API Amazon RDS, utilisez l’opération [BacktrackDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html). Cette opération effectue un retour en arrière du cluster de bases de données spécifié dans la valeur `DBClusterIdentifier` à l’heure spécifiée.
# Surveillance du retour en arrière pour un cluster de bases de données Aurora MySQL
Vous pouvez afficher les informations et surveiller les métriques de retour en arrière pour un cluster de bases de données.
## Console
**Pour afficher les informations et surveiller les métriques de retour en arrière à l’aide de la 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. Choisissez **Bases de données**.
1. Choisissez le nom du cluster de bases de données pour lequel vous souhaitez afficher les informations.
Les informations de retour sur trace se trouvent dans la section **Retour sur trace**.
![\[Détails de retour en arrière pour un cluster de bases de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
Lorsque le retour sur trace est activé, les informations suivantes sont disponibles :
+ **Target window (Fenêtre cible)** – Laps de temps actuel spécifié pour la fenêtre de retour sur trace cible. La cible correspond au laps de temps maximal pendant lequel vous pouvez effectuer un retour sur trace si le stockage est suffisant.
+ **Actual window (Fenêtre réelle)** – Laps de temps réel pendant lequel vous pouvez effectuer un retour sur trace, qui peut être inférieur à celui de la fenêtre de retour sur trace cible. La fenêtre de retour sur trace réelle est basée sur votre charge de travail et sur le stockage disponible pour conserver les enregistrements de modification du retour sur trace.
+ **Date du retour en arrière le plus ancien** : date de retour en arrière le plus ancien possible pour le cluster de bases de données. Vous ne pouvez pas effectuer un retour en arrière du cluster de bases de données à un horodatage antérieure à l’heure affichée.
1. Procédez comme suit pour afficher les métriques de retour en arrière pour le cluster de bases de données :
1. Dans le panneau de navigation, choisissez **Instances**.
1. Choisissez le nom de l’instance principale pour le cluster de bases de données dont vous voulez afficher les détails.
1. Dans la **CloudWatch**section, tapez **Backtrack** dans le **CloudWatch**champ pour afficher uniquement les métriques Backtrack.
![\[Métriques de retour sur trace\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
Les métriques suivantes sont affichées :
+ **Taux de création d’enregistrements de modification de retour en arrière (nombre)** : cette métrique affiche le nombre d’enregistrements de modification de retour en arrière créés en 5 minutes pour votre cluster de bases de données. Vous pouvez utiliser cette métrique pour estimer le coût du retour sur trace pour votre fenêtre de retour sur trace cible.
+ **[Facturé] Enregistrements de modification de retour en arrière stockés (nombre)** : cette métrique affiche le nombre réel d’enregistrements de modification de retour en arrière utilisés par votre cluster de bases de données.
+ **Fenêtre de retour en arrière réelle (minutes)** : cette métrique indique s’il y a une différence entre la fenêtre de retour en arrière cible et la fenêtre de retour en arrière réelle. Par exemple, si votre fenêtre de retour sur trace cible est de 2 heures (120 minutes) et que cette métrique indique 100 minutes pour la fenêtre de retour sur trace réelle, la fenêtre de retour sur trace réelle est plus petite que la fenêtre de retour sur trace cible.
+ **Backtrack Window Alert (Count) (Alerte de fenêtre de retour sur trace (nombre))** – Cette métrique indique le nombre de fois où la fenêtre de retour sur trace réelle est plus petite que la fenêtre de retour sur trace cible pour un laps de temps donné.
**Note**
Les métriques suivantes peuvent avoir du retard par rapport à l’heure réelle :
**Backtrack Change Records Creation Rate (Count) (Taux de création d’enregistrements de modification de retour en arrière (nombre))**
**[Billed] Backtrack Change Records Stored (Count) ([Facturé] Enregistrements de modification de retour sur trace stockés (nombre))**
## AWS CLI
La procédure suivante explique comment afficher des informations de retour en arrière pour un cluster de bases de données à l’aide de l AWS CLI.
**Pour afficher les informations de retour d'un cluster de bases de données à l'aide du AWS CLI**
+ Appelez la commande [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
L’exemple suivant affiche les informations de retour en arrière pour `sample-cluster`.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Pour Windows :
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## API RDS
Pour consulter les informations de retour d'un cluster de bases de données à l'aide de l'API Amazon RDS, utilisez l'opération [DBClustersDescribe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html). Cette opération renvoie des informations sur les retours en arrière pour le cluster de bases de données spécifié dans la valeur `DBClusterIdentifier`.
## Abonnement à un événement de retour en arrière avec la console
La procédure suivante explique comment s’abonner à un événement de retour en arrière à l’aide de la console. L’événement vous envoie un e-mail ou une notification lorsque votre fenêtre de retour en arrière réelle est plus petite que votre fenêtre de retour en arrière cible.
**Pour afficher des informations de retour en arrière à l’aide de la 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. Choisissez **Abonnements aux événements**.
1. Choisissez **Créer un abonnement aux événements**.
1. Dans la zone **Nom**, attribuez un nom à l’abonnement aux événements et vérifiez que **Oui** est sélectionné pour **Activé**.
1. Dans la section **Target (Cible)**, choisissez **New email topic (Nouvelle rubrique d’e-mail)**.
1. Dans **Nom de la rubrique**, attribuez un nom à la rubrique, puis indiquez les adresses e-mail ou les numéros de téléphone qui recevront les notifications dans **Avec ces destinataires**.
1. Dans la section **Source**, choisissez **Instances** pour **Type de source**.
1. Pour **Instances to include (Instances à inclure)**, choisissez **Select specific instances (Sélectionner des instances spécifiques)**, puis sélectionnez votre instance de base de données.
1. Pour **Event categories to include (Catégories d’événement à inclure)**, choisissez **Select specific event categories (Sélectionner des catégories d’événement spécifiques)**, puis sélectionnez **backtrack (retour en arrière)**.
Votre page doit ressembler à la page suivante.
![\[Abonnement à des événements de retour en arrière\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. Sélectionnez **Créer**.
## Extraction de retours sur trace existants
Vous pouvez extraire des informations sur des retours en arrière existants pour un cluster de bases de données. Ces informations incluent l’identifiant unique du retour en arrière, la date et l’heure de destination et d’origine du retour en arrière, la date et l’heure de la demande de retour en arrière et l’état actuel du retour en arrière.
**Note**
Actuellement, vous ne pouvez pas extraire des retours en arrière existants à l’aide de la console.
### AWS CLI
La procédure suivante explique comment extraire des retours en arrière existants pour un cluster de bases de données à l’aide de l AWS CLI.
**Pour récupérer des backtracks existants à l'aide du AWS CLI**
+ Appelez la commande [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
L’exemple suivant extrait les retours en arrière existants pour `sample-cluster`.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Pour Windows :
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### API RDS
Pour récupérer des informations sur les backtracks d'un cluster de bases de données à l'aide de l'API Amazon RDS, utilisez l'opération [Describe DBCluster Backtracks](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html). Cette opération renvoie des informations sur les retours en arrière pour le cluster de bases de données spécifié dans la valeur `DBClusterIdentifier`.
# Désactivation du retour en arrière pour un cluster de bases de données Aurora MySQL
Vous pouvez désactiver la fonction de retour en arrière pour un cluster de bases de données.
## Console
Vous pouvez désactiver le retour en arrière pour un cluster de bases de données à l’aide de la console. Après avoir entièrement désactivé le retour en arrière pour un cluster, vous ne pouvez pas l’activer à nouveau pour ce cluster.
**Pour désactiver la fonction de retour en arrière pour un cluster de bases de données à l’aide de la console**
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. Choisissez **Bases de données**.
1. Choisissez le cluster que vous souhaitez modifier, puis choisissez **Modifier**.
1. Dans la section **Retour sur trace**, choisissez **Disable Backtrack (Désactiver le retour sur trace)**.
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez une des options suivantes :
+ **Apply during the next scheduled maintenance window (Appliquer lors de la prochaine fenêtre de maintenance planifiée)** – Attend la prochaine fenêtre de maintenance avant d’appliquer la modification.
+ **Appliquer immédiatement** – Applique la modification dès que possible.
1. Choisissez **Modifier le cluster**.
## AWS CLI
Vous pouvez désactiver la fonction de retour en arrière pour un cluster de bases de données à partir de l’AWS CLIen définissant la fenêtre de retour en arrière cible sur `0` (zéro). Après avoir entièrement désactivé le retour en arrière pour un cluster, vous ne pouvez pas l’activer à nouveau pour ce cluster.
**Pour modifier la fenêtre de retour en arrière cible pour un cluster de bases de données à l’aide de l AWS CLI**
+ Appelez la commande [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
+ `--backtrack-window` – spécifier `0` pour désactiver le retour sur trace.
L’exemple suivant désactive la fonction de retour en arrière cible pour `sample-cluster` en configurant `--backtrack-window` à `0`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Pour Windows :
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## API RDS
Pour désactiver la fonction de retour en arrière pour un cluster de bases de données à partir de l’API Amazon RDS, utilisez l’opération [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Définissez la valeur de `BacktrackWindow` à `0` (zéro), et spécifiez le cluster de bases de données dans la valeur `DBClusterIdentifier`. Après avoir entièrement désactivé le retour en arrière pour un cluster, vous ne pouvez pas l’activer à nouveau pour ce cluster.
# Test d’Amazon Aurora MySQL à l’aide de requêtes d’injection d’erreurs
Vous pouvez tester la tolérance aux pannes de votre cluster de bases de données Aurora MySQL à l’aide des requêtes d’injection d’erreurs. Les requêtes d’injection d’erreurs sont émises sous forme de commandes SQL à une instance Amazon Aurora. Elles vous permettent de programmer une simulation de l’un des événements suivants :
+ Un incident de l’instance de base de données du dispositif d’écriture ou de lecture
+ Un échec d’un réplica Aurora
+ Une défaillance disque
+ Une surcharge disque
Quand une requête d’injection d’erreurs spécifie un incident, elle provoque un incident de l’instance de base de données Aurora MySQL. Les autres requêtes d’injection d’erreurs se traduisent par des simulations d’événements d’erreur, mais n’entraînent pas la manifestation de l’événement. Lorsque vous soumettez une requête d’injection d’erreurs, vous pouvez aussi spécifier la durée pendant laquelle la simulation de l’événement d’erreur peut se produire.
Vous pouvez soumettre une requête d’injection d’erreurs à l’une de vos instances de réplica Aurora en vous connectant au point de terminaison du réplica Aurora. Pour plus d’informations, consultez [Connexions de point de terminaison Amazon Aurora](Aurora.Overview.Endpoints.md).
L’exécution de requêtes d’injection d’erreurs nécessite tous les privilèges d’utilisateur principal. Pour plus d’informations, consultez [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md).
## Test d’un incident d’instance
Vous pouvez forcer un incident d’instance Amazon Aurora à l’aide de la requête d’injection d’erreurs `ALTER SYSTEM CRASH`.
Pour cette requête d’injection d’erreurs, un basculement ne se produira pas. Si vous souhaitez tester un basculement, vous pouvez choisir l'action d'instance de **basculement** pour votre cluster de base de données dans la console RDS, ou utiliser la [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI commande ou l'opération de l'API [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS.
### Syntaxe
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### Options
Cette requête accepte l’un des types d’incident suivants :
+ **`INSTANCE`** — Simulation d’un incident de la base de données compatible MySQL pour l’instance Amazon Aurora.
+ **`DISPATCHER`** — Simulation d’un incident lié au répartiteur sur l’instance de scripteur pour le cluster de bases de données Aurora. Le *répartiteur* écrit les mises à jour sur le volume de cluster d’un cluster de bases de données Amazon Aurora.
+ **`NODE`** — Simulation d’un incident de la base de données compatible MySQL et du répartiteur pour l’instance Amazon Aurora. Pour cette simulation d’injection d’erreurs, le cache est également supprimé.
Le type d’incident par défaut est `INSTANCE`.
## Test d’une défaillance d’un réplica Aurora
Vous pouvez simuler l’échec d’un réplica Aurora à l’aide de la fonction de requête d’injection d’erreurs `ALTER SYSTEM SIMULATE READ REPLICA FAILURE`.
L’échec d’un réplica Aurora bloque toutes les demandes provenant de l’instance d’enregistreur et adressées à un réplica Aurora ou à tous les réplicas Aurora du cluster de bases de données pendant un intervalle de temps spécifié. Une fois l’intervalle écoulé, les réplicas Aurora affectés sont automatiquement synchronisés avec l’instance d’enregistreur.
### Syntaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Options
La requête d’injection d’erreurs accepte les paramètres suivants :
+ **`percentage_of_failure`** — Pourcentage de demandes de blocage pendant l’événement d’échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune demande n’est bloquée. Si vous spécifiez 100, toutes les demandes sont bloquées.
+ **Failure type (Type d’échec)** — Type d’échec à simuler. Spécifiez `TO ALL` pour simuler des échecs pour tous les réplicas Aurora dans le cluster de bases de données. Spécifiez `TO` et le nom du réplica Aurora pour simuler l’échec d’un réplica Aurora unique. Le type d’incident par défaut est `TO ALL`.
+ **`quantity`** — Durée pendant laquelle simuler l’échec du réplica Aurora. L’intervalle est une durée suivie d’une unité de temps. La simulation intervient pendant la durée spécifiée par l’unité. Par exemple, `20 MINUTE` entraîne l’exécution de la simulation pendant 20 minutes.
**Note**
Soyez vigilant lorsque vous spécifiez l’intervalle de l’événement d’erreur du réplica Aurora. Si vous spécifiez un intervalle trop long et que votre instance d’enregistreur écrit une importante quantité de données pendant l’échec, votre cluster Aurora DB peut considérer que votre réplica Aurora s’est bloqué et le remplacer.
## Test d’une défaillance disque
Vous pouvez simuler l’échec d’un disque pour un cluster de bases de données Aurora à l’aide de la requête d’injection d’erreurs `ALTER SYSTEM SIMULATE DISK FAILURE`.
Pendant la simulation d’un échec du disque, le cluster de bases de données Aurora marque de façon aléatoire des segments de disque comme défectueux. Les demandes adressées à ces segments seront bloquées pendant la durée de la simulation.
### Syntaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Options
La requête d’injection d’erreurs accepte les paramètres suivants :
+ **`percentage_of_failure`** — Pourcentage du disque à marquer comme défaillant pendant l’événement d’échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n’est marquée comme défaillante. Si vous spécifiez 100, la totalité du disque est marquée comme défaillante.
+ **`DISK index`** — Bloc de données logique spécifique pour lequel simuler l’événement d’échec. Si vous dépassez la plage de blocs de données logiques disponibles, vous recevez une erreur qui vous indique la valeur d’index maximale que vous pouvez spécifier. Pour plus d’informations, consultez [Affichage du statut du volume pour un cluster de base de données Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`NODE index`** — Nœud de stockage spécifique pour lequel simuler l’événement d’échec. Si vous dépassez la plage de nœuds de stockage disponibles, vous recevez une erreur qui vous indique la valeur d’index maximale que vous pouvez spécifier. Pour plus d’informations, consultez [Affichage du statut du volume pour un cluster de base de données Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`quantity`** — Durée pendant laquelle l’échec de disque est simulé. L’intervalle est une durée suivie d’une unité de temps. La simulation intervient pendant la durée spécifiée par l’unité. Par exemple, `20 MINUTE` entraîne l’exécution de la simulation pendant 20 minutes.
## Test d’une surcharge disque
Vous pouvez simuler l’échec d’un disque pour un cluster de bases de données Aurora à l’aide de la requête d’injection d’erreurs `ALTER SYSTEM SIMULATE DISK CONGESTION`.
Pendant la simulation d’une surcharge du disque, le cluster de bases de données Aurora marque de façon aléatoire les segments disque comme surchargés. Les demandes adressées à ces segments sont retardées entre le délai minimal et le délai maximal spécifiés de la durée de la simulation.
### Syntaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Options
La requête d’injection d’erreurs accepte les paramètres suivants :
+ **`percentage_of_failure`** — Pourcentage du disque à marquer comme surchargé pendant l’événement d’échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n’est marquée comme surchargée. Si vous spécifiez 100, la totalité du disque est marquée comme surchargée.
+ **`DISK index` ou `NODE index`** — Disque ou nœud spécifique pour lequel l’événement d’échec est simulé. Si vous dépassez la plage d’index du disque ou du nœud, vous recevez une erreur qui vous indique la valeur d’index maximale que vous pouvez spécifier.
+ **`minimum` et `maximum`** — Durées minimale et maximale du délai de surcharge, en millisecondes. Les segments de disque marqués comme surchargés sont retardés pendant une durée aléatoire comprise entre la durée minimale et la durée maximale en millisecondes de la simulation.
+ **`quantity`** — Durée pendant laquelle la surcharge du disque est simulée. L’intervalle est une durée suivie d’une unité de temps. La simulation intervient pendant la durée spécifiée par l’unité de temps. Par exemple, `20 MINUTE` entraîne l’exécution de la simulation pendant 20 minutes.
# Modification de tables dans Amazon Aurora à l’aide de Fast DDL
Amazon Aurora inclut des optimisations pour exécuter une opération `ALTER TABLE` en place, presque instantanément. L’opération s’effectue sans nécessiter la copie de la table et sans impact matériel sur les autres instructions DML. Puisque l’opération ne consomme pas de stockage temporaire pour une copie de table, les instructions DDL sont pratiques même pour des tables volumineuses sur des classes d’instance Small.
Aurora MySQL version 3 est compatible avec la fonction MySQL 8.0 appelée Instant DDL. Aurora MySQL version 2 utilise une implémentation différente appelée Fast DDL.
**Topics**
+ [Instant DDL (Aurora MySQL version 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [Fast DDL (Aurora MySQL version 2)](#AuroraMySQL.Managing.FastDDL-v2)
## Instant DDL (Aurora MySQL version 3)
L’optimisation effectuée par Aurora MySQL version 3 pour améliorer l’efficacité de certaines opérations DDL est appelée DDL Instant DDL.
Aurora MySQL version 3 est compatible avec la fonction Instant DDL de MySQL 8.0 version communautaire. Vous effectuez une opération Instant DDL à l’aide de la clause `ALGORITHM=INSTANT` avec l’instruction `ALTER TABLE`. Pour plus de détails sur la syntaxe et l’utilisation d’Instant DDL, consultez [ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) et [Online DDL Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html) dans la documentation MySQL.
Les exemples suivants illustrent la fonction Instant DDL. Les instructions `ALTER TABLE` ajoutent des colonnes et modifient les valeurs par défaut des colonnes. Les exemples incluent des colonnes régulières et virtuelles, ainsi que des tables régulières et partitionnées. À chaque étape, vous pouvez consulter les résultats en émettant les instructions `SHOW CREATE TABLE` et `DESCRIBE`.
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## Fast DDL (Aurora MySQL version 2)
Fast DDL dans Aurora MySQL est une optimisation conçue pour améliorer les performances de certaines modifications de schéma, telles que l’ajout ou la suppression de colonnes, en réduisant la durée d’indisponibilité et l’utilisation des ressources. Elle permet d’effectuer ces opérations de manière plus efficace par rapport aux méthodes DDL traditionnelles.
**Important**
Pour l’instant, vous devez activer le mode lab d’Aurora pour pouvoir utiliser Fast DDL. Pour en savoir plus sur l’activation du mode lab, consultez [Mode Lab Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md).
L’optimisation Fast DDL a été initialement introduite en mode lab sur Aurora MySQL version 2 pour améliorer l’efficacité de certaines opérations DDL. Dans la version 3 d’Aurora MySQL, le mode lab a été abandonné et Fast DDL a été remplacé par la fonctionnalité Instant DDL de MySQL 8.0.
Dans MySQL, de nombreuses opérations de langage de définition de données (DDL) ont un impact important sur les performances.
Par exemple, supposons que vous utilisiez une opération `ALTER TABLE` pour ajouter une colonne à une table. En fonction de l’algorithme spécifié pour l’opération, cette dernière peut impliquer :
+ la création d’une copie intégrale de la table,
+ la création d’une table temporaire pour traiter les opérations DML (Data Manipulation Language) simultanées,
+ la reconstruction de tous les index pour la table,
+ l’application de verrous de table lors de l’application de modifications DML simultanées,
+ le ralentissement du débit DML simultané.
Cet impact sur les performances peut être particulièrement difficile dans les environnements impliquant de grandes tables ou des volumes de transactions élevés. Fast DDL contribue à atténuer ces difficultés en optimisant les modifications de schéma, ce qui permet des opérations plus rapides et moins gourmandes en ressources.
### Limitations FAST DDL
Fast DDL présente actuellement les limitations suivantes :
+ FAST DLL prend uniquement en charge l’ajout de colonnes acceptant la valeur null, sans valeurs par défaut, à la fin d’une table existante.
+ Fast DDL ne fonctionne pas pour les tables partitionnées.
+ Fast DDL ne fonctionne pas pour des tables InnoDB qui utilisent le format de ligne REDUNDANT.
+ Fast DDL ne fonctionne pas pour les tables avec des index de recherche en texte intégral.
+ Si la taille maximale d’enregistrement possible pour l’opération DDL est trop importante, Fast DDL n’est pas utilisé. Une taille d’enregistrement est trop importante si elle est supérieure à la moitié de la taille de la page. La taille maximale d’un enregistrement est calculée en ajoutant les tailles maximales de toutes les colonnes. Pour les colonnes de taille variable, conformément aux normes InnoDB, les octets externes ne sont pas compris dans le calcul.
### Syntaxe FAST DDL
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
Cette instruction accepte les options suivantes :
+ **`tbl_name` — **Nom de la table à modifier.
+ **`col_name` — **Nom de la colonne à ajouter.
+ **`col_definition` — **Définition de la colonne à ajouter.
**Note**
Vous devez spécifier une définition de colonne acceptant la valeur null sans valeur par défaut. Sinon, Fast DLL n’est pas utilisé.
### Exemples FAST DDL
Les exemples suivants illustrent l’accélération due aux opérations Fast DDL. Le premier exemple SQL exécute des instructions `ALTER TABLE` sur une grande table sans utiliser Fast DDL. Cette opération prend beaucoup de temps. Un exemple d’interface CLI montre comment activer Fast DDL pour le cluster. Ensuite, un autre exemple SQL exécute les mêmes instructions `ALTER TABLE` sur une table identique. Avec Fast DDL activé, l’opération est très rapide.
Cet exemple utilise la table `ORDERS` du benchmark TPC-H, qui contient 150 millions de lignes. Ce cluster utilise volontairement une classe d’instance relativement petite afin de montrer combien de temps les instructions `ALTER TABLE` peuvent prendre lorsque vous ne pouvez pas utiliser Fast DDL. L’exemple crée un clone de la table d’origine contenant des données identiques. La vérification du paramètre `aurora_lab_mode` confirme que le cluster ne peut pas utiliser Fast DDL, car le mode Lab n’est pas activé. Ensuite, les instructions `ALTER TABLE ADD COLUMN` prennent beaucoup de temps pour ajouter des colonnes à la fin de la table.
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
Cet exemple effectue la même préparation d’une grande table que l’exemple précédent. Cependant, vous ne pouvez pas simplement activer le mode Lab dans une séance SQL interactive. Ce paramètre doit être activé dans un groupe de paramètres personnalisé. Pour ce faire, il faut sortir de la session `mysql` et exécuter quelques commandes de la CLI AWS ou utiliser la AWS Management Console.
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
L’activation du mode Lab pour le cluster nécessite d’utiliser un groupe de paramètres. Cet exemple d’AWS CLI utilise un groupe de paramètres de cluster afin de garantir que toutes les instances de base de données dans le cluster utilisent la même valeur pour le paramètre de mode Lab.
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
L’exemple suivant montre les étapes restantes une fois que les modifications du groupe de paramètres ont pris effet. Il teste le paramètre `aurora_lab_mode` pour s’assurer que le cluster peut utiliser Fast DDL. Ensuite, il exécute des instructions `ALTER TABLE` pour ajouter des colonnes à la fin d’une autre grande table. Cette fois, les instructions se terminent très rapidement.
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Affichage du statut du volume pour un cluster de base de données Aurora MySQL
Dans Amazon Aurora, un volume de cluster de base de données se compose d'un ensemble de blocs logiques. Chacun d'eux représente 10 gigaoctets de stockage alloué. Ces blocs sont appelés *groupes de protection*.
Les données figurant dans chaque groupe de protection sont répliquées sur six périphériques de stockage physiques, appelés *nœuds de stockage*. Ces nœuds de stockage sont alloués dans trois zones de disponibilité dans la région AWS où se trouve le cluster de base de données. Chaque nœud de stockage contient à son tour un ou plusieurs blocs de données logiques pour le volume de cluster de base de données. Pour plus d'informations sur les groupes de protection et les nœuds de stockage, consultez [Introducing the Aurora Storage Engine](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) sur le blog AWS Database.
Vous pouvez simuler la panne d'un nœud de stockage entier ou d'un seul bloc de données logique au sein d'un nœud de stockage. Pour ce faire, utilisez l'instruction d'injection d'erreurs `ALTER SYSTEM SIMULATE DISK FAILURE`. Pour l'instruction, vous devez spécifier la valeur d'index d'un nœud de stockage ou d'un bloc de données logique spécifique. Toutefois, si vous spécifiez une valeur d'index supérieure au nombre de nœuds de stockage ou de blocs de données logiques utilisés par le volume de cluster de base de données, l'instruction renvoie une erreur. Pour en savoir plus sur les requêtes d'injection d'erreurs, consultez [Test d’Amazon Aurora MySQL à l’aide de requêtes d’injection d’erreurs](AuroraMySQL.Managing.FaultInjectionQueries.md).
Vous pouvez éviter cette erreur en utilisant l'instruction `SHOW VOLUME STATUS`. L'instruction renvoie deux variables de statut de serveur, `Disks` et `Nodes`. Ces variables représentent respectivement le nombre total de blocs de données logiques et de nœuds de stockage pour le volume de cluster de base de données.
## Syntaxe
```
SHOW VOLUME STATUS
```
## exemple
L'exemple suivant illustre un résultat SHOW VOLUME STATUS classique.
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```