[SERVER-4698] Disable foreground indexing Created: 17/Jan/12  Updated: 28/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 2.0.2
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Colin Howe Assignee: Unassigned
Resolution: Won't Fix Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

It would be great if there was a configuration option that allowed you to specify that all index builds should be done in the background. Due to a bug on our part we accidentally started an index build on a huge data set in the foreground. This totally locked up our application and we were forced to do some replication failovers. We've taken additional steps at our end but it would be nice if this was prevented by MongoDB itself. For a 24/7 application once a collection gets over a certain size it becomes really undesirable to do a foreground index.



 Comments   
Comment by Colin Howe [ 28/Mar/13 ]

I like that foreground index builds are killable... but they shouldn't be started in the first place (in a big production environment). You can easily knock out your database for a few minutes before even realising that this has happened. Given that MongoDB wants to be the scalable solution for the enterprise then accidental downtime really isn't an option.

Comment by Vinaykr [ 05/Mar/13 ]

This really makes sense for any reasonable production app. It is too easy to shoot your foot with current default indexing option. Would be great to get it in the backlog.

Comment by Eric Milkie [ 05/Mar/13 ]

In-progress foreground index builds are now killable as of version 2.4

Comment by Y. Wayne Huang [ 08/Nov/12 ]

@Brian, see SERVER-3067

Comment by Brian Wylie [ 18/May/12 ]

Just an upvote for this. As my server is currently locked because of an accidental foreground index. It also appears that an index in progress cannot be killed from the mongo console.

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