O WAL (Write Ahead Log) é um log de transação, necessário para garantir a atomicidade e durabilidade das transações mesmo após falhas.

Até a verão 9.6 o diretório que armazena os logs de transação ficam por padrão em pg_xlog dentro do pg_data, a partir da versão 10 este foi renomeado para pg_wal, inicialmente no pg_data, mas podendo ter sua localização modificada no arquivo postgresql.conf, muitas das vezes essa alteração ocorre para um tuning do banco de dados, movendo os logs de transação para discos de maiores velocidades.

Quando comandos DML são executados, o MVCC faz com que versões novas das tuplas(Linhas) sejam criadas na tabela. Com o tempo, as transações atuais são finalizadas e algumas das versões de tuplas se tornam permanentemente inacessíveis para todas as transações atuais e futuras, chamadas de tuplas mortas. Ainda assim, essas versões ocupam espaço na tabela e esse espaço precisa ser recuperado. A relação entre espaço ocupado por tuplas mortas e espaço total é conhecido como inchaço (bloat, em inglês).

Neste tutorial, você irá aprender como fazer backup e restore dos bancos de dados PostgreSQL usando a ferramenta pg_dump, pg_dumpall, psql e pg_restore.

Fazer backup de bancos de dados é uma das tarefas mais críticas na administração de banco de dados. Antes de fazer backup dos bancos de dados, você deve considerar os seguintes tipos de backup:

• Bancos de dados completos ou parciais
• Dados e estruturas, ou apenas estruturas
• Recuperação pontual
• Restaurar desempenho

O PostgreSQL vem com pg_dump e pg_dumpall que são ferramentas que ajudam a fazer backup fácil e eficaz.

O programa pg_upgrade depende dos serviços, tanto da versão de origem quanto da versão de destino, não estejam no ar. Contudo, depende dos diretórios de dados estarem inicializados.

Quando executado, o pg_upgrade inicia as instâncias das duas versões e faz a transferência (cópia ou hard link) dos objetos que não sofreram alterações estruturais, assim como cria novos objetos no destino e copia os dados daqueles que sofreram alterações estruturais. Portanto, ele precisa conhecer as localizações dos diretórios de dados e dos diretórios de binários.

Para usar o modo de hard link, adicione -k nos comandos do pg_upgrade abaixo.

Neste artigo, vamos mergulhar nos detalhes básicos de configuração do recurso de Streaming Replication no PostgreSQL. A replicação de streaming é o bloco de construção fundamental para alcançar alta disponibilidade em seu Servidor PostgreSQL e é produzida executando uma configuração master-slave.

Terminologia Master-Slave

Servidor Master(Mestre) / Primário

• O servidor que pode receber gravações.
• Também chamado de servidor de leitura / gravação.

Slave(slave) / Standby Server

• Um servidor onde os dados são mantidos em sincronia com o Master continuamente.
• Também chamado de servidor de backup ou réplica.
• Um servidor em espera passiva é aquele ao qual não pode ser conectado até que seja promovido a servidor master.
• Em contraste, um servidor hot standby pode aceitar conexões e atender a consultas somente leitura. Para o restante desta discussão, nos concentraremos apenas em servidores hot standby.

O banco de dados é o coração da aplicação. Antes de nos aprofundarmos em alguns insights sobre por que é essencial monitorar o Postgres, primeiro discutiremos um pouco sobre monitoramento.

Monitorar é coletar pontos de dados históricos que você usa para gerar alertas (para quaisquer anomalias), para otimizar seu banco de dados e, por último, ser proativo no caso de algo dar errado (por exemplo, um banco de dados com falha).

A abordagem “Veremos quando isso acontecer” pode funcionar com seus projetos pessoais, mas pode custar muito dinheiro para uma empresa se não for atendida. Embora seja essencial monitorar seu banco de dados, também é importante saber o que e por que monitorar . De minha experiência profissional como DBA, tenho visto a maioria dos DBAs, desenvolvedores e equipes operacionais falharem em monitorar o Postgres para as coisas certas. Neste post, discutiremos a estrutura de monitoramento PostgreSQL que construí trabalhando como DBA.

Por que é essencial monitorar o PostgreSQL?

Existem 5 razões principais para monitorar seu banco de dados PostgreSQL.

1. Disponibilidade

2. Otimização do sistema

3. Identificar problemas de desempenho

4. Melhoria do processo de negócios

5. Planejamento de Capacidade

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.