ping
Latência é relativa ao protocolo TCP/IP idependente da porta.
Valeu Gurgel,
alguem teve alguma experiencia com o serviço RDS da amazon com Postgres
e poderia compartilhar?
Você deveria abrir uma nova thread pois o assunto é outro.
Todavia, eu tenho ambientes de produção de baixa performance no RDS. Não
é que o RDS seja ruim em performance, nada disso, mas com o RDS você não
pode monitorar todos os aspectos do servidor relativos à performance.
Com o RDS você pode até fazer modificações no postgresql.conf e alocar
iops garantido no painel de controle, o que é interessante. Mas para
sistemas estremamente dependentes de desempenho, falta "algo mais" e
esse algo mais é acesso ao sistema operacional, separação de
tablespaces, tuning de kernel, e isso você não terá.
Vejos algumas vantagens interessantes no RDS como a perfeita
possibilidade de automação, deploy supersimples, você pode usar a
maioria das extensões PostgreSQL, enfim, é realmente 100% PostgreSQL.
Como "extras" eles disponibilizam duas coisas que acho bastante úteis:
replicação síncrona multizona (não é pelo protocolo PostgreSQL, eles
fazem pelo storage) o que te permite failover automático caso uma zona
AWS falhe (mas nunca passei por esse incidente com o RDS) bem como fazer
upgrade de versão (menor, tipo 9.3.1 para 9.3.2) com *zero* downtime.
Isso eu já usei e acho muito útil.
Outra coisa útil é o gerenciamento dos backups. Com alguns cliques no
painel de controle, você pode restaurar um PITR no timestamp desejado. É
uma mão na roda que tira muita carga dos ombros do DBA.
Uma *baita* desvantagem: você não consegue tirar backups binários do
RDS. pg_basebackup não poderá se conectar. A única forma de tirar seus
dados de dentro do RDS é com pg_dump.
Não, meus sistemas de maior performance *não* estão no RDS. Aqueles com
poucos dados e performance negligenciável sim.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
