On 21-10-2016 11:11, Flavio Henrique Araque Gurgel wrote: > > > Em sex, 21 de out de 2016 às 14:25, Cleiton Luiz Domazak > <[email protected] <mailto:[email protected]>> escreveu: > > 2016-10-20 16:21 GMT-02:00 Fabrízio de Royes Mello > <[email protected] <mailto:[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. >
Bom saber disso... eu realmente não usei ele ainda em produção... > 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. > Realmente o PostgreSQL lida muito bem com essa questão de falha de arquivamento... pode ser preciosismo da minha parte mas tenho muito receio de colocar, por exemplo o s3cmd, direto no "archive_command" e por algum motivo ele retornar pro PostgreSQL Ok mas isso não ser verdade ... ou mesmo por algum motivo um segmento ficar corrompido por lá. Na verdade meu conhecimento de AWS é bem restrito então posso estar com receio de algo que nem é tão comum assim. > 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ó*. > Bom, esse detalhe eu realmente desconhecia ... obrigado pela dica! > Fica minha recomendação - wal-e e ponto. Mas tem mais gente na lista com > outras ideias :) > Confio no seu julgamento, então partiu testar ele então... > 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. > Interessante... também irei verificar... Valeu pelas dicas Flávio. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
