Se o colega tem uma aplicação Web escrita em Java, provavelmente ela
roda dentro de um Tomcat ou outro servidor de aplicações similar.
Nesses casos, cuidado com o PgBouncer: o driver JDBC usa em muitos casos
prepared statements que *não* são compatíveis com o modo transaction do
PgBouncer, somente o modo connection. Dá pra configurar do lado do JDBC
todavia.
Vc quis dizer o modo do pool "session"... para manter 100% de
Agradeço a precisão :)
Nesses casos, também, normalmente o servidor de aplicações já possui um
pool de conexões que pode ser facilmente configurado, com a vantagem de
reportar suas atividades para as threads que pedem por conexões. Quando
isso ocorre, colocar mais um pool não traz nenhuma vantagem e, pelo
contrário, pode até piorar as coisas e causar erros que você não
compreenderá.
Se bem ajustado (Ex: pool do JBoss + PGBouncer) podemos ter uma vantagem
sim, que é a possibilidade fazer manutenções com downtime mínimo, e
nestas inclusive atualização de binários (ontem saiu 9.4.5, 9.3.10,
9.2.14, 9.1.19 e 9.0.23).
Certamente. Nesse caso o que já fiz foi manter o PgBouncer em 1:1 e modo
session.
Como no pgbouncer conseguimos criar aqueles "virtual databases"
conseguimos segmentar as aplicações dessa forma criando pools separados,
e com isso podemos fazer um "PAUSE" em um determinado pool que pertence
a uma aplicação para, por exemplo, executar um pg_repack para recriar
datafiles inchados... enfim, é apenas um caso de uso.
É bastante útil mesmo.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
