Présentation du retour sur trace Disponibilité des régions et des versions Considérations relatives aux mises à niveau pour les clusters compatibles avec le retour sur trace Configuration de retour sur trace Exécution d'un retour sur trace Surveillance de retour sur trace Abonnement à un événement de retour sur trace Extraction de retours sur trace existants Désactivation de retour sur trace pour un cluster de base de données

Retour sur trace d'un cluster de base de données Aurora

Édition compatible avec Amazon Aurora MySQL vous permet d'effectuer un retour sur trace d'un cluster de base de données à une heure spécifique, sans restaurer les données à partir d'une sauvegarde.

Table des matières

Présentation du retour sur trace

Le retour sur trace permet de « faire revenir en arrière » le cluster de base de données à l'heure que vous spécifiez. Le retour sur trace ne remplace pas une sauvegarde de votre cluster de base de données afin de pouvoir la restaurer à un instant dans le passé. Toutefois, le retour sur trace 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 sur trace pour faire revenir le cluster de base de données à une heure précédant l'action destructrice sans aucune interruption minimale du service.
Vous pouvez effectuer rapidement un retour sur trace d'un cluster de base de données. La restauration d'un cluster de base de données à un instant dans le passé lance un nouveau cluster de base de données et restaure celui-ci à partir des données de sauvegarde ou d'un instantané de cluster de base de données ; cette opération peut prendre plusieurs heures. Le retour sur trace d'un cluster de base de données ne nécessite pas de nouveau cluster de base de données et fait revenir en arrière le cluster de base de données en quelques minutes.
Vous pouvez explorer les précédentes modifications de données. Vous pouvez effectuer des retours sur trace d'un cluster de base 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 sur trace d'un cluster de base de données de trois heures, puis effectuer un autre retour sur trace en avant d'une heure. Dans ce cas, l'heure du retour sur trace est antérieure de deux heures par rapport à l'heure d'origine.

Note

Pour plus d'informations sur la restauration d'un cluster de base 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.

Fenêtre de retour sur trace

Avec le retour sur trace, il y a une fenêtre de retour sur trace cible et une fenêtre de retour sur trace réelle :

La fenêtre de retour sur trace cible correspond au laps de temps pendant lequel vous souhaitez pouvoir effectuer un retour sur trace de votre cluster de base de données. Lorsque vous activez le retour sur trace, vous spécifiez une fenêtre de retour sur trace cible. Par exemple, vous pouvez spécifier une fenêtre de retour sur trace cible de 24 heures si vous souhaitez pouvoir effectuer un retour sur trace d'une journée du cluster de base de données.
La fenêtre de retour sur trace réelle correspond au laps de temps réel pendant lequel vous pouvez effectuer un retour sur trace de votre cluster de base de données ; sa valeur peut être inférieure à celle 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 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 base de données Aurora avec le retour sur trace activé, vous générez des enregistrements de modifications. Aurora conserve les enregistrements de modifications pour la fenêtre de retour sur trace cible, et leur stockage vous est facturé sur une base horaire. La fenêtre de retour sur trace cible et la charge de travail sur votre cluster de base 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 base 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 sur trace que si votre charge de travail est légère.

Vous pouvez considérer votre fenêtre de retour sur trace cible comme étant l'objectif du laps de temps maximal pendant lequel vous souhaitez pouvoir faire un retour sur trace de votre cluster de base de données. Dans la plupart des cas, vous pouvez effectuer un retour sur trace correspondant au laps de temps maximal spécifié. Toutefois, dans certains cas, le cluster de base de données ne peut pas stocker suffisamment d'enregistrements de modification pour effectuer un retour sur trace correspondant au laps de temps maximal, et votre fenêtre de retour sur trace réelle est plus petite que votre fenêtre de retour sur trace cible. Généralement, la fenêtre de retour sur trace réelle est plus petite que la fenêtre de retour sur trace cible lorsque la charge de travail est particulièrement lourde sur votre cluster de base de données. Lorsque votre fenêtre de retour sur trace réelle est plus petite que votre fenêtre de retour sur trace cible, nous vous envoyons une notification.

Lorsque le retour sur trace est activé pour un cluster de base 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 sur trace. 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 sur trace pour stocker la table, il est possible que celle-ci soit supprimée des enregistrements de modification du retour sur trace.

Heure de retour sur trace

Aurora procède toujours au retour sur trace à une heure cohérente pour le cluster de base de données. Cela élimine la possibilité de transactions non validées une fois le retour sur trace terminé. Lorsque vous spécifiez une heure de retour sur trace, 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 AWS CLI. Pour plus d’informations, consultez Extraction de retours sur trace existants.

Limites du retour sur trace

Les limites suivantes s'appliquent à un retour sur trace :

Le retour sur trace est disponible uniquement pour les clusters de bases de données créés avec la fonction de retour sur trace activée. Vous ne pouvez pas modifier un cluster de base de données pour activer la fonctionnalité Backtrack. Vous pouvez activer la fonction de retour sur trace lorsque vous créez un nouveau cluster de base de données, restaurez un instantané de cluster de base de données.
La limite pour une fenêtre de retour sur trace est de 72 heures.
Le retour sur trace affecte l'ensemble du cluster de base de données. Par exemple, vous ne pouvez pas effectuer un retour sur trace sélectif sur une seule table ou une seule mise à jour de données.
Le retour sur trace n'est pas pris en charge avec la réplication de journaux binaires (binlog). La réplication entre régions doit être désactivée avant de pouvoir configurer ou utiliser la fonction de retour sur trace.
Vous ne pouvez pas effectuer un retour sur trace 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 sur trace à 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 base de données Amazon Aurora.
Le retour sur trace 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 sur trace, 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 sur trace, 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 sur trace 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 sur trace, vous ne pouvez pas effectuer un retour sur trace à une heure antérieure à celle où la mise à jour a eu lieu.

Disponibilité des régions et des versions

Le retour sur trace n'est pas disponible pour Aurora PostgreSQL.

Voici les moteurs pris en charge et la disponibilité des régions pour le retour sur trace avec Aurora MySQL.

Région	Aurora MySQL version 3	Aurora MySQL version 2
USA Est (Ohio)	Toutes les versions	Toutes les versions
USA Est (Virginie du Nord)	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 (Melbourne)	–	–
Asie-Pacifique (Mumbai)	Toutes les versions	Toutes les versions
Asie-Pacifique (Osaka)	Toutes les versions	Version 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 (Tokyo)	Toutes les versions	Toutes les versions
Canada (Centre)	Toutes les versions	Toutes les versions
Canada Ouest (Calgary)	–	–
Chine (Beijing)	–	–
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)	–	–
Moyen-Orient (Bahreïn)	–	–
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 sur trace

Vous pouvez mettre à niveau un cluster de base de données prenant en charge le retour sur trace 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 sur trace.

Configuration de retour sur trace

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.

Vous pouvez utiliser la console pour configurer le retour sur trace lorsque vous créez un nouveau cluster de base de données. Vous pouvez également modifier un cluster de base de données pour modifier la fenêtre de retour sur trace d'un cluster compatible avec le retour sur trace. 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.

Rubriques

Configuration du retour sur trace avec la console lors de la création d'un cluster de base de données
Configuration du retour sur trace avec la console lors de la modification d'un cluster de base de données

Configuration du retour sur trace avec la console lors de la création d'un cluster de base de données

Lorsque vous créez un cluster de base de données Aurora MySQL, la configuration du retour sur trace consiste à choisir Enable Backtrack (Activer le retour sur trace) et à spécifier pour Target Backtrack window (Fenêtre de retour sur trace cible) une valeur supérieure à zéro dans la section Retour sur trace.

Pour créer un cluster de base de données, suivez les instructions de Création d'un cluster de base de données Amazon Aurora. L'image suivante montre la section Retour sur trace.

Activation du retour sur trace pendant la création d'un cluster de base de données à partir de la console

Lorsque vous créez un nouveau cluster de base de données, Aurora n'a aucune donnée pour la charge de travail du cluster de base de données. Il ne peut donc pas estimer de coût spécifique pour le nouveau cluster de base 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 base de données.

Configuration du retour sur trace avec la console lors de la modification d'un cluster de base de données

Vous pouvez modifier le retour sur trace pour un cluster de base de données à l'aide de la console.

Note

Actuellement, vous pouvez modifier le retour sur trace uniquement pour un cluster de base de données dont la fonction de retour sur trace est activée. La section Retour sur trace n'apparaît pas pour un cluster de base de données créé avec la fonction de retour sur trace désactivée ou si cette fonction a été désactivée pour le cluster de base de données.

Pour modifier le retour sur trace pour un cluster de base de données à l'aide de la console

Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.
Choisissez Bases de données.
Choisissez le cluster que vous souhaitez modifier, puis choisissez Modifier.
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.

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 base 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 déjà été activé 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.
Choisissez Continuer.
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 de Target Backtrack window (Fenêtre de retour sur trace cible).
- Apply immediately (Appliquer immédiatement) – Applique la modification de Target Backtrack window (Fenêtre de retour sur trace cible) dès que possible.
Choisissez Modifier le cluster.

Lorsque vous créez un nouveau cluster de base de données Aurora MySQL à l'aide de la commande create-db-cluster 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 plus d’informations, consultez Création d'un cluster de base de données Amazon Aurora.

Vous pouvez également spécifier la --backtrack-window valeur à l'aide des commandes AWS CLI suivantes :

La procédure suivante explique comment modifier la fenêtre de retour sur trace cible pour un cluster de base 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 AWS CLI et fournissez les valeurs suivantes :
- --db-cluster-identifier – Nom du cluster de base de données.
- --backtrack-window – Nombre maximal de secondes pendant lesquelles vous souhaitez pouvoir faire un retour sur trace de cluster de base de données.
L'exemple suivant définit la fenêtre de retour sur trace cible pour sample-cluster à une journée (86 400 secondes).

Pour LinuxmacOS, ou Unix :
```
aws rds modify-db-cluster \
    --db-cluster-identifier sample-cluster \
    --backtrack-window 86400
```
Dans Windows :
```
aws rds modify-db-cluster ^
    --db-cluster-identifier sample-cluster ^
    --backtrack-window 86400
```

Note

Actuellement, vous pouvez activer le retour sur trace uniquement pour un cluster de base de données créé avec la fonction de retour sur trace activée.

Lorsque vous créez un cluster de base de données Aurora MySQL en utilisant l'opération CreateDBCluster de l'API Amazon RDS, le retour sur trace est configuré lorsque vous spécifiez une valeur supérieure à zéro pour BacktrackWindow. La valeur BacktrackWindow spécifie la fenêtre de retour sur trace cible pour le cluster de base de données spécifié dans la valeur DBClusterIdentifier. Pour plus d'informations, consultez Création d'un cluster de base de données Amazon Aurora.

Vous pouvez également spécifier la valeur BacktrackWindow à l'aide des opérations d'API suivantes :

Note

Actuellement, vous pouvez activer le retour sur trace uniquement pour un cluster de base de données créé avec la fonction de retour sur trace activée.

Exécution d'un retour sur trace

Vous pouvez effectuer un retour sur trace pour un cluster de base de données à un horodatage de retour sur trace spécifié. Si l'horodatage de retour sur trace n'est pas antérieur à l'heure de retour sur trace la plus ancienne possible et ne se situe pas dans le futur, le retour sur trace du cluster de base 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 sur trace sur un cluster de base 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 sur trace. Forcer un retour sur trace peut interférer avec d'autres opérations utilisant la journalisation binaire.

Important

Le retour sur trace 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 base de données, il est possible que le retour sur trace 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 sur trace du cluster de base 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 base de données Amazon Aurora.

La procédure suivante explique comment effectuer une opération de retour sur trace pour un cluster de base de données à l'aide de la console.

Pour effectuer une opération de retour sur trace à l'aide de la console

Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.
Dans le panneau de navigation, choisissez Instances.
Choisissez l'instance principale du cluster de base de données pour lequel vous souhaitez effectuer un retour sur trace.
Pour Actions, choisissez Backtrack DB cluster (Retour sur trace de cluster de base de données).
Sur la page Backtrack DB cluster (Retour sur trace de cluster de base de données), entrez l'horodatage de retour sur trace à appliquer au retour sur trace de cluster de base de données.
Choisissez Backtrack DB cluster (Retour sur trace de cluster de base de données).

La procédure suivante explique comment effectuer un retour sur trace de cluster de base de données à l'aide de l AWS CLI.

Pour revenir en arrière sur un cluster de bases de données à l'aide du AWS CLI

Appelez la commande backtrack-db-cluster AWS CLI et fournissez les valeurs suivantes :
- --db-cluster-identifier – Nom du cluster de base de données.
- --backtrack-to – Horodatage de retour sur trace de cluster de base de données, spécifié au format ISO 8601.
L'exemple suivant effectue un retour sur trace du cluster de base de données sample-cluster à 10 h, le 19 mars 2018.

Pour LinuxmacOS, ou Unix :
```
aws rds backtrack-db-cluster \
    --db-cluster-identifier sample-cluster \
    --backtrack-to 2018-03-19T10:00:00+00:00
```
Dans Windows :
```
aws rds backtrack-db-cluster ^
    --db-cluster-identifier sample-cluster ^
    --backtrack-to 2018-03-19T10:00:00+00:00
```

Pour effectuer un retour sur trace de cluster de base de données à l'aide de l'API Amazon RDS, utilisez l'opération BacktrackDBCluster. Cette opération effectue un retour sur trace du cluster de base de données spécifié dans la valeur DBClusterIdentifier à l'heure spécifiée.

Surveillance de retour sur trace

Vous pouvez afficher les informations et surveiller les métriques de retour sur trace pour un cluster de base de données.

Pour afficher les informations et surveiller les métriques de retour sur trace à l'aide de la console

Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.
Choisissez Bases de données.
Choisissez le nom du cluster de base de données pour lequel vous souhaitez afficher les informations.

Les informations de retour sur trace se trouvent dans la section Retour sur trace.

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 sur trace le plus ancien – Date de retour sur trace le plus ancien possible pour le cluster de base de données. Vous ne pouvez pas effectuer un retour sur trace du cluster de base de données à un horodatage antérieure à l'heure affichée.
Procédez comme suit pour afficher les métriques de retour sur trace pour le cluster de base de données :
1. Dans le panneau de navigation, choisissez Instances.
2. Choisissez le nom de l'instance principale pour le cluster de base de données dont vous voulez afficher les détails.
3. Dans la CloudWatchsection, tapez Backtrack dans le CloudWatchchamp pour afficher uniquement les métriques Backtrack.
  
  Les métriques suivantes sont affichées :
  - Backtrack Change Records Creation Rate (Count) (Taux de création d'enregistrements de modification de retour sur trace (nombre)) – Cette métrique affiche le nombre d'enregistrements de modification de retour sur trace créés en 5 minutes pour votre cluster de base 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.
  - [Billed] Backtrack Change Records Stored (Count) ([Facturé] Enregistrements de modification de retour sur trace stockés (nombre)) – Cette métrique affiche le nombre réel d'enregistrements de modification de retour sur trace utilisés par votre cluster de base de données.
  - Backtrack Window Actual (Minutes) (Fenêtre de retour sur trace réelle (minutes)) – Cette métrique indique s'il y a une différence entre la fenêtre de retour sur trace cible et la fenêtre de retour sur trace 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 sur trace (nombre))
  
  [Billed] Backtrack Change Records Stored (Count) ([Facturé] Enregistrements de modification de retour sur trace stockés (nombre))

La procédure suivante explique comment afficher des informations de retour sur trace pour un cluster de base 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 AWS CLI et fournissez les valeurs suivantes :
- --db-cluster-identifier – Nom du cluster de base de données.
L'exemple suivant affiche les informations de retour sur trace pour sample-cluster.

Pour LinuxmacOS, ou Unix :
```
aws rds describe-db-clusters \
    --db-cluster-identifier sample-cluster
```
Dans Windows :
```
aws rds describe-db-clusters ^
    --db-cluster-identifier sample-cluster
```

Pour afficher des informations de retour sur trace pour un cluster de base de données à l'aide de l'API Amazon RDS, utilisez l'opération DescribeDBClusters. Cette opération renvoie des informations sur les retours sur trace pour le cluster de base de données spécifié dans la valeur DBClusterIdentifier.

Abonnement à un événement de retour sur trace avec la console

La procédure suivante explique comment s'abonner à un événement de retour sur trace à l'aide de la console. L'événement vous envoie un e-mail ou une notification lorsque votre fenêtre de retour sur trace réelle est plus petite que votre fenêtre de retour sur trace cible.

Pour afficher des informations de retour sur trace à l'aide de la console

Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.
Choisissez Abonnements aux événements.
Choisissez Créer un abonnement aux événements.
Dans la zone Nom, attribuez un nom à l'abonnement aux événements et vérifiez que Oui est sélectionné pour Activé.
Dans la section Target (Cible), choisissez New email topic (Nouvelle rubrique d'e-mail).
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.
Dans la section Source, choisissez Instances pour Type de source.
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.
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 sur trace).

Votre page doit ressembler à la page suivante.
Sélectionnez Créer.

Extraction de retours sur trace existants

Vous pouvez extraire des informations sur des retours sur trace existants pour un cluster de base de données. Ces informations incluent l'identifiant unique du retour sur trace, la date et l'heure de destination et d'origine du retour sur trace, la date et l'heure de la demande de retour sur trace et l'état actuel du retour sur trace.

Note

Actuellement, vous ne pouvez pas extraire des retours sur trace existants à l'aide de la console.

La procédure suivante explique comment extraire des retours sur trace existants pour un cluster de base 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 AWS CLI et fournissez les valeurs suivantes :
- --db-cluster-identifier – Nom du cluster de base de données.
L'exemple suivant extrait les retours sur trace existants pour sample-cluster.

Pour LinuxmacOS, ou Unix :
```
aws rds describe-db-cluster-backtracks \
    --db-cluster-identifier sample-cluster
```
Dans Windows :
```
aws rds describe-db-cluster-backtracks ^
    --db-cluster-identifier sample-cluster
```

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 ClusterBacktracksDescribeDB. Cette opération renvoie des informations sur les retours sur trace pour le cluster de base de données spécifié dans la valeur DBClusterIdentifier.

Désactivation de retour sur trace pour un cluster de base de données

Vous pouvez désactiver la fonction de retour sur trace pour un cluster de base de données.

Vous pouvez désactiver le retour sur trace pour un cluster de base de données à l'aide de la console. Après avoir entièrement désactivé le retour sur trace pour un cluster, vous ne pouvez pas l'activer à nouveau pour ce cluster.

Pour désactiver la fonction de retour sur trace pour un cluster de base de données à l'aide de la console

Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.
Choisissez Bases de données.
Choisissez le cluster que vous souhaitez modifier, puis choisissez Modifier.
Dans la section Retour sur trace, choisissez Disable Backtrack (Désactiver le retour sur trace).
Choisissez Continuer.
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.
Choisissez Modifier le cluster.

Vous pouvez désactiver la fonctionnalité Backtrack pour un cluster de bases de données à l'aide du AWS CLI en réglant la fenêtre de retour cible sur 0 (zéro). Après avoir entièrement désactivé le retour sur trace pour un cluster, vous ne pouvez pas l'activer à nouveau pour ce cluster.

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 AWS CLI et fournissez les valeurs suivantes :
- --db-cluster-identifier – Nom du cluster de base de données.
- --backtrack-window – spécifier 0 pour désactiver le retour sur trace.
L'exemple suivant désactive la fonction de retour sur trace cible pour sample-cluster en configurant --backtrack-window à 0.

Pour LinuxmacOS, ou Unix :
```
aws rds modify-db-cluster \
    --db-cluster-identifier sample-cluster \
    --backtrack-window 0
```
Dans Windows :
```
aws rds modify-db-cluster ^
    --db-cluster-identifier sample-cluster ^
    --backtrack-window 0
```

Pour désactiver la fonction de retour sur trace pour un cluster de base de données à partir de l'API Amazon RDS, utilisez l'opération ModifyDBCluster. Définissez la valeur de BacktrackWindow à 0 (zéro), et spécifiez le cluster de base de données dans la valeur DBClusterIdentifier. Après avoir entièrement désactivé le retour sur trace pour un cluster, vous ne pouvez pas l'activer à nouveau pour ce cluster.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Gestion des performances et dimensionnement pour Amazon Aurora MySQL

Test d'Amazon Aurora MySQL à l'aide de requêtes d'injection d'erreurs