Hi Thierry,
On 6/21/18 7:19 PM, thierry bordaz via FreeIPA-users wrote:
Hi Harald,
Sorry to be back late.
There is not enough detail to confirm but my feeling is that the MODRDN (write) failed to
update the changelog because of many replication agreements (read) competing with it. It
retried several times but without success so the full txn was aborted.
I think this can be mitigate with appropriate deadlock policy
(nsslapd-db-deadlock-policy: 6 for example).
Now it broke the index and that is really unexpected (even after a db_deadlock). It worth
to try to reproduce.
thanks for your help
I am not sure what that means, but point is that I have a corrupted
entry in 2 of 6 replicas. jxplorer refuses to touch this entry. How
can I fix this?
If the "transaction" was aborted, how comes that the ldap databases
differ? Ain't this the definition for "not having a transaction"?
I found something new: "ipa-replica-manage list-ruv" shows an error
# ipa-replica-manage list-ruv
unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090
# ipa-replica-manage clean-ruv 7
unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000
Replica ID 7 not found
Every helpful hint how to fix this is highly appreciated
Harri