[SERVER-16449] Validate indexes early during initial sync Created: 08/Dec/14  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-12309 Initial sync should build indexes whi... Closed
Assigned Teams:
Replication
Participants:

 Description   

Validate index definitions early in initial sync, otherwise If an invalid index is present (eg. field starts with '$') this won't be discovered until much work has been done, which may include copying all the data for the database and applying parts of the oplog.



 Comments   
Comment by Kevin Pulo [ 09/Dec/14 ]

Yes, db.upgradeCheck() warns about these indexes. However, it's only advisory — if the replset is upgraded anyway (and it can be), then it will continue to function normally (until an initial sync fails in this way).

You're correct that this is mostly about 2.4 -> 2.6, since these indexes can easily be made in 2.4 (and earlier), and are invalid in 2.6 (and later). A backport to 2.6 would be very useful, however there is still value in having this fixed without a backport, since that would at least protect against the scenario of 2.4 -> 2.6 -> 2.8 in (relatively) rapid succession (i.e. without intervening initial syncs).

There is also the issue of adding a 2.6/2.8 member to an otherwise 2.4 replset (e.g. for testing prior to upgrading). Even though this isn't a great idea, it is possible and isn't great to have it fail after cloning.

Comment by Eric Milkie [ 08/Dec/14 ]

The upgradeChecker can be used to detect such indexes before upgrading to 2.6. Is it correct that in order for this feature to be useful, it would be targeted at users who upgraded 2.4 to 2.6 without running the upgradeChecker? We would have to backport this feature to the 2.6 series.

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