Por que a restauração pontual da minha instância de banco de dados Amazon RDS demora muito tempo?

Resolução

Depois de restaurar a instância de banco de dados do RDS a partir do backup, visualize os arquivos de log do Amazon RDS para acompanhar o progresso de sua restauração pontual.

O Amazon RDS carrega logs de transações de instâncias de banco de dados para o Amazon Simple Storage Service (Amazon S3) a cada 5 minutos. Durante uma restauração point-in-time, o snapshot mais próximo do horário definido no point-in-time é restaurado primeiro. Em seguida, o Amazon RDS aplica os logs de transações até o point-in-time definido por você. A duração da operação é baseada no número de logs de transações.

Por exemplo, você deve realizar uma restauração pontual às 06:15 UTC para um backup automático de uma instância de banco de dados feito às 04:00 UTC do mesmo dia. Neste exemplo, a instância é restaurada a partir do backup criado às 04:00 UTC. Em seguida, o Amazon RDS aplica os logs de transações até 06:15 UTC à instância restaurada para concluir o processo de restauração pontual.

Para reduzir o tempo necessário para restaurar sua instância de banco de dados em um horário específico, use as seguintes práticas recomendadas:

• Faça snapshots manuais regularmente para diminuir o objetivo do ponto de recuperação para instâncias de origem que têm backups automatizados ativados.
• Certifique-se de que o banco de dados de origem não tenha consultas de longa duração no processo no momento da restauração pontual. Transações de longa duração podem aumentar o tempo de recuperação e fazer com que o banco de dados fique indisponível por mais tempo.
• Verifique o tamanho do seu log de transações. Grandes transações são gravadas no arquivo de transação de uma só vez, e o Amazon RDS não divide as transações em arquivos diferentes.
  Observação: grandes arquivos de log de transações aumentam o tempo de recuperação de falhas.
• Execute uma verificação completa da tabela, como SELECT * em cada tabela, para acelerar o acesso a tabelas importantes após uma restauração. Isso faz com que o Amazon RDS baixe todos os dados da tabela do Amazon S3 para o volume Amazon Elastic Block Store (Amazon EBS).
  Observação: se você não baixar todos os dados da tabela, mas tentar acessar um bloco do EBS, poderá ocorrer um carregamento lento. Depois que o snapshot da sua instância for restaurado, os dados do snapshot que estão no Amazon S3 são copiados para o volume do EBS. Quando você tenta acessar um bloco que ainda não foi copiado, o Amazon RDS retira esse bloco do Amazon S3 e, em seguida, resulta em latência de E/S.

Quando você restaura uma instância de banco de dados Amazon RDS para PostgreSQL em um ponto específico no tempo, você recebe informações em seu arquivo de log.

Exemplo de saída:

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

Informações relacionadas

Snapshots do Amazon EBS

Por que meu clone de cluster de banco de dados Amazon Aurora, a restauração de snapshot ou a restauração pontual estão demorando tanto?