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

Re: slapd hangs doing large ldap (add|modify|delete)



There's a lot of good advice here. Just a couple notes...

Buchan Milne wrote:
If this is your level of experience with OpenLDAP, I would also
hesitate. Please review all the relevant sections of the FAQ-o-matic, at
minimum:

- -do some DB_CONFIG tuning
- -set up OpenLDAP caching (cachesize, idlcachesize)
- -set up checkpointing, and consider running db_checkpoint (the correct
version) as the user slapd is running as via cron or similar

The use of db_checkpoint is unnecessary in OpenLDAP 2.3, an internal task will handle this automatically.


- -ensure database recovery will run if ever slapd dies unexpectedly
(power failure, hardware failure, OS failure, PECKAC)

OpenLDAP 2.3 will perform recovery automatically; external startup scripts should not do anything here. For catastrophic failure, the automatic recovery will probably fail, but it would have required manual intervention regardless.


- -deal with your transaction logs sanely

This may require patching BerkeleyDB to get "sane" behavior.

- -ensure you have some sane means of backups of your data in LDAP (either
snapshots of the database and transaction logs, or slapcat the data as
the user slapd runs as via cron or similar).

slapcat in OpenLDAP 2.2.27 was fixed to prevent any writes/flushes/checkpoints from occurring. As such, it no longer makes any difference what user you run as, it will not accidentally change the ownership of any database files. (In older releases, slapcat performed a checkpoint before closing the database environment. If slapcat was running as root, and the checkpoint caused a new log file to be created, it would be created/owned by root, and other processes would be unable to write to the log. This was ITS#3703.)


--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/