[Date Prev][Date Next]
Re: slapd, bdb, 32-bit -> 64-bit
On 15. okt. 2006, at 18.52, matthew sporleder wrote:
On 10/15/06, Frode Nordahl <firstname.lastname@example.org> wrote:
I am trying to use a slapd BDB database created on a 32-bit intel
system on a 64-bit (amd64/EMT64) system. Running slapcat on the
database works fine, but when the server is started, ldapsearch is
unable to find anything.
I understand that there are architectural differences between a 32-
bit and 64-bit systems, but I don't think Berkeley DB have any
problems with having its data being interchanged between the
We are running OpenLDAP in a distributed environment where every
server has a local copy of the LDAP database for performance and
reliability reasons. The database is 6 GB, so it is non-trivial
export it to LDIF and import it again on the 64-bit systems. (It
takes way too long).
I am setting up one server to just be a spare LDAP slave so we
easilly can take it down and copy the database to any new system
added to the cluster without causing any downtime anywhere. But this
is not possible as long as I cannot use the same database on 32-bit
and 64-bit systems.
Would it be possible to make this work at all?
Could this be caused by a platform-dependent variable type being used
somewhere, rather than a fixed sized variable type, making slapd
interpret the same data diffrently on different platforms?
Are you using the same binary on both machines? If it's
32bit-compiled slapd/bdb, then I don't think you would have any
problems based on the underlying architecture. BDB does have an
endian-independent option, but I don't think you're running into that.
Maybe you just have to reindex/recover after the copy.
Different binary. The 64-bit computer is running a 64-bit binary, and
I am trying to use the BDB database created on a 32-bit computer with
a 32-bit binary.
I know I may be asking for trouble trying this, but I really would
like it to work.
If there are deliberate differences I would like to know about it, if
not I will try and help to find the source of the problem.
And you can definitely add new replicas without causing any downtime
by using the strategy you're suggesting- even using slapcat/slapadd.
Yes, this would be possible, but as the slapadd step may take several
hours I cannot rely on this. I have tested it with slapadd -q and it
still takes too long. There just is alot of data that must go in