The last time slapadd was used on this database was many years ago, and yeah as I said, slapindex is my mitigation for queries not working after reloading the mdb with arm64.  we're using cn=config. we see the same indexing performance on 2.6.2 though.

i've not tested loading an arm64 mdb with an x86 instance, i'll try that tomorrow and report back.

i may have to accept running the process through the day, then sync forwards after switching over. not ideal but not intolerable. it would be nice to know why indexes get messed up by the architecture swap though.

Sent from Outlook for iOS
From: Quanah Gibson-Mount <quanah@fast-mail.org>
Sent: Thursday, July 20, 2023 4:54:56 PM
To: Maud Parratt <Maud.Parratt@bjss.com>; openldap-technical@openldap.org <openldap-technical@openldap.org>
Subject: Re: slapindex a 60GB mdb in reasonable time
 


--On Thursday, July 20, 2023 4:14 PM +0000 Maud Parratt
<Maud.Parratt@bjss.com> wrote:

>
>
> The database already exists as an mdb, I could dump and restore it with
> slapadd, but I expect that'd take as much time as the slapindex.
>
> If I load the mdb from an x86 instance of openldap on an arm64 index,
> queries return zero results until I do a slapindex, I suspect the way
> indexes is encoded is inconsistent between architectures.
>
> It certainly would've saved me some time experimenting with tool
> threads if I was aware of that limitation.


Do you see the same load time issue on x86_64 as on arm64?

Also it's not clear to me why you're indexing the entire database with
slapindex if it was already loaded via slapadd, which would have created
the indices as they existed at the time the DB was loaded.  You should only
have to slapindex any changes made since that time.

Are you using cn=config or slapd.conf would be another question of mine.  I
hit a serious bug in OpenLDAP 2.6.4 in regards to cn=config and adding
indexing that slapindex couldn't fix (ITS#9993, ITS#10047).

--Quanah



The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR