2013/8/23 Danilo Silva <[email protected]> > Em 23 de agosto de 2013 13:32, Matheus de Oliveira < > [email protected]> escreveu: > > >> >> 2013/8/23 Flavio Henrique Araque Gurgel <[email protected]> >> >>> >>> Em 23-08-2013 13:01, Matheus de Oliveira escreveu: >>> >>>> >>>> 2013/8/23 Danilo Silva <[email protected] >>>> <mailto:danilo.dsg.gomes@**gmail.com <[email protected]>>> >>>> >>>> >>>> Pessoal, >>>> >>>> Considerando a lacuna entre o pg_start_backup e o pg_stop_backup, >>>> qual parâmetro do postgresql.conf eu devo aumentar para o postgres >>>> manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o >>>> wal_keep_segments? >>>> >>>> >>>> IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os >>>> logs de transação independente da quantidade, até que seja executado o >>>> pg_stop_backup, além disso, só irá "liberar" a chamada do pg_stop_backup >>>> quando todos os logs de transação até sua chamada já tenham sido >>>> arquivados (por isso o pg_stop_backup "dá uma travadinha" as vezes). >>>> >>> >>> Opa, opa! >>> Não não. >>> O PostgreSQL *não* faz isso. >>> >>> >> Ok. Foi mal... Dessa vez a expressão do "IIRC" foi falsa... =P >> >> Não lembrava com relação à arquivamento desabilitado, pois não é um >> cenário comum (ao menos pra mim). >> >> >> A pergunta original tem uma resposta verdadeira: o parâmetro >>> wal_keep_segments é quem diz quantos segmentos extras devem ser armazenados >>> após arquivados pelo archive_command ou reciclados após checkpoint. >>> >>> >> No case de um backup base, não me parece uma boa estratégia confiar no >> wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja >> para ativar o arquivamento temporariamente durante o backup. >> >> >> Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre >>> pg_start/stop_backup seria praticamente impossível calcular um espaço >>> consumido pelo diretório pg_xlog. >>> >>> >> Praticamente? Seria realmente impossível. É claro que pode-se ter uma >> estimativa baseado no tamanho do PGDATA e no histórico. >> >> >> >>> >>> De qualquer forma, se você tiver o arquivamento de logs de transação >>>> ativos, você não tem que se preocupar com isso de qualquer forma, ao >>>> menos que queira um basebackup sem os "archives". >>>> >>> >>> Esta frase está ok ;) >>> >>> >> Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem* ter >> arquivamento habilitado? Qual o motivo? >> >> > O arquivamento não está habilitado (em um servidor teste, somente > alteramos wal_level = archive para testar a rotina que irá efetuar a > cópia). Atualmente não existe nenhuma política de backup e/ou dump, devemos > analisar todo o ambiente, pois quando se tenta efetuar um dump (a base é > pequena, possui em torno de 40 GB), a aplicação trava, creio que seja por > conta dos acessos/transações, que são muitos mas ainda não temos um número > exato. > > xiii.... mas se diz que já está verificando, ok... =D
Eu, particularmente, recomendaria você tentar o pg_dump pelo menos em horários de menor uso. > Imagino que, para uma situação emergencial, uma cópia da base resolveria > temporariamente, mas fico preocupado com essa lacuna entre o start/backup, > ou será que dado a situação atual, devemos confiar apenas em ter os dados > até o momento em que se iniciou a cópia? > > Realmente, quando você faz **só** um backup base, sem arquivamento, você irá precisar de todos os logs de transação gerados entre a chamada do pg_start_backup e pg_stop_backup. Em primeiro lugar, eu recomendaria você a tentar criar uma política de backup para PITR e habilitar **sempre** o arquivamento. Mas... De forma temporária, você pode fazer o seguinte: 1. Engane o PostgreSQL e habilite o arquivamento sem arquivar (loucura né?!): archive_mode = on archive_command = 'exit 0' # veja, não faz nada, só finge que copiou Reinicie o PostgreSQL (terás de reiniciar somente uma vez, por causa do archive_mode). 2. Quando for executar o backup base, configure o archive_command para efetivamente copiar os logs de transação: archive_command = 'cp %p /path/to/%f' # ou seu comando... Execute um reload no PostgreSQL (veja, não precisa de restart). 3. Realize sua cópia normalmente: pg_start_backup => cópia (tar, cp, etc.) => pg_stop_backup 4. Volte o archive_command para 'exit 0' Pronto, agora basta você "pegar" os arquivos salvos pelo archive_command "temporário" e salvá-los junto ao seu backup. Pode até colocá-los dentro do diretório pg_xlog do backup, ou, numa restauração você precisará somente configurar o restore_command no recovery.conf. Mais uma vez, vejo isso como algo temporário e rápido enquanto não define uma boa política de backup com arquivamento, pg_dump, etc... Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
