In a replica set, aborting an index build does not result in any oplog entries that would affect downstream secondary nodes because the createIndexes entry would not be written to the oplog.
With two phase index builds, an index build that failed on the primary would result in a pair of startIndexBuild and abortIndexBuild oplog entries being propagated to secondary nodes. The abortIndexBuild oplog entry contains similar information to the startIndexBuild but any information relating to why the index build was aborted can only be found in the logs on the primary. It would be useful for the reason/cause for aborting the index build to be relayed to secondary nodes for improved diagnostics. We might be able to log aborted index builds on a secondary as follows:
Aborting index build: 17e76e49-af0b-42bc-84e2-d1a71230e070, timestamp: Timestamp(1568352953, 4), reason: abortIndexBuild oplog entry encountered: IndexBuildAborted: Index build aborted: Index build interrupted: 17e76e49-af0b-42bc-84e2-d1a71230e070: Interrupted: operation was interrupted, collection UUID: 1a489dee-2a27-49cc-9a32-65acb6bdfb55 Aborting index build: 55b67e95-55dd-4072-920d-94ee4b08affa, timestamp: Timestamp(1568353029, 1005), reason: abortIndexBuild oplog entry encountered: DuplicateKey{ keyPattern: { i: 1.0 }, keyValue: { i: 0.0 } }: E11000 duplicate key error collection: test.hybrid_i_r0_p0 index: i_1 dup key: { i: 0.0 }, collection UUID: 4944e76e-0d12-419e-bbe9-5eaece0d1ef2
- is depended on by
-
SERVER-43692 enable two phase index builds by default
- Closed
- related to
-
SERVER-44585 generated abortIndexBuild oplog entry may exceed 16mb causing fassert
- Closed