[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Re: slapd, bdb, 32-bit -> 64-bit

On 10/15/06, Frode Nordahl <frode@nordahl.net> wrote:
On 15. okt. 2006, at 18.52, matthew sporleder wrote:

> On 10/15/06, Frode Nordahl <frode@nordahl.net> wrote:
>> Hello,
>> 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
>> platforms.
>> 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
there :-)

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?