https://bugs.openldap.org/show_bug.cgi?id=9647
Issue ID: 9647 Summary: Glue entry creation doesn't replicate properly Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: ondra@mistotebe.net Target Milestone: ---
In plain syncrepl, when an entry is turned into glue (to remove it when it still has children), it won't replicate correctly to its consumers - a NEW_COOKIE intermediate message is sent instead.
Scenario: - 4 servers (A, B, C, D) and a tree with two entries - cn=parent,cn=suffix and its parent, the database suffix - D replicates from C, C replicates from A and B, no other links set up for this
Now: 1. add an entry "cn=child,cn=parent,cn=suffix" on A 2. remove "cn=parent,cn=suffix" from B
As things settle, cn=parent,cn=suffix is retained on D while being deleted from C.
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |replication
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6097
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.1
https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Right, the cause is slightly different. When dealing with the delete and turning the entry into a glue, CSN of the operation is not recorded in the modify, that's why the replica ends up ignoring it.
We should replace the entryCSN as part of the operation, but syncprov should probably figure out it's a delete when we do it, otherwise I suspect we push out glue entries to consumers that are leafs and never get reclaimed?
https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- If the issue is fixed (the glue entry has the right entryCSN recorded), the set up still exposes another issue when sessionlog is not configured/available:
In the above scenario, when things settle and B is allowed to replicate from A, cn=parent,cn=suffix is recreated in the cluster (sometimes except D not sure why yet). This is because A has to do a present phase and sends all entries, including cn=parent,cn=suffix (it hasn't seen the delete yet) while B has processed the delete in full, so it has no information to reject it anymore (except contextCSN, which we ignore in this case).
We could start judging entries in the present phase by their entryCSN as compared to our cookie, but this way we make it harder to fix existing database differences (if replication failed somehow in the past).
https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- And during the present phase we don't actually know which sid was responsible for this delete. We can't just pick one at random because we might then relay that deletion over a running persist session (or store it inside our sessionlog for later) - if we chose wrong, it's possible that server would never hear about the deletion from anyone.
That suggests we also have to taint the whole sessionlog/accesslog and all running persist sessions, forcing everyone into a full refresh. In that case, depends whether ITS#8125 and similar issues have actually been fully resolved otherwise we risk desyncs and/or everyone refreshing+reconnecting indefinitely.
https://bugs.openldap.org/show_bug.cgi?id=9647
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9580
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.1 |2.6.2
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.2 |2.6.1 Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs@openldap.org |ondra@mistotebe.net Ever confirmed|0 |1
--- Comment #4 from Quanah Gibson-Mount quanah@openldap.org --- https://git.openldap.org/openldap/openldap/-/merge_requests/444
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- • 8d514517 by Ondřej Kuzník at 2021-12-09T20:50:02+00:00 ITS#9647 Record delete's CSN in the glue entry
• e8f1038d by Ondřej Kuzník at 2021-12-09T20:50:02+00:00 ITS#9647 Treat glue entries as missing
We're using MANAGE_DSAIT control so we get to see them, but they don't really exist (except for their CSN sometimes).
• ba37508f by Ondřej Kuzník at 2021-12-09T20:50:02+00:00 ITS#9647 Find correct sid in compare_csns() more of the time
https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #6 from Quanah Gibson-Mount quanah@openldap.org --- RE26:
• 0a7e5abc by Ondřej Kuzník at 2021-12-13T17:04:15+00:00 ITS#9647 Record delete's CSN in the glue entry
• 93487d54 by Ondřej Kuzník at 2021-12-13T17:04:19+00:00 ITS#9647 Treat glue entries as missing
We're using MANAGE_DSAIT control so we get to see them, but they don't really exist (except for their CSN sometimes).
• fb4f4227 by Ondřej Kuzník at 2021-12-13T17:04:23+00:00 ITS#9647 Find correct sid in compare_csns() more of the time
https://bugs.openldap.org/show_bug.cgi?id=9647
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org