Em 02-10-2012 17:09, Matheus de Oliveira escreveu: > Tenho PostgreSQL 9.1.6 instalado no ubuntu com archive_mode > habilitado. No parâmetro archive_command estou fazendo um rsync -a > dos logs para o destino escolhido. > > > Eu não vejo muita vantagem no rsync dentro archive_command, já que ele > só arquiva quando terminar de "preencher" o log.
Qual o problema de usar rsync? Ele é ótimo para transferência entre máquinas! E ele se diferencia do scp, por exemplo, pois um daemon rsync aparece na máquina remota. Qualquer comando pode ser utilizado no archive_command: scp, rsync, cp, copy (argh!), ftp, mail, , um script seu, etc, etc, etc, etc... O único cuidado é: retorne 0 se deu certo, qualquer outro valor se não deu certo. O rsync preenche esse requisito. > Tenho essa dúvida pois estou receoso, como postgresql recicla os > arquivos de log e como estou utilizando rsync, tenho medo de perder > algum arquivo de log. > > > Não vejo porque, a não ser por causa de algum erro de hardware, pois se > a cópia (rsync, cp, tar, etc.) apresentar erro - retornar algo diferente > de zero - o PostgreSQL tenta realizar (executar o archive_command) > novamente. Tenta de novo e *guarda o segmento* até que o comando retorne 0. Isso, inclusive, é causa de falha de servidor mestre: o archive_command vai falhando, os segmentos vão se acumulando e a partição onde está o pg_xlog acaba enchendo. Recomendo sempre monitorar a comunicação entre as máquinas quando se usa comando remoto para guarda do archive, pois se houver falha de envio por muito tempo o servidor principal *vai* falhar por falta de espaço em disco. Já aconteceu comigo mais de uma vez. > Esse meu receio é real? Existe alguma solução mais confiável de > manter um backup dos logs de transações após o archive_command? > > > Como disse, acho que não. Mas tem soluções de alta disponibilidade que > vão deixar um "backup" mais tempo real. Se você está falando de replicação, alta disponibilidade, isso *NÃO* (em maiúsculas e negrito mesmo), repito, não é backup. Mesmo que você tenha replicação, tenha seu backup. Se houver uma falha lógica no servidor mestre (um DROP TABLE no lugar errado, por exemplo) a replicação *não* permite voltar no tempo pois ela vai aplicar isso o mais rápido que puder. Já o backup em estratégia PITR permite isso. > Outra coisa, não se esqueça de executar um backup base periodicamente > (nesse caso o rsync é ótimo). O tempo entre backups de base deve ser dimensionado de acordo com o tempo que pretende ter para a restauração. Todo backup deve ter testes de restauração pra garantir que é recuperável e em quanto tempo é recuperável. E lembre-se de fazer um pg_dump de tempos em tempos também. Só ele garante que os dados lógicos estão todos íntegros, o backup físico leva os erros junto e você não vê. []s __________________________________ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos & Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: [email protected] ______________________________ FREE SOFTWARE SOLUTIONS _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
