Re: Replication - state of the art?

You could also use WAL shipping and some PITR trickery to keep a 'warm
standby' database up to date. How far behind it falls is up to you,
since you'll be periodically syncing the current WAL file to the backup
machine. Do the sync once a minute, and at most you lose 60 seconds of
data.

On Wed, Mar 01, 2006 at 02:49:18PM -0500, Andrew Sullivan wrote:
> On Wed, Mar 01, 2006 at 11:28:06AM -0800, Bryce Nesbitt wrote:
> > Actually let me loosen that a bit: we don't need two phase commit. We
> > can loose the most recent transaction, or even the last few seconds of
> > transactions. What we can't survive is -- on the day of the emergency
> > -- a long and complicated DB rebuild with mistakes and hard-to-debug
> > data issues.
>
> Then I suggest you use Slony-I. While it is not plug and play, the
> thing it _is_ designed to handle reasonably well is failover and
> (better) switchover. Most systems plan to solve that piece of
> functionality later, with a script or something, at which point it is
> apparent that setting up failover or swichover to be anything
> approaching safe is actually very tricky. (Log shipping is probably
> not in this category, but AFAIK the promote-to-live support for a
> standby database copy is still not all built by anyone. If you like
> rolling your own, however, it might be your answer.)
>
> > There's no fire creating demand for replication, so there is little time
> > budget.
> > So is there a sort of padded, no-sharp-corners, playroom that gets us
> > 90% of the way there?
>
> The "no budget" remark here is what makes me strike CMD's Mammoth
> Replicator off the list. But I'm sure their administration tools are
> far sweeter than the admittedly hackish ones that Slony currently
> delivers out of the box.
>
> > nightly) into something more reasonable (like 500 milliseconds). But
> > risk -- of data corruption --
> > and time --too much-- will can the project.
>
> Another big reason to use a live-standby system like Slony is that
> once you have the extra database online, you suddenly think of all
> sorts of nifty queries you can move there without destroying your
> production performance. Be careful not to get addicted, is all.
>
> A
>
> --
> Andrew Sullivan | ajs(at)crankycanuck(dot)ca
> Information security isn't a technological problem. It's an economics
> problem.
> --Bruce Schneier
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461