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
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
