directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [replication] Master slave replication will not suffice
Date Thu, 24 Feb 2005 06:51:43 GMT

Alex Karasulu wrote:

> Alan D. Cabrera wrote:
>> Alex Karasulu wrote:
>>> I was thinking about replication earlier today.  I was hoping we can 
>>> quickly implement master slave replication by piggy backing on a JMS 
>>> implementation like ActiveMQ.  It quickly occured to me however that 
>>> there is no way we can utilize a master slave rep. configuration 
>>> without loosing all the benefits of having embedded services like 
>>> Kerberos, DNS, DHCP etc.
>>> The reasoning behind this has to do with the way master-slave rep. 
>>> works.  Basically there is one master and all other servers are 
>>> slaves a.k.a. replicas.  A request to modify a replica returns an 
>>> error indicating the replica is not writable along with a referral 
>>> to the master.  I forget the exact LDAP result code returned.  The 
>>> client would then contact the master for the alteration what ever it 
>>> may be.  The master makes the change and propagates it to the 
>>> replicas usually using a special replication user that bypasses 
>>> certain checks.
>>> Here's the problem: with a master slave setup an embedded inet 
>>> service like Kerberos will have to contact the master of the system 
>>> to make alterations on all replicas for any alterations to the DIT!  
>>> This defeats the entire purpose of embedding the service in the 
>>> first place and limits the HA yeild from replication.
>>> So what we need is multimaster replication.  This is an order of 
>>> magnitude more complex than master slave replication. 
>> Once you have replication what's the point in embedding?
> No network latency between say,
> DNS and LDAP or
> Kerberos and LDAP or
> DHCP and LDAP ...
> Also the there is less entropy to the system.  It also means that 
> there are not as many exposed points for attack from a security 
> standpoint.  Intra process communication is more secure and faster 
> than two separate inter process servers talking to each other.
> Does this make sense or am I missing something here?  I'm begining to 
> doubt myself because you're like the 3rd person to think there was a 
> flaw with this reasoning.

Your motivation is admirable but, you cannot eat your cake and have it 
too.  :)  You propose to have intra-process servers that share state w/ 
external processes, processes that are hopefully on different boxes and, 
for many deployments, in separate buildings most likely in different 

The embedded server is great but keep it a single server; at least use a 
logger to make changes durable.  I think it would be great if the ADS 
servers supported *both* embedded servers and clustered resilient servers.


View raw message