[SERVER-27531] setFeatureCompatibilityVersion to 3.4 Created: 28/Dec/16  Updated: 18/Jan/17  Resolved: 18/Jan/17

Status: Closed
Project: Core Server
Component/s: Admin
Affects Version/s: 3.4.1
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: yang hao Assignee: Kelsey Schubert
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File conn151.log     PNG File screenshot-1.png    
Operating System: ALL
Participants:

 Description   

when we setFeatureCompatibilityVersion to 3.4
mongod shard log :
2016-12-28T11:20:43.472+0000 I INDEX [conn1435] build index on: admin.system.version properties: { v: 2, key:

{ version: 1 }

, name: "incompatible_with_version_32", ns: "admin.system.version" }
2016-12-28T11:20:43.472+0000 I INDEX [conn1435] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2016-12-28T11:20:43.475+0000 I INDEX [conn1435] build index done. scanned 4 total records. 0 secs
2016-12-28T11:20:43.476+0000 I COMMAND [conn1435] setting featureCompatibilityVersion to 3.4
2016-12-28T11:20:45.307+0000 I COMMAND [conn1435] setting featureCompatibilityVersion to 3.2
2016-12-28T11:20:45.307+0000 I COMMAND [conn1435] CMD: dropIndexes admin.system.version
2016-12-28T11:20:45.582+0000 I COMMAND [conn1435] setting featureCompatibilityVersion to 3.2
2016-12-28T11:20:45.582+0000 I COMMAND [conn1435] CMD: dropIndexes admin.system.version
^C



 Comments   
Comment by Kelsey Schubert [ 18/Jan/17 ]

Hi 282848081@qq.com,

We haven’t heard back from you for some time, so I’m going to mark this ticket as resolved. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Regards,
Thomas

Comment by Tess Avitabile (Inactive) [ 05/Jan/17 ]

I can confirm by looking at the logs that the shard received the command {setFeatureCompatibilityVersion: "3.4"}:

2016-12-29T13:46:06.177+0000 D COMMAND  [conn151] run command admin.$cmd { setFeatureCompatibilityVersion: "3.4" }

The command succeeded:

2016-12-29T13:46:06.233+0000 I COMMAND  [conn151] setting featureCompatibilityVersion to 3.4
2016-12-29T13:46:06.277+0000 I COMMAND  [conn151] command admin.$cmd appName: "MongoDB Shell" command: update { update: "system.version", updates: [ { q: { _id: "featureCompatibilityVersion" }, u: { version: "3.4" }, upsert: true } ], writeConcern: { w: "majority" } } numYields:0 reslen:159 locks:{ Global: { acquireCount: { r: 4, w: 4 } }, Database: { acquireCount: { w: 2, W: 2 } }, Collection: { acquireCount: { w: 2 } }, Metadata: { acquireCount: { w: 2 } }, oplog: { acquireCount: { w: 2 } } } protocol:op_query 47ms
2016-12-29T13:46:06.278+0000 I COMMAND  [conn151] command admin.$cmd appName: "MongoDB Shell" command: setFeatureCompatibilityVersion { v: 2, key: { version: 1 }, ns: "admin.system.version", name: "incompatible_with_version_32" } numYields:0 reslen:134 locks:{ Global: { acquireCount: { r: 4, w: 4 } }, Database: { acquireCount: { w: 2, W: 2 } }, Collection: { acquireCount: { w: 2 } }, Metadata: { acquireCount: { w: 2 } }, oplog: { acquireCount: { w: 2 } } } protocol:op_command 98ms

Immediately after, the shard received the command {setFeatureCompatibilityVersion: "3.2"}:

2016-12-29T13:46:06.734+0000 D COMMAND  [conn151] run command admin.$cmd { setFeatureCompatibilityVersion: "3.2" }

This command also succeeded:

2016-12-29T13:46:06.740+0000 I COMMAND  [conn151] setting featureCompatibilityVersion to 3.2
2016-12-29T13:46:06.791+0000 I COMMAND  [conn151] command admin.system.version command: dropIndexes { dropIndexes: "system.version", index: "incompatible_with_version_32", writeConcern: { w: "majority" } } numYields:0 reslen:114 locks:{ Global: { acquireCount: { r: 4, w: 4 } }, Database: { acquireCount: { w: 2, W: 2 } }, Collection: { acquireCount: { w: 1 } }, Metadata: { acquireCount: { w: 2 } }, oplog: { acquireCount: { w: 2 } } } protocol:op_query 41ms
2016-12-29T13:46:06.791+0000 I COMMAND  [conn151] command admin.$cmd command: setFeatureCompatibilityVersion { setFeatureCompatibilityVersion: "3.2" } numYields:0 reslen:134 locks:{ Global: { acquireCount: { r: 4, w: 4 } }, Database: { acquireCount: { w: 2, W: 2 } }, Collection: { acquireCount: { w: 1 } }, Metadata: { acquireCount: { w: 2 } }, oplog: { acquireCount: { w: 2 } } } protocol:op_command 56ms

I do not know why the shard received the command {setFeatureCompatibilityVersion: "3.2"}. It would be helpful to see logs from the mongos and/or the config primary. If running the command {setFeatureCompatibilityVersion: "3.4"} on the mongos returned an error message, that would be useful too. Thank you for your help!

Comment by Tess Avitabile (Inactive) [ 04/Jan/17 ]

Thank you, the logs from the shard primary are very helpful. Can you also please attach the log of the mongos?

Comment by yang hao [ 30/Dec/16 ]

log file is conn151

Comment by Daniel Pasette (Inactive) [ 29/Dec/16 ]

can you attach the complete log of the mongos which you ran the setFeatureCompatibility command on as well as the complete log of one of the primary nodes of one of you shard replica sets?

Comment by yang hao [ 29/Dec/16 ]

Comment by yang hao [ 29/Dec/16 ]

Hi Thomas,
we have six nodes(three shards,one relpset every shard) ,three config servers,like:

we upgrade from 3.2.10

we stop balance and upgrade the cluster use opsmanager(3.4.0.383) then start balance

we execute it on mongos , fail, then use opsmanager set to 3.4 also fail.

yes, all nodes in my cluster affected by this issue

Comment by Kelsey Schubert [ 28/Dec/16 ]

Hi 282848081@qq.com,

Thank you for reporting this issue. I have a few questions that will help us better understand what is happening.

  1. Would you please describe your sharded cluster? How many nodes, shards, config servers, etc?
  2. Would you please describe your upgrade process?
  3. Which versions of MongoDB have you run previously with these data files?
  4. Would you please clarify how you are setting setFeatureCompatibilityVersion to 3.4? Is it being executed on a mongos or mongod?
  5. Are all nodes in your cluster affected by this issue?

Thanks for your help,
Thomas

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