Re: robust OpenLDAP installation using replication in production env
From: Valentin Rottmann (ba_db2_at_gmx.net)
Date: 06/27/05
- Next message: Peter T. Breuer: "Re: Firefox autocomplete"
- Previous message: Yvan_at_office: "Re: Firefox autocomplete"
- In reply to: Walter Mautner: "Re: robust OpenLDAP installation using replication in production env"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 27 Jun 2005 12:00:38 +0200
Walter Mautner wrote:
> Valentin Rottmann wrote:
>
>
>>We are going to replace our IBM Tivoli Directory Server with a
>>replicated OpenLDAP solution on two linux hosts.
>>
>>In order to get a failsafe environment we need the replication.
>>>From our opinion the master/slave replication does not fit our
>>specification because write requests to the ldap server should
>>be possible nearly all the time.
>
>
> What do you intend to use the ldap for?
> We have around 1000 pcs in multiple locations, where the master ldap server
> is running on a solaris cluster. Single-signon and user/group management is
> the main task.
The ldap is also mainly used for user/group management. Besides, it will be used
to store timestamp information: The time when the customer logs in, logs out ...
>
>>The slave does not allow write requests in master/slave replication.
>>
>
> Actually they are redirected to the master. It's the same as with nt4 domain
> pdc/bdc combination.
That doesnt help in the case the master is not available.
>
>
>>ACID transaction are not strictly demanded. Data loss to a certain extent
>>is acceptable.
>>
>
> To _what_ certain extent? And, how much time to invest in debugging? The
> "certain amount" of only one byte lost can be a total show-off.
>
The timestamp information is not crucial. But to take out this
information from the ldap is not possible due to several reasons:
costs, change requests to the vendor, ...
In contrast to that we have among others the creation of new customer accounts. These changes
are important. Therefore, this approach seems not to be safe.
>
>>At the moment, the articles in the usenet and the documentation show me
>>two basic approaches:
>>
>>1. a modificated master/slave replication:
>>Does a slave recognize that the master is unreachable, the slave will be
>>restarted with a modified configuration in order to become the master.
>
>
> What if only the dsl line in between got interrupted for a while just long
> enough to trigger the automatic failover, while at the main office a bunch
> of new users has been inserted from SAP?
All LDAP machines are in the company lan.
>
>
>>Does the master recover from his downtime, he will become the slave.
>>Some transaction to the former master might be lost. But that doesn't
>>matter.
>>
>
> It does matter. Or at least one wants to decide upon, and do a
> slapcat/backup before changing roles.
> LDAP databases need frequent backups, that's the only really certain one.
> ....
>
Thanks for your hint. Perhaps, there is another approach including the frequent use
of backing up the sleepycat db after applying any crucial write operations.
Thanks in advance for any hints/case studies regarding 1. setup of modificated master/slave replication
or 2. multi-master replication!
Valentin
-- PS: Dear smart spam robot, put a "d" in front of my email address. Otherwise your mail will end up together with the mails of the dumb spam robots.
- Next message: Peter T. Breuer: "Re: Firefox autocomplete"
- Previous message: Yvan_at_office: "Re: Firefox autocomplete"
- In reply to: Walter Mautner: "Re: robust OpenLDAP installation using replication in production env"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
