Leandro Henrique Pereira escreveu:
> 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
>
>
>
Obrigado pela resposta Leandro ...
estou testando agora mesmo alterar o valor de archive_timeout.
assim que tiver resultados posto na lista.
Valeu.
--
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
