Re: Replication and PITR

On Tue, Sep 26, 2006 at 08:21:44AM +0200, Bo Lorentsen wrote:
> seems like they have some kind of statement queue (no trigger setup) and
> a transfer protocol all integrated in the server, and that makes it
> "simpel". There is no understanding regarding transactions, as far as I
> have seen.

Note that, the last time I looked at it, there was no interlock to
ensure that your statement queue (which is basically just a log of
statements as executed on the "master") was not accidentally blown
away by your cleanup process before your target replicas were up to
date. This might have improved recently, but when I looked at it
MySQL's async replication was high on the "ease of use" and low on
the "works in sticky situations". As I say, they may have fixed it;
but I advise people to look very carefully at how it works before
deciding it is adequate.

The important thing to remember about database replicas is that
you're _already_ planning for the small percentage of cases where
things break. Therefore, an 80/20 solution is not good enough: the
thing has to work when most things have broken, or it's no use to
you.

> That makes sense ... then the only thing to worry about is where these
> "baches" are written. On the same disk as the master database or on the
> client side, or will it be advisable to use a NFS mount between these to
> machines to balance the disk writing ?

No. I suggest you have a look at the docs, and take these questions
to the (again functioning) Slony list, where people can advise about
that.

The short answer is that the things to write are stored in the origin
for the table (don't think of it as a database replica, because you
can have different tables originating in different nodes). You can
_also_ write sets out to disk, if you like. Someone (my colleagues,
in fact) appear to have a nasty bug in that functionality that they
can't nail down; nobody else has reproduced it.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris