handle edge condition on recoonect - repeated network errors while pa… #438
+4
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this is a continuation of #420
I have realized that there is a scenario when transaction will get skipped
Consider following sequence of events:
b.prevGset
equals TranA andb.currGset
equals TranBBinlogSyncer.retrySync
and re establish binlong stream "from TranA". Thus first transaction we are going to see - TranB (which we already saw before error was encountered)Thus we are going to enter
advanceCurrentGtidSet
with state:b.prevGset === TraA
b.currGset === TranB
gtid === TranB
without proposed change - upon exit of this function we will have state:
b.prevGset === TranB
b.currGset === TranB
Which means, that if network error is encountered again, while processing same TranB - we will be re establishing replication stream from TranB, in other words first transaction delivered after such reconnect will be TranC, so TranB will never be fully processed.