Re: slow cn=config changes; Re: Correct procedure to backup LDAP?

[Aaron Richton <richton@nbcs.rutgers.edu>]

Howard's spoken well to the internals of back-config. I'll note:

(a) it's supposed to be safe to slapcat the hot 2.3.24 hdb, but I'm hoping 
you know that and therefore you want to snapshot at quiescent state only

(b) if I was trying to take a snapshot of the directory at precisely one 
time, I'd probably set up a consumer and kill it to take the slapcat. Or 
possibly come up with a accesslog consumer that applies deltas to known 
slapcat's. Or maybe take a slapcat that might end at t=0+, and revert the 
accesslog with some accesslog reverser?

[this isn't toward you personally...it applies at all times, but it seems 
like a good reminder]
There's a lot of discussion on what's safe (or not) on live databases 
lately. There's also no reason to trust me (after all, I'm just one 
user!), and it's open software, so nobody has to. If I was skeptical about 
this, for instance, I would start test008 in one window, and slapcat it in 
an infinite loop in another...or whatever might make you happy using it 
for backups at your site. If it works, great; if you can contribute a 
useful example of it not working, that's quite possibly even better, and 
myself and the rest of the community thank you.

On Mon, 14 Aug 2006, Eric Irrgang wrote:

> I'm trying to migrate to a reliable live update mechanism and I have tried 
> using slapcat after putting the directory into read-only mode, but that seems 
> to bring up additional issues.
>
> In OL 2.3.24 with hdb, how supported is it to do the following?
> $ ldapmodify
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> replace: olcReadOnly
> olcReadOnly: TRUE
> -
>
> ^D
>
>
> It seems to work, usually in about a second, but sometimes can take upwards 
> of a minute, during which time the directory seems to be in some sort of 
> stop-the-world state where connections just hang, preventing it from being 
> the non-intrusive backup approach I'd hoped for.  The CPU usage doesn't spike 
> and the disk usage appears normal.  I've seen similar behavior with other 
> cn=config changes.
>
> Has anyone else encountered this?  Is it supposed to work better?  Any ideas 
> what might be going on or what I should look for?  There don't seem to be any 
> runaway polling loops or lwp fights going on.  A truss shows a little bit of 
> lwp polling activity and some writes going on, but nothing suspicious like 
> the hang early in 2.3.x when shutting down with gentlehup.