[Date Prev][Date Next]
Re: Re: slapd, bdb, 32-bit -> 64-bit
On 10/15/06, Frode Nordahl <email@example.com> wrote:
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
Use the same binary set on all of your replicas, otherwise you can't
reasonably expect the same database files to work.
I also have a large database (my slapcat-ed file is over 4gb), but I
don't see how it's more reliable to shutdown a spare for one hour
while you scp versus four hours while you slapadd. What's the
difference? A minute's worth of replication to catch-up with?