On Monday 30 January 2006 16:40, ricardo.ferreira@cimsoft.pt wrote: > Hi, > I'm using openLDAP server with berkeley sleepycat as dabase backend with > more than 150GBytes of information. Which version? > I'm having some problems when I'm adding information to LDAP server and the > connection suddenly went down despite net failure or other similar problem. Hmm, this should only occur if there is some sort of failure on the server side (power, CPU, etc). > After that, I supect that the database backend becomes > innacessible/corrupt???? > If I try to access the ldap server using for example LdapBrowser the server > doesn't response and is like it didn't exist. > When I go to the linux server I check the slapd process and it is up. > I stop the ldap server process and restart it in debug mode with > "slapd -d -1". It starts normaly without any errors messages. > But if I go to the LdapBrowser it appears that the server doesn't exist and > my application doesn't work properly. > 1 - The first attempt to restart correctly the LDAP server I need to remove > the last log files and restart the service slapd. Which log files? You should never remove the transaction log files (log.* in the database directory), or the database environment (__db*). > If I do this the ldap server starts to response and everything seems to go > right BUT if I consult the last node inserted the service went down again. You lost it when you removed the "logs", if they were the transaction logs. > 2 - The second attempt I try to recover the Database backend with > db_recover command but doesn't succed and takes a long time. You should have done that first. If db_recover runs for a long time, it probably means you haven't got checkpoint'ing enabled (see slapd-bdb man page, search for checkpoint). > 3 - The thirth attempt I backup the Ldap server with slapdcat command to a > file and then slapadd command from the same file. That is the only solution > that gives > me the system correctly recover and running properly, but the last node is > lost during this proccess. This proccess takes much time and the server is > down during > that time. Well, this is the same as case (1), you removed the transaction logs. > 4 - The forth attempt that I haven't try this but I read in some foruns and > that is possible to go to the id2entry.bdb with an editor and truncate > last non-multiple block. Restart the service and it seems to starts > correctly. > I know that openLDAP doesn't have transactions. Wrong, the LDAP protocol doesn't allow transactions, but that says nothing about the backend storage. With BDB, OpenLDAP runs operations on the database with transaction support. Unfortunately, you've been deleting the only record of them before doing anything else. > A - Is there anyway of workaround this limitation during runtime insertions > to avoid corruption? There is no limitation. > B - Or is there any easier way of recovering the DB if this problem > occours? Correctly configure checkpointing, and ensure that database recovery is run before slapd starts after any possible unclean shutdown. Or, upgrade to 2.3.x, which should do all of this for you automatically. Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpPDD7T9VuZg.pgp
Description: PGP signature