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

Descripción breve

Con la opción Restaurar a un momento dado, puede restaurar una instancia de base de datos a un momento específico cuando tenga habilitadas las copias de seguridad automatizadas. Las instancias de Amazon RDS que tienen habilitadas las copias de seguridad automatizadas se pueden restaurar hasta la hora más antigua a la que se puede restaurar. La hora más antigua a la que se puede restaurar especifica hasta qué momento anterior dentro del periodo de retención de la copia de seguridad se puede restaurar la instancia. El periodo máximo de retención está establecido en 35 días, es decir, cinco semanas de calendario. Este valor se puede cambiar en el rango de 0 a 35 días al modificar la instancia. Puede iniciar una restauración a un momento dado y especificar cualquier fecha y hora dentro del periodo de retención hasta la hora más reciente a la que se puede restaurar. La hora más reciente a la que se puede restaurar es la hora más reciente a partir de la cual se puede restaurar la instancia.

Puede utilizar el comando de la Interfaz de línea de comandos de AWS (AWS CLI) describe-db-instances para devolver la hora más reciente a la que se puede restaurar para la instancia. La hora más reciente a la que se puede restaurar normalmente se encuentra dentro de los últimos cinco minutos. También puede encontrar la hora más reciente a la que se puede restaurar al elegir Copias de seguridad automatizadas en la consola de Amazon RDS.

Cuando inicia una restauración a un momento dado para la instancia de base de datos, Amazon RDS llama a la API RestoreDBInstanceToPointInTime en su nombre. Se realiza un seguimiento de esta API en AWS CloudTrail. Para obtener más información, consulte Ver eventos de CloudTrail en la consola de CloudTrail.

También puede verificar el avance de la restauración a un momento dado si revisa los archivos de registro de RDS. Una vez restaurada la instancia de RDS a partir de la copia de seguridad, puede utilizar los archivos de registro de RDS para realizar un seguimiento del avance de la recuperación.

RDS carga los registros de transacciones de las instancias de base de datos en Amazon Simple Storage Service (Amazon S3) cada cinco minutos. Durante la restauración a un momento dado, se restaura primero la instantánea más cercana a la hora mencionada en el momento dado. A continuación, los registros de transacciones se aplican hasta la hora que se indicó al iniciar la restauración a un momento dado. Esta operación puede tardar más en función del número de registros de transacciones que se deban aplicar.

Por ejemplo, suponga que tiene la copia de seguridad automatizada de una instancia de base de datos tomada a las 04.00 h UTC de hoy, y debe realizar una restauración a un momento dado a las 06.15 h UTC. En este caso, la instancia se restaura a partir de la copia de seguridad creada a las 04.00 h UTC. A continuación, los registros de transacciones hasta las 06.16 h UTC se aplican a la instancia restaurada para completar el proceso de restauración a un momento dado.

Resolución

Utilice las siguientes prácticas recomendadas para reducir el tiempo que se tarda en restaurar la instancia de base de datos a un momento específico:

• Si habilitó las copias de seguridad automáticas en las instancias de origen, es una práctica recomendada realizar instantáneas manuales a intervalos regulares para evitar que se acumule un gran número de cambios delta y se disminuya el objetivo de punto de recuperación.
• Asegúrese de que no hay ninguna consulta de larga duración en ejecución en la base de datos de origen en el momento de la restauración a un momento dado. Las transacciones de larga duración pueden prolongar el tiempo de recuperación, lo que significa que la base de datos puede tardar más en estar disponible.
• Utilice el tamaño correcto del registro de transacciones siempre que sea posible. Las transacciones grandes se escriben en el archivo de transacciones a una hora y no se dividen en diferentes archivos. Por lo tanto, el archivo de registro de transacciones resulta ser más grande de lo necesario, lo que aumenta el tiempo de recuperación de la caída.
• Durante la restauración a un momento dado, una vez restaurada la instantánea de la instancia, los datos de la instantánea que se encuentran en S3 se copian en el volumen subyacente de Amazon Elastic Block Store (Amazon EBS). Este proceso se conoce como carga diferida. Cuando se intenta acceder a un bloque que aún no está copiado, RDS extrae ese bloque de S3, lo que provoca una latencia de E/S. Para ayudar a mitigar los efectos de la carga diferida en las tablas a las que necesita acceder rápidamente, puede realizar operaciones que impliquen análisis completos de la tabla, como SELECT *. Esto permite que Amazon RDS descargue todos los datos de las tablas con copia de seguridad a partir de S3.

Ejemplo:

Es posible que vea la siguiente información en un archivo de registro al restaurar la instancia de base de datos de RDS para PostgreSQL a un momento específico:

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

Información relacionada

Restauración desde una instantánea de base de datos

Instantáneas de Amazon EBS

¿Por qué demoran tanto tiempo los procesos de clonación de clúster de base de datos de Amazon Aurora, de restauración de instantáneas o de restauración a un momento dado?

Implementación de una estrategia de recuperación de desastres con Amazon RDS