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