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
-