Em sex, 21 de out de 2016 às 20:38, Cleiton Luiz Domazak < [email protected]> escreveu:
> 2016-10-21 15:54 GMT-02:00 Fabrízio de Royes Mello < > [email protected]>: > > > > > 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. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
