[SERVER-3935] mixing 1.8.3 and 2.0.0 in a replica set will cause 1.8.3 cannot use it's indexes Created: 23/Sep/11  Updated: 29/Feb/12  Resolved: 24/Sep/11

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Replication
Affects Version/s: 1.8.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Liu Qishuai Assignee: Unassigned
Resolution: Done Votes: 0
Labels: indexing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

1. set up a new replica set on a 2.0.0 server
2. insert some data and create some indexes on them
3. add a 1.8.3 SECONDARY and a ARBITER and wait for the resync to complete
4. stop the PRIMARY, wait for the 1.8.3 SECONDARY to became PRIMARY
5. do some queries on the new 1.8.3 PRIMARY. the server cannot use the indexes.



 Comments   
Comment by Liu Qishuai [ 26/Sep/11 ]

The index is described as

{v: 1}

in system.indexes, but actually the index data is stored in old version. There is no assertion about index version in mongod <= 1.8.2, so it can correctly use the index.

Comment by Eliot Horowitz (Inactive) [ 25/Sep/11 ]

1.8.2 will assert if a v1 index is used.
Not sure what you mean.

Comment by Liu Qishuai [ 25/Sep/11 ]

I don't think it's expected. The 1.8.2 server can use the fake v1 index correctly, but 1.8.3 can't.

Comment by Eliot Horowitz (Inactive) [ 24/Sep/11 ]

This is expected.

See upgrade section in release notes:
http://www.mongodb.org/display/DOCS/2.0+Release+Notes

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