Pourquoi la restauration ponctuelle de mon instance de base de données Amazon RDS prend-elle beaucoup de temps ?

Résolution

Après avoir restauré l'instance de base de données RDS à partir d'une sauvegarde, consultez les fichiers journaux Amazon RDS pour suivre la progression de votre restauration ponctuelle.

Amazon RDS charge les journaux de transactions pour les instances de bases de données sur Amazon Simple Storage Service (Amazon S3) toutes les 5 minutes. Lors d'une restauration ponctuelle, l'instantané le plus proche de l'heure que vous avez définie à ce moment-là est restauré en premier. Puis, Amazon RDS applique les journaux de transactions jusqu'au moment que vous avez défini. La durée de l'opération dépend du nombre de journaux de transactions.

Par exemple, vous devez effectuer une restauration ponctuelle à 06h15 UTC pour une sauvegarde automatique d'une instance de base de données effectuée à 04h00 UTC le même jour. Dans cet exemple, l'instance effectue une restauration à partir de la sauvegarde créée à 04h00 UTC. Amazon RDS applique ensuite les journaux de transactions jusqu'à 6h15 UTC à l'instance restaurée pour terminer le processus de restauration ponctuelle.

Pour réduire le temps nécessaire à la restauration de votre instance de base de données à une heure précise, appliquez les bonnes pratiques suivantes :

• Prenez régulièrement des instantanés manuels afin de réduire l'objectif de point de reprise pour les instances source sur lesquelles les sauvegardes automatisées sont activées.
• Assurez-vous que la base de données source ne comporte pas de requêtes de longue durée en cours de traitement au moment de la restauration ponctuelle. Les transactions de longue durée peuvent augmenter le délai de reprise et prolonger l'indisponibilité de la base de données.
• Vérifiez la taille de votre journal de transactions. Les transactions importantes sont enregistrées en même temps dans le fichier de transactions, et Amazon RDS ne répartit pas les transactions entre différents fichiers.
  Remarque : Les fichiers journaux de transactions volumineux augmentent le délai de reprise après incident.
• Exécutez une analyse complète de la table, telle que SELECT * sur chaque table pour accélérer l'accès aux tables importantes après une restauration. Amazon RDS est alors invité à télécharger toutes les données de table d'Amazon S3 vers le volume Amazon Elastic Block Store (Amazon EBS).
  Remarque : Si vous ne téléchargez pas toutes les données de la table mais que vous essayez d'accéder à un bloc EBS, un chargement différé peut se produire. Une fois l'instantané de votre instance restauré, les données de l'instantané qui se trouve dans Amazon S3 sont copiées dans le volume EBS. Lorsque vous essayez d'accéder à un bloc qui n'est pas encore copié, Amazon RDS extrait ce bloc d'Amazon S3 et il en résulte une latence d'I/O.

Lorsque vous restaurez une instance de base de données Amazon RDS pour PostgreSQL à un moment précis, vous recevez des informations dans votre fichier journal.

Exemple de sortie :

2022-06-01 13:16:19 UTC::@:[8613]:LOG: starting point-in-time recovery to 2022-06-01 12:54:30+002022-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

Instantanés Amazon EBS

Pourquoi le clonage de mon cluster de bases de données Amazon Aurora, la restauration de mes instantanés ou la restauration ponctuelle prennent-ils autant de temps ?