List:Replication« Previous MessageNext Message »
From:Rick James Date:September 13 2010 9:01pm
Subject:Re: Unique ID's across multiple databases
View as plain text  
  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 

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 Schubert<maxs@stripped>wrote:
>> 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:
>> To unsubscribe:

Rick James - MySQL Geek

Unique ID's across multiple databasesKiss D├íniel12 Sep
  • Re: Unique ID's across multiple databasesMarcus Bointon12 Sep
    • Re: Unique ID's across multiple databasesMax Schubert12 Sep
  • RE: Unique ID's across multiple databasesJerry Schwartz13 Sep