2016-10-22 18:39 GMT-02:00 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
> > > Em sex, 21 de out de 2016 às 20:38, Cleiton Luiz Domazak < > cleitondoma...@gmail.com> escreveu: > >> 2016-10-21 15:54 GMT-02:00 Fabrízio de Royes Mello < >> fabri...@timbira.com.br>: >> >> >> >> > 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á. >> >> > Quando usamos o wal-e não usamos o s3cmd, é o próprio wal-e que vai no > archive_command > Ele faz uma compressão com lzop antes de enviar o segmento. > Todas as ferramentas que enviam dados pra S3 usam a biblioteca boto. Os > arquivos são divididos em pedaços de 8kiB (por omissão) e é feito check md5 > do envio. Pode ficar tranquilo, se essas ferramentas retornam zero, o > arquivo foi enviado e checado. > > Aliás, não recomendo usar o s3cmd em lugar algum. Prefira sempre aws > tools. É muuuuuuuito mais rápido (tipo 10x num último upload massivo que > tive de fazer) e foi escrito pela equipe da própria Amazon. O pessoal que > escreve o s3cmd, sei lá porque, tem tanta confusão com versões, o que cai > nos repositórios das distros sempre é super velho, o site oficial não > explica direito qual versão usar, se você baixar do github às vezes o build > tá quebrado ou alguma biblioteca você vai ter que atualizar com o pip, > enfim, dependency hell com version hell. > > > >> >> Na verdade meu conhecimento de AWS é bem restrito então posso estar com >> receio de algo que nem é tão comum assim. >> >> > O wal-e só me deixou na mão uma vez e a correção foi simples - tinha um > bug que ele ignorava diretório vazio na hora do backup. Aí, fui promover um > servidor a mestre e o PostgreSQL morria porque não tinha o diretório > pg_clog. Nem preciso dizer que era só criar que o problema se resolveu. > Enfim, eu gosto da ferramenta, movimento servidores para todos os lados (no > mundo do cloud em pouco mais de 2 anos fiz mais promoção para mestre do que > toda a minha vida de DBA), tirando o bug acima (que já foi corrigido) nada > mais me deixou na mão. > > >> > 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! >> >> > Cada pedido de stat de arquivo no S3 é cobrado. Imagina quantos faz um > simples rsync de uma centena de arquivos, a conta é exponencial. > > >> > 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... >> >> > Um outro colega me lembrou aqui, infelizmente não está disponível ainda na > região South America. Nas regiões US e EU já tem. Veja onde estão seus > servidores. > > >> >> Valeu pelas dicas Flávio. >> >> > Sempre um prazer. > Muito obrigado a todos que contribuíram, foi esclarecedor em vários pontos, e me fez a optar pelo WAL-e, que já era o plano A, mas ao decorrer dos testes outras ferramentas surgiram e por isso levantei esses itens. > > []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
