Pourquoi la restauration ponctuelle de mon instance DB Amazon RDS prend-elle beaucoup de temps ?

Brève description

Avec l'option Restore to point in time (Restaurer à un point dans le temps), vous pouvez restaurer une instance DB à un moment précis lorsque les sauvegardes automatiques sont activées. Les instances Amazon RDS pour lesquelles les sauvegardes automatiques sont activées peuvent être restaurées au plus tôt. Le délai de restauration le plus précoce indique jusqu'où vous pouvez restaurer votre instance au cours de la période de rétention de la sauvegarde. La période de conservation maximale est fixée à 35 jours, soit cinq semaines civiles. Vous pouvez modifier cette valeur de 0 à 35 jours en modifiant l'instance. Vous pouvez lancer une restauration à un moment donné et spécifier n'importe quelle seconde pendant votre période de rétention, jusqu'au point du dernier moment restaurable. La dernière date de restauration est la dernière heure à partir de laquelle vous pouvez restaurer l'instance.

Vous pouvez utiliser la commande Interface de la ligne de commande( AWS CLI) describe-db-instances de l'interface de ligne de commande AWS (AWS CLI) pour renvoyer la dernière heure de restauration pour votre instance. La dernière période de restauration se situe généralement dans les cinq dernières minutes. Vous pouvez également connaître l'heure de restauration la plus récente en sélectionnant Sauvegardes automatisées dans la console Amazon RDS.

Lorsque vous lancez une restauration à un point dans le temps pour votre instance DB, Amazon RDS appelle l'API RestoreDBInstanceToPointIntime en votre nom. Cette API est suivie dans AWS CloudTrail. Pour plus d'informations, consultez la section Affichage des événements CloudTrail dans la console CloudTrail.

Vous pouvez également vérifier la progression de la restauration ponctuelle en consultant les fichiers journaux RDS. Une fois l'instance RDS restaurée à partir d'une sauvegarde, vous pouvez utiliser les fichiers journaux RDS pour suivre la progression de la restauration.

RDS télécharge les journaux de transactions des instances DB vers Amazon Simple Storage Service (Amazon S3) toutes les cinq minutes. Lors d'une restauration à un point dans le temps, l'instantané le plus proche de l'heure mentionnée à un point dans le temps est restauré en premier. Ensuite, les journaux de transactions sont appliqués jusqu'au moment que vous avez mentionné lorsque vous avez lancé le point de restauration. Cette opération peut prendre plus de temps en fonction du nombre de journaux de transactions qui doivent être appliqués.

Supposons, par exemple, que la sauvegarde automatique d'une instance de bases de données ait été effectuée à 4 h 00 UTC aujourd'hui et que vous deviez effectuer une restauration ponctuelle à 6 h 15 UTC. Dans ce cas, l'instance est restaurée à partir de la sauvegarde créée à 04h00 UTC. Ensuite, les journaux de transactions jusqu'à 06 h 16 UTC sont appliqués à l'instance restaurée pour terminer le processus de restauration à un moment donné.

Solution

Utilisez les meilleures pratiques suivantes pour réduire le temps nécessaire à la restauration de votre instance DB à un moment précis :

• Si vous avez activé les sauvegardes automatiques sur vos instances sources, il est recommandé de prendre des instantanés manuels à intervalles réguliers afin d'éviter l'accumulation d'un grand nombre de changements de delta et de réduire l'objectif de point de récupération.
• Assurez-vous qu'aucune requête de longue durée n'est en cours d'exécution sur la base de données source au moment de la restauration ponctuelle. Les transactions de longue durée peuvent prolonger le temps de récupération, ce qui signifie que la base de données peut mettre plus de temps à être disponible.
• 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 des transactions finit par devenir plus volumineux que nécessaire, ce qui augmente le temps de récupération après incident.
• Au cours de la restauration ponctuelle, après la restauration de l'instantané de votre instance, les données de l'instantané situé dans S3 sont copiées dans le volume Amazon Elastic Block Store (Amazon EBS) sous-jacent. Ce processus est connu sous le nom de chargement différé. Lorsque vous essayez d'accéder à un bloc qui n'est pas déjà copié, RDS extrait ce bloc de S3, ce qui entraîne une latence d'E/S. Pour atténuer les effets du chargement différé sur les tables auxquelles vous devez accéder rapidement, vous pouvez effectuer des opérations qui impliquent des analyses de tables complètes, telles que SELECT *. Cela permet à Amazon RDS de télécharger toutes les données de table sauvegardées depuis S3.

Exemple :

Vous pouvez voir les informations suivantes dans un fichier journal lorsque vous restaurez votre instance DB RDS pour PostgreSQL à un moment précis :

2022-06-01 13:16:19 UTC::@:[8613]:LOG: starting point-in-time recovery to 2022-06-01 12:54:30+00
2022-06-01 13:16:19 UTC::@:[8613]:LOG: redo starts at 0/48A3220
waiting for 000000010000000000000001 archive /rdsdbdata/log/restore/pg-wal-archive.1.* to be downloaded
2022-06-01 13:17:22 UTC:127.0.0.1(46110):rdsadmin@rdsadmin:[10322]:FATAL: the database system is starting up
2022-06-01 13:17:25 UTC::@:[8613]:LOG: restored log file "000000010000000000000001" from archive
recovering 000000010000000000000002
2022-06-01 13:17:26 UTC::@:[8613]:LOG: restored log file "000000010000000000000002" from archive
recovering 000000010000000000000003
2022-06-01 13:17:28 UTC::@:[8613]:LOG: restored log file "000000010000000000000003" from archive
recovering 000000010000000000000004
2022-06-01 13:18:54 UTC::@:[8613]:LOG: restored log file "000000010000000000000022" from archive
recovering 000000010000000000000023
.
.
2022-06-01 13:33:16 UTC::@:[8613]:LOG: restored log file "00000001000000060000000B" from archive
2022-06-01 13:33:16 UTC::@:[8613]:LOG: recovery stopping before commit of transaction 9266438, time 2022-06-01 12:56:14.648042+00
2022-06-01 13:33:16 UTC::@:[8613]:LOG: redo done at 6/2C0003C0
2022-06-01 13:33:16 UTC::@:[8613]:LOG: last completed transaction was at log time 2022-06-01 12:51:14.646151+00
recovering 00000002.history
2022-06-01 13:33:16 UTC::@:[8613]:LOG: selected new timeline ID: 2
2022-06-01 13:33:16 UTC::@:[8613]:LOG: archive recovery complete
recovering 00000001.history
2022-06-01 13:33:16 UTC::@:[8620]:LOG: checkpoint starting: end-of-recovery immediate wait
2022-06-01 13:33:16 UTC::@:[8620]:LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 8 recycled; write=0.002 s, sync=0.003 s, total=0.031 s; sync files=2, longest=0.003 s, average=0.002 s; distance=655360 kB, estimate=1611806 
kB
2022-06-01 13:33:16 UTC::@:[8607]:LOG: database system is ready to accept connections
2022-06-01 13:37:18 UTC::@:[8607]:LOG: received fast shutdown request
2022-06-01 13:37:18 UTC::@:[8607]:LOG: aborting any active transactions
2022-06-01 13:37:18 UTC::@:[8607]:LOG: background worker "logical replication launcher" (PID 7394) exited with exit code 1
2022-06-01 13:37:18 UTC::@:[8620]:LOG: shutting down
2022-06-01 13:37:18 UTC::@:[8620]:LOG: checkpoint starting: shutdown immediate
2022-06-01 13:37:18 UTC::@:[8620]:LOG: checkpoint complete: wrote 9 buffers (0.0%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.003 s, sync=0.003 s, total=0.024 s; sync files=7, longest=0.003 s, average=0.001 s; distance=65535 kB, estimate=1457179
        kB
2022-06-01 13:37:20 UTC::@:[8607]:LOG: database system is shut down
2022-06-01 13:37:24 UTC::@:[10870]:LOG: starting PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-12), 64-bit
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on IPv6 address "::", port 5432
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-06-01 13:37:24 UTC::@:[10875]:LOG: database system was shut down at 2022-06-01 13:37:18 UTC
2022-06-01 13:37:24 UTC::@:[10870]:LOG: database system is ready to accept connections

Informations connexes

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

Instantanés Amazon EBS

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

Implémentation d'une stratégie de reprise après sinistre avec Amazon RDS