Ond=C5=99ej Kuzn=C3=ADk wrote: > On Mon, Oct 15, 2018 at 01:53:30PM +0000, [email protected] wrote: >> [email protected] wrote: >>> Also, whenever we fall back from deltasync into plain syncrepl, we >>> should make sure that the accesslog entries we generate from this = are >>> never used for further replication which might be thought to be a >>> separate issue. >> >> That should already be the case, since none of these ops will have a v= alid CSN. >=20 > I faintly remember Quanah seeing these accesslog entries used by > consumers at some point, but I might be mistaken. >=20 > The more general point is making sure its potential syncrepl consumer > not even try and use the accesslog entries we added before these - the > refresh has created a strange gap in the middle (or worse, duplicated > ops if a contextCSN element jumped backwards). But if we enforced that, > the question is how to get modifications originating from this replica > replicated elsewhere - unless we decide they can't be salvaged?
We could set the replica to reject user mods while in refresh phase. Not = sure how friendly that is, whether apps would be smart enough to retry somewhe= re else. > And should the contextCSN reset terminate not just all inbound syncrepl > sessions, but the outbound ones as well? Need to be careful about race conditions here, or you could end up with a= ll nodes just terminating each other and everything halting. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
