[LUGOS] mysql replication

[Grega]

uf... sem premalo tocno obrazlozil problem...
takole je:

> A -> B -> C -> A

>This setup will only works if you only do non conflicting updates
>between the tables.  In other words, if you insert data in A and C, you
>should never insert a row in A that may have a conflicting key with a
>row insert in C

imam 2 serverja za neko web stran. eden sluzi kot backup prvemu.
Problem nastane, ker uporabniki pogosto updatajo/insertajo nove stvari v
bazo.
Ce primarni server slucajno dela, pa nek uporabnik ni mogel do njega in je
bil preusmerjen na sekundarnega (recimo da je padel peering med dvema
ponudnikoma) in tu nekaj insertal v bazo, ob istem casu pa je nek drug
uporabnik na primarnem strezniku tudi nekaj insertal v bazo, imam sedaj 2
bazi z enakimi tabelami in dvema enakima kljucema v vsaki.

sedaj pride do zapleta pri replikaciji...
kaksna ideja?


lp
Grega Lebar


----- Original Message -----
From: "Jure Pecar" <pegasus at telemach.net>
To: <lugos-list at lugos.si>
Sent: Friday, March 29, 2002 1:20 AM
Subject: Re: [LUGOS] mysql replication


> On Fri, 29 Mar 2002 01:05:35 +0100
> "Grega" <grega at britva.eu.org> wrote:
>
> > zivjo!
> >
> > zanima me, ce ima kdo reseno bi-directional mysql replikacijo. se
> > pravi, da dva serverja eden drugega updatata.
>
> hm? nazadnje ko sem gledal bi to moralo delovati v zadnjih verzijah
> 3.23.4x in v 4.0.
>
> iz mysql manuala, 4.10.4:
>
> Starting in Version 3.23.26, it is safe to connect servers in a circular
> master-slave relationship with log- slave-updates enabled.
> Note, however, that many queries will not work right in this kind of
> setup unless your client code is written to take care of the potential
> problems that can happen from updates that occur in different sequence
> on different servers.
>
> This means that you can do a setup like the following:
>
> A -> B -> C -> A
>
> This setup will only works if you only do non conflicting updates
> between the tables.  In other words, if you insert data in A and C, you
> should never insert a row in A that may have a conflicting key with a
> row insert in C.  You should also not update the sam rows on two servers
> if the order in which the updates are applied matters.
>
> Note that the log format has changed in Version 3.23.26 so that
> pre- 3.23.26 slaves will not be able to read it.
>
> --
>
>
> Pegasus
>
>
> Unfortunatly, SMTP email is anything but a small set of problems.  Quite
> the opposite: it's a tarpit of bureaucratic standards committees,
> arrogant implementors, impatient administrators and whiny end-users.