Upon rollback, there are several scenarios that can occur, given these time periods for the start and end of rollback:
1. Prior to index build starting.
2. During index build phase 1 (collection scan and inserting into sorter(s))
3. During index build phase 2 (bulk load of index table(s))
4. During index build phase 3 (catch up from side table(s))
5. After index build completes.
This work should only begin after we have a stable basic rollback procedure that handles resumable index builds. See SERVER-48418.
- is related to
-
SERVER-46558 Bgsync stops all index builds even before transitioning to rollback state and causes secondary replication to hang
- Closed
-
SERVER-51020 Abort index builds for rollback in the expected phase in resumable index build rollback tests
- Closed
-
SERVER-39451 Add recover to a stable timestamp logic for startIndexBuild, abortIndexBuild, commitIndexBuild
- Closed
-
SERVER-39458 Add continuous draining on secondary's index build thread while it awaits a commitIndexBuild oplog entry
- Closed
-
SERVER-39484 Add step-up and step-down state transition logic to simul index builds
- Closed
-
SERVER-40894 Remove unused setGhostCommitTimestampForWrite() and TimestampIndexBuildDrain
- Closed
-
SERVER-44467 Implement startup recovery for two-phase index builds
- Closed
-
SERVER-48418 Rollback restart resumable index builds from beginning
- Closed
- related to
-
SERVER-50391 Index build hung during startup recovery waiting for optime to be majority committed
- Closed
-
SERVER-50775 resumable index build rollback tests hang in RollbackTest.kSyncSourceOpsBeforeRollback
- Closed
-
SERVER-51007 adjust rollback to resume index build from phase 2 (bulk load index table from sorted keys)
- Closed
-
SERVER-51008 adjust rollback to resume index build from phase 3 (catch up from side table)
- Closed