[nycbug-talk] mysql replication and failover

[Massimiliano Stucchi]

On 270506, 14:33, David Rio Deiros wrote:
> On Thu, May 25, 2006 at 11:20:31PM +0200, Massimiliano Stucchi wrote:
> > On 250506, 11:39, David Rio Deiros wrote:
> > > 
> > > What do you guys think? Is MySQL clustering the only valid solution
> > > here?
> > 
> > Not really.  There is this new method, available only with MySQL 5.1,
> > which enables you to have master/master replication.
> > 
> > http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
> > 
> > It'a nice feature.
> 
> Thanks for the reply Massimiliano and sorry for the late reply.

No problem.

> Finally I decided to implement a solution based on replication only. The
> reason is because the database is going to server reads most of the 
> time.

I see.

> The article you sent is very interesting but there is something that 
> still don't understand. When you use the autoincrement feature found
> in mysql5, you're solving a problem but you are also introducing another
> one since the ids are totally different between servers. That means
> you have to make the application aware about it. 

You have to make applications aware of multiple databases they can
read/write to, but there's no compatibility problem for what concerns
id's.

ID's are unique accross machines.  What you introduce is some type of
randomization, in order no to have situations where a write is done at
the same exact time on two different machines, replication is
interrupted whoknowswhy, and you end up having two different tuples with
the same id but different data.  I've experienced this problem back in
the 3.23.x days with a master/master-like implementation which lacked
this sort of mechanisms.

Ciao !
-- 

Massimiliano Stucchi, CTO & Director of Operations
WillyStudios.com - IT Consulting, Web and VoIP Services
stucchi at willystudios.com | Tel (+39) 0244417203 | Fax (+39) 0244417204
IT-20040, Carnate (Milano), via Carducci 9
								
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20060529/80963a61/attachment.bin>