2台服务器上的mongoDB复制和分片合理吗？
考虑以下设置：
有 2 台物理服务器设置为常规 mongodb 复制集（包括仲裁进程，因此自动故障转移将正常工作）。
现在，据我了解，大多数实际工作将在主服务器上完成，而从属服务器主要只是做保持其数据集同步的工作。
在该设置中引入分片是否合理，即在同一两台服务器上设置另一个复制集，以便每台服务器都有一个 mongod 进程作为主进程运行，一个进程作为辅助进程运行。
预期的结果是两台服务器都将在两台服务器都启动时分担实际查询/插入的工作负载。如果一台服务器出现故障，整个设置应该优雅地进行故障转移以继续运行，直到另一台服务器恢复。
除了设置的总体开销和进程数量（mongos/configservers/arbiters）之外，此设置是否有任何缺点？
Consider the following setup:
There a 2 physical servers which are set up as a regular mongodb replication set (including an arbiter process, so automatic failover will work correctly).
now, as far as i understand, most actual work will be done on the primary server, while the slave will mostly just do work to keep its dataset in sync.
Would it be reasonable, to introduce sharding into this setup in a way that one would set up another replication set on the same 2 servers, so that each of them has one mongod process running as primary and one process running as secondary.
The expected result would be that both servers will share the workload of actual querys/inserts while both are up. In the case of one server failing the whole setup should elegantly fail over to continue running, until the other server is restored.
Are there any downsides to this setup, except the overall overhead in setup and number of processes (mongos/configservers/arbiters)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
那肯定会起作用。不久前我在 #mongodb IRC 频道中问了一个问题，关于在一台机器上运行多个 mongod 进程是否是一个坏主意。答案是“只要你有 RAM/CPU/带宽，就可以疯狂”。
值得注意的是，如果您正在寻找高性能读取，并且不介意写入速度慢一点，您可以：
这将为您提供类似于 MySQL 的集群设置 - 在主服务器上写入一次，但任何从服务器都可以读取。在读取次数多于写入次数的情况下（例如，一个数量级），这可能会带来更高的性能，但我不知道当节点出现故障时它会如何表现（因为写入可能会停止尝试写入）到 3 个节点，但只有 2 个节点启动，等等 - 这需要测试）。
That would definitely work. I'd asked a question in the #mongodb IRC channel a bit ago as to whether or not it was a bad idea to run multiple mongod processes on a single machine. The answer was "as long as you have the RAM/CPU/bandwidth, go nuts".
It's worth noting that if you're looking for high-performance reads, and don't mind writes being a bit slower, you could:
This would get you a clustered setup similar to MySQL - write once on the master, but any of the slaves is eligible for a read. In a circumstance where you have many more reads than writes (say, an order of magnitude), this may be higher performance, but I don't know how it'd behave when a node goes down (since writes may stall trying to write to 3 nodes, but only 2 are up, etc - that would need testing).
需要注意的一件事是，当两台机器都启动时，您的查询将在它们之间分配。当一台机器出现故障时，所有查询都将转到剩余的机器，从而使对其的要求加倍。您必须确保您的机器能够承受突然加倍的查询。
One thing to note is that while both machines are up, your queries are being split between them. When one goes down, all queries will go to the remaining machine thus doubling the demands placed on it. You'd have to make sure your machines could withstand a sudden doubling of queries.
在这种情况下，我首先会重新考虑分片，并使其成为 2 台机器（+1 个仲裁器）的未分片副本集。
In that situation, I'd reconsider sharding in the first place, and just make it an un-sharded replica set of 2 machines (+1 arbiter).
您缺少一个关键细节：如果您的分片设置仅包含两个物理节点，那么如果其中一个节点死亡，您的所有数据都会消失。这是因为分片层以下没有任何冗余（推荐的方式是每个分片由一个副本集组成）。
然而，您所说的关于副本集的内容是正确的：您可以在两个无共享节点上运行它，并有一个额外的仲裁器。但是，建议设置为 3 个节点：一个主节点和两个辅助节点。
http://www.markus-gattol.name/ws/mongodb.html# do_i_need_an_arbiter
You are missing one crucial detail: if you have a sharded setup with two physical nodes only, if one dies, all your data is gone. This is because you don't have any redundancy below the sharding layer (the recommended way is that each shard is composed of a replica set).
What you said about the replica set however is true: you can run it on two shared-nothing nodes and have an additional arbiter. However, the recommended setup would be 3 nodes: one primary and two secondaries.
http://www.markus-gattol.name/ws/mongodb.html#do_i_need_an_arbiter