mongodb，一个最小的生产数据库是否*需要*一个副本集？

Question

我对 mongodb 相当陌生，正在这里解决一些 DevOps 问题。

我们在 AWS 上部署了一个 B2B Saas 产品，客户之间没有网络效应，并且一些客户拥有比其他客户大得多的数据库。它们目前正在一台中央 mongodb 服务器上运行，我们遇到了严重的噪音邻居问题，我们需要隔离拥有大量联系人的客户端。

我的问题是：对于我们在 aws 中为单个大客户提供自己的隔离 vpc 的设置，最小合理的 mongodb 服务器是多少？这是否需要是 mongo 文档中所示的 3 服务器副本集，或者可以合理地使用一个 ec2 实例作为小型数据库的生产 mongo 服务器吗？

Answer 1

您可以在单个 MongoDB 实例上运行生产环境。在非常特殊的情况下。在我们澄清了有关副本集的一些事情之后，让我们看看这些情况是什么。

在副本集上

与普遍的看法相反，副本集只有一个主要目的：确保数据库的可用性。让我们假设您只有一个实例。每一次维护工作、每一次服务器崩溃、每一次管理错误都会导致停机。停机不仅会影响您的 SLA（已经够糟糕了），而且很可能会导致 DBA 在聚会之夜后早上 06:00 从床上起床，现在他试图让自己的咖啡因含量足够高能够恢复半醉的数据库。

此外：不可避免地，您将丢失备份和恢复服务之间的所有数据。首先，显然，您将丢失上次备份和服务器不可用之间的所有数据。然后，您将丢失停机期间生成的所有数据。

现在让我们假设您有一个包含两个数据承载节点和仲裁器的副本集。稍微好一些。您的主节点发生故障，另一个数据承载节点被选举出来，并且由于大多数驱动程序提供的自动故障转移，您的服务将继续运行，不会出现停机和数据丢失的情况。但是：你失去了冗余。所以为了降低风险，一位DBA又被叫醒了，他现在必须将仲裁器提升为数据承载节点，等待数据同步，同时希望同步速度快于你的数据变化速度。数据（更准确地说：您希望复制 oplog 窗口大于同步数据所需的时间）。否则，数据同步将失败，您必须关闭应用程序才能使同步成功。通过此设置，您可以选择何时关闭应用程序以恢复冗余。

旁注：如果您的数据更改率超过复制操作日志窗口，您应该进行分片。始终确保您的复制 oplog 窗口足够大。

现在让我们假设您有三个数据承载节点，如建议的那样。即使一台服务器发生故障（或更新等），您仍然拥有冗余。一个节点在夜间出现故障？睡个好觉！

那么什么时候才能拥有单台服务器的生产环境呢？

考虑到上述情况，当且仅当您可以拥有单实例生产环境时

• 没有 SLA 和/或您的客户可以忍受延长的停机时间
• 您的 DBA 随时待命以恢复服务
• 您和/或您的客户可以忍受在上次备份和恢复服务之间丢失数据的情况。

在我所知道的最严肃的业务应用程序中，其中一个或多个条件的答案是“否”。

我可以拥有一个具有两个数据承载节点和一个仲裁器的生产环境吗？

是的，假设您可以接受这样一个事实：丢失一个数据承载节点将导致您失去冗余。在这种情况下，您很可能必须重新同步数据，这需要您密切监视复制操作日志窗口并确保重新同步所需的时间适合它。

考虑到仲裁器实例和数据承载节点之间的价格差异，无论您选择具有两个数据承载节点和一个仲裁器的设置还是具有三个数据承载节点的建议设置，这都是一个风险管理问题。

结论

可以合理地使用一个 ec2 实例作为小型数据库的生产 mongo 服务器吗？

坦白地说：恕我直言，不是。这将接近疏忽，增加了可以用相对较少的钱来减轻的风险，并且很可能比至少拥有一个具有两个数据承载节点和一个仲裁器的副本集昂贵得多。如果你考虑到一切。

这是否需要是 mongo 文档中所示的 3 服务器副本集？

除非你真的、真的、真的知道自己在做什么：是的。