并提前感谢您的时间。
对于给定的分片设置，在指定要与之通信的配置服务器时启动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看到它只是一个字符串比较，但我的问题是这个的根本原因。
此问题的一些背景：我正在使用厨师进行我的mongo部署。我们最近进行了migrating the config server with the same hostname的练习。然而，这仍然是一个破坏性的过程，因为厨师拿起配置服务器的顺序已经改变，因此改变订单mongos开始其过程。我知道这个问题直接是因为厨师的功能，但我很好奇为什么Mongo不灵活。
再次感谢您的时间。
答案 0 :(得分：2)
当mongos进程更改分片群集的元数据时，它必须“同时”在所有三个配置服务器中更改它（即所有三个必须达成一致才能进行有效的元数据更改）。
如果系统在这样的元数据更改过程中发生故障，如果未修复配置数据库顺序，则可能存在更多可能排除错误状态的排列。要求固定的配置dbs序列允许（a）更简单地检查集群的所有成员是否正在查看相同的元数据（b）当系统崩溃或以其他方式意外停止时，可能状态的显着减少。
此外，如果不同的mongos'可以在不同的配置服务器上启动相同的操作，它还可以减少“竞争条件”类型的错误。即使作为mongos进程的简单更改采用“虚拟”分布式锁定以查看是否有必要 - 您如何处理不同mongos'检查配置服务器的情况以不同的顺序检查（并取出锁？
总结一下，三个配置服务器不是一个副本集，但其中一个仍然必须是始终接受“第一个”更改的那个 - 想想configdbs的顺序mongos被指定为这种“第一”身份。