2 ms·
The article is definitely still true. When using Postgres in larger systems it's always a problem when the client asks "well what about redundancy?" — there is
by jwr 13y ago
The article is definitely still true. When using Postgres in larger systems it's always a problem when the client asks "well what about redundancy?" — there is no good answer to that, for reasons outlined in the article and the post above.
- pilif 13y agoThat's entirely not true. Postgres has built-in replication and you can even do synchronous replication if you want to pay for the latency - you can't have more redundancy than this. Doing the failover is trivially done using something like keepalived or heartbeat as Postgres has built-in support for quickly promoting a slave to the master. What we don't have, however is good load balancing. Also, because load balancing is f'ing hard to get right when you are in a master/slave replication configuration because it's really hard to know what queries you can safely send to the slave. After thinking quickly, here are some cases: use of nextval/currval, use of select after insert/update in a transaction, querying unlogged tables, and probably many more. A good load balancer knows about all of this.
- willvarfar 13y agoI think in spirit the post you were replying to meant load balancing?