Pourquoi la restauration de l'instantané de mon cluster DB compatible avec Aurora MySQL prend-elle autant de temps ?

Brève description

Le processus de restauration d'instantanés pour les clusters DB compatibles avec Amazon Aurora MySQL implique un certain nombre de tâches importantes. Par exemple, au cours de ce processus, un cluster Aurora est créé, tout comme le volume de cluster à haute disponibilité. Des processus tels que la vérification de l'état, l'allocation du stockage et du matériel, ainsi que l'écriture de volumes de données participent tous au délai nécessaire à la restauration d'un instantané.

La durée de restauration d'un instantané est influencée par plusieurs facteurs :

• Pour les clusters Aurora, un seul est réparti sur trois zones de disponibilité (AZ) afin de garantir une haute disponibilité. Lorsque le cluster Aurora effectue une restauration à partir de l'instantané, il provisionne le stockage dans ces trois AZ. Une fois que le cluster est disponible, il crée six copies supplémentaires dans le volume du cluster pour stocker les données. Le volume de stockage est réparti entre des centaines de nœuds de stockage, et distribué sur trois AZ différentes.
• Une fois le cluster Aurora créé, le cluster télécharge les données depuis Amazon Simple Storage Solution S3 (Amazon S3) vers les nœuds de stockage. Le cluster effectue cette opération avant que les données ne soient disponibles. Contrairement au processus de restauration d'Amazon Relational Database Service (Amazon RDS) pour les instances MySQL, le chargement différé n'a pas lieu après la restauration.
• Les restaurations Aurora ne sont pas linéaires. Par exemple, vous pouvez restaurer deux clusters distincts, l'un avec 1 Go de données et l'autre avec 10 Go de données. Au lieu de prendre dix fois plus de temps, la restauration d'un ensemble de données volumineux ne prend qu'un peu plus de temps que celle d'un ensemble de données plus petit.
• Les autres processus de restauration incluent la vérification de l'état, l'allocation du stockage et du matériel, ainsi que l'écriture de volumes de données. Tous ces processus prennent beaucoup de temps, mais doivent être exécutés avec précision pour obtenir les meilleures performances.

Résolution

Vous pouvez utiliser la fonction de clonage de cluster Aurora ou la fonction de retour en arrière lorsque vous apportez des modifications à vos bases de données Aurora, en fonction de votre cas d'utilisation.

Clone de cluster Aurora

L'utilisation de la fonction de clonage de cluster Aurora est le moyen le plus rapide de créer une copie identique de votre cluster actuel. Une fois le cluster cloné créé, vous pouvez tester vos modifications par rapport au cluster cloné sans affecter le cluster d'origine. Si le test est réussi, vous pouvez appliquer des modifications au cluster d'origine.

Remarque : il est toujours recommandé de prendre un instantané de votre cluster avant d'apporter des modifications à une base de données.

Voici quelques cas d'utilisation courants pour le clonage d'un cluster Aurora existant :

• Vous souhaitez expérimenter et évaluer l'impact de modifications telles que les modifications de schéma ou les modifications de groupes de paramètres.
• Vous souhaitez effectuer des opérations à forte charge de travail, telles que l'exportation de données ou l'exécution de requêtes analytiques.
• Vous souhaitez créer une copie d'un cluster DB de production dans un environnement hors production à des fins de développement ou de test.

Fonction de retour en arrière Aurora

Vous pouvez également utiliser la fonctionnalité de retour en arrière pour vos clusters Aurora. Le retour en arrière vous permet de corriger rapidement les erreurs en effectuant un rembobinage sur place de vos données. Le retour en arrière d'un cluster DB ne nécessite pas la création d'un nouveau cluster DB et ne prend donc que quelques minutes.

Mais cette fonction présente des limites. Tout d'abord, elle n'est disponible que sur les clusters créés avec la fonction activée. Donc, si cette fonction n'est pas activée sur votre cluster, vous devez effectuer une restauration d'instantané pour activer le retour en arrière. De plus, le retour en arrière ne prend pas en charge la réplication des journaux binaires, et la réplication entre régions doit être désactivée avant de pouvoir configurer ou utiliser le retour en arrière. La limite pour une fenêtre de retour en arrière est de 72 heures.

Considérations

Les fonctions de clonage de cluster et de retour en arrière Aurora ont été introduites pour améliorer le temps de restauration d'Aurora dans certains cas d'utilisation. Cependant, la prise régulière d'instantanés reste une bonne pratique, et il est préférable d'adopter cette approche avant d'apporter des modifications planifiées à une base de données.

Assurez-vous également 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 accroître le temps nécessaire à la mise à disposition de la base de données restaurée.

Informations connexes

Clonage d'un volume pour un cluster DB Amazon Aurora

Retour en arrière d'un cluster DB Aurora