mongodb - 为什么在启动 mongos 时配置服务器字符串顺序敏感？

Question

提前感谢您的宝贵时间。

对于给定的分片设置，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 不那么灵活。

再次感谢您的宝贵时间。

Answer 1

当 mongos 进程更改分片集群的元数据时，它必须“同时”在所有三个配置服务器中更改它(即所有三个必须一致才能进行有效的元数据更改)。

如果系统在这样的元数据更改过程中宕机，如果配置数据库顺序不固定，将会有更多可能的不正确状态排列需要展开。需要固定顺序的配置数据库允许 (a) 更简单地检查集群的所有成员是否正在查看相同的元数据 (b) 在系统崩溃或意外停止时显着减少可能的状态。

此外，如果不同的 mongos 可以在不同的配置服务器上启动相同的操作，它还可以减少出现“竞争条件”类错误的机会。即使像 mongos 进程这样简单的更改也采用“虚拟”分布式锁来查看是否有必要 - 您如何处理不同 mongos 检查配置服务器的情况以不同的顺序检查(并取出)锁？

总而言之，这三个配置服务器不是副本集，但其中一个仍然必须是始终“首先”接受更改的服务器 - 想想 configdbs 的顺序mongos 作为这种“第一”状态的指定。