[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:
Backports
Depends
is depended on by SERVER-33946 Decrease number of initial sync attem... Blocked
Problem/Incident
causes SERVER-48457 Revert ignoring multiple text indexes... Closed
Related
related to SERVER-28071 FTS index language override parsing e... Closed
is related to SERVER-48423 Initial sync should ignore multiple t... Backlog
is related to SERVER-27122 Restart initial sync for known index ... Backlog
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   

SERVER-26202 relaxed a lot of index constraints but missed a few. We should re-audit index_catalog_impl.cpp for errors that can be ignored.



 Comments   
Comment by Githook User [ 30/May/20 ]

Author:

{'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}

Message: SERVER-48457 Revert "SERVER-32225 Only limit number of text indexes created by user connections"

This reverts commit 73a812bd10647977e7b2ad6f1614ab0cfbe2b007.
Branch: v4.4
https://github.com/mongodb/mongo/commit/6552d96ab0432f521322262b6b3764460545e0eb

Comment by Githook User [ 27/May/20 ]

Author:

{'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}

Message: SERVER-48457 Revert "SERVER-32225 Only limit number of text indexes created by user connections"

This reverts commit 7ce7dc274c7c899855f14ac55b5344b32399598c.
Branch: master
https://github.com/mongodb/mongo/commit/2cb53453d3feed404c8c946f3353e6bc1b68fa62

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: SERVER-32225 Only limit number of text indexes created by user connections

(cherry picked from commit 7ce7dc274c7c899855f14ac55b5344b32399598c)
Branch: v4.4
https://github.com/mongodb/mongo/commit/73a812bd10647977e7b2ad6f1614ab0cfbe2b007

Comment by Githook User [ 21/Apr/20 ]

Author:

{'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}

Message: SERVER-32225 Only limit number of text indexes created by user connections
Branch: master
https://github.com/mongodb/mongo/commit/7ce7dc274c7c899855f14ac55b5344b32399598c

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 SERVER-32903, and it seemed a good candidate for a bug that the initial sync fuzzer could catch and deterministically reproduce. I would be interested in the prospect of adding create/drop index operations to the fuzzer grammar as a part of fixing this or related tickets, if it adds sufficient value.

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:

I {_id : 1, a:2}
--- Clone Start Optime ---
U {_id : 1, b:3}
U {_id : 1, a:1, b:1}  // This cannot be ignored due to a duplicate key error.
U {_id : 1, a:2}
I {_id : 2, a:1}
--- Clone End Optime ---
Reapplying from Clone Start Optime to Clone End Optime.

Comment by Judah Schvimer [ 07/Nov/19 ]

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.

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.

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