-
Type: Improvement
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Admin, Index Maintenance
-
None
Problem: installed deployments are likely to contain documents whose for which index keys are too long to index. MongoDB 2.6 will be stricter about long index keys than earlier versions.
Proposal: the 2.6 release could include a command that looked for overly long index keys in a collection, and, depending on a boolean argument, either counted the number of bad documents, or else wrote each document to a BSON file in the dbpath and removed the document from the collection.
Rationale for setting aside offending documents in the mongod: suppose the collection only has an index on _id, then uniqueness of _id values isn't enforced, and so there may not be any unique value that identifies a document with overly long _id fields. So just reporting the bad documents will not be enough for a client program to issue valid cleanup operations in all cases.
Rationale for a boolean argument saying whether to count or set aside the documents: (a) users might want to assess the magnitude of the problem before clearing out the offending documents, and probably wants to do that assessment on secondaries but a command that changes collections has to be run on a primary.
Documentation changes needed: once this command exists, it needs to be documented, and the release notes/upgrade steps should recommend using this command to look for and/or clean out offending documents as part of the upgrade process (e.g., upgrade one secondary (per shard), then run this command).
- is related to
-
SERVER-5290 fail to insert docs with fields too long to index, and fail to create indexes where doc keys are too big
- Closed
- related to
-
SERVER-8391 Pre-flight upgrade tool to check for changes breaking backwards compatibility or introducing regressions
- Closed