Em 23 de agosto de 2013 17:24, Danilo Silva <[email protected]>escreveu:
> > > > Em 23 de agosto de 2013 16:11, Matheus de Oliveira < > [email protected]> escreveu: > > >> >> 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... >> >> Era isso que eu precisava saber, vou testar e depois falo como foi. > > []s > Danilo > > Pessoal deu certo a dica do Matheus, agora surgiu outra dúvida: Preciso montar um script que execute o backup base, até então beleza, sem problemas, existe a possibilidade de colocar no script algum comando que altere a diretiva archive_command ou algo similar? []s Danilo
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
