Pourquoi la restauration d'un instantané de mon instance de base de données Amazon RDS for MySQL prend-elle autant de temps ?

Brève description

Les longues durées de restauration d'instantanés sont généralement causées par de longues récupérations de bases de données. Le temps de récupération dépend de la charge de travail sur votre instance lorsque l'instantané a été pris. Si la journalisation binaire est activée dans votre instance de base de données source, la récupération peut prendre plus de temps. Par conséquent, la durée de restauration de votre instantané peut également être affectée.

Résolution

Lorsque vous restaurez un instantané, Amazon RDS exécute un processus de récupération et le moteur de base de données MySQL est démarré sur une nouvelle instance de base de données. Le démarrage de la nouvelle instance de base de données peut prendre jusqu'à quelques minutes, en fonction de la durée de la session de récupération pendant le démarrage d'une instance. Pour plus d'informations, consultez InnoDB crash recovery sur le site Web de MySQL.

Remarque : vous constaterez une certaine latence (ou chargement lent) jusqu'à ce que le volume soit entièrement restauré (hydraté) à partir d'Amazon Simple Storage Service (Amazon S3). Pour plus d'informations sur le chargement lent, consultez Restauration à partir d'un instantané.

Pour réduire le temps d'achèvement de la restauration des instantanés dans Amazon RDS, envisagez les approches suivantes :

• Planifiez une fenêtre de sauvegarde ou prenez un instantané manuel de votre instance de base de données pendant les heures creuses. Les activités effectuées sur l'instance de base de données source lors de la prise d'un instantané affectent le temps de récupération de la base de données et les temps de restauration des instantanés.
• Si une instance source utilise le type de stockage magnétique pendant un instantané, l'instance nouvellement restaurée sera en état de modification. Par exemple, lorsque vous restaurez un instantané de bases de données en tant que type de stockage SSD polyvalent (GP2) ou IOPS provisionnés (PIOPS), le changement de volume sous-jacent se produit. Par conséquent, votre nouvelle instance indique un état de « modification ». Pendant ce temps, vous pouvez toujours vous connecter à une instance Amazon RDS, bien que vous puissiez subir une certaine dégradation des performances.
• Restaurez temporairement votre instance vers une classe d'instance de base de données supérieure (telle qu'une classe d'instance dotée de plus de mémoire ou de RAM). En mettant à niveau la classe d'instance de base de données, les temps de récupération en cas de panne peuvent être améliorés. Vous gagnez temporairement plus de ressources, ce qui peut contribuer à accélérer le temps global de récupération en cas de panne. Une fois la restauration d'instantané terminée, vous pouvez réduire la classe d'instance.

Pour réduire le temps d'achèvement de la restauration des instantanés pour lesquels la journalisation binaire est activée dans Amazon RDS, tenez compte des points suivants :

• Lorsque la journalisation binaire est activée (par exemple lorsque les sauvegardes automatisées sont activées dans l'instance source), les journaux binaires affectent directement le temps de restauration des instantanés. Lors de la récupération sur incident, le processus de restauration des instantanés effectue également une récupération du journal binaire.
• Pour réduire les temps de récupération des journaux binaires, évitez les transactions volumineuses et les fichiers binlog volumineux. Plus les données enregistrées dans les journaux binaires sont nombreuses, plus le processus de restauration doit traiter de données pendant une récupération de binlog. Par conséquent, le temps de récupération est augmenté, ce qui augmente également les temps de restauration des instantanés.
• Utilisez la taille de transaction correcte dans la mesure du possible. Les transactions volumineuses sont écrites dans le fichier journal binaire en une seule fois, et ne sont pas réparties entre différents fichiers. Par conséquent, le fichier journal binaire finit par être volumineux, ce qui augmente le temps de récupération en cas de crash.
• Le type de format de journalisation binaire utilisé peut également avoir un impact sur la taille et l'efficacité de la récupération. Certains formats (tels que la journalisation basée sur les lignes) enregistrent plus d'informations que d'autres dans les journaux binaires. Les instructions qui modifient un grand nombre de lignes dans une table amènent le moteur de base de données à générer des entrées de journal binaire pour chaque ligne modifiée. Par conséquent, vous obtiendrez un fichier binlog volumineux. Pour plus d'informations sur le format de journalisation basé sur les lignes, consultez Usage of row-based logging and replication (Utilisation de la journalisation et de la réplication basées sur les lignes) sur le site Web de MySQL. Pour plus d'informations sur les différents types de formats de journalisation binaire, consultez Advantages and disadvantages of statement-based and row-based replication (Avantages et inconvénients de la réplication basée sur des instructions et des lignes) sur le site Web de MySQL.