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 ?

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. Les longs délais de restauration sont généralement dus à des transactions de longue durée dans la base de données source au moment de la sauvegarde.

Résolution

Remarque : en cas d'erreurs lors de l'exécution de commandes depuis l'interface de ligne de commande AWS (AWS CLI), vérifiez que vous utilisez la version la plus récente d'AWS CLI.

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. Cette sauvegarde continue vous permet de restaurer vos données sur un nouveau cluster, à tout moment pendant 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 instantanée, Amazon Relational Database Service (Amazon RDS) appelle les API suivantes en votre nom :

• RestoreDBClusterFromSnapshot ou RestoreDBClusterToPointInTime. Ces API créent un nouveau cluster et restaurent le volume à partir d'Amazon Simple Storage Service (Amazon S3). Cette opération peut prendre quelques heures. Lorsque vous restaurez des données dans un cluster Aurora, toutes les données sont transférées en parallèle depuis Amazon S3 vers les six copies de vos trois zones de disponibilité.
• Le clonage du volume de stockage de cluster est une variation de RestoreDBClusterToPointInTime. Il utilise le protocole de copie sur écriture et se termine généralement en quelques minutes.

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 peut être téléchargé, cela signifie que l'instance est configurée et que le moteur est en train d'effectuer une restauration 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 ou l'API AWS pour effectuer une opération de restauration, vous devez appeler l'appel CreateDBInstance car il n'est pas automatique.

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

Il est recommandé de vérifier qu'il n'y a pas d'opérations d'écriture de longue durée sur la base de données source au moment de l'instantané, à un moment ponctuel, ou lors du clonage. Toute opération DCL, DDL, ou DML (transactions en écriture ouverte) longue durée pourrait allonger le temps nécessaire à la mise à disposition de la base de données restaurée.

Par exemple, vous activez le journal binaire d'un cluster Aurora, ce qui augmente le temps nécessaire pour effectuer une restauration. 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 que cela ne soit nécessaire. Pour la réplication entre régions, vous pouvez plutôt évaluer les bases de données globales Aurora. Les bases de données globales Aurora ne nécessitent pas non plus de journaux binaires.

Informations connexes

Stockage et fiabilité Amazon Aurora

Restauration à partir d'un instantané de cluster de base de données