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