[SERVER-44571] Documents involved in SERVER-44050 corruption scenario cannot be updated or deleted after upgrade Created: 12/Nov/19 Updated: 29/Oct/23 Resolved: 19/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.6.15 |
| Fix Version/s: | 3.6.16, 3.4.24, 4.2.2, 4.0.14, 4.3.2 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | David Storch | Assignee: | Arun Banala |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v4.2, v4.0, v3.6, v3.4
|
||||||||||||
| Sprint: | Query 2019-11-18, Query 2019-12-02 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Ideally, users would be able to recover from As an example, suppose the following was executed on a server version that does not contain the fix for
The user then updates the server to a version that contains the fix for
Due to this limitation, users can only recover by first dropping the index, then cleaning up any documents with arrays on the hash-indexed path, and finally rebuilding the hashed index. These recovery steps could be operationally cumbersome, especially if the index is necessary to support hashed sharding. |
| Comments |
| Comment by Githook User [ 20/Nov/19 ] | ||||||||
|
Author: {'name': 'Arun Banala', 'username': 'banarun', 'email': 'arun.banala@10gen.com'}Message: (cherry picked from commit 35c6778143fc55eb9617ab4a54e616ba1e537ad5) | ||||||||
| Comment by Githook User [ 20/Nov/19 ] | ||||||||
|
Author: {'name': 'Arun Banala', 'username': 'banarun', 'email': 'arun.banala@10gen.com'}Message: (cherry picked from commit 35c6778143fc55eb9617ab4a54e616ba1e537ad5) | ||||||||
| Comment by Githook User [ 20/Nov/19 ] | ||||||||
|
Author: {'name': 'Arun Banala', 'username': 'banarun', 'email': 'arun.banala@10gen.com'}Message: (cherry picked from commit 35c6778143fc55eb9617ab4a54e616ba1e537ad5) | ||||||||
| Comment by Githook User [ 20/Nov/19 ] | ||||||||
|
Author: {'name': 'Arun Banala', 'username': 'banarun', 'email': 'arun.banala@10gen.com'}Message: (cherry picked from commit 35c6778143fc55eb9617ab4a54e616ba1e537ad5) | ||||||||
| Comment by Githook User [ 19/Nov/19 ] | ||||||||
|
Author: {'name': 'Arun Banala', 'username': 'banarun', 'email': 'arun.banala@10gen.com'}Message: | ||||||||
| Comment by David Storch [ 12/Nov/19 ] | ||||||||
|
One further complication is that the behavior is slightly different (and arguably worse) on the 4.2 branch. I used 4.2.0 to produce a corrupt hashed index per
This shows that in 4.2, documents with an illegal array along the hashed path can be deleted. However, the index maintenance code does not clean up the incorrect index keys associated with such documents. The index therefore remains in a bad state even after the bad documents have been cleaned up. This situation can be remedied by rebuilding the index. However, it would be better to allow users to recover from | ||||||||
| Comment by David Storch [ 12/Nov/19 ] | ||||||||
|
I only marked this as affecting 3.6.15, since it looks like that is the only version that has actually been released as of this writing that contains the fix for |