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

Breve descrizione

Con l'opzione Ripristino point-in-time, è possibile ripristinare un'istanza di database in un momento specifico quando sono abilitati i backup automatici. Le istanze di Amazon RDS con backup automatici abilitati possono essere ripristinate il più presto possibile. La prima ora ripristinabile specifica fino a che punto nel periodo di conservazione del backup è possibile ripristinare l'istanza. Il periodo di conservazione massimo è impostato su 35 giorni, ovvero cinque settimane di calendario. È possibile modificare questo valore da 0 a 35 giorni modificando l'istanza. Quando avvii un ripristino point-in-time, puoi specificare il giorno e l’ora a cui ripristinare i dati, fino al punto di ripristino più recente. L'ultima ora ripristinabile è l'ultima volta da cui è possibile ripristinare l'istanza.

Puoi utilizzare il comando describe-db-instances dell’Interfaccia della linea di comando AWS (AWS CLI) per restituire l'ultima ora ripristinabile per la tua istanza. Il tempo di ripristino più recente è in genere entro gli ultimi cinque minuti. Puoi anche trovare l'orario ripristinabile più recente scegliendo i backup automatici nella console di Amazon RDS.

Quando avvii un ripristino point-in-time per la tua istanza database, Amazon RDS chiama l'API RestoredBInstanceToPointInTime per tuo conto. Questa API viene rilevata in AWS CloudTrail. Per ulteriori informazioni, consulta Visualizzazione degli eventi CloudTrail nella console di CloudTrail.

È inoltre possibile controllare l'avanzamento del ripristino point-in-time esaminando i file di registro di RDS. Dopo il ripristino dell'istanza di RDS dal backup, è possibile utilizzare i file di registro di RDS per tenere traccia dell'avanzamento del ripristino.

RDS carica i registri delle transazioni per le istanze di database su Amazon Simple Storage Service (Amazon S3) ogni cinque minuti. Durante un ripristino point-in-time, viene ripristinato per primo lo snapshot più vicino all'ora indicata in point-in-time. Quindi, i registri delle transazioni vengono applicati fino al momento indicato quando è stato avviato il point-in-restore. Questa operazione potrebbe richiedere più tempo a seconda del numero di registri delle transazioni che devono essere applicati.

Ad esempio, supponi di avere il backup automatico di un'istanza di database eseguita oggi alle 04:00 UTC e di dover eseguire un ripristino point-in-time alle 06:15 UTC. In questo caso, l'istanza viene ripristinata dal backup creato alle 04:00 UTC. Quindi, i registri delle transazioni fino alle 06:16 UTC vengono applicati all'istanza ripristinata per completare il processo di ripristino point-in-time.

Risoluzione

Utilizza le seguenti best practice per ridurre il tempo necessario per ripristinare l'istanza di database a un determinato point-in-time:

• Se hai abilitato i backup automatici sulle istanze di origine, è consigliabile eseguire snapshot manuali a intervalli regolari per evitare che si accumuli un numero elevato di modifiche delta e ridurre l'obiettivo del punto di ripristino.
• Accertati che non siano in esecuzione query di lunga durata nel database di origine al momento del ripristino point-in-time. Le transazioni a esecuzione prolungata possono prolungare i tempi di ripristino, il che significa che il database può impiegare più tempo per diventare disponibile.
• Utilizzare le dimensioni corrette del registro delle transazioni ove possibile. Le transazioni di grandi dimensioni vengono scritte nel file delle transazioni contemporaneamente e non vengono suddivise tra file diversi. Pertanto, il file di registro delle transazioni finisce per diventare più grande del necessario, aumentando il tempo di ripristino dell'arresto anomalo.
• Durante il ripristino point-in-time, dopo il ripristino dello snapshot dell'istanza, i dati dello snapshot che si trova in S3 vengono copiati nel volume sottostante Amazon Elastic Block Store (Amazon EBS). Questo processo è noto come lazy loading. Quando si tenta di accedere a un blocco che non è già stato copiato, RDS estrae quel blocco da S3, con conseguente latenza I/O. Per ridurre gli effetti del caricamento lento sulle tabelle a cui è necessario accedere rapidamente, è possibile eseguire operazioni che coinvolgono scansioni di tabelle complete, come SELECT *. Ciò consente ad Amazon RDS di scaricare tutti i dati della tabella di backup da S3.

Esempio:

È possibile che vengano visualizzate le seguenti informazioni in un file di registro quando si ripristina l'istanza database di RDS per PostgreSQL in un momento specifico:

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

Informazioni correlate

Ripristino da uno snapshot del database

Snapshot Amazon EBS

Perché la clonazione del mio cluster DB di Amazon Aurora, il ripristino di snapshot o il ripristino point-in-time impiegano così tanto?

Implementazione di una strategia di ripristino di emergenza con Amazon RDS