[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: |
|
||||||||
| 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. |