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
