Mongos specified a different config database string

Working with Data
1

I’m keeping seeing this error when I try to do anything in my mongo cluster.

The interesting is when I do:
sh.status()
the first five times does not work and give this error:
"could not initialize sharding on connection domain-name3:27017 :: caused by :: mongos specified a different config database string : stored : domain-name3:27017 vs given : domain-name1:27017,domain-name2:27017,domain-name3:27017

after a few times doing
sh.status()
then it works.

Why do I have this issue and how can I fix this?
MongoDB shell version: 2.4.8

2

Welcome to the MongoDB Community Forums @Joao_Luiz_Castro_Nau!

This message indicates a mongos was started with a different configDB value than expected. In MongoDB 2.4 all mongos must use identical config database strings.

MongoDB 2.4.8 was released in November 2013 and the MongoDB 2.4 server series reached End of Life in March, 2016. I strongly encourage you to upgrade to the final 2.4.14 release and plan your upgrade path to a supported version (current MongoDB 4.0 or newer). There have been many critical improvements in stability, performance, features, and security since the 2.4 release series.

Regards,
Stennie

1 Like
3

Ok, so what I will try to do is:

  • stop all the mongos
  • copy folder from one config to others
  • start mongos

What do you think

4

Hi @Joao_Luiz_Castro_Nau ,

Have you changed any config server hostnames prior to seeing this message occurring? If so, there’s a tutorial to Migrate Config Servers with Different Hostnames (MongoDB 2.4).

If not, it would be worth trying:

  • shut down all mongos processes
  • restart all mongos with a consistent configDB string (including the order of servers)

If the mongos shutdown & restart approach doesn’t resolve your error, the tutorial approach including shutting down all MongoDB processes should.

This is a very old version of MongoDB; config servers in modern server versions are now replica sets and much more straightforward to manage.

Regards,
Stennie

5

Unfortunately the approach above does not solved this issue. I think now I need a specialist for solving this issue. Here is the community, maybe if I send a message here looking for a specialist of old versions, do you think I can find one? If not, there is a channel where I can find multiple mongo specialists?

6

Hi @Joao_Luiz_Castro_Nau,

Which of the suggested approaches did you try? If shutting down all the mongos processes wasn’t sufficient, I expect shutting down all mongod and mongos processes per the MongoDB 2.4 tutorial link should have worked.

We don’t have a job category in the forums at the moment – I would look to your normal channels where you would hire trusted consultants or experts.

If you are going to hire a specialist, I would get their advice to plan an upgrade to a modern and supported version of MongoDB. For example, MongoDB’s Consulting team has a Major Version Upgrade package.

For some approaches to consider if you want to fast track upgrading through multiple major versions, see Replace mongodb binaries all at once? - #3 by Stennie_X.

Regards,
Stennie

7

hoi hoi stennie

Just to let you know, we decided to rebuild the cluster from scratch, because I tried to make this process Migrate Config Servers with Different Hostnames — MongoDB Manual and does not work. I think the configdb folder got different because we did some mistake and got corrupt.
But now i still have the old data there that we would love to get back.
In this case do you have some suggestion on how can I get those datas there using another approach? Like maybe connect direct from the replicas? What do you think.