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?