The Simultaneous Index Builds On All Nodes project (PM-253) introduces new oplog entries. Tools will need to address those in mongodump mongorestore.

Update 2019-02-06:  the design document lists the following required changes for mongomirror; most of these will also apply to mongorestore:

• The new startIndexBuild, abortIndexBuild oplog entries will be filtered out and discarded by MongoMirror.
  • MongoMirror’s source and destination nodes cannot communicate with one another to take advantage of primary-secondary index build voting protocols new in v4.2.
  • Nor is it guaranteed that index builds will deterministically finish successfully on different servers when started at the same point-in-time due to races with concurrent writes during an index build. An index build can non-deterministically fail depending when it checks index uniqueness constraint violations that could be resolved by a data write concurrent with the index build. If the build proceeded faster on the destination node than the source, the constraint violation might not have yet resolved. Waiting until the index build commits on the source promises this won’t happen on the destination.

• MongoMirror will convert old createIndexes and new commitIndexBuild oplog entries into a createIndexes server command against the destination node.
  • This will avoid MongoMirror having to handle FCV concerns, whether it is should use createIndexes or commitIndexBuild in the applyOps command against the destination node.
  • Furthermore, this avoids server work to make commitIndexBuild via applyOps specially run an index build from the beginning.
  • MongoMirror can use choose a commitQuorum setting, if desired. Not specifying one will lead to using the default, which will be all members of the destination replica set.
    • The commitQuorum setting is not present in oplog entries.

• The createIndexes command will be a blocking call: it will not return until the index build has either finished or failed.
  • Blocking on a commitIndexBuild oplog entry ensures commit timestamp ordering relative to the other oplog entries being applied.
    • If MongoMirror cuts the user over to the destination node after applying the commitIndexBuild oplog entry, we will know that writes that violate the uniqueness constraints of the index will fail, just like on the source at that point-in-time. If commitIndexBuild were applied asynchronously, then there is no such guarantee.
  • MongoMirror can achieve ‘fire-and-forget’ functionality as desired by running the createIndexes command on a side thread while proceeding with oplog application. It was suggested that this functionality is desirable for things like MongoMirror’s version of the initial sync process.

• applyOps will fail on all the new index build oplog entries, start/abort/commitIndexBuild. A user should not manage a simultaneous index build. An attempt to do so against a primary will lead to undefined behavior.

• MongoMirror should ignore the config.system.indexBuilds collection. The destination node will populate the collection as indexes are building. There is nothing in the collection that is worth copying over to the destination node.