[SERVER-9856] No check for building identical background indexes concurrently Created: 04/Jun/13 Updated: 11/Jul/16 Resolved: 10/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 2.4.4, 2.5.0 |
| Fix Version/s: | 2.4.5, 2.5.1 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Thomas Rueckstiess | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
Everything seems to work ok, until you
After one of these operations, even hinting on that particular index fails with the same error. It seems the index does get deleted but not properly cleaned up. |
||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Issue Status as of Sep 19, 2014 ISSUE SUMMARY USER IMPACT
When upgrading to MongoDB 2.6.x, this index corruption is detected during the startup sequence and the server aborts as follows:
WORKAROUNDS Users running a standalone server may temporarily convert the standalone node to a replica set, then add a new node to the replica set. Once the new node has finished its initial sync, shut it down and restart it as a standalone instance, and manually build the indexes that were corrupted on the primary. The new instance should now be used instead of the original one. Alternatively, standalone servers can be recovered by running repairDatabase() using a 2.4-series MongoDB version 2.4.5 or older. Then it is safe to upgrade to MongoDB 2.6. If running MongoDB 2.4 is preferred, it is highly recommended to upgrade to the latest 2.4.x release. AFFECTED VERSIONS FIX VERSION RESOLUTION DETAILS Original descriptionSince 2.4 it is possible to build background indexes concurrently. There is no check if that index is the same one, which can lead to a situation where the same index exists multiple times on a collection. Trying to drop that index, or all indexes, or the collection leads to this error:
Subsequent queries using the half-dropped index will result in errors as well. In 2.4.x, the secondaries were unaffected by this because we didn't allow background index builds on secondaries. The index was only present once on the secondary. In 2.5.0 the duplicate index carries over to the secondaries and show the same behavior as the primaries. This is a regression from 2.2 where a second background index build was not allowed and therefore the bug could not occur. A db.repairDatabase() seems to fix the problem. |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 01/Jul/13 ] |
|
chengas123, we don't have a quick fix available to remove the extra indexes at this point other than doing a repair database. There are a couple of alternatives:
|
| Comment by Wiliam [ 01/Jul/13 ] |
|
That would be great Ben McCann, repairDatabase is a expensive task y large databases. |
| Comment by Ben McCann [ 01/Jul/13 ] |
|
Can you guys also add a fix to allow proper deletion of the multiple indexes? My disk is 60% used, so I will not be able to run db.repairDatabase() |
| Comment by auto [ 19/Jun/13 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by auto [ 10/Jun/13 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |