[SERVER-32225] Initial sync should ignore multiple text indexes on same collection error Created: 08/Dec/17 Updated: 30/Oct/23 Resolved: 21/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc4, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Ali Mir |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | former-quick-wins | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.4, v4.2, v4.0, v3.6
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2020-03-23, Repl 2020-04-06, Repl 2020-04-20, Repl 2020-05-04 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 8 | ||||||||||||||||||||||||||||||||||||
| Description |
|
|
| Comments |
| Comment by Githook User [ 30/May/20 ] | ||||||||
|
Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: This reverts commit 73a812bd10647977e7b2ad6f1614ab0cfbe2b007. | ||||||||
| Comment by Githook User [ 27/May/20 ] | ||||||||
|
Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: This reverts commit 7ce7dc274c7c899855f14ac55b5344b32399598c. | ||||||||
| Comment by Suganthi Mani [ 26/May/20 ] | ||||||||
|
siyuan.zhou Filed SERVER-48423 to address the issue. | ||||||||
| Comment by Githook User [ 05/May/20 ] | ||||||||
|
Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: (cherry picked from commit 7ce7dc274c7c899855f14ac55b5344b32399598c) | ||||||||
| Comment by Githook User [ 21/Apr/20 ] | ||||||||
|
Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: | ||||||||
| Comment by William Schultz (Inactive) [ 31/Jan/20 ] | ||||||||
|
If we need to write a repro test when working on the fix for this, I'd be interested to see if we could reproduce some of the original bugs in the initial sync fuzzer. We recently worked on a manual repro for something similar in | ||||||||
| Comment by Siyuan Zhou [ 08/Nov/19 ] | ||||||||
|
Right, I think the correctness depends on the fact we cannot change the index name and update another field in the same command. | ||||||||
| Comment by Judah Schvimer [ 08/Nov/19 ] | ||||||||
|
So siyuan.zhou, am I correct that the safety of the index case is based on the fact that the only "unique index" for indexes is on the name, which is the primary key? The above case for documents only exists when there is a secondary unique index? | ||||||||
| Comment by Siyuan Zhou [ 07/Nov/19 ] | ||||||||
|
Here's an example of an update modifying more than one field. We cannot just ignore the duplicate key error since there might be other fields modified in the same operation as in the following case (as discussed in CLOUDP-5551:
| ||||||||
| Comment by Judah Schvimer [ 07/Nov/19 ] | ||||||||
siyuan.zhou, what do we do here now for normal updates? Is the document guaranteed to be removed in the case you're describing? | ||||||||
| Comment by Siyuan Zhou [ 07/Nov/19 ] | ||||||||
|
Thanks louis.williams! Since index can be viewed as a document with a unique index on its name in terms of idempotnecy. I was wondering whether a similar case of updating a unique indexed field and another normal field in one update could happen. If the update on unique indexed field fails and rolls back the change of the normal field in the same WT transaction, then we'll lose the change of the normal field when ignoring the error. I don't think a similar case could happen here. The worst case is to change the "expireAfterSeconds" on a wrong index, but the wrong index will be dropped eventually. Thus ignoring the error should be safe. | ||||||||
| Comment by Louis Williams [ 04/Nov/19 ] | ||||||||
|
siyuan.zhou the only property of an index that may change is the "expireAfterSeconds" with collMod, which is used for TTL indexes, but an index may not change names. | ||||||||
| Comment by Siyuan Zhou [ 17/Oct/19 ] | ||||||||
|
To my understanding, we only allow create and drop indexes, so there's no way to update a property of an existing index or change its name. louis.williams, is this correct? If so, I think the proposed solution is safe in term of idempotency. |