Início / dba / Perguntas / 3365
Accepted
Jamess
Asked: 2011-06-18 03:18:55 +0800 CST

Postgresql - Recuperação usando recovery.conf

  • 772

Estou tentando recuperar um banco de dados usando o arquivo recovery.conf para fazer uma cópia pontual.

No arquivo recovery.conf, adicionei um tempo de destino de recuperação conforme abaixo.

recovery_target_time = '2011-06-16 04:10:00 IST'

Mas nos logs posso ver se ele avança o tempo em 3,5 horas para 07:40 e a recuperação real é tentada para esse horário, não o tempo que dei em recovery_target_time.

2011-06-16 12:53:45 IST LOG:  starting archive recovery
2011-06-16 12:53:45 IST LOG:  restore_command = '/app/postgresinstall/bin/pg_standby -l /dbdata/archive %f %p %r'
2011-06-16 12:53:45 IST LOG:  recovery_target_time = '2011-06-16 07:40:00+05:30'
cp: cannot stat `/dbdata/archive/00000001.history': No such file or directory

Por que essa diferença de 3,5 horas e preciso de ajuda para descobrir o que está acontecendo ao decidir o tempo-alvo de recuperação?

Atualização: aqui estão os detalhes de tempo do banco de dados

postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now());
 date_part | date_part 
-----------+-----------
         5 |        30
(1 row)

postgres=# select now();
               now                
----------------------------------
 2011-08-12 13:08:19.333068+05:30
(1 row)

OS Date/Time:
postgres@xxxxx:~$ date
Fri Aug 12 13:10:19 IST 2011

Eu enfrentei o mesmo problema quando tento restaurar de arquivos WAL no mesmo servidor e meu servidor de backup. Também posso reproduzir consistentemente esse problema em ambos os servidores.

Portanto, se eu precisar criar um backup próximo ao horário atual, uso um recovery_target_time 3,5 horas atrasado no horário atual e inicio o banco de dados com recovery.conf

postgresql restore

2 respostas

  1. Best Answer

    ISENÇÃO DE RESPONSABILIDADE: Não sou um DBA PostgreSQL, embora me envolva muito com isso.

    Você provavelmente precisa verificar seu fuso horário no sistema operacional e no psql.

    No sistema operacional execute isto:

    [postgres@radarPG-db1 ~]$ date
Fri Jun 17 12:55:37 EDT 2011

    No psql, execute o seguinte:

    postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now());
 date_part | date_part
-----------+-----------
        -4 |         0

postgres=# select now();
              now
-------------------------------
 2011-06-17 12:54:39.195291-04

    Muitas vezes, alguns se esquecem de ter como padrão o fuso horário do postgres para o do sistema operacional. Se os arquivos WAL também contiverem o fuso horário em seus timestamps internos, você deve alinhar o fuso horário definido no postgres com o dos arquivos WAL.

    Outra coisa a considerar é o seguinte:

    O comportamento padrão da recuperação é recuperar ao longo da mesma linha do tempo atual quando o backup básico foi feito. Se você deseja recuperar em algum cronograma filho (ou seja, deseja retornar a algum estado que foi gerado após uma tentativa de recuperação), é necessário especificar o ID do cronograma de destino em 'recovery.conf'. Você não pode recuperar em linhas de tempo que se ramificaram antes do backup básico.

    ATUALIZAÇÃO 2011-06-20 15:08 EDT

    Isso está certo na documentação online. Por favor, dê uma olhada e veja se você perdeu algum arquivo WAL ao longo do caminho. Se você esperou muito tempo para configurar os arquivos WAL no novo servidor, o postgres pode tê-los excluído na inicialização. Você pode precisar encontrar esses arquivos WAL. Veja se eles residem na pasta pg_xlog do servidor antigo.

    Recuperando usando um backup de arquivo contínuo

    1. Pare o servidor, se estiver em execução.

    2. Se você tiver espaço para fazer isso, copie todo o diretório de dados do cluster e quaisquer tablespaces para um local temporário, caso precise deles posteriormente. Observe que esta precaução exigirá que você tenha espaço livre suficiente em seu sistema para manter duas cópias de seu banco de dados existente. Se você não tiver espaço suficiente, precisará pelo menos copiar o conteúdo do subdiretório pg_xlog do diretório de dados do cluster, pois ele pode conter logs que não foram arquivados antes de o sistema cair.

    3. Limpe todos os arquivos e subdiretórios existentes no diretório de dados do cluster e nos diretórios raiz de quaisquer tablespaces que você estiver usando.

    4. Restaure os arquivos de banco de dados de seu backup básico. Tenha cuidado para que eles sejam restaurados com a propriedade correta (o usuário do sistema de banco de dados, não o root!) e com as permissões corretas. Se você estiver usando tablespaces, verifique se os links simbólicos em pg_tblspc/ foram restaurados corretamente.

    5. Remova todos os arquivos presentes em pg_xlog/; eles vieram do despejo de backup e, portanto, provavelmente são obsoletos em vez de atuais. Se você não arquivou pg_xlog/, recrie-o, tendo o cuidado de restabelecê-lo como um link simbólico, caso o tenha configurado dessa forma antes.

    6. Se você desarquivou os arquivos de segmento WAL que salvou na etapa 2, copie-os para pg_xlog/. (É melhor copiá-los, não movê-los, para que você ainda tenha os arquivos não modificados se ocorrer um problema e você tiver que começar de novo.)

    7. Crie um arquivo de comando de recuperação recovery.conf no diretório de dados do cluster (consulte Configurações de recuperação). Você também pode modificar temporariamente pg_hba.conf para impedir que usuários comuns se conectem até ter certeza de que a recuperação funcionou.

    8. Inicie o servidor. O servidor entrará no modo de recuperação e procederá à leitura dos arquivos WAL arquivados necessários. Caso a recuperação seja encerrada devido a um erro externo, o servidor pode simplesmente ser reiniciado e continuará a recuperação. Após a conclusão do processo de recuperação, o servidor renomeará recovery.conf para recovery.done (para evitar a reentrada acidental no modo de recuperação em caso de travamento posterior) e, em seguida, iniciará as operações normais do banco de dados.

    9. Inspecione o conteúdo do banco de dados para garantir que você recuperou para onde deseja estar. Caso contrário, retorne à etapa 1. Se tudo estiver bem, deixe seus usuários entrarem restaurando o pg_hba.conf ao normal.

    • 4

  2. No PostgreSQL, ISTpode não significar 'Indian Standard Time', dependendo da configuração 'timezone_abbreviations'em postgresql.conf. Deve ser definido como 'India'for ISTpara ser interpretado conforme desejado aqui.

    • 3

relate perguntas