-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 3.2.0, 3.3.0
-
Component/s: Replication
-
Fully Compatible
-
ALL
-
Repl 2016-11-21
-
(copied to CRM)
-
0
If we use the lastFetchedOptime, which is also the common point found during rollback, it is possible that a sync source is selected which will cause the rollback to be attempted again (after the first says it succeeds), but while in an inconsistent state (with minvalid showing an invalid state, needing to apply before being consistent).
By using the end of minvalid bounds as a criteria for sync source selection it will not be possible to do another rollback until the first has completed and apply all necessary options to get into a consistent state.
- is duplicated by
-
SERVER-27277 [rsBackgroundSync] Fatal assertion 18750 UnrecoverableRollbackError on numerous 3.2.10 replica sets
- Closed
-
SERVER-28056 rollback fail
- Closed
-
SERVER-25026 Secondary abort immediately following losing Primary election, will not restart
- Closed
-
SERVER-27547 Adjust the system time . then MongoDB status maintian RECOVERING
- Closed
-
SERVER-27676 Mongod is not able to restart after OOM kill
- Closed
-
SERVER-25861 Adjust minValid logic
- Closed
- is related to
-
SERVER-21537 chainingAllowed = false not being enforced after rs.stepDown()
- Closed
-
SERVER-21988 Rollback does not wait for applier to finish before starting
- Closed
-
SERVER-23070 rewrite SyncSourceResolver to select sync source asynchronously
- Closed
-
SERVER-27050 Ensure upstream node doesn't roll back after checking minvald
- Closed
-
SERVER-25848 Enforce single sync source during rollback
- Closed
- related to
-
SERVER-26415 Make sure to catch up to minValid before exiting rollback
- Closed
-
SERVER-26922 minvalid2 should wait for arbiter to be up before shutting secondary down.
- Closed
-
SERVER-26972 BackgroundSync should compare minValidSaved to _lastOpTimeFetched
- Closed