On Tue, Jun 10, 2008 at 12:11:51PM -0700, Howard Chu wrote:
Another alternative, if you will never change the number of servers involved, is to do away with the central idblock entry and just allocate every-other-Nth ID. E.g., with 3 servers, server1 will allocate 0, 3, 6, 9 ... server2 will allocate 1,4,7,10,... server3 will allocate 2,5,8,11...
That guarantees there will never be conflicts, unless you decide to change the number of masters.
As UIDs and GIDs are 32-bit numbers these days they are effectively inexhaustable in most environments. Setting N in your example above to a large number would not be a problem. Thus your 3-server case might choose N=100, giving server1 0,100,200,300,400 and server2 1,101,201,301 etc. The 3-server setup could then safely grow as far as you need.
Doing purely random allocation from a 32-bit number space followed by a sanity check and uniqueness check is likely to be just as safe in practice and has no configuration overhead. Your random numbers must be good though: not crypto-quality, but good enough that the chance of two servers starting at the same number is effectively zero.
(OK, the birthday paradox is not to be trifled with for large N but the randomness only has to be good enough to avoid a clash during the longest feasible replication delay)
Some people have an aesthetic objection to the random allocation system ("Why are the numbers so *big*? We dont need that...") so I still usually use the unique sequential allocation scheme: Perl implementation attached.
Andrew