Mongo upgrade from 3.4 to 3.6 config.system.sessions is not sharded.

[Balakrishnan Babu]

Hello, 

I have upgraded my mongo cluster from mongo 3.4.15 to 3.6.5. After the upgrade I am getting the following error. 

Refresh for collection config.system.sessions took 8 ms and found the collection is not sharded

This is the method I followed. 

I have 2 shards in 3 servers and config servers are shared in the mongo shard. 

1. db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )

Run this command from Mongos. 

2. Made sure the compatiblity is 3.4 before starting the upgrade. 

3. Stop the balancer. 

4. Choose the secondary. Gracefully shutdown the servers.

5, Remove the 3.4 packages. 

6. Install 3.6.5 packages. 

7. Start the mongod and mongo config server. 

8. Wait for the servers to join the cluster. 

9. Repeat the steps from 4 to 8 for the other secondary. 

10. Step down the mongo shard primary and mongo config primary. 

11. Repeat steps 4 to 8 on the last secondary. 

12. After that upgrade the mongos component. 

13. Start the balancer. 

14. Set the compatibility to 3.6.

14. Monitor the error logs.

Please let me know what I am doing wrong and how to correct it. 

Thank you, 

[Kevin Adistambha]

Hi,

I general the procedure you outlined seems to generally conform to the one posted in Upgrade a Sharded Cluster to 3.6. Could you please ensure that all the details are also correct as per the linked documentation page?

The log line you mentioned seems to indicate that this is not an error, but an informative message. Perhaps the messages are printed to the logs during the upgrade process? Are you seeing the message regularly even after setting the setFeatureCompatibilityVersion to 3.6? Also, have you seen any detrimental issues in relation to this message, e.g. crashing mongod process, etc.?

Please note that the config.system.sessions collection is used internally by MongoDB and should not be manipulated manually.

On a related note, please be advised that it’s not recommended to run multiple mongod processes inside a single machine as they can create a resource contention. Therefore the setup you described (running the config servers processes in the same hardware that’s running the shards) is strongly not recommended in a production environment.

Best regards
Kevin

​

[Balakrishnan Babu]

Yes I confirm I had followed the guidelines mentioned in the document.  The issue here is config.system.sessions is not sharded. And its throwing the message every 30 seconds. And its spamming the entire cluster. I am not sure how I can resolve it. Lucky it was my load test environment. Planning to do a downgrade to 3.4.16 next week. 

I am glad you replied 

Thank you 

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to a topic in the Google Groups "mongodb-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongodb-user/FK51OlgbTK0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mongodb-user+unsubscribe@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/51b139a3-c293-4da3-8e6d-75bd42a1418f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.