Em sex, 21 de out de 2016 às 14:25, Cleiton Luiz Domazak < [email protected]> escreveu:
> 2016-10-20 16:21 GMT-02:00 Fabrízio de Royes Mello < > [email protected]>: > > On 19-10-2016 16:44, Cleiton Luiz Domazak wrote: > > Boa tarde pessoal. > > > > Estou montando um projeto de PITR e estou utilizando o pg_rman. Como são > > vários servers e não queremos manter um servidor só para rodar o Barman, > > parti para WAL-e e pg_rman, e nos meus testes, para o nosso caso o > > pg_rman se mostrou ser a melhor opção, porém com a limitação de não ter > > suporte nativo para envio ao S3 da Amazon. > > > > Alguém utiliza o pg_rman ou até mesmo o Barman enviando para S3? Como > > que está configurado o upload e download dos backups e wals? > > > > O que estamos pensando em utilizar é algo como s3fs e mapear um bucket, > > assim enviando direto para o S3, mas me preocupa a questão de latência, > > quedas do s3fs, que já tive casos, e acabar perdendo o envio de algum > > archive. Não seria o caso então de usar um disco de "stage", onde de > > tempos em tempos roda um rsync com o s3fs? Queria saber das pessoas que > > já tiveram alguma experiência com um cenário parecido. > > > > Não tenho 100% de certeza mas acho que o wal-e [1] trata disso pra vc. > > Nos servidores na Amazon, tenho usado só o wal-e, com retenção configurada direto no bucket S3. Mesmo com os servidores fazendo muita escrita, o que gera muito wal, o wal-e tem dado conta sem acumular demais os arquivos. Se isso acontecer, você pode também otimizar o bucket para upload, em alguns casos chega a dobrar a velocidade. > De qualquer forma, como vc mesmo mencionou, é recomendado vc ter um > "staging" local para archive e depois subir pro s3 ou para outro storage > externo. > > Eu não vejo qual a vantagem de fazer isso. O PostgreSQL lida muito bem com os archives falhados, tudo o que é necessário é ter um espaço suficiente para esses casos. Ter uma área de staging nada mais é do que ter... espaço em disco extra. E um controle extra do envio, o que o PostgreSQL já faz bem. Talvez o Fabrízio tenha outra coisa em mente que não pesquei. > > Tenho utilizado o pgBackRest [2] e pra subir pro s3 usamos o s3fs+rsync > (vc tb já mencionou). > > O problema do s3fs é que ele é montado com fuse, em espaço de usuário, aí você precisa monitorar mais uma coisa se o sistema de arquivos morrer. Quando se faz rsync para o S3 (seja rsync comum num s3fs ou seja usando a funcionalidade sync do comando 'aws s3' do awstools, cada verificação de metadados consome banda - e isso a Amazon cobra *sem dó*. Fica minha recomendação - wal-e e ponto. Mas tem mais gente na lista com outras ideias :) Uma alternativa pra quem precisa compartilhar entre vários servidores sem passar pelo S3 é usar o novo "nfs gerenciado" que a Amazon acabou de lançar. Eles têm empurrado bastante esse cara pra certos casos de uso. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
