[SERVER-46147] Update repair to fix multikey errors without performing an index rebuild Created: 14/Feb/20 Updated: 29/Oct/23 Resolved: 29/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0, 4.4.10 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Brian Lane | Assignee: | Fausto Leyva (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | intern_validate_improvements | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||||||||||||||
| Sprint: | Execution Team 2020-05-04, Execution Team 2020-07-27, Execution Team 2020-08-10 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
When we have validation errors with multikey flags such as: "... is not multi-key but has more than one key in document" would be great when running repair if we could actually correct these without needing to rebuild the index. Proposed solution:
|
| Comments |
| Comment by Githook User [ 17/Sep/21 ] |
|
Author: {'name': 'Faustoleyva54', 'email': 'fausto.leyva@mongodb.com', 'username': 'Faustoleyva54'}Message: (cherry picked from commit 6dd3014) |
| Comment by Githook User [ 28/Jul/20 ] |
|
Author: {'name': 'Faustoleyva54', 'email': 'fausto.leyva@mongodb.com', 'username': 'Faustoleyva54'}Message: |
| Comment by Fausto Leyva (Inactive) [ 27/Jul/20 ] |
| Comment by Louis Williams [ 01/Jul/20 ] |
|
Could we make this validation repair behavior a standalone-only feature? That would be consistent with reIndex, which is also standalone-only. |
| Comment by Daniel Gottlieb (Inactive) [ 05/May/20 ] |
|
An alternate implementation of ghost timestamping I mentioned to vamsi.krishna and chenhao.qu was asking WT to find an appropriate timestamp for an update. For our ghost timestamping cases, it would be min(<last update's durable_timestamp>, <stable_timestamp> + 1). We can also emulate this in MongoDB (with more stable_timestamp retrying for races) if WT exposed a document version's durable_timestamp value. |
| Comment by Eric Milkie [ 05/May/20 ] |
|
I'm kind of torn. It would be really nice to have a way to correct these problems on a running system without needing to restart the process (twice!) to use --repair. But only the --repair solution is straightforward. |
| Comment by Louis Williams [ 05/May/20 ] |
|
Just clarifying that there are no problems with a solution that only implements this behavior in --repair mode. The options that Dan suggested are to expand this behavior to work with the validate command on a live server. |
| Comment by Daniel Gottlieb (Inactive) [ 05/May/20 ] |
|
Had a conversation with gregory.wlodarek and louis.williams. The trouble with correcting multikey values is that there's no natural optime associated with this write. We wanted to raise our known options with a greater audience. What we have include:
|
| Comment by Eric Milkie [ 06/Apr/20 ] |
|
Another option is to add a special flag to the validate command to permit it to make data changes rather than just observe them. |
| Comment by Eric Milkie [ 27/Feb/20 ] |
|
Repair doesn't run a validate-like scan ahead of time, so I'm not sure how it would identify this situation prior to rebuilding indexes. We would have to have the validate command save something durable for repair to look at, possibly? Sounds tricky. |