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

A recuperação em um 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 administradores restaurem um banco de dados PostgreSQL a 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 alta carga de transações.

Este blog explorará o PITR e fornecerá 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 Principais

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

1. Backup Base

Um backup base é uma captura do banco de dados em um ponto específico no tempo. Ele 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 ponto de partida para o PITR.

2. Logs de Escrita Antecipada (WAL)

Os arquivos WAL registram cada mudança feita no banco de dados. Esses logs armazenam as mudanças necessárias para recuperar o banco de dados ao seu estado em um momento específico. Quando você realiza uma 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árias situações:

Desfazer Mudanças Acidentais

Operações acidentais, como uma declaraçã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 logo antes do 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 um instantâneo limpo 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 testes. O PITR possibilita a criação de um instantâneo do banco de dados em um ponto específico, facilitando experimentos controlados sem afetar dados em tempo real.

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 rapidamente restaurar o banco de dados para seu último estado consistente, garantindo a continuidade dos negócios.

Uso Eficiente de Recursos

Ao combinar backups base 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 um rollback de transação única até uma restauração completa do banco de dados de forma eficiente.

O que há de novo no PostgreSQL 17 para PITR?

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

Síntese 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ções.

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, particularmente para grandes conjuntos de dados.

Compatibilidade Aprimorada com Replicação Lógica

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 sobre Arquivamento de WAL

O PostgreSQL 17 oferece mais controle sobre o arquivamento de WAL, permitindo que você ajuste as políticas de retenção para corresponder aos requisitos de recuperação.

Passos Detalhados para Executar PITR no PostgreSQL

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

• Arquivamento de WAL: Ative e configure o arquivamento de WAL.
• Backup base: Faça um backup base completo usando pg_basebackup ou pgBackRest.
• Armazenamento seguro: Certifique-se de que os backups e os arquivos WAL sejam armazenados de forma segura, preferencialmente fora do local.

1. Configure o Arquivamento de WAL

O arquivamento de WAL é crucial 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

Então, 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;

Procure por quaisquer 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 ativar 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 Faltando ou Corrompidos

Problema

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

Solução

• Certifique-se de que os backups e arquivos WAL sejam validados regularmente usando ferramentas como pg_verifybackup.
• Use armazenamento redundante para arquivos WAL.

Objetivo 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 de destino.

Gargalos de Desempenho Durante a Recuperação

Problema

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

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/.
• Assegure 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 programados e arquivamento de WAL.
2. Monitore a arquivação de WAL: Verifique regularmente pg_stat_archiver em busca de problemas.
3. Valide os backups: Sempre verifique a integridade do backup usando pg_verifybackup.
4. Teste os procedimentos de recuperação: Simule regularmente cenários de recuperação para garantir a prontidão.
5. Proteja os arquivos de WAL: Para os arquivos de WAL, use armazenamento seguro e redundante, como serviços de nuvem ou discos configurados em RAID.

Conclusão

A recuperação ponto-a-ponto (PITR) é crítica para manter a confiabilidade do banco de dados e mitigar a perda de dados em caso de incidentes. As melhorias do pgEdge e do PostgreSQL 17 tornam o PITR mais rápido, eficiente e mais 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 regulares e monitoramento são essenciais para garantir que os processos de recuperação estejam disponíveis quando você mais precisar.