提前感谢你的时间。
对于给定的分片设置，在指定要与之对话的配置服务器时启动mongos。假设我们从以下mongos选项开始：
--configdb=cf1,cf2,cf3
一切都很好。如果要重新启动mongos（或启动其他mongos），请执行以下操作：
-- configdb=cf3,cf2,cf1
会导致以下错误：
Tue Jul 9 23:32:41 uncaught exception: error: { "$err" : "could not initialize sharding on connection rs1/db1.me.net:27017,db2.me.net:27017,db3.me.net:27017, :: caused by :: mongos specified a different config database string : stored :cfg1:27017,cfg2:27017,cfg3:27017 vs given :cfg3:27017,cfg2:27017,cfg1:27017","code" : 15907}
我的问题是，Mongo对配置服务器字符串的顺序敏感的推理是什么？我可以想象在某个时候它会解析不同的服务器主机名/端口，那么为什么不直接比较一下这个集合呢？我知道您可以从source code中看到，这只是一个字符串比较，但我的问题是造成这种情况的根本原因。
这个问题的一些上下文：我正在使用chef进行mongo部署。我们最近进行了migrating the config server with the same hostname练习。但是，这仍然是一个中断性的过程，因为主厨获取配置服务器的顺序已经改变，因此更改mongos开始其过程的顺序。我知道这个问题直接是因为厨师的功能，但是我很好奇为什么mongo没有这么灵活。
再次感谢你的时间。
最佳答案
当mongos进程更改分片集群的元数据时，它必须“同时”更改所有三个配置服务器中的元数据（即，为了进行有效的元数据更改，所有三个配置服务器必须一致）。
如果系统在这种元数据更改过程中崩溃，如果配置数据库顺序不固定，则可能会有更多不正确状态的排列来展开。需要固定的配置数据库序列可以（a）更简单地检查集群的所有成员是否正在查看相同的元数据（b）在系统崩溃或意外停止时显著减少可能的状态。
此外，如果不同的mongos'可以在不同的配置服务器上启动相同的操作，那么它还减少了“竞争条件”类错误的机会。即使是像mongos流程这样的简单更改，使用一个“虚拟”分布式锁来查看是否有必要—您如何处理不同的mongos'检查配置服务器以不同的顺序检查（并取出）锁的情况？
总之，这三个配置服务器不是一个副本集，但其中一个仍然必须是始终接受“第一个”更改的服务器-将configdbs到mongos的顺序视为此类“第一个”状态的指定。
关于mongodb - 启动mongos时，为什么配置服务器字符串顺序敏感？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17930872/