我在三台机器上有两个分片(使用mongodb 1.8.2):
nodeI including: shard1(primary) and shard2(primary)
nodeII including: shard1(secondary) and shard2(secondary)
nodeIII including: shard1(arbiter) and shard2 (arbiter)
NodeII负载越来越高(CPU和IO),NodeI也很高,但比nodeII好一点。
在我的java客户端中,我指定代码只查询NodeII,而NodeI仅用于编写。
我打算将nodeIII从仲裁器转换为辅助节点以在NodeII上共享读取负载。
你认为这是一个好主意,如果我这样做,我应该考虑什么,或者你有其他建议来降低负荷?
答案 0 :(得分:0)
只要仲裁硬件具有与您的辅助硬件类似的规范,您建议的方法似乎是合理的,因为它将分发辅助读取。通常,仲裁器具有非常低的硬件规格或在共享硬件上,但我假设在您的配置中不是这种情况。
如果副本集中有奇数个服务器,则不再需要仲裁服务器。
您可能需要look into Read Preference here,特别是您可能有兴趣指定标签集来选择辅助设备。
答案 1 :(得分:0)
从辅助节点读取并不一定按照您的预期“分配”负载。如果没有找到性能问题的根源,您可能只是面临更多挑战。
特别是,在现有服务器中添加辅助服务器将:
您还应该考虑在失败的情况下会发生什么。如果您的服务器在当前负载下挣扎,如果您的任何一台物理服务器出现问题并且所有流量最终都会到达单个服务器,那么事情可能会急剧崩溃。
理想情况下,您应该运行mongostat或类似monitoring tools以更好地了解服务器的性能特征以及可能导致负载的因素(内存压力,锁定%,I / O,网络,..)。如果您可以将mongostat输出的样本发布到PasteBin或类似的内容,将会很有帮助。
您还应该使用explain()查看常见查询,以了解索引使用情况,并检查它们是否需要访问所有分片,还是定向到特定分片。
如果所有3台服务器都是相同的硬件规格,作为短期改进,我会考虑:
删除仲裁程序并将其替换为辅助节点。如果您的一台服务器发生故障,这将提供额外的数据冗余,并有助于防止所有负载在一台服务器上着陆。
在NodeI上降低主节点,以便NodeI和NodeII各有一个主节点和辅助节点(而不是NodeI上的两个主节点和NodeII上的两个副节点)。主服务器和辅助服务器具有不同的写入特性,因此可以更好地平衡负载。
检查分片密钥和常见查询以确认它们将合理地平衡读取和写入。潜在的问题包括“热点”,其中所有对集合的写入都会触及单个分片。或者查询会触及所有分片以获得结果。
如果不从辅助节点读取,则测试性能变化。这可能看似违反直觉,但根据查询的性质,从辅助文件中读取可能实际上会导致其他问题。
最后,你提到使用1.8.2。 MongoDB 2.0和2.2中有显着的性能和锁定/产生改进,以及其他错误修复。在您的开发环境中测试升级是值得的,因为这可能会解决您的一些问题。