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 <m...@webwizarddesign.com>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=n...@dinagon.com > >
