0

Let's imagine we have:

  • 1 replica set with 2 data instances (rs0_0 and rs0_1) and a arbiter instance (rs0_2).
  • 3 config servers instances (cfg0, cfg1 and cfg2).
  • 1 mongos instance (mos0).

After all the instances have been launched (rs0_0, rs0_1, rs0_0, cfg0, cfg1, cfg2, mos0), we configure the replica set:

mongo rs0_0_host:rs0_0_port
    rs.initiate()

    cfg = rs.conf()
    cfg.members[0].priority = 100              (rs0_0 will be the primary if alive)
    rs.reconfig(cfg)

    rs.add("rs0_1_host:rs0_1_port")
    rs.addArb("rs0_2_host:rs0_2_port")         (arbiter)

And then we add the replica set (as a shard) to the cluster:

mongo mos0_host:mos0_port
    use admin
    db.runCommand({ addShard: "rs0/rs0_0_host:rs0_0_port", maxSize: 400000, name: "shard_rs0" })

Now let's suppose that whole the cluster (all instances) go down, and then all instances get up except rs0_0. How is the replica set (the shard) contacted?

I mean: My application (or mongo shell) connects to mos0, mos0 asks to config servers (cfg0, cfg1 and/or cfg2), config servers return "rs0/rs0_0_host:rs0_0_port" (due to the "addShard" command we did run) from their config, then mos0 tries to connect to "rs0_0_host:rs0_0_port", but it can't because rs0_0 is down. So, how does mos0 know about the existence of rs0_1 and rs0_2 (the replica set instances that are alive)?

Of course, we could have configured the shard in this way:

    db.runCommand({ addShard: "rs0/rs0_0_host:rs0_0_port,rs0_1_host:rs0_1_port,rs0_2_host:rs0_2_port", maxSize: 400000, name: "shard_rs0" })

In that way, the mos0 would receive the full list of replica set instances from the config servers. But, since MongoDB 2.0.3, only one instance (of the replica set) is required to be especified in the "addShard" command. So where is the trick?

4

1 回答 1

0

在mongos这种情况下，将在内存中保存一个 relcica 集的内部映射，该映射每隔一段时间就会刷新一次（就像驱动程序一样），此时当成员开始上线时，它会进行一些检查以及不检测哪个成员它应该联系。当然，在存在主节点之前，它不能写入成员。

如果重新启动 mongos 并且配置的成员处于脱机状态，则种子列表很好，此时 mongos 可以将另一个成员作为种子。

于 2013-07-22T11:48:14.773 回答