[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: automatic uidnumber overlay

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.

|                 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