2016-10-21 11:11 GMT-02:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
> > > Em sex, 21 de out de 2016 às 14:25, Cleiton Luiz Domazak < > cleitondoma...@gmail.com> escreveu: > >> 2016-10-20 16:21 GMT-02:00 Fabrízio de Royes Mello < >> fabri...@timbira.com.br>: >> >> 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. > Pena que ainda não tem no Brasil, senão seria realmente muito mais fácil. > > []s > Flavio Gurgel > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
