¿Por qué la restauración a un momento dado de mi instancia de base de datos de Amazon RDS tarda mucho tiempo?

Resolución

Tras restaurar la instancia de base de datos de RDS a partir de la copia de seguridad, consulta los archivos de registro de Amazon RDS para realizar un seguimiento del progreso de la restauración en un momento dado.

Amazon RDS carga los registros de transacciones de las instancias de base de datos en Amazon Simple Storage Service (Amazon S3) cada 5 minutos. Durante una restauración a un momento dado, la instantánea más cercana a la hora establecida en ese momento se restaura primero. A continuación, Amazon RDS aplica los registros de transacciones hasta el momento dado que establezcas. La duración de la operación se basa en la cantidad de registros de transacciones.

Por ejemplo, debes realizar una restauración a un momento dado a las 06:15 UTC para realizar una copia de seguridad automática de una instancia de base de datos realizada a las 04:00 UTC del mismo día. En este ejemplo, la instancia se restaura a partir de la copia de seguridad que se creó a las 04:00 UTC. A continuación, Amazon RDS aplica los registros de transacciones hasta las 06:15 UTC a la instancia restaurada para completar el proceso de restauración a un momento dado.

Para reducir el tiempo que lleva restaurar la instancia de base de datos a un momento específico, sigue estas prácticas recomendadas:

• Realiza instantáneas manuales con regularidad para reducir el objetivo de punto de recuperación para las instancias de origen que tienen activadas las copias de seguridad automatizadas.
• Asegúrate de que la base de datos de origen no tenga consultas de ejecución prolongada en el proceso en el momento de la restauración a un momento dado. Las transacciones de larga duración pueden aumentar el tiempo de recuperación y hacer que la base de datos no esté disponible durante más tiempo.
• Comprueba el tamaño de tu registro de transacciones. Las transacciones grandes se escriben en el archivo de transacciones al mismo tiempo y Amazon RDS no divide las transacciones en archivos diferentes.
  Nota: Los archivos de registro de transacciones de gran tamaño aumentan el tiempo de recuperación tras un bloqueo.
• Ejecuta un análisis de tablas completas, como SELECT * en cada tabla para acelerar el acceso a las tablas importantes después de una restauración. Esto hace que Amazon RDS descargue todos los datos de la tabla de Amazon S3 al volumen de Amazon Elastic Block Store (Amazon EBS).
  Nota: Si no descargas todos los datos de la tabla pero intentas acceder a un bloque de EBS, puede producirse una carga lenta. Una vez restaurada la instantánea de la instancia, los datos de la instantánea que se encuentra en Amazon S3 se copian en el volumen de EBS. Cuando intentas acceder a un bloque que aún no se ha copiado, Amazon RDS extrae ese bloque de Amazon S3 y, a continuación, se produce una latencia de E/S.

Cuando restauras una instancia de base de datos de Amazon RDS para PostgreSQL en un momento específico, recibes información en tu archivo de registro.

Resultado de ejemplo:

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

Información relacionada

Instantáneas de Amazon EBS

¿Por qué la clonación de mi clúster de base de datos de Amazon Aurora, la restauración de instantáneas o la restauración a un momento dado tardan tanto?