Here is my reply to a similar post. Hopefully you will find it useful...

Dave Kernen

> > I would like to completely replace a subtree of information with data held in a 
>ldif format each
> > night. Do I have to delete each entity in the subtree before doing this or is 
>there a quicker
> > approach?
> >> Ray Gardener
>
> There are a few other options that have not been mentioned here, so I'll toss them 
>out for you to
> ponder.
> In all of these, I'll call your source LDAP "LDAP1" and the target LDAP "LDAP2".
>
> 1) You can export the subtree in question on LDAP1. Then export LDAP2, excluding the 
>subtree in
> question. (There are command line switches in db2ldif that allow you to decide which 
>subtrees do or
> do not get exported).
> Then rebuild your LDAP2 based on its previous (partial) export, then run ldapmodify 
>to add the
> subtree exported from LDAP1. Major flaw with this approach is that you'll have to 
>schedule a daily
> (nightly?) outage to do this. There can also be performance problems if your LDAPs 
>are large.
>
> 2) Make sure you have plenty of room in the change log on LDAP1 to hold a day's 
>worth of changes,
> then periodically query the changelog on LDAP1 to apply changes from LDAP1 to LDAP2. 
>This is a
> little bit like implementing your own version of replication, except that you can 
>customize it by
> inspecting each change that occurred in LDAP1 and deciding if and how you wish to 
>reflect that on
> LDAP2. The major disadvantage to this approach is that if the change after the most 
>recent change
> you've propagated to LDAP2 rolls out of the changelog on LDAP1 then you're basically 
>screwed.
> (Processing LDAP1's changelog more frequently will greatly reduce your risks in this 
>regard.)
>
> 3) Write a script that periodically compares the data in LDAP1 to the data in LDAP2, 
>adjusting the
> latter if necessary. The major disadvantage of this approach is that it can be 
>resource intensive
> and also time-consuming, especially if you're not very careful to program for 
>efficiency.
>
> 4) Write a script that searches the entire subtree in question in LDAP1, then 
>deletes (if present)
> and re-adds to LDAP2. The disadvantages here are similar to 3), above, but this 
>script may be easier
> to write. (If you have a lot of indexed attributes on LDAP2, though, then it could 
>be even more
> resource-intensive then option 3.)
>
> If you don't have direct access to LDAP1, and you only have access to the LDIF file, 
>then you'll
> have to do something for each entry like this:
> 1) try to add it.
> 2) if the add fails because the entry exists, replace all of the attributes with the 
>ones provided
> in the ldif. (To make it easier on your ldap server, you can check them first to see 
>if they're
> different, and only replace attributes
> with different values. Since LDAP is designed to be searched quickly at the cost of 
>expensive
> modifies, this may be well worth the effort.)
> 3) if an entry in LDAP2 has not been processed in 1) or 2) above, then delete it.
>
> Hope this helps...
>
> Dave Kernen




Reply via email to