2016-10-21 15:54 GMT-02:00 Fabrízio de Royes Mello <[email protected]> :
> 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... > Fabricio, estou testando o pgbackrest e me pareceu bem interessant, mas estou com um problema, mesmo utilizando o -db-include, ele faz o restore full. Fiz vários testes e em todos, além da base utilizada no parâmetro foram restauradas. Estou usando o seguinte comando pgbackrest --stanza=demo --db-include=teste2 restore > > > > 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 >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
