Hello,
Thank you for your response - it was very helpful.
Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077
I also saw that entryCSN can be negative as well but the proposed solution should fix the problem. createTimestamp: 20230110130503 entryCSN: 20230110130503.*-060060Z*#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int
I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow: 1) do a backup create ldif (contains contextCSN: 20230410125515*.-401856Z* #000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database.
Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup? Or is there any other way?
Configuration uses provider and consumer with replication.
Thank you in advance for your response,
BR,
Peter
Am Mi., 14. Juni 2023 um 17:09 Uhr schrieb Quanah Gibson-Mount < quanah@fast-mail.org>:
--On Tuesday, June 13, 2023 12:11 PM +0200 awsome jang jangawsome@gmail.com wrote:
Hello,
I am running openldap 2.6.3 configured as provider-consumer and I would like to do backup/restore of the database on the provider.
I create a backup on working sladp using command(ends with success, file created): slapd.exe –T cat –f slapd.conf –l backup.ldif
And then trying to load it using slapd command into a new database(restore): slapd.exe -T add -f slapd.conf -l backup.ldif -d -1
Command ends with: . creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int createTimestamp: 20230410111050Z entryCSN: 20230410111051.368528Z#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int modifyTimestamp: 20230410111050Z contextCSN: 20230410125515.-401856Z#000000#000#000000
This appears to be a bug with generating the CSN on windows, likely due to some type of overflow. Can you please file a bug report at https://bugs.openldap.org
Thanks!
Regards, Quanah
--On Sunday, July 9, 2023 9:28 AM +0200 awsome jang jangawsome@gmail.com wrote:
Hello,
Thank you for your response - it was very helpful.
Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077
Thanks!
I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow:
- do a backup create ldif (contains contextCSN:
20230410125515.-401856Z#000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database.
Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup?
If you only have a single server, I would do the following:
Stop server export database remove all entryCSN and contextCSN attributes load database with slapad, using the -w flag to regenerate the contextCSN value at the end.
However, I would only do the above if you have your suggested fix in place so the problem doesn't re-occur.
If you have > 1 server, you would need to stop all the servers, do the above on one server, and then after it's complete, export its db again with slapcat, then copy that over to the other servers and reload them with the fixed database. Again with the caveat about having fixed binaries in place.
Regards, Quanah
Op 13-07-2023 om 17:59 schreef Quanah Gibson-Mount:
If you only have a single server, I would do the following:
Stop server export database remove all entryCSN and contextCSN attributes load database with slapad, using the -w flag to regenerate the contextCSN value at the end.
Would the procedure above also make ancient (and no longer relevant) contextCSN attributes disappear from our years-old database?
Then, in our openlap 2.4 -> 2.5 transition, we could do that, and start with only new & relevant contextCSN's in our database.
I guess, since we are not yet production, I could simply try it out.
Will do tomorrow if I find the time.
--On Thursday, July 13, 2023 8:54 PM +0200 sacawulu cyusedfzfb@gmail.com wrote:
Op 13-07-2023 om 17:59 schreef Quanah Gibson-Mount:
If you only have a single server, I would do the following:
Stop server export database remove all entryCSN and contextCSN attributes load database with slapad, using the -w flag to regenerate the contextCSN value at the end.
Would the procedure above also make ancient (and no longer relevant) contextCSN attributes disappear from our years-old database?
Correct.
--Quanah
openldap-technical@openldap.org