Arquivamento Contínuo

O PostgreSQL mantém um registro prévio de escrita, ou simplesmente WAL (write

ahead log, em inglês), que fica localizado no subdiretório pg_wal dentro do diretório de dados

do cluster. Este log contém todas as modificações realizadas nos arquivos de dados no banco de dados. O objetivo principal deste log é a segurança de travamento, ou seja, se o sistema travar, o banco de dados pode ser restaurado, repetindo os registros de logs feitos desde o último ponto de verificação. A existência deste log torna possível uma terceira estratégia de backup chamado de Arquivamento Contínuo, que combina o backup a nível de sistema de arquivo com o backup dos arquivos de log WAL (POSTGRESQL, 2019).

4.3.6.3.1 Configuração

O PostgreSQL em execução, produz uma sequência de registros WAL, que é dividido fisicamente em arquivos de segmentos. O sistema cria estes arquivos, os mantem por um tempo dentro no diretório pg_wal e, em seguida, os recicla, apagando os mais antigos. Por este motivo, para realizar o backup dos dados do WAL, é necessário capturar cada arquivo de

segmento, quando já estiver preenchido e salvá-lo em algum lugar (disco separado, servidor externo ou fita, por exemplo) antes que o mesmo seja reciclado para reutilização (POSTGRESQL, 2019).

Para fornecer maior flexibilidade ao administrador, o PostgreSQL permite que seja informado um comando shell a ser executado para copiar um arquivo de segmento completo para o lugar onde ele precisa ir.

Para ativar o arquivamento do WAL, primeiramente, é necessário abrir o arquivo postgres.conf e configurar as seguintes variáveis:

a) em wal_level, configurar como replica; b) em archive_mode, configurar para on;

c) em archive_command, especificar o comando shell que irá realizar a cópia do arquivo de segmento.

O comando a ser utilizado em archive_command é praticamente o seguinte: Figura 31 – Comando archive_command

Fonte: Autores, 2019.

Este comando realizará um teste para verificar se o arquivo já existe no diretório

/home/postgres/backup/archive/. Caso o arquivo não exista, o mesmo é copiado para o diretório

de destino informado.

Alguns cuidados que são importantes adotar e pontos que valem a pena destacar: a) é aconselhável testar o comando inserido em archive_command para garantir

que realmente não seja substituído algum arquivo existente e que seja retornado um status diferente de zero. Se o resultado for zero, o PostgreSQL entenderá que o arquivo foi copiado com sucesso e o removerá ou reciclará do servidor. Caso contrário, um status diferente de zero, o PostgreSQL entenderá que o arquivo não foi arquivado, então, ele tentará novamente periodicamente até conseguir;

b) o diretório de destino deve estar localizado em uma partição ou volume diferente do diretório de arquivos do banco de dados;

c) o diretório de destino dos arquivos WAL deve possuir permissões de acesso e de alterações para o usuário postgres.

Após alterações anteriores, é necessário fazer o restart do servidor PostgreSQL

4.3.6.3.2 Realizando backup base

Para realizar um backup base de um cluster do PostgreSQL, é necessário usar a ferramenta pg_basebackup no Terminal do Ubuntu no servidor. O comando completo a ser executado é o seguinte:

pg_basebackup -D bkp_20190331 -Ft -z -P

Onde:

a) -D é informação do diretório para gravar a saída;

b) -Ft grava a saída como arquivos do formato tar no diretório de destino;

c) -z ativa a compactação gzip da saída do arquivo tar, com o nível de compactação padrão;

d) -P fornecerá um relatório de progresso aproximado durante o backup que vai de 0 a 100%.

Após a conclusão da execução do comando, pode-se verificar que foi criada um diretório chamado bkp_20190331 a partir do diretório onde foi executado o comando. Dentro deste diretório foram criados os seguintes arquivos:

Figura 32 – Lista dos arquivos criados a partir do comando pg_basebakcup

Na imagem acima, o arquivo base.tar.gz contém o backup de todo o sistema de arquivos cluster do PostgreSQL; o arquivo pg_wal.tar.gz contém os arquivos WAL gerados até o momento do backup; e os arquivos 16417.tar.gz e 16418.tar.gz são backups dos arquivos de dados dos namespaces criados no cluster (lembrando que o nome numérico se refere ao OID do objeto que consta no catálogo do sistema pg_class e que pode ser facilmente visualizado, utilizando a view de sistema pg_namespace).

4.3.6.3.3 Restauração usando o arquivamento contínuo

Suponha-se que o pior aconteceu e será necessário restaurar o banco de dados a partir do backup. A seguir, será listado o procedimento para restaurar o cluster do banco de dados, utilizando a estratégia de backup de arquivamento contínuo:

a) parar o servidor, se o mesmo estiver em execução;

b) copiar todo diretório de dados (PGDATA) do cluster e todos os tablespaces para um local temporário, caso seja necessário usá-los posteriormente;

- Esta operação exigirá que se tenha espaço em disco suficiente para armazenar duas cópias do banco de dados;

- Caso não haja espaço suficiente, ao menos, deve-se salvar o conteúdo do subdiretório pg_wal, pois ele pode conter arquivos WAL que não foram copiados antes do sistema parar de funcionar.

c) remover todos os arquivos e subdiretórios existentes no diretório de dados do cluster e dos tablespaces utilizados;

d) restaurar os arquivos de banco de dados do backup do sistema de arquivos, realizado no tópico 4.3.6.3.2;

- Certificar de que todos os arquivos sejam restaurados com as propriedades e permissões corretas, no caso com o usuário do PostgreSQL e não root; - Caso esteja-se usando tablespaces, deve-se verificar se os links simbólicos

foram restaurados corretamente no subdiretório pg_tblspc.

e) apagar todos os arquivos presentes no subdiretório pg_wal. Lembrando que estes arquivos vieram do sistema de arquivos no momento do backup base e, portanto, são antigos e obsoletos;

f) verificar se no diretório pg_wal da cópia do banco criado no passo b, há arquivos WAL que não foram enviados para o diretório de arquivamento

(configurado no tópico 4.3.6.3.1), caso haja, deve-se copiar imediatamente estes arquivos para o diretório de arquivamento;

g) criar um arquivo chamado recovery.conf no diretório de dados do cluster e adicionar um comando de recuperação, que será detalhado posteriormente; h) modificar temporariamente o arquivo pg_hba.conf para impedir que usuários

comuns tentem se conectar ao PostgreSQL até que se tenha certeza que a recuperação foi bem-sucedida;

i) iniciar o servidor;

- O servidor entrará em modo de recuperação e começará a ler os arquivos

WAL arquivados de que precisa;

- Caso ocorra algum erro externo, o servidor irá simplesmente ser reiniciado e continuará a recuperação;

- Após a conclusão do processo de recuperação, o servidor renomeará o arquivo recovery.conf para recovery.done e iniciará as operações normais do banco de dados.

j) verificar o conteúdo do banco de dados para ter certeza de que a recuperação foi realizada para o estado desejado;

k) caso tudo estiver correto, deve-se restaurar as configurações do pg_hba.conf ao normal, para que os usuários se conectem novamente ao banco.

A parte mais importante para todo o processo listado anteriormente funcionar está na configuração do arquivo recovery.conf. A única coisa que deve ser especificada neste arquivo é a variável restore_command, que informa ao PostgreSQL como deve recuperar os segmentos do arquivo WAL. O comando a ser informado no restore_command deve ser algo como:

restore_command = '/home/postgres/backup/log_archive/%f %p'

Este comando copiará os segmentos WAL gravados anteriormente no diretório de arquivamento e os executará desde o momento que o backup do item 2 foi feito.

Deve-se dar permissão ao PostgreSQL executar o arquivo recovery.conf

Caso a recuperação encontrar arquivos WAL corrompidos, a recuperação será interrompida neste ponto e o servidor não será iniciado. Neste caso, o processo de recuperação deve ser executado novamente desde o início, especificando um "destino de recuperação" antes do ponto de corrupção para que a recuperação possa ser concluída normalmente.

Outro ponto muito interessante no restore do banco de dados é a capacidade de poder recuperar o banco de dados até o dia e hora desejado. Isto é possível adicionando mais uma linha no arquivo recovery.conf com a variável ‘recovery_target_time’ em que deve ser informado o dia e horário até o ponto em que se deseja realizar o restauro. Por exemplo:

recovery_target_time = ‘2019-01-14 22:39:00’

No exemplo acima, o banco de dados será restaurado até as 22:39 do dia 14 de janeiro de 2019.