If setting up a new delta-MPR environment such that: - server A has been slapadd-ed the seed data - accesslog is set to "logops all" There is a sequence of events where servers are started and replicate from each other before they get a chance to talk to A, they will each generate a CSN and replicate it. Once they start talking to A, it will see that it has a CSN (its own) that none of them have sent and "syncprov-nopresent" makes it just go ahead where the only sane outcome is to send SYNC_REFRESH_REQUIRED. Am I missing a usecase for this or should it just have been this way all along?
I guess running without that option wouldn't have helped and the same would have happened anyway since the log is just missing things. Seems like adding a new serverID into a deltasync cluster is an administrative task that should be documented and managed. We have two options there: - we have syncprov return a SYNC_REFRESH_REQUIRED, triggering a fallback sync and tainting everyone's accesslog - we mandate that the initial environment set up is done very carefully (the seed is contacted first by everyone or distributed ahead of time) and keep the current behaviour
(In reply to Ondřej Kuzník from comment #1) > I guess running without that option wouldn't have helped and the same would > have happened anyway since the log is just missing things. > > Seems like adding a new serverID into a deltasync cluster is an > administrative task that should be documented and managed. We have two > options there: > - we have syncprov return a SYNC_REFRESH_REQUIRED, triggering a fallback > sync and tainting everyone's accesslog > - we mandate that the initial environment set up is done very carefully (the > seed is contacted first by everyone or distributed ahead of time) and keep > the current behaviour I consider it essential that it be trivial to add new nodes to an MPR cluster at any time w/o it requiring any special handling. Replication is already insanely complex in OpenLDAP.
I'm inclined to making it reject that op, the problem with deltasync is these transitions wreak havoc on the accesslog. When we finally understand it, the exact scope of the damage and how to deal with it, we might need to be able to interfere with other client sessions - and how not to keep triggering this forever if we want to keep delta-MPR viable.
(In reply to Ondřej Kuzník from comment #0) > If setting up a new delta-MPR environment such that: > - server A has been slapadd-ed the seed data > - accesslog is set to "logops all" > > There is a sequence of events where servers are started and replicate from > each other before they get a chance to talk to A, they will each generate a > CSN and replicate it. Once they start talking to A, it will see that it has > a CSN (its own) that none of them have sent and "syncprov-nopresent" makes > it just go ahead where the only sane outcome is to send > SYNC_REFRESH_REQUIRED. > > Am I missing a usecase for this or should it just have been this way all > along? Sounds like the seed data should include the accesslog context entry.
• c51320a6 by Ondřej Kuzník at 2021-12-13T19:20:58+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
RE26: • 60c92687 by Ondřej Kuzník at 2021-12-14T16:46:40+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
• 52b89f52 by Ondřej Kuzník at 2021-12-14T16:50:11+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
RE25: (In reply to Quanah Gibson-Mount from comment #7) > • 52b89f52 > by Ondřej Kuzník at 2021-12-14T16:50:11+00:00 > ITS#9742 Reject a refresh if we can't do a precise resync