Recuperação em Ponto no Tempo (PITR) no PostgreSQL

A recuperação em ponto no tempo (PITR) é um recurso robusto no PostgreSQL que se tornou ainda mais eficiente e amigável com o advento do PostgreSQL. Ele permite que os administradores restaurem um banco de dados PostgreSQL para um momento específico no passado. Isso é particularmente útil se você gerencia a recuperação de desastres para um sistema em grande escala com uma carga de transações alta.

Este blog explorará o PITR e equipará você com conhecimento sobre possíveis armadilhas e suas soluções, garantindo uma implementação suave e bem-sucedida. Também compartilharemos seus principais benefícios e detalharemos uma implementação passo a passo do PostgreSQL.

Componentes Chave

A implementação do PITR envolve dois componentes chave:

1. Backup Base

Um backup base é uma captura do banco de dados em um ponto específico no tempo. Inclui todos os arquivos de dados, arquivos de configuração e metadados necessários para restaurar o banco de dados ao seu estado original. O backup base serve como o ponto de partida para o PITR.

2. Logs de Escrita Antecipada (WAL)

Os arquivos WAL registram todas as alterações feitas no banco de dados. Esses logs armazenam as alterações necessárias para recuperar o banco de dados ao seu estado em um momento específico. Quando você realiza um PITR, você reproduz os arquivos WAL sequencialmente para recriar o estado desejado do banco de dados.

Por que usar o PITR?

O PITR é benéfico em vários cenários:

Desfazer Alterações Acidentais

Operações acidentais, como uma instrução DELETE ou DROP sem uma cláusula WHERE, podem resultar em perda significativa de dados. Com o PITR, você pode recuperar o banco de dados para um estado imediatamente anterior ao erro, preservando dados críticos.

Recuperar de Corrupção de Dados

Erros de aplicação, falhas de hardware ou corrupção de disco podem causar inconsistências nos dados. O PITR permite restaurar uma cópia limpa do banco de dados e reproduzir apenas alterações válidas, minimizando o tempo de inatividade e a perda de dados.

Restaurar para Testes ou Depuração

Desenvolvedores frequentemente precisam replicar um banco de dados de produção para fins de depuração ou teste. O PITR possibilita a criação de uma cópia instantânea do banco de dados em um ponto específico, facilitando experimentos controlados sem afetar dados em produção.

Recuperação de Desastres

O PITR é essencial para estratégias de recuperação de desastres. Em falhas catastróficas, como desastres naturais ou ciberataques, você pode restaurar rapidamente o banco de dados para seu último estado consistente, garantindo a continuidade dos negócios.

Uso Eficiente de Recursos

Ao combinar backups completos periódicos com arquivos WAL, o PITR minimiza a necessidade de backups completos frequentes, economizando espaço de armazenamento e reduzindo os tempos de backup. O PITR também é um método de recuperação exato, permitindo que você recupere até um segundo específico e minimizando o risco de perda de dados durante um incidente. É flexível o suficiente para lidar com diversos cenários de recuperação, desde o rollback de uma única transação até a restauração completa de um banco de dados de forma eficiente.

Quais são as novidades no PostgreSQL 17 para o PITR?

O PostgreSQL 17 introduz várias melhorias para o PITR, focando em desempenho, usabilidade e compatibilidade:

Sincronização de Slot de Failover

Os slots de replicação lógica agora suportam sincronização durante failovers. Isso garante que os WALs necessários para o PITR sejam retidos mesmo após um failover, reduzindo a intervenção manual.

Compressão de WAL Aprimorada

O algoritmo de compressão de WAL foi atualizado para melhorar a eficiência de armazenamento, reduzindo o espaço necessário para arquivar os WALs. Isso é particularmente benéfico para sistemas de grande escala com altas taxas de transação.

Velocidades de Recuperação Mais Rápidas

As otimizações no processo de replay do WAL resultam em tempos de recuperação mais rápidos, especialmente para grandes conjuntos de dados.

Melhor Compatibilidade Com Replicação Lógica

O PITR agora se integra melhor com configurações de replicação lógica, facilitando a recuperação de clusters que utilizam replicação física e lógica.

Controle Granular de Arquivamento de WAL

O PostgreSQL 17 oferece mais controle sobre o arquivamento de WAL, permitindo ajustar as políticas de retenção para atender aos requisitos de recuperação.

Passos Detalhados para Realizar PITR no PostgreSQL

Siga estes passos para configurar e realizar o PITR. Antes de usar o PITR, você precisará de:

• Arquivamento de WAL: Ative e configure o arquivamento de WAL.
• Backup completo: Faça um backup completo usando pg_basebackup ou pgBackRest.
• Armazenamento seguro: Garanta que os backups e os arquivos de WAL sejam armazenados de forma segura, de preferência externamente.

1. Configure o Arquivamento de WAL

O arquivamento de WAL é fundamental para o PITR, pois armazena as alterações incrementais entre os backups. Para configurar o arquivamento de WAL, atualize o arquivo postgresql.conf, definindo:

wal_level = replica          # Ensures sufficient logging for recovery

​

archive_mode = on            # Enables WAL archiving

​

archive_command = 'cp %p /path/to/wal_archive/%f'  # Command to archive WALs

​

max_wal_senders = 3          # Allows replication and archiving

Em seguida, após definir os parâmetros de configuração, reinicie o servidor PostgreSQL:

sudo systemctl restart postgresql

Verifique o status do arquivamento de WAL com o seguinte comando:

SELECT * FROM pg_stat_archiver;

Verifique se há erros na visualização pg_stat_archiver ou nos logs do PostgreSQL.

2. Realize um Backup Base

Faça um backup base para usar como ponto de partida para PITR; usando pg_basebackup, o comando tem a seguinte forma:

pg_basebackup -D /path/to/backup_directory -Fp -Xs -P

Isso cria um snapshot consistente do banco de dados e garante que os arquivos WAL sejam arquivados para recuperação.

3. Valide a Integridade do Backup

Use pg_verifybackup para validar a integridade do seu backup:

pg_verifybackup /path/to/backup_directory

4. Simule uma Falha

Para fins de demonstração, você pode simular uma falha. Por exemplo, exclua acidentalmente dados:

DELETE FROM critical_table WHERE id = 123;

5. Restaure o Backup Base

Antes de restaurar o backup base, pare o servidor PostgreSQL:

sudo systemctl stop postgresql

Em seguida, use o seguinte comando para alterar o nome do diretório de dados existente:

mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old

Depois, substitua o diretório de dados pelo backup base:

cp -r /path/to/backup_directory /var/lib/pgsql/17/data

Atualize as permissões no diretório de dados:

chown -R postgres:postgres /var/lib/pgsql/17/data

6. Configure a Recuperação

Para habilitar o modo de recuperação, você primeiro precisa criar um arquivo recovery.signal no diretório de dados do PostgreSQL:

touch /var/lib/pgsql/17/data/recovery.signal

Em seguida, atualize postgresql.conf, adicionando os seguintes parâmetros:

restore_command = 'cp /path/to/wal_archive/%f "%p"'  # Restore archived WALs

​

recovery_target_time = '2024-11-19 12:00:00'    # Specify target time

​

Alternatively, use recovery_target_lsn or recovery_target_name for more advanced scenarios.

7. Inicie o PostgreSQL em Modo de Recuperação

Reinicie o servidor PostgreSQL com o comando:

sudo systemctl start postgresql

Monitore os logs para o progresso da recuperação:

tail -f /var/lib/pgsql/17/pg_log/postgresql.log

O PostgreSQL sairá automaticamente do modo de recuperação e se tornará operacional quando a recuperação estiver completa.

8. Verificar Recuperação

Após a recuperação, valide o estado do banco de dados:

SELECT * FROM critical_table WHERE id = 123;

Abordando Problemas Potenciais

Arquivos WAL Ausentes ou Corrompidos

Problema

Arquivos WAL necessários para a recuperação estão ausentes ou corrompidos.

Solução

• Garanta que backups e arquivos WAL sejam validados regularmente usando ferramentas como pg_verifybackup.
• Use armazenamento redundante para arquivos WAL.

Alvo de Recuperação Incorreto

Problema

A recuperação para em um estado não intencional.

Solução

• Verifique novamente o recovery_target_time, recovery_target_lsn ou recovery_target_name.
• Use pg_waldump para inspecionar arquivos WAL em busca de eventos-alvo.

Gargalos de Desempenho Durante a Recuperação

Problema

A recuperação leva muito tempo devido a arquivos WAL grandes.

Solução

• Otimize o desempenho da recuperação aumentando maintenance_work_mem e max_parallel_workers.
• Use compressão WAL para reduzir o tamanho do arquivo.

Problemas de Desvio de Relógio

Problema

Os timestamps de recuperação precisam ser alinhados devido a diferenças de relógio.

Solução

Sincronize os relógios do servidor usando ferramentas como NTP.

Arquivamento WAL Mal Configurado

Problema

Um archive_command inadequado causa falhas na arquivação de WAL.

Solução

• Teste o archive_command manualmente: cp /caminho/para/test_wal /caminho/para/wal_archive/.
• Garanta permissões suficientes para o diretório de arquivamento.

Melhores Práticas para PITR

1. Automatize backups: Use ferramentas como pgBackRest ou Barman para backups agendados e arquivamento de WAL.
2. Monitore a arquivação de WAL: Verifique regularmente pg_stat_archiver em busca de problemas.
3. Valide backups: Sempre verifique a integridade do backup usando pg_verifybackup.
4. Teste procedimentos de recuperação: Simule regularmente cenários de recuperação para garantir a prontidão.
5. Proteja arquivos de WAL: Para arquivos de WAL, use armazenamento seguro e redundante, como serviços em nuvem ou discos configurados em RAID.

Conclusão

A recuperação em um ponto no tempo (PITR) é crítica para manter a confiabilidade do banco de dados e mitigar a perda de dados em caso de incidente. As melhorias do pgEdge e do PostgreSQL 17 tornam o PITR mais rápido, eficiente e fácil de gerenciar, especialmente para sistemas em grande escala ou altamente disponíveis.

Seguir os passos e melhores práticas deste guia ajudará você a implementar e gerenciar o PITR de forma eficaz em seus ambientes PostgreSQL. Testes e monitoramento regulares são essenciais para garantir que os processos de recuperação estejam disponíveis quando você mais precisar deles.