Olá lista ...
Estou testando o funcionamento do PITR aqui na empresa, mas estou com
uma dúvida na recuperação dos dados pelos arquivos de WAL.
Vou explicar passo a passo o que fiz e o resultado:
- Iniciei um banco novo em uma maquina de teste (/usr/local/pgsql/bin -D
/usr/local/pgsql/data)
- Em seguida restaurei um banco que temos do nosso sistema apartir do
dump que fazemos diariamente. Utilizei o pg_restore e o banco restaurou
100%.
- Configurei o postgres.conf para executar o WAL ARCHIVING.
archive_command = 'cp -i %p /teste/wal/%f </dev/null'
- O WAL ARCHIVING esta funcionando sem problemas.
- Criei o base backup do banco com os seguintes passos usando o psql:
- select pg_start_backup('teste.tar.gz');
- tar -czf /teste/base/teste.tar.gz /usr/local/pgsql/data
- select pg_stop_backup();
- o base backup ocorreu sem problemas, criando no diretorio de archive
do WAL o arquivo 000000010000000000000075.00918954.backup e o arquivo
000000010000000000000075
- Apos ter o WAL ARCHIVING funcionanado e ter criar o base backup, me
conectei no banco pelo pgAdmin.
Neste banco temos uma tabela com 5.153.747 registros. Ralizei um
DELETE de todos os registros do ano de 2007 desta tabela apagando assim
2.767.015 registros.
Com essa ação foi gerado alguns arquivos de WAL no diretorio de
archive. No log do postgres foi registrado o archive do arquivos de WAL
corretamente.
- archived transaction log file "000000010000000000000076"
Essa mensagem se repetiu até o arquivo 000000010000000000000089
Nesse momento percebi que no diretorio /usr/local/pgsql/data/pg_xlog/
existem 3 arquivos de WAL que não foram arquivados no diretorio de
archive do WAL.
- Continuando com meu teste, parei o postgres para tentar agora
restaurar o banco apartir do base backup e dos WAL arquivados.
- Renomiei o diretorio "/usr/local/pgsql/data" para
"/usr/local/pgsal/data.OLD"
- Descompactei o base backup criando o novo "/usr/local/pgsal/data" e
acertei as permissoes do diretorio corretamente.
- Apaguei o conteudo do "/usr/local/pgsal/data/pg_xlog/" e
/"usr/local/pgsal/data/pg_xlog/archive_status" pois continham dados da
hora que o base backup foi gerado.
- Criei o arquivo recovery.conf com o conteudo
- restore_command = 'cp /teste/wal/%f "%p"'
- Iniciei o Postgres novamente. No log do postgres observei:
- starting archive recovery
- restore_command = "cp /teste/wal/%f "%p""
- cp: impossível fazer stat em `/teste/wal/00000001.history':
Arquivo ou diretório não encontrado
- restored log file "000000010000000000000075.00918954.backup" from
archive
- restored log file "000000010000000000000075" from archive
- checkpoint record is at 0/75918954
- redo record is at 0/75918954; undo record is at 0/0; shutdown FALSE
- next transaction ID: 0/1806; next OID: 24576
- next MultiXactId: 1; next MultiXactOffset: 0
- automatic recovery in progress
- redo starts at 0/7591899C
- restored log file "000000010000000000000076" from archive
Esta ultima mensagem se repetiu ate o arquivo
000000010000000000000089 que era o ultimo arquivo no diretorio de WAL.
- cp: impossível fazer stat em
`/spacecom/wal/00000001000000000000008A': Arquivo ou diretório não
encontrado
- could not open file "pg_xlog/00000001000000000000008A" (log file
0, segment 138): Arquivo ou diretório não encontrado
- redo done at 0/89FFFAB0
- restored log file "000000010000000000000089" from archive
- archive recovery complete
- database system is ready
- Após isso, me conectei no banco e fui verificar se o banco estava
correto,
mas para minha surpresa, os dados que havia apagado com o DELETE ainda
estao na base.
Estou usando o Postgres 8.2.4
Após escrever todo este email, percebi uma conhecidencia que acho nao
ser por acaso. Ficaram 3 arquivos no diretorio /usr/local/pgsql/pg_log/
que nao foram arquivados no diretorio do WAL,
e o no meu postgres.conf esta definido o valor de "checkpoint_segments = 3".
Apos essa luz, executei todo o processo de restauracao acima, mas
copiando os arquivos que faltaram a ser arquivados no diretorio do WAL,
e pronto. O DELETE foi executado.
Entao conclui que o checkpoint_segments é a quantidade de transacoes que
podemos perder em caso de uma catastrófe do banco, tipo na queima de um hd.
É isso mesmo ?
Obrigado e desculpem pelo longo email.
--
Abraços ...
Eduardo Lobo Blanco
Spacecom Tecnologia e Comunicações LTDA.
[EMAIL PROTECTED]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
