Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-39239

Two-phase index builds on secondaries will wait for the commitIndexBuild oplog entry before committing.



    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.3.1
    • Storage
    • None
    • Fully Compatible
    • Storage NYC 2019-03-11, Execution Team 2019-09-23
    • 31
    • 5


      The secondary's index build thread should spin in a loop before finishing up and committing the index.

      The secondary will do nothing while spinning in a loop. It should drop all locks. SERVER-39458 will add functionality to the loop, of periodically reacquiring the lock and running side table draining.

      On receipt of the commitIndexBuild oplog entry, the secondary should signal the index build to commit with a timestamp passed in the oplog entry. The oplog applier thread will need to drop locks to allow the index build to take the X lock for index commit – I believe this should be safe, since 'c' oplog entries are applied serially, and so dropping the lock is OK. IndexBuildsCoordinator::commitIndexBuild will need to fetch a Future from the index build to return to the oplog applier thread to wait upon for commit completion.

      SERVER-39533 will be done after this ticket and will hook up the abortIndexBuild oplog entry so that alternatively the index build on the secondary can be aborted while it's spinning in that loop waiting for commit. In case that's a design consideration.

      Do not try to act on abort/commit signals earlier in the index build on secondaries than that spinning loop that waits for commit/abort. This is the simple first iteration implementation, we'll make it fancier in a subsequent ticket.


        Issue Links



              benety.goh@mongodb.com Benety Goh
              dianna.hohensee@mongodb.com Dianna Hohensee
              0 Vote for this issue
              5 Start watching this issue