From: Rick James Date: September 13 2010 9:01pm Subject: Re: Unique ID's across multiple databases List-Archive: http://lists.mysql.com/replication/1958 Message-Id: <4C8E912D.4080203@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit If you have 200 Masters in circular replication, and you lose one, on average twice a week, what is your plan for automatically repairing the ring?? If the machines are in Customer sites, what control do you have over getting them alive after an outage? I forsee week-long outages downstream of a lazy customer! Bottom line: Don't do it. On 9/12/10 12:45 PM, Kiss Dániel wrote: > You may be right. I'm not arguing that offset + increment is working. > > I'm just wondering if that's the optimal solution when you do not know how > many servers you will have in your array in the future. In my view, the > 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 > increment value. It just doesn't scale well enough to me. > If you go with BIGINT ID's, you may have a big enough interval to be > generous and pick a big increment value and allow 200 or even 2000 to make > sure you cover worst case scenarios. I'm just not sure if it's worth it to > use up 8 bytes for a primary key, when in general 4/5/6 is more than enough. > > Any thoughts on this? > > On Sun, Sep 12, 2010 at 9:32 PM, Max Schubertwrote: > >> Server offset + increment works really well, is simple, and well >> documented and reliable - not sure why you would want to re-invent >> something that works so well :). >> >> -- >> MySQL Replication Mailing List >> For list archives: http://lists.mysql.com/replication >> To unsubscribe: >> http://lists.mysql.com/replication?unsub=niel@stripped >> >> -- Rick James - MySQL Geek