Em 2 de outubro de 2012 17:20, Flavio Henrique Araque Gurgel < [email protected]> escreveu:
> > 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. > Com isso pode ocorrer um certo atraso na escrita em disco? > > 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. > É justamente isso que pretendo fazer (PITR), mas fiquei com dúvidas em relação a cópia dos logs. Minha estratégia é a seguinte: 1 - fazer o backup base periodicamente e gravar em fita; 2 - através do archive_command colocar os logs em um dirétorio no próprio servidor para não depender de rede; 3 - gravar em fita o conteúdo do diretório das cópias dos logs; 4 - excluir os arquivos dos diretórios de cópia (backup base e logs) de 3 dias para trás; Minha intenção com isso é poder voltar no tempo, já que a empresa passará por auditorias e poderá ser solicitado o estado da base de dados em determinado dia e hora. > > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
