On 21/09/05, Michal Dobroczynski <[EMAIL PROTECTED]> wrote: > On 21/09/05, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: > > > > > > --On Wednesday, September 21, 2005 2:40 PM +0200 Michal Dobroczynski > > <[EMAIL PROTECTED]> wrote: > > > > > For the past 30 days it happened two times that the database 'just > > > crashed'. For the first time I noticed that it was possible to > > > 'slapcat' the database and suddenly at some point it was simply > > > stopping. Nothing else was possible. I'm making backups of the > > > database every hour. > > >
I went into details a bit. Before I 'slapadded' the database from the backup ldif I copied contents of /var/lib/ldap to a separate place. Now I ran the db_recovery. Below is the output: db_recover: Finding last valid log LSN: file: 31 offset 8779253 db_recover: Recovery starting from [1][28] db_recover: Recovery complete at Wed Sep 21 22:39:50 2005 db_recover: Maximum transaction ID 800082a9 Recovery checkpoint [31][8780885] Seems that this could fix the database within a moment... but that's fixing. Idea is to avoid fixing (I'd like to know what is causing the problem...) I found out a few things that might cause the problem but I do not have enough experience to judge which one is the most likely: - bdb database tuning, meaning I should configure checkpointing, cachesize, idlcachesize etc. - I'll refer to faq-o-matic for some clues about the possible values; - running db_checkpoint (uid same as slapd's uid) (but how often?) I have created a few indices to speed up searching (exactly 9). I also found out that it might be a problem that I'm running slapcat with uid=root every hour. copy-paste: 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.) end-copy-paste I checked ownership of the database files I stored after crash - all files belong to ldap:ldap. Files belong to ldap:ldap, so maybe slapcat was not the cause... but I don't know. Anyway, I'll change it - from now on slapcat will run as ldap:ldap. Hints and advices are welcome. Regards, Michal Dobroczynski
