From: Johan De Meersman Date: September 13 2010 11:26am Subject: Re: Unique ID's across multiple databases List-Archive: http://lists.mysql.com/mysql/222963 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=005045013c64e316d00490225ec0 --005045013c64e316d00490225ec0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=E1niel wrote: > This is actually more for failover scenarios where databases are spread i= n > 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 >wrote: > > > > > > > On Sun, Sep 12, 2010 at 9:45 PM, Kiss D=E1niel 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 > > > --=20 Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel --005045013c64e316d00490225ec0--