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 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: http://lists.mysql.com/replication
>> To unsubscribe:
>> http://lists.mysql.com/replication?unsub=1
>>
>>
--
Rick James - MySQL Geek
