PostgreSQL 12, Cade o recovery.conf ?

Pessoal recentemente precisei fazer um restore de um banco corrompido no PostgreSQL 12, já havia sido configurado previamente o arquivamento dos logs de transação e uma copia do pg_data para que quando necessário fosse feito o Point-in-time Recovery (PITR) em que conseguimos voltar no tempo no banco de dados.

Ate ai tudo bem, facil de fazer.

Mas eu não achava o recovery.conf que seria o arquivo onde determinamos o target time ou seja em qual data e hora iremos voltar no banco de dados.

Então vamos la para a solução.

A maior mudança no PostgreSQL v12 do ponto de vista da compatibilidade com versões anteriores é que recovery.conf foi absorvido pelo postgresql.conf.

Este artigo descreve as mudanças e como você pode se adaptar a elas.

Se livrando do recovery.conf

Até agora, a presença do arquivo recovery.conf era o gatilho para o PostgreSQL entrar no modo de recuperação ao iniciar o servidor. Além disso, o arquivo continha todos os parâmetros para configurar a recuperação, por exemplo

• standby_mode: determina se esta é uma recuperação de arquivo normal ou modo de espera
• restore_command: comando para restaurar segmentos WAL arquivados
• Os recovery_target * parâmetros para determinar para qual ponto recuperar
• primary_conninfo: como se conectar ao servidor primário de replicação de streaming

O recovery.conf foi visto como um problema por muito tempo, uma vez que não é razoável ter parâmetros de configuração em mais de um arquivo.

No PostgreSQL v12, a mudança foi feita e os parâmetros do recovery.conf agora fazem parte de postgresql.conf. Esses parâmetros são ignorados até que o PostgreSQL esteja no modo de recuperação.

Embora isso faça com que o PostgreSQL funcione mais naturalmente para os iniciantes, tem algumas consequências às quais os usuários experientes precisam se adaptar:

Como dizer ao PostgreSQL para entrar no modo de recuperação?

Até agora, a existência do arquivo recovery.conf aciona o modo de recuperação.

Desde que o arquivo foi removido, dois novos arquivos tomaram seu lugar:

• recovery.signal: diz ao PostgreSQL para entrar na recuperação normal do arquivo
• standby.signal: diz ao PostgreSQL para entrar no modo de espera

Os arquivos podem estar vazios, apenas o fato de eles existirem é relevante. Eles são excluídos assim que a recuperação termina.

O parâmetro “ standby_mode” não é mais necessário e foi removido.

O que acontece com os parâmetros após a conclusão da recuperação?

Antes, recovery.conf foi renomeado para recovery.done após o término da recuperação. Isso removeu efetivamente os parâmetros de recuperação.

A partir da v12, os arquivos recovery.signal ou standby.signal serão excluídos quando a recuperação terminar, mas os parâmetros postgresql.conf permanecerão. Eles serão ignorados enquanto o PostgreSQL não estiver em recuperação, mas é uma boa idéia desativá-los com um #comentário “ ”. Isso evitará surpresas desagradáveis ​​posteriormente, por exemplo, quando você criar um servidor em espera.
Se você definir os parâmetros de recuperação usando ALTER SYSTEM, redefina-os com ALTER SYSTEM RESET.

O que acontece com a opção --write-recovery-conf “ ” do pg_basebackup?

A opção ainda existe, e isso não é um erro. Não cria recovery.conf mais nada, mas adiciona parâmetros de configuração de recuperação.

Em vez de adicionar os parâmetros a postgresql.conf, ele os adiciona postgresql.auto.conf, assim como ALTER SYSTEM faz. Isso é mais seguro, pois o arquivo é feito para edição automática.

O que acontece se eu recuperar o PostgreSQL 12 com recovery.conf?

Se você não percebeu as mudanças e tentou recuperar o PostgreSQL v12 com recovery.conf, o seguinte acontecerá:

• recovery.conf é ignorado.
• O PostgreSQL encontra backup_label, mas nenhum arquivo de sinal, portanto, executará a recuperação de falha a partir do ponto de verificação em backup_label.
• Se você criou o backup pg_basebackup e deixou a opção “ --wal-method” em seu nível padrão “ stream”, o PostgreSQL será recuperado com sucesso até o final do backup, mas não mais.
  Isso significa que você deve reiniciar a recuperação desde o início.
• Se o backup não incluir todos os segmentos WAL necessários pg_wal, a recuperação falhará com a mensagem de erro:
  ERROR: could not find redo location referenced by checkpoint record
  Como nenhuma recuperação foi realizada ainda, você pode corrigir o erro e continuar a recuperação.

Como adaptar meus scripts de backup?

O backup não é afetado pela mudança. Portanto, seus scripts de backup não precisam de modificações.

Scripts que executam recuperação de arquivo ou configuram servidores em espera terão que ser adaptados. A principal dificuldade será adicionar os parâmetros de recuperação necessários.
Minha recomendação é adicionar os parâmetros postgresql.auto.conf, pois como eu disse antes, esse arquivo é feito para edição automática.

Aqui está um exemplo de código para adicionar recovery_target_time:

sed --in-place \-e "/^recovery_target/d" \-e "$ a recovery_target_time = '2019-11-20 12:00:00'" \$PGDATA/postgresql.auto.conf

O comando primeiro remove todas as opções começando com “ recovery_target” e, em seguida, adiciona o parâmetro.

Não se esqueça de fazer o seguinte antes de iniciar o servidor:

touch $PGDATA/recovery.signal

Recomendo que você remova os parâmetros de recuperação novamente quando a recuperação for concluída.

Resumo

Os usuários experientes precisarão se acostumar com as mudanças na recuperação, mas não deve ser muito difícil de se adaptar.

Scripts que executam recuperação automática terão que ser modificados.

Aproveite esta oportunidade para testar seu procedimento de backup e recuperação!