Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You've got the wrong end of the stick here a bit. Postgres has had a "warm standby" system since version 8.1 which you can use to keep a second server in recovery mode waiting to go live. So as far as HA goes, that's pretty good - we use it at Last.fm and it works well for us.

What's lacking is a decent way of setting up read-only slaves like you can with MySQL. That was what was promised with 8.4 and that's what's annoying.

At Last.fm we have a large, frequently-changing DB schema which is impractical to replicate in its entirety using the existing Postgres replication mechanisms (Slony, Londiste, etc).

The annoying thing is that it appears they backed these changes out of 8.4 because of issues with the synchronous part of the replication patch (which we don't care about).

Oh well.



Just to clarify, hot standby wasn't backed out, because the changes were never "in". There was a working patch set against the 8.4 tree (which you could still get today) for hot standby, and the testing/review of that code ran into enough corner cases that the reviewers thought it was best to push it. While many of the same people are involved in the synchronous replication piece, the issues in that code didn't really play a part (it had pretty much been decided at least month ago that synchronous replication wouldn't make it)


So, what do you guys do then?

I imagine Last.fm is not running on one gigantic postgres db, are you using db partitioning or something similar?


Most of our hardcore data is in non-relational sources (including Hadoop).

Our global DB is Postgres - that holds everything which we haven't had a reason to move off it - it's a pair of Sun boxes with 128GB of RAM using Postgres warm standby (in this case the hardware is a lot cheaper than trying to shard it).

And we also have a ton of other MySQL and Postgres databases running other services.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: