[SERVER-38145] Extend upgradeCheckAllDBs() and/or upgradeCheck() to look for indexes not compliant with version 3.4 index definition rules Created: 15/Nov/18  Updated: 09/May/19  Resolved: 09/May/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: William Byrne III Assignee: Kelsey Schubert
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File index34.js    
Issue Links:
Related
Participants:
Case:

 Description   

Version 3.4 introduced stricter validation of index specifications.

However, the new code is only run when an index is recreated, meaning the following scenario is all too possible:

  • In version 3.2, an index with key {cust_id:1, background:true} is created.
  • The weaker syntax checking in that version does not catch the missing }, { and instead of a single field index on cust_id created in background, a compound index is created in the foreground with a non-existent second field called "background" appended to the key).
  • upgrade in place to 3.4 of PSA replica set goes through without error
  • more upgrades to 3.6 and 4.0 can also succeed.
  • Then when hardware failure necessitates the resyncing of a node, it fails on the recreate of this index due to the non-compliant definition.
  • likewise if the OM/CM headDB becomes stale and needs to be resynced, it will fail.

To enable DBA's to detect and fix index definitions that do not comply with the stricter rules in version 3.4 and later, it would be nice if the upgradeCheck utilities (or some other new utility) existed that would examine all indexes for a collection/database/cluster and report on those that cannot be upgraded.

It would be better to discover and repair them in planned outage windows than in the midst of an already unplanned outage.

Many of these boolean fields in version 3.2 index keys are called unique, sparse and background, meaning they were almost certainly intended to be index options and not part of the key, so the index is not created as intended either, and it is in the customer's interest to fix that too.



 Comments   
Comment by Kelsey Schubert [ 09/May/19 ]

Including this feature inside of MongoDB is expensive, and may require minimum floors before upgrading. Instead, we're looking into external tools that behave similar to the script William provided which would address the same user pain without concern about which particular version they are are on before upgrading.

Comment by William Byrne III [ 07/Jan/19 ]

The attached script has been replaced with one that has comments: index34.js

The side effects if the non-compliant key field comes from index options mistakenly added to the key is as follows:

Intended Index Option Actual Key Effect
create in background {lsid:1, background:true} Index is created in foreground, blocking other jobs
sparse index {lsid:1, sparse:true} Index is not sparse, and is being updated for every insert/delete
unique index {lsid:1, unique:true} Index does not enforce uniqueness of lsid

The impact of indexes with these mistakes in their definition is mostly small. Once created, the index that was intended to be built in the background will probably be used by the Query Planner in exactly the way the index with the correct definition would be, and will return the correct results. This is because the intended key is most commonly an [index prefix](https://docs.mongodb.com/v3.4/core/index-compound/#prefixes) of the actual key. Similarly, the non-sparse index will assist queries correctly.

All three options specification errors will waste space, as the extra non-existent field name at the end of the key will be indexed as a null for every entry. An index intended to be sparse will waste more space as it will index all the documents with null key field values.

The most serious potential impact is from uniqueness not being enforced as expected, as that means duplicate documents would be loaded without error.

Generated at Thu Feb 08 04:48:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.