PostgreSQL 9.0 Is Now Available

It's hard because of the consistency guarantees that PostgreSQL makes. If you need true multi-master replication (you probably don't) the best solution is to use some form of queue to manage writes across the cluster. The DRBD solutions sound awesome but trade one SPOF for another, and have drawbacks in terms of speed (replicating block devices makes them slow) and risk (network latency, write contention) and are limited to at most two masters.

If you find yourself needing a replication solution beyond hot standby; it's possible that PostgreSQL isn't the right tool for the job.

pgpool-II seems to be well maintained and simple. I'm not sure what you wish for, but pgpool-II seems to be it.

I think MySQL's swappable storage engines make building replication a tad easier. Actually, I have no idea.

NDB cluster is not something I'd recommend to anyone. At least it wasn't 2 years ago. I got random failures that only people at #mysql-ndb on freenode could explain, very cryptic log files, weird configuration bugs reproduced by tens of people and not fixed for years, etc.

It's even harder to maintain than multi-master. You know what can fail in multi-master and how to check it - 99% of cases is just one of the nodes stopping accepting the replication stream for some reason. You can check that easily, because you see secs_behind > 0 on the slave status - everything else ends up in the error log.

With NDB, the situation is much harder. You've got 3 types of nodes that can fail, you don't easily see if one of them failed (I had situations where every node was "connected", both data nodes were "live", but the manager (or was it frontend...) decided they're out of sync and cannot deal with them at all). Effectively you've got a network of independent nodes which can fail and not output any error - it's another node that shows you only the effect of such failure. I could not find any way to reliably monitor the cluster status and there are not nearly enough information on the web to solve the problems on your own. #mysql-ndb is great, but the people there can give you a patch to your database "to try if it fixes the problem" - problem that cannot be easily reproduced and causes the DB to stop working under a high load in the middle of the day - exactly when I need to DB to stay up.

Multi-master was a lot less painful.

Bucardo provides multi-master replication for PostgreSQL http://bucardo.org/ and is actively maintained, albiet written in Perl.

The reason most replication systems sit outside of PostgreSQL are there are many different use cases for replication and no one method is going to get it right enough to complicate the core code. There are efforts underway to create a common structure to base replication on so that projects like Bucardo, Slony and Londiste can more easily and reliably plug into the core database engine for replication.

Wow, thanks for all the replies. What I'm primarily interested in is eliminating single points of failure. So a number of web servers can bounce between any of the (geographically separated) database servers for read and write queries. I'm wondering if this is possible in a clean way with some general solution or if application code has to support partitioning of data to make this work.

Good call. I skipped over that, but you're right: it will come in very handy (for example, my local development DB).

Word.

Really? You capitalize excel and access in every day use?

I'm not the OP, and I don't follow phoronix regularly, but it seems sensationalist at times.

No.. Unfortunately, they don't.