I could be way off here, but how about letting your unique id be a calculated column of the the server's MAC address concatenated with an auto-increment id column?
I hope this helps... ~~Fish~~ On Mon, Sep 13, 2010 at 7:26 AM, Johan De Meersman <vegiv...@tuxera.be>wrote: > Hmm, that's a very interesting scenario, indeed. > > One bad connection will break the chain, though, so in effect you'll be > multiplying the disconnecting rate... > > I think you'd be better of with a star topology, but MySQL unfortunately > only allows ring-types. This is gonna require some good thinking on your > part :-) > > On Mon, Sep 13, 2010 at 12:28 PM, Kiss Dániel <n...@dinagon.com> wrote: > > > This is actually more for failover scenarios where databases are spread > in > > multiple locations with unreliable internet connections. But you want to > > keep every single location working even when they are cut off from the > > other > > databases. The primary purpose is not load distribution. > > > > On Mon, Sep 13, 2010 at 12:03 PM, Johan De Meersman <vegiv...@tuxera.be > > >wrote: > > > > > > > > > > > On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel <n...@dinagon.com> wrote: > > > > > >> offset + increment thingy is good if you know in advance that you'll > > have > > >> a > > >> limited number of servers. But if you have no idea that you will have > 2, > > >> 20, > > >> or 200 servers in your array in the future, you just can't pick an > > optimal > > >> > > > > > > What benefit do you think you will reap from that many masters ? Don't > > > forget that every write still has to be done on every server, so you're > > not > > > actually distributing that load; while for reads you only need simple > > > slaves. > > > > > > > > > -- > > > Bier met grenadyn > > > Is als mosterd by den wyn > > > Sy die't drinkt, is eene kwezel > > > Hy die't drinkt, is ras een ezel > > > > > > > > > -- > Bier met grenadyn > Is als mosterd by den wyn > Sy die't drinkt, is eene kwezel > Hy die't drinkt, is ras een ezel >
