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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
Attachment:
uniqueUidNumber.pm
Description: Perl program