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

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

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


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.