Re: Postgres replication: dump/restore, PITR, Slony,...?

All right, so I misspelled Bucardo (also Mammoth...), and the company's name
is Command Prompt (please get someone to work on that incomprehensible logo
- I went back and looked at it and still have no clue what it means :-).

Now how about some serious answers relating to my questions?

Dimitri, thanks for your answer. I don't need to replicate TO the staging
server (this is where the changes happen) but rather FROM the staging server
TO the Web (query) servers. I think my description wasn't clear enough.
Currently the staging DB changes daily as new records are inserted to it
(would have liked to use COPY instead, but I believe that's only useful for
bulk loading the whole DB, not appending to it?). Those changes need to be
reflected on the Web servers. Today this is done via dump-copy files-restore
of the whole DB (we shut down each Web server DB while restoring it,
obviously), and I we are looking for a better way.

I would truly appreciate specific suggestions and pointers/references ("some
trigger based asynchronous replication" doesn't help much...).

Also is my understanding of PITR limitations correct?

Thanks,

-- Shaul

On Thu, Jun 11, 2009 at 7:32 PM, Joshua D. Drake <jd(at)commandprompt(dot)com>wrote:

> On Thu, 2009-06-11 at 16:30 +0000, Greg Sabino Mullane wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: RIPEMD160
> >
> > >> Then there are Slony-I, Buchardo, Mamoth Replicator from CMO, simple
> > >> replication in Postgres 8.4 and other projects...
> >
> > > CMO? :)
> >
> > Buchardo? :)
>
> A new desert, Buchardo CMO:
>
> Two shots of brandy
> One shot of rum
> Vanilla Ice cream
> Cherries
>
> Blend to perfection.
>
> Joshua D. Drake
>