Re: Warm standby architecture opinions

Jeff,

> What type of warm standby would never become a temporary master? I was
> thinking to script up which db server is the master at a particular time
> using heartbeat and some things I've done in the past, then whichever is
> the master creates the WAL archives.

Well, what I'm saying is that switching masters on Slony is a couple of 2-line
commands and can be done with the servers live. To switch using PITR, you
pretty much have to shut down one server and restart the other. So it's a
question of whether you only expect to be doing this for failures, or more
frequently for various purposes (upgrades, new feature tests, etc.)

> > Such as using an advanced filesystem or storage device that allows
> > transactional instant snapshots of filesystems for archive purposes?
>
> That sounds neat and expensive! :-)

Actually, LVM2 and JFS which are both OSS support this. Of course, devices
like the NetApp support it *better* ...

> 1) If the master DB server goes down, we want to be able to bring up the
> warm standby in minutes, preferably seconds. We're running a db driven
> website which has lots of reads and writes

Slony, PITR, and shared storage will all allow this. Snapshots aren't
adequate because unless you pay $$$$ (like NetApp) you can't take them more
often than once every hour or so (they interrupt I/O).

> 2) We can afford a semi decent dual processor Dell with 6 disks in it and a
> PERC RAID controller. The warm standby is likely to be two single disks in
> another dual processor Dell. We will also have access to a Dell NAS device
> with Gb connectivity.

Dells are crap. Buy something else. You'll get 3x the performance for only
25% more money. I'm pretty fond of dual-opteron home-builds, only about
$2500. IBM sells some decent Opteron machines these days (so does Sun, but
they're two expensive, and HP's suffer from bad RAID). Or, in the 2nd tier,
both Penguin Computing and Microway have relatively good reputations.

As a comparison: I have one dot-com client running on Dell 2650s, and they
have a 3-machine Slony cluster that just keeps up with their load. I've
another client with a website about twice as busy, and they run everything
off of a single quad-Opteron home build.

> 3) It's used for reads and writes on a busy website. I would say it's a bit
> more read intensive than write intensive, but that could change. As usual
> with these things, management wants maximum uptime.

Well, I'm really seeing Slony in your future. The reason is upgrades. Slony
is the only solution that's going to allow you to upgrade to 8.1 without
taking the site down. Admittedly, it will make DDL considerably more
painful. So here's my suggestion:

1) devise a PITR or shared-storage based solution (btw, the Dell NAS is *not*
adequately redundant shared storage) for the next 6 months, while your app is
still being developed.

2) when you think the vast majority of tinkering is done, switch to a
Slony-based solution. WHo knows, maybe by that time Slony-II will be out.

--
Josh Berkus
Aglio Database Solutions
San Francisco