Andrew Sullivan wrote:
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.
I know the MySQL scheme is not perfect, but the setup of one is
relatively easy, but you still have to know what is going on, otherwise
you are not going to get a good night sleep :-)
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.
I agree, and that is why you have to be very careful about your choice :-)
Well the nice thing about using a slave DB for reporting is the focus to
keep it in sync. If it is a backup server you may ignore it for a while,
and then Murphy strikes at you :-)
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.
Thanks, I willl !
/BL
