Por que a recuperação a um ponto anterior no tempo da instância de banco de dados do Amazon RDS está demorando muito?

Breve descrição

Com a opção Recuperação a um ponto anterior no tempo, é possível restaurar uma instância de banco de dados a um ponto específico no tempo quando houver backups automatizados habilitados. As instâncias do Amazon RDS que têm backups automatizados habilitados podem ser recuperadas até o primeiro momento que pode ser restaurável. O primeiro tempo restaurável especifica em quanto tempo é possível recuperar sua instância dentro do período de retenção do backup. O período máximo de retenção é definido como 35 dias, ou seja, cinco semanas corridas. É possível alterar esse valor de 0 para 35 dias modificando a instância. É possível iniciar a recuperação a um ponto anterior no tempo e especificar qualquer data e horário dentro do período de retenção até o último momento restaurável. O horário restaurável mais recente é o horário mais recente a partir do qual é possível recuperar a instância.

É possível usar o comando describe-db-instances da AWS Command Line Interface (AWS CLI) para retornar o horário restaurável mais recente para a instância. O tempo de restauração mais recente geralmente ocorre dentro dos últimos cinco minutos. Também é possível encontrar o tempo restaurável mais recente escolhendo backups automatizados no console do Amazon RDS.

Quando uma recuperação a um ponto anterior no tempo para a instância de banco de dados é iniciada, o Amazon RDS chama a API RestoreDBInstanceToPointInTime em seu nome. Essa API é rastreada no AWS CloudTrail. Para obter mais informações, consulte visualização de eventos do CloudTrail no console do CloudTrail.

Também é possível verificar o andamento da recuperação a um ponto anterior no tempo analisando os arquivos de log do RDS. Depois que a instância do RDS for restaurada a partir do backup, será possível usar os arquivos de log do RDS para rastrear o andamento da recuperação.

O RDS carrega os logs de transações para instâncias de banco de dados no Amazon Simple Storage Service (Amazon S3) a cada cinco minutos. Durante uma recuperação a um ponto anterior no tempo, o snapshot mais próximo do horário mencionado no ponto anterior é recuperado primeiro. Em seguida, os logs de transação são aplicados até o momento em que o tempo foi mencionado e quando foi iniciado o ponto da restauração. Essa operação pode demorar mais, dependendo do número de logs de transação que devem ser aplicados.

Por exemplo, suponha que o backup automatizado de uma instância de banco de dados tenha sido feito às 04:00 UTC de hoje e que será preciso executar uma recuperação a um ponto anterior no tempo às 06:15 UTC. Nesse caso, a instância é recuperada a partir do backup criado às 04:00 UTC. Em seguida, os logs de transação até 06:16 UTC são aplicados à instância restaurada para concluir o processo de recuperação a um ponto anterior no tempo.

Resolução

Use as seguintes práticas recomendadas para reduzir o tempo necessário para recuperar a instância de banco de dados para um ponto específico no tempo:

• Caso tenha habilitado backups automáticos nas instâncias de origem, recomenda-se capturar snapshots manuais em intervalos regulares para evitar o acúmulo de um grande número de alterações delta e diminuir o objetivo do ponto de recuperação.
• Certifique-se de que nenhuma consulta de longa duração esteja sendo executada no banco de dados de origem no momento da recuperação a um ponto anterior no tempo. Transações de longa duração podem estender o tempo de recuperação, o que significa que pode levar mais tempo para o banco de dados ficar disponível.
• Use o tamanho correto do log de transações sempre que possível. Transações grandes são gravadas no arquivo de transações de uma só vez e não são divididas entre arquivos diferentes. Portanto, o arquivo de log de transações fica maior que o necessário, aumentando o tempo de recuperação de falhas.
• Durante a recuperação a um ponto anterior no tempo, depois que o snapshot da instância é restaurado, os dados do snapshot localizado no S3 são copiados para o volume subjacente do Amazon Elastic Block Store (Amazon EBS). Esse processo é conhecido como carregamento lento. Quando há uma tentativa de acesso a um bloco que ainda não foi copiado, o RDS extrai esse bloco do S3, resultando em latência de E/S. Para ajudar a mitigar os efeitos do carregamento lento em tabelas que precisam ser acessadas rapidamente, é possível executar as operações que envolvem varreduras da tabela inteira, como SELECT *. Isso permite que o Amazon RDS faça o download de todos os dados da tabela de backup do S3.

Exemplo:

É possível ver as seguintes informações em um arquivo de log ao restaurar sua instância de banco de dados do RDS for PostgreSQL para um ponto específico no tempo:

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

Informações relacionadas

Restauração de um snapshot de banco de dados

Snapshots do Amazon EBS

Por que o clone, restauração de snapshot ou recuperação a um ponto anterior no tempo do cluster de banco de dados do Amazon Aurora está demorando tanto?

Implementando uma estratégia de recuperação de desastres com o Amazon RDS