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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral