2015-05-12 14:31 GMT-03:00 Cleiton Luiz Domazak <[email protected]>:
> Um detalhe que pode ser a causa, é que esta base tem muitos arquivos blob, > utilizando tipos OID que ficam armazenados na pg_largeobjects, e o bytea > output está setado como "ESCAPE" e não posso alterá-lo para HEX. > > Para large objects o formato do bytea_output não importa. Ainda mais, para formato binário os large objects também são salvos como binário. Já colunas bytea pode ter diferença. > A base tem uns 7GB, o dump acaba ficando com uns 1.7G compactados, já > tentei não compactar tbm e nada. > > O que percebi é que ao exportar os large objects, a taxa de transferência > cai para alguns míseros Kb. > > Minha pergunta é se existe uma forma de fazer o pg_dump funcionar bem > remotamente, ou é uma característica dele não trabalhar bem remotamente? > > Sintaxe do pg_dump > > pg_dump -h <host> -v -Fc -b -E UTF-8 -f <file> -U <user> <database> > Um problema é que se a taxa de transferência for baixa você fica com pouca opção, porque o pg_dump faz a compressão dos dados do lado do cliente, e não do lado do servidor, ou seja, você vai transmitir os 7GB (assumindo que a maior parte seja BLOBs) sempre. Uma solução comum é fazer o dump no servidor ou usar um túnel com compressão, o que não é possível com um RDS. Talvez você possa tentar uma conexão SSL com compressão e ver se ajuda na transferência. Faça também uma análise (usando o cloud watch) para ver onde está o gargalo, se está mesmo na transferência ou simplesmente na leitura dos dados do disco, se for uma instância pequena, pode ser lenta também. Me fez pensar agora, não tem backup pg_dump feito pela própria AWS né? Me parece que seria muito bom ter. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
