7 ms·
Hot Standby in postgres is pretty damn good for replication (like you said making failover occur properly takes a little bit of effort but its not too hard). A
by bbromhead 13y ago
Hot Standby in postgres is pretty damn good for replication (like you said making failover occur properly takes a little bit of effort but its not too hard).
Also pgpool2 helps a lot with partitioning and parallel queries.
For a relational db, postgres does a pretty good job at distribution and fault tolerance.
- drdaeman 13y agoPostgres won't let you perform any sufficiently long (read-only) queries on slaves. For example, I was unable to run pg_dumpall on a slave to have DB snapshots. This is [well-explained](http://www.postgresql.org/message-id/201102272005.00234.jens@wilke.org http://www.postgresql.org/message-id/201102272005.00234.jens...), but still inconvenient. This way, slaves are only useful for failover and possibly offloading very short read-only transactions, which is pretty limited.
- joevandyk 13y agoThis used to be the case, but it's not anymore. You can run long-living queries, run pg_dump, etc on slaves.
- moe 13y agoDo you have a reference in which pg version this got fixed? We still pg_xlog_replay_pause() our slaves, it would be nice to drop that.
- bbromhead 13y agohttp://www.postgresql.org/docs/9.2/static/runtime-config-replication.html#GUC-MAX-STANDBY-ARCHIVE-DELAY http://www.postgresql.org/docs/9.2/static/runtime-config-rep...
- drdaeman 13y agoAh, that's really good news to hear. Seems it's time to upgrade. :) Could you, please, provide a reference to a documentation or a changelog? Maybe I'm looking for a wrong keywords, but I can't find any mentions of such changes by myself.