Eduardo Lobo Blanco escreveu:
> 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.
>
>
Seu e-mail é bem longo mesmo ... ;-)
Mas a resposta é curta. Sim. Na verdade pode ocorrer de perder no máximo
estes 3 mas pode ser menos, em vários testes que fiz as vezes ficava
somente 1 ou 2 que não tinham sido arquivados.
Por isto é recomendável ter um processo agendando, no cron por exemplo,
que copie de vez em quando estes arquivos do pg_xlog que ainda não foram
arquivados e estão em uso para uma área de backup ou fita de forma a
minimizar a quantidade de transações perdidas.
Por coincidência estou testando bastante estes processo de backup via
PITR no postgres esta semana.
Veja também que você pode definir no parametro archive_timeout um tempo
para que ocorra o log switch, isto tem um custo de performance se for um
tempo muito pequeno, mas para determinadas situações pode ser
aconselhável defini-lo.
Leandro Henrique Pereira Neto
Administração de bancos de dados - DBA/OC
SUPCD/CDSUT/CDSBB
61 21059359
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa
pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada
exclusivamente a seu destinatário e pode conter informações confidenciais,
protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e
sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira,
por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a
government company established under Brazilian law (5.615/70) -- is directed
exclusively to its addressee and may contain confidential data, protected under
professional secrecy rules. Its unauthorized use is illegal and may subject the
transgressor to the law's penalties. If you're not the addressee, please send
it back, elucidating the failure."
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
