Recuperação-recovery Postgresql

Esse documento e uma traducao de um capitulo de um livro no qual a fonte foi citada no final do documento. Vejo que muitas pessoas detem duvidas em relacao a Point-in-time recovery , essa e minha forma de contribuicao com a comunidade Postgresql. Desculpem pela falta de acentuacao no documento(traduzi o documento ontem as 11/04/2006 01:30 AM ,nao me preocupei muito com a estetica :P ) por qualquer falha de traducao, acho que nao sao muitas e nao poe em risco o bom entendimento.

Point-in-time recovery

Quando voce faz uma mudanca em algum banco de dados do Postgresql, Postgresql grava suas mudancas no shared-buffer pool, o write ahead log(WAL) e eventualmente no arquivo que voce mudou. O WAL contem registros completos das mudancas que voce fez. O mecanismo de Point-in-time recovery usa um historico de modificacoes gravados nos arquivos WAL. Imaginne o PITR como um esquema de backup incremental. Voce comeca com um backup completo e depois, arquiva as mudancas realizadas. Quando ocorrer um crash no seu server, voce restora o backup completo(full backup) e aplica as mudancas, em sequencia, ate que se recupere todos os dados que desejas recuperar.

Point-in-time recovery(PITR) pode parecer muito intimidador se voce comeca a ler a documentacao. Para voce ter uma boa visao sobre o sistema de PITR, iremos criar uma nova base, da um crash nela e recuperar os dados usando o mecanismo de PITR. Voce pode seguir se quiser, mas voce ira precisar de um spaco em disco extra.

Iremos comecar criando um novo cluster.

$export PGDATA=/usr/local/pgPITR

initdb

The files belonging to this database system will be owned by user "pg".

This user must also own the server process.

...

Success. You can now start the database server using:

postmaster -D /usr/local/pgPITR/data

or

pg_ctl -D /usr/local/pgPITR/data -l logfile start

Agora iremos mudar o arquivo $PGDATA/postgresql.conf para acionar o mecanismo de PITR. A unica mudanca que voce deve fazer e definir o parametro archive_command. O parametro archive_command diz ao Postgresql como os arquivos de WAL(write-ahead-log) irao ser gerados pelo servidor. Tomemos como exempo a seguinte configuracao:

archive_command='cp %p /tmp/wals/%f '

Postgresql ira executar o archive_command ao inves de simplesmente deletar os arquivos WAL como ele normalmente faz. %p significa o caminho completo do WAL e o %f e o nome do arquivo.

Agora iremos criar o diretorio /tmp/wals, startar o processo postmaster e criar um banco de dados para que possamos trabalhar.

$mkdir /tmp/wals

$pg_ctl -l /tmp/pg.log start

$createdb teste

CREATE DATABASE

Nesse momento eu tenho um cluster completo , os dados relativos ao cluster estao em $PGDATA, e um banco de dados chamado teste. Quando eu realizo mudancas no meu banco de dados teste, essas mudancas sao gravados nos arquivos WAL que estao em $PGDATA/pg_xlog(como em qualquer outro cluster). Quando um arquivo WAL cresce, Postgresql ira copiar ele para o diretorio /tmp/wals para mante-los sao e salvos. A unica diferenca entre um cluster convencional e um cluster que esteja com o mecanismo de PITR acionado e que o servidor Postgresql ira arquivar os arquivos WAL ao inves de deleta-los.

Como o mecanismo de PITR trabalha com as mudancas efetudas no banco de dados e gravadas nos arquivos WAL, iremos gerar alguns arquivos WAL criando algumas tabelas. Nao interessa o que dados irao conter as tabelas, nos queremos somente gerar os arquivos WAL, ate que eles crescam( cada arquivo WAL contem 16 megas).

$psql

Welcome to psql 8.0.0, the PostgreSQL interactive terminal. ...

teste=# BEGIN WORK; /* aqui comecamos a nossa transacao*/

teste=# create table teste1 as select * from pg_class,pg_attribute;

SELECT

teste=# COMMIT; executed at 12:30:00 pm /*terminamos a nossa transacao*/

teste=#\q

O commando create table produz uma tabela que contem mais de 245000 registros e produz bastante arquivos WAL capas de chegar aos 16 megas cada um. Voce pode ver os segmentos WAL olhando o diretorio /tmp/wals

$ls /tmp/walls

000000010000000000000000

000000010000000000000001

000000010000000000000002

000000010000000000000003

000000010000000000000004

Agora iremos criar um backup completo de todo os meus dados do meu cluster. Para simplificar o exemplo irei criar um arquivo .tar.gz e salva-lo no diretorio /tmp. Antes de eu comecar o meu backup, iremos dizer ao Postgresql o que estamos prestes a fazer chamando a funcao pg_start_backup()

$psql teste

Welcome to psql 8.0.0, the PostgreSQL interactive terminal. ...

teste=# select pg_start_backup('full baclup-Segunda');

pg_start_backup

----------------

0/52EA2B8 (1 row)

teste=# \q

Agora iremos criar o backup dos nossos dados do cluster

tar czvf /tmp/pgdata.tar.gz $PGDATA

O argumento que demos ao funcao pg_start_backup() e simplesmete um rotulo que ajuda a lembrarmos de onde os arquivos vieram. Voce ire achar o seguinte arquivo $PGDATA/backup_label depois de chamar a funcao, e o rotulo que passamos como parametro estara dentro desse arquivo.

Quando terminarmos de criar o nosso backup, no caso o nosso tarball, iremos dizer ao Postgresql que terminanos chamando a funcao pg_stop_backup()

$psql teste

Welcome to psql 8.0.0, the PostgreSQL interactive terminal. ...