[Date Prev][Date Next]
Re: alock + ldbm in 2.3.21
matthew sporleder wrote:
db_upgrade will change the low level BerkeleyDB data structures but it
obviously has no knowledge of OpenLDAP's own data structures. Since you
are already aware that 2.1 to 2.3 have data format incompatibilities, it
makes absolutely no sense to believe you could just db_upgrade the data
files and immediately use them with 2.3.
The reason I'm using LDBM is that I can migrate my servers to 2.3
LDBM is going to be removed from OpenLDAP 2.4, and there are many reasons
Apr 11 15:21:22 labogldir02 slapd: [ID 658149 local6.debug]
ldbm_back_db_open: alock package is unstable; database may be
Apr 11 15:21:22 labogldir02 slapd: [ID 100111 local6.debug]
Can I get a status on alock for LDBM?
it looks like ldbm is having some alock rethinks. Should I wait for
ldbm to be re-stabilized in 2.3.x?
not to use LDBM (stability, etc). I would rethink why you are using LDBM
in the first place (not that the problem you are reporting doesn't need
to be addressed).
-very quickly- by sticking with the same backend as I was using in
Basically, my procedure was:
install binaries, run db_upgrade, start slapd. (takes about two minutes)
My database is about 6M entries. I agree 100% that I should start
using BDB. I have no interest in using something that is no longer
supported. (too bad my peers don't necessarily think that way) So my
main reason for using LDBM is that I can do the upgrades fast, and
then work on larger changes slower.
The notion that you can upgrade LDBM (or any other slapd database) with
any shortcut around slapcat/slapadd is mistaken.
As an aside, I am pushing for this quick transition because I was
under the impression that 2.1 and 2.3 could not replicate to
eachother. Is this correct? I would love to compile a compatibility
matrix to help anyone who is also trying to create upgrade paths. I
already know that slapcat/slapadd from 2.1 to 2.3 requires some
OpenLDAP 2.3 will accept replication data from any other server.
However, as I recall, the entryCSN operational attribute was introduced
in 2.1 and its syntax/format changed in 2.2, so those attributes may
need to be rewritten on the 2.3 server (if you plan to switch over to
-- 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/