Is it safe to use a 'clone' of an openldap servers's database to rebuild another server in a cluster? In my tests, I followed a procedure where I shut 2 servers down, copied the backend database from one to the other, and restarted and everything seems to indicate that the 'cloned' server is valid. Replication works.. Adds/deletes work.. etc.. Is there any danger in using this procedure? Is there anything 'instance specific' that is stored in the directory that could cause an issue? Ive found that even using slapadd's 'quick' flag it can still take 4 hours to import an LDIF, and if I can rely on this procedure to rebuild an LDAP read server in a crisis, I'd like to continue using it.

Is it safe to use a 'clone' of an openldap servers's database to rebuild another server in a cluster? In my tests, I followed a procedure where I shut 2 servers down, copied the backend database from one to the other, and restarted and everything seems to indicate that the 'cloned' server is valid. Replication works.. Adds/deletes work.. etc.. Is there any danger in using this procedure? Is there anything 'instance specific' that is stored in the directory that could cause an issue? Ive found that even using slapadd's 'quick' flag it can still take 4 hours to import an LDIF, and if I can rely on this procedure to rebuild an LDAP read server in a crisis, I'd like to continue using it.

--On Wednesday, January 23, 2008 9:35 AM -0500 Thomas Ledbetter <tledbett(a)revelstone.net&gt; wrote: > Ive found that even using slapadd's 'quick' flag it can still take 4 > hours to import an LDIF, and if I can rely on this procedure to rebuild > an LDAP read server in a crisis, I'd like to continue using it. This would generally indicate that you've failed to properly tune DB_CONFIG.

Is it safe to use a 'clone' of an openldap servers's database to rebuild another server in a cluster? In my tests, I followed a procedure where I shut 2 servers down, copied the backend database from one to the other, and restarted and everything seems to indicate that the 'cloned' server is valid. Replication works.. Adds/deletes work.. etc.. Is there any danger in using this procedure? Is there anything 'instance specific' that is stored in the directory that could cause an issue? Ive found that even using slapadd's 'quick' flag it can still take 4 hours to import an LDIF, and if I can rely on this procedure to rebuild an LDAP read server in a crisis, I'd like to continue using it.

This would generally indicate that you've failed to properly tune DB_CONFIG.

Or he's got a ~35GB database...

We went to some effort to make sure that it's safe to run slapcat while slapd is running, to allow hot backups to be performed. Ignoring this feature is pretty counterproductive. BerkeleyDB itself also provides documentation for how to perform a hot backup of the raw DB files. Both of these options exist and are already documented; anything else you do at your own risk.

--On Thursday, January 24, 2008 10:13 PM -0500 Thomas Ledbetter <tledbett(a)revelstone.net&gt; wrote: > > Thanks for all the feedback on this guys. > >> This would generally indicate that you've failed to properly tune >> DB_CONFIG. > > Completely possible! :) I worked through the stuff in the openldap > faq-a-matic in the past, but it was complicated, and we've added alot of > users since that time. > > Is there a better tuning guide out there? One that relates more to the > actual data structures being used? There's the FAQ entry at: <http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=... but it looks like it needs some updating. Here's the general overview: The amount of cachesize to set in the DB_CONFIG file for loading via slapadd should, if at all possible, be the size of "du -c -h *.bdb" in the data directory. This is how much space your DB will take while loading via slapadd. Other things you can do to decrease the amount of time loading data takes is to use the -q flag when bulk loading, and to set the tool-threads parameter in slapd.conf to be equal to the number of real cores (i.e., no hyper-threading) your system has. Since I don't know the specifics of your indexing, it's hard to know exactly how long it should take to load your DB, but if the size of *.bdb is > than the 4GB of memory on your system, it is time to upgrade your systems RAM. You also don't say whether you are running a 32 or 64-bit kernel, and that's vital information to have.