[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Corrupt index files
> -----Original Message-----
> From: Darren Gamble [mailto:Darren.Gamble@sjrb.ca]
> Good day,
>
> Despite the undeserved criticism, thank you for your reply.
> Please note again that I was rolling back to the original version of the
> server that I had used (i.e. the one that generated those files). That's
> the only reason I considered using my backup db files. I also described
> that very well. I am not sure why you even mentioned 2.1.X ; I have not
> even tried it yet.
I mentioned this as a concrete example of where attempting to re-use the
raw database files from a previous version will fail. There are plenty of
other issues with backup/restore of raw database files, like the fact that
gdbm creates sparse files, but all the "holes" would be filled in upon
the restore, giving extremely inefficient disk usage. gdbm in particular
seems
to have problems with losing track of what space it has allocated, causing
excessive growth of its database files.
> > Both slapadd and slapindex are additive programs. They will
> > not overwrite
> > data that already exists, they will only insert new data. If
> > you want to
> > recreate your indices from scratch, delete everything but the
> > id2entry and
> > the dn2id databases, then run slapindex.
>
> Thanks for this information. I am not sure if your reindexing procedure is
> correct, though. See results below.
Sorry for this, I forgot about the nextid file. back-bdb (which I use most
often)
doesn't use one so it slipped from my mind.
> Testing yesterday afternoon turns out slapindex does change my index files,
> though. And, I think I have actually identified my problem (the problem
> that causes the import indexes to go bad). In all of my tests, I've run
> slapindex after a slapadd. Why? That's how I was instructed to do it from
> this mailing list away-back when I first started to use OpenLDAP.
>
> http://www.openldap.org/lists/openldap-software/200111/msg00373.html
I can't explain the rationale behind that post. As near as I can tell,
slapadd
has always done a full index on the added entries, so the following slapindex
is
redundant. You would only need to run slapindex if you have added new
indexing
directives to slapd.conf with an existing database.
> Now, this information gives me a solution to my first problem (use bdb
> instead of gdbm) and a workaround to my second problem (don't run slapindex
> unless all of the index files have been removed), so I will do further
> testing with that server/backend combination.
This result is troubling, since both slapadd and slapindex invoke the
identical
code to process the indices. Given identical input one would expect them to
produce identical results, and duplicate results are supposed to be
discarded.
>
> In the event that I consider it, though, could someone please provide some
> advice on what to expect if I were to upgrade to OpenLDAP 2.1.X?
That depends on whether you continue to use back-ldbm or decide to migrate to
back-bdb. back-ldbm is about the same as it was in 2.0; slightly faster as
most
of 2.1 is faster than 2.0. If you want to use back-bdb you will be required
to
upgrade to Sleepycat BDB 4.x as there are serious locking bugs in BDB 3.
I'm not sure that any of the BDB issues have any bearing on your present
problems, but it wouldn't hurt to try that upgrade.
> Mr. Chu, I feel that an apology is in order. I realize that there are many
> problems caused by individuals who do not read the documentation and who
> deserve the response that you gave, but this has not yet happened here, and
> you would have known that if you would have read the message and
> thread more
> carefully before replying.
>
> Thanks again to everyone for their help, including Mr. Chu .
To go thru all that heat and still remain polite, you're a better man than
me.
I apologize for any criticism I directed at you.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support