Ond=C5=99ej Kuzn=C3=ADk wrote:
On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc@symas.com wrote:
ondra@mistotebe.net 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/