Pourquoi le clonage d'un cluster de base de données Amazon Aurora, la prise d'un instantané ou la restauration à un instant dans le passé durent-ils aussi longtemps ?

Date de la dernière mise à jour : 2020-10-21

J'effectue un clonage de cluster, une prise d'instantanés ou une restauration à un instant dans le passé sur mon cluster Amazon Aurora. Pourquoi cette restauration prend-elle si longtemps et comment puis-je résoudre ce problème ?

Brève description

Les techniques de sauvegarde et de restauration continues d'Amazon Aurora sont optimisées pour éviter les variations des temps de restauration. Elles aident également le volume de stockage du cluster à atteindre des performances complètes dès que le cluster est disponible. En règle générale, les longues périodes de restauration sont dues à des transactions de longue durée dans la base de données source au moment où la sauvegarde a été effectuée.

Résolution

Remarque : si vous recevez des erreurs lors de l'exécution de commandes depuis l'interface de ligne de commande AWS (AWS CLI), assurez-vous d'utiliser la version la plus récente de l'interface de ligne de commande AWS.

Amazon Aurora sauvegarde automatiquement et en continu les modifications du volume de votre cluster. Les sauvegardes sont conservées pendant toute la durée de votre période de conservation des sauvegardes. Vous pouvez aussi, grâce à cette sauvegarde continue, restaurer vos données sur un nouveau cluster à partir de n'importe quel instant dans le passé compris dans la période de conservation spécifiée. Ainsi, il n'est plus nécessaire de recourir à un long processus de restauration par progression binlog. Étant donné que vous créez un nouveau cluster, il n'y a aucun impact sur les performances ni interruption de votre base de données d'origine.

Lorsque vous lancez un clonage, un instantané ou une restauration à un instant dans le passé, Amazon RDS appelle les API suivantes en votre nom :

Au terme de cette étape, le cluster passe à l'état Disponible. Vous pouvez vérifier l'état de votre cluster en actualisant la console ou en vérifiant avec l'interface de ligne de commande AWS.

Le processus de création d'une instance ne démarre que lorsque le cluster est disponible. Cela se produit en deux étapes : la configuration de l'instance et la reprise après un incident de base de données.

Vous pouvez vérifier si l'API a fini de configurer l'instance en recherchant le fichier journal des erreurs MySQL. Vous pouvez le faire même si le statut de l'instance est Création. Si le fichier journal des erreurs est disponible pour le téléchargement, c'est que l'instance est configurée et que le moteur effectue désormais une reprise après incident. Le fichier journal des erreurs est également la meilleure ressource pour vérifier la progression de la reprise après incident de votre base de données, ainsi que les métriques Amazon CloudWatch.

Remarque : si vous utilisez l'interface de ligne de commande AWS ou l'API pour effectuer une opération de restauration, assurez-vous d'appeler l'appel CreateDBInstance, car cet appel n'est pas automatique.

Rechercher des opérations d'écriture longues sur la base de données source

La meilleure façon d'empêcher une longue reprise après incident consiste à s'assurer qu'aucune opération d'écriture longue durée n'est en cours d'exécution sur la base de données source au moment de la prise de l'instantané, de la restauration à un instant dans le passé, ou du clonage. Toute opération DCL, DDL ou DML (transactions en écriture ouverte) longue durée peut allonger le temps nécessaire à la mise à disposition de la base de données restaurée.

Par exemple, si vous activez le journal binaire pour un cluster Aurora, cela augmente le temps nécessaire pour effectuer une reprise. En effet, InnoDB vérifie automatiquement les journaux et effectue une restauration par progression de la base de données vers le présent. Il annule ensuite toutes les transactions non validées qui sont présentes au moment de la reprise. Pour plus d'informations sur la reprise après un incident InnoDB, consultez Reprise Innodb.

Lorsque l'instance termine les processus de création et de reprise, le cluster et l'instance sont alors prêts à accepter les connexions entrantes.

Remarque : le journal binaire n'est pas nécessaire pour Aurora. Il est recommandé de le désactiver à moins qu'il ne soit nécessaire. Pour la réplication entre régions, vous pouvez plutôt évaluer les bases de données globales Aurora pour lesquelles les journaux binaires ne sont également pas nécessaires.