Por que a recuperação a um ponto anterior no tempo da instância de banco de dados do Amazon RDS está demorando muito?
Estou executando uma operação de recuperação a um ponto anterior no tempo na instância de banco de dados relacional do Amazon RDS. A operação está demorando muito para ser concluída.
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
Implementando uma estratégia de recuperação de desastres com o Amazon RDS
Conteúdo relevante
- Por que a minha instância de banco de dados do Amazon RDS reiniciou, foi recuperada ou fez failover?AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos