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 sur trace d'un cluster de base de données Aurora
Avec Amazon Aurora My SQL -Compatible Edition, vous pouvez revenir en arrière sur un cluster de base de données à un moment précis, sans restaurer les données à partir d'une sauvegarde.
Table des matières
Considérations relatives aux mises à niveau pour les clusters compatibles avec le retour sur trace
Configuration du retour en arrière sur un cluster Aurora My SQL DB
Réalisation d'un retour en arrière pour un cluster Aurora My SQL DB
Surveillance du retour en arrière pour un cluster Aurora My SQL DB
Abonnement à un événement de retour sur trace avec la console
Désactivation du retour en arrière pour un cluster Aurora My DB SQL
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, telle qu'une action DELETE sans WHERE clause, vous pouvez revenir en arrière sur le cluster de bases de données à une époque antérieure à l'action destructrice avec une interruption de service minimale.
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 du describe-db-cluster-backtracks AWS CLIcommande. Pour de plus amples informations, veuillez consulter 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.
-
Vous ne pouvez pas créer de répliques de 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 de revenir en arrière 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 choisissez 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 les déploiements bleu/vert.
-
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 un AWS Région qui ne prend pas en charge le retour en arrière.
-
Si vous effectuez une mise à niveau sur place pour un cluster compatible avec le backtrack depuis la SQL version 2 vers la version 3 d'Aurora My, vous ne pouvez pas revenir en arrière avant que la mise à niveau n'ait eu lieu.
Disponibilité des régions et des versions
Backtrack n'est pas disponible pour Aurora SQL Postgre.
Vous trouverez ci-dessous les moteurs pris en charge et la disponibilité des régions pour Backtrack with Aurora MySQL.
| Région | Aurora Ma SQL version 3 | Aurora Ma SQL 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 (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 (UAE) | – | – |
| 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 compatible avec le backtrack d'Aurora My SQL version 2 vers la version 3, car toutes les versions mineures d'Aurora My SQL version 3 sont prises en charge pour Backtrack.
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 au AWS Management Console et ouvrez la RDS console Amazon à 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 décrit comment récupérer les backtracks existants pour un cluster de base de données à l'aide du AWS CLI.
Pour récupérer des backtracks existants à l'aide du AWS CLI
-
Appelez le describe-db-cluster-backtracks AWS CLIcommandez 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.Dans Linux, macOS, ou Unix:
aws rds describe-db-cluster-backtracks \ --db-cluster-identifier sample-clusterDans 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 d'Amazon RDSAPI, utilisez l'opération D escribeDBCluster Backtracks. 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.
