[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLdap corruption/recovery issue
ricardo.ferreira@cimsoft.pt wrote:
Hi,
I'm using openLDAP server with berkeley sleepycat as dabase backend with
more than 150GBytes of information.
Sleepycat BerkeleyDB is a database library but it is not an OpenLDAP
database backend. back-bdb, back-hdb, and back-ldbm are all OpenLDAP
database backends that can use BerkeleyDB. Which version of OpenLDAP and
which database backend are you actually using?
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.
After that, I supect that the database backend becomes
innacessible/corrupt????
On the current OpenLDAP releases, if the database is corrupt, you will
get a log message saying so. On back-bdb and back-hdb, a recovery will
be performed automatically.
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.
What log files? If you're talking about the BDB transaction log files,
then removing them is guaranteed to leave the database unrecoverable.
Don't do that. Read the BerkeleyDB documentation.
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.
2 - The second attempt I try to recover the Database backend with db_recover
command but doesn't succed and takes a long time.
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.
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.
That is utterly idiotic advice. The BDB database file formats are
undocumented and change from version to version. You have no idea what
further damage you can be causing.
I know that openLDAP doesn't have transactions.
Your knowledge is wrong. back-bdb and back-hdb are both transactional
databases, that is the main reason back-bdb was written.
A - Is there anyway of workaround this limitation during runtime insertions
to avoid corruption?
B - Or is there any easier way of recovering the DB if this problem occours?
Use a current version of OpenLDAP - 2.3.19. Use the back-bdb or back-hdb
backends, and not back-ldbm. Read the slapd-bdb(5) manpage and configure
things correctly. Read the FAQ-o-Matic for more suggestions.
http://www.openldap.org/faq/data/cache/1166.html
--
-- 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/