mongodb的风险因素分析

时间:2014-11-19 16:00:09

标签: mongodb sharding risk-analysis

我正在尝试制作mongodb,我正在尝试分析其中涉及的风险因素。

我在测试环境中的配置是

Routing server------> Config Server ------- > Shard01
                                              Shard02
                                              Shard03

我的路由服务器和配置服务器在同一台机器上运行。 Shard01,Shard02,Shard03分别在三台不同的机器上运行。我想分析一下这个系统中涉及的所有风险因素。例如,一种情况是如果任何Shard机器关闭应用程序将停止?

1 个答案:

答案 0 :(得分:0)

  1. 只有一个配置服务器是一个非常糟糕的想法(TM)。对于生产环境,始终始终 始终 使用三个配置服务器。原因:没有配置服务器,群集基本上变得无用,因为查询路由器从配置服务器获取有关哪个密钥范围存在于哪个分片上的信息。 (放置mongos'元数据缓存,因为这只会延迟问题)。 注意:如果不这样做,请自担风险。
  2. 让配置服务器和查询路由器在同一台机器上运行是一个非常糟糕的主意。在负载很重的情况下,这些机器需要竞争网络IO。虽然这是一种罕见的情况,但它仍然可能发生。在每个应用服务器上放置一个查询路由器会更有意义:它可以减少网络延迟(在数据到达之前减少一跳),单个mongos不会超载而你不会需要在配置服务器上运行你的mongos。 ;)说真的,这是建议和经过充分验证的设置。
  3. 将分片作为独立实例运行是 AWFUL 的想法。如果您的主分片(包含未分类集合的分片,包括system)失败,则您遇到了大麻烦。您应 始终 将副本集用作分片。 注意:如果不这样做,请自担风险。
  4. MongoDB驱动程序的一个鲜为人知的功能是您可以将它们配置为使用多个mongos实例。如果第一个失败,则尝试下一个。因此,使用多个mongos(每个应用程序服务器一个),正确的数据源配置,三个配置服务器和副本集作为分片,没有单点故障(节点方式)。