-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.4.14, 3.6.7, 4.0.2
-
Component/s: Index Maintenance, Replication
-
None
-
Fully Compatible
-
ALL
-
v4.0, v3.6, v3.4
-
-
Storage NYC 2018-09-24, Storage NYC 2018-10-08
MongoDB 3.4 introduced validation of index options (SERVER-769). This validation applies to all newly created indexes, regardless of index version. 3.4 also introduced v:2 indexes, so it is illegal for any unknown/unvalidated options to be present in the index catalog for a v:2 index spec. However, old v:1 indexes may exist with unknown options, and oplog entries for creating v:1 indexes with illegal options may exist.
Therefore, the applyOps command should ignore any unknown options when creating a v:1 index. On the other hand, applyOps should error on unknown options for v:2 indexes. This works correctly for op:"c" createIndexes oplog entries:
MongoDB Enterprise > db.adminCommand({applyOps: [{op:"c", ui: UUID("a0aff12b-0a98-429b-9f2a-892b57fcdbd5"), ns: "test.$cmd", o: {createIndexes: "c", key: {a:1}, name: "a_1", v:1, unknown: 1}}]}) { "applied" : 1, "results" : [ true ], "ok" : 1 } MongoDB Enterprise > db.adminCommand({applyOps: [{op:"c", ui: UUID("a0aff12b-0a98-429b-9f2a-892b57fcdbd5"), ns: "test.$cmd", o: {createIndexes: "c", key: {b:1}, name: "c_1", v:2, unknown: 1}}]}) { "applied" : 1, "code" : 197, "codeName" : "InvalidIndexSpecificationOption", "errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { key: { b: 1.0 }, name: \"c_1\", v: 2.0, unknown: 1.0, ns: \"test.c\" }", "results" : [ false ], "ok" : 0 }
However, when the oplog entry is an insert into system.indexes, unknown options are rejected regardless of index version:
MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", unknown: 1, v: 1}}]}) { "applied" : 1, "code" : 197, "codeName" : "InvalidIndexSpecificationOption", "errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", unknown: 1.0, v: 1.0 }", "results" : [ false ], "ok" : 0 } MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", unknown: 1, v: 2}}]}) { "applied" : 1, "code" : 197, "codeName" : "InvalidIndexSpecificationOption", "errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { collation: { locale: \"simple\" }, ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", unknown: 1.0, v: 2.0 }", "results" : [ false ], "ok" : 0 }
This is not the expected behavior in the v:1 case. It looks like this is due to applyOps's implementation of insert into system.indexes in terms of the DBDirectClient. Support for anything related to system.indexes was recently removed as part of SERVER-36015, but this issue still affects older versions.
- is related to
-
SERVER-28594 non-atomic applyOps should log each individual op
- Closed
-
SERVER-31161 Index created through applyOps command should not inherit collection default collation
- Closed
-
SERVER-769 Validate top-level & index spec field names for the createIndexes command
- Closed
-
SERVER-36015 Remove references to system.namespaces and system.indexes
- Closed
- related to
-
SERVER-37333 [3.4] applyOps does not validate background index spec for system.indexes inserts
- Closed