Perché il ripristino point-in-time della mia istanza database Amazon RDS richiede molto tempo?

Risoluzione

Dopo aver ripristinato l'istanza database RDS da un backup, visualizza i file di log di Amazon RDS per monitorare l'avanzamento del ripristino point-in-time.

Amazon RDS carica i log delle transazioni delle istanze database su Amazon Simple Storage Service (Amazon S3) ogni 5 minuti. Durante un ripristino point-in-time, viene ripristinato per primo lo snapshot più vicino all'ora impostata nel point-in-time. Quindi Amazon RDS applica i log delle transazioni fino al momento impostato. La durata dell'operazione si basa sul numero di log delle transazioni.

Ad esempio, devi eseguire un ripristino point-in-time alle 06:15 UTC utilizzando un backup automatico di un'istanza database eseguito alle 04:00 UTC dello stesso giorno. In questo esempio, l'istanza viene ripristinata dal backup creato alle 04:00 UTC. Quindi Amazon RDS applica i log delle transazioni fino alle 06:15 UTC all'istanza ripristinata per completare il processo di ripristino point-in-time.

Per ridurre il tempo necessario per al ripristino di un'istanza database a un orario specifico, utilizza le seguenti best practice:

• Esegui regolarmente snapshot manuali per ridurre l'obiettivo del punto di ripristino per le istanze di origine con backup automatici attivati.
• Assicurati che il database di origine non contenga query di lunga durata nel processo al momento del ripristino point-in-time. Le transazioni di lunga durata possono aumentare i tempi di ripristino e rendere il database non disponibile più a lungo.
• Controlla le dimensioni del log delle transazioni. Le transazioni di grandi dimensioni vengono scritte contemporaneamente nel file delle transazioni e Amazon RDS non suddivide le transazioni in file diversi.
  Nota: i file di log delle transazioni di grandi dimensioni aumentano i tempi di ripristino in caso di arresto anomalo.
• Esegui una scansione completa della tabella, ad esempio SELECT * su ogni tabella per velocizzare l'accesso alle tabelle importanti dopo il ripristino. Così facendo, induci Amazon RDS di scaricare tutti i dati delle tabelle da Amazon S3 al volume Amazon Elastic Block Store (Amazon EBS).
  Nota: se non scarichi tutti i dati delle tabelle, ma provi ad accedere a un blocco EBS, può verificarsi un caricamento lento. Dopo il ripristino dello snapshot dell'istanza, i dati dello snapshot presente in Amazon S3 vengono copiati nel volume EBS. Quando tenti di accedere a un blocco che non è già stato copiato, Amazon RDS estrae il blocco da Amazon S3, da cui la latenza di I/O.

Quando ripristini un'istanza database Amazon RDS per PostgreSQL a un determinato momento, ricevi informazioni nel file di log.

Esempio di output:

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

Informazioni correlate

Snapshot di Amazon EBS

Perché la clonazione, il ripristino da snapshot o il ripristino point-in-time di un cluster di database Amazon Aurora richiede molto tempo?