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 :-)