-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Execution Team 2021-01-25, Execution Team 2021-02-08
-
(copied to CRM)
Index multikey metadata can either become inconsistent with collection data or more permissive than the data requires. There are three main ways this can happen:
- Indexes built before 3.4 (
SERVER-15086) lack path-specific multikey metadata. All fields in an index are considered multikey and require blocking sorts. SeeSERVER-33387. - Collection data has changed such that certain document paths are no longer multikey.
- Bugs:
SERVER-48471,SERVER-47694,SERVER-43074, etc.
Multikey metadata may only be made less restrictive. If a collection's data has changed such that an index no longer has multikey documents or the multikey paths include more fields than are multikey, then the multikey metadata may be inconsistent. This is correct and allowed by the implementation, but it can lead to undesirable performance problems. The only solution is to reindex.
Collection validation scans all documents and generates multikey information, and it has the ability to fix index multikey metadata without returning an error. Allow foreground validation to "fix up" the following permitted inconsistencies:
- An index is multikey but there are no multikey fields
- An index has multikeyPaths covering fields that are not multikey
- An index does not have multikeyPaths but there are multikey documents (for pre-3.4 indexes)
- related to
-
SERVER-56877 insert operations may fail to set index to multikey after aborted multikey catalog update
- Closed
-
SERVER-57083 Coverity analysis defect 120111: Parse warning
- Closed
-
SERVER-61509 full validation attempts to fix up multikey on read-only server
- Closed