3 ms·

For those of you running postgresql with some kind of multi-server setup, how do you do load balancing and replication right now? I'm running pgpool-ii but jus

For those of you running postgresql with some kind of multi-server setup, how do you do load balancing and replication right now? I'm running pgpool-ii but just tonight noticed some pretty serious discrepancies between the two backend postgresql instances so I am getting rid of pgpool for the time being. Will this change make pgpool-ii obsolete?

kingkilr 17y ago
I'm not an expert, but PgPool also servers as a local connection pooler, so for those purposes it won't be obsoleted.
- neilc 17y ago
  I'd personally recommend pgbouncer as a connection pooler rather than pgpool. https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer
  - russss 17y ago
    I second that, I did a comparison a few years ago and pgbouncer blew pgpool away: http://www.last.fm/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer http://www.last.fm/user/Russ/journal/2008/02/21/zd_postgres_...
    - yesimahuman 17y ago
      Thanks guys.
rosser 17y ago
The last place I worked used F5s for load balancing and Bucardo for replication. The F5s worked well enough, and I've become a huge fan of Bucardo. It has capabilities that I think blow Slony away. (Custom code, and pre-warmed slaves are two of the biggest differentiators.) The new job is doing something that could best be described as very primitive sharding (completely unnecessary, given the demonstrated loads compared to the levels of concurrency PostgreSQL can support with minimal tuning), without replication. I'm eliminating the former, and will eventually be adding some HA capabilities, and probably also bringing Bucardo in. I don't think SR is going to obsolete a connection pool any time soon -- you still need to direct traffic appropriately between master and slave(s). I've never used it, but I've consistently heard good things about pgBoucner as a connection pooler.
bdr 17y ago
slony worked well enough at my last job
emmett 17y ago
We use londiste (from SkyTools). It's excellent. From what I've read, londiste already plans to start offering streaming replication (vs. trigger-based replication) for the transport mechanism.

kingkilr 17y ago

I'm not an expert, but PgPool also servers as a local connection pooler, so for those purposes it won't be obsoleted.

neilc 17y ago
I'd personally recommend pgbouncer as a connection pooler rather than pgpool. https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer
- russss 17y ago
  I second that, I did a comparison a few years ago and pgbouncer blew pgpool away: http://www.last.fm/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer http://www.last.fm/user/Russ/journal/2008/02/21/zd_postgres_...
  - yesimahuman 17y ago
    Thanks guys.

rosser 17y ago

The last place I worked used F5s for load balancing and Bucardo for replication. The F5s worked well enough, and I've become a huge fan of Bucardo. It has capabilities that I think blow Slony away. (Custom code, and pre-warmed slaves are two of the biggest differentiators.) The new job is doing something that could best be described as very primitive sharding (completely unnecessary, given the demonstrated loads compared to the levels of concurrency PostgreSQL can support with minimal tuning), without replication. I'm eliminating the former, and will eventually be adding some HA capabilities, and probably also bringing Bucardo in. I don't think SR is going to obsolete a connection pool any time soon -- you still need to direct traffic appropriately between master and slave(s). I've never used it, but I've consistently heard good things about pgBoucner as a connection pooler.

bdr 17y ago

slony worked well enough at my last job

emmett 17y ago

We use londiste (from SkyTools). It's excellent. From what I've read, londiste already plans to start offering streaming replication (vs. trigger-based replication) for the transport mechanism.