-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
Repl 2020-04-20, Repl 2020-05-04, Repl 2020-05-18, Repl 2020-06-01
-
(copied to CRM)
-
0
Currently we treat falling off the back of the oplog the same as being on a divergent branch of history here. Before deciding to go into rollback, we should check if we've fallen off the back of our sync source's oplog and if so switch sync sources (with an InvalidSyncSource error) instead of rolling back (OplogStartMissing error). We can do this exactly the same as how it's done in the SyncSourceResolver by comparing our last fetched optime to the sync source's oldest optime.
- is duplicated by
-
SERVER-33878 Update OplogFetcher to go into SyncSource selection on CappedPositionLost error
- Closed
-
SERVER-47271 Update oplog fetcher to return an InvalidSyncSource error only when the former sync source should be blacklisted
- Closed
-
SERVER-47272 Update bgsync to blacklist invalid sync sources
- Closed
- is related to
-
SERVER-71156 Fatal Assertion 40507 UnrecoverableRollbackError and Mongo Crash with 4.0.27 WT
- Closed
-
SERVER-33878 Update OplogFetcher to go into SyncSource selection on CappedPositionLost error
- Closed
- related to
-
SERVER-27403 Consider term and rbid when validating the proposed sync source
- Closed
-
SERVER-27980 Secondary tries to rollback when it lagged to much behind primary
- Closed
- mentioned in
-
Page Loading...