为什么在生产中不建议将MongoDB实例作为副本集启动? [英] Why starting a solo MongoDB instance as replica set is not recommended in production?

问题描述

在此答案中评论的讨论之后，@ kevinadi建议我打开与他的评论有关的新问题:

Following the discussions in the comments at this answer, @kevinadi recommended me to open a new questions related to his comment:

出于开发目的，您可以使用一个节点启动副本集. [...]请注意，这不是针对生产环境的推荐设置.

You can start a replica set with one node for development purposes. [...] Be advised that this is not a recommended setup for a production environment.

许多人正在为MongoDB单独实例创建一个副本集，并且对为什么不建议这样做有明确的答案很有趣，以供将来参考.

Many people are starting a replica set for solo MongoDB instances, and having a clear answer about WHY this is not recommended is interesting for future reference.

我希望@kevinadi会回答它，提供有关内存，CPU，性能以及所有影响的原因以及不建议为MongoDB实例启动副本集的原因.

I'm hoping @kevinadi will answer it, providing arguments in terms of memory, CPU, performance and all the impact and reasons why it's not recommended to start a replica set for a MongoDB instance.

推荐答案

副本集的主要功能是为MongoDB部署提供数据冗余和高可用性.也就是说，如果副本集中的主节点由于任何原因发生故障，则辅助节点将立即接管新的主节点(平均在10秒钟之内).有关此主题的更多详细信息，请参见复制.

The main function of a replica set is to provide data redundancy and high availability for your MongoDB deployment. That is, if the primary node in a replica set went down for any reason, a secondary would immediately take over as the new primary (on average within ~10 seconds). See Replication for more details on this topic.

正式的MongoDB驱动程序知道此副本集选举事件，并将提供对新主数据库的自动重新连接和操作重试.从应用程序的角度来看，数据库方面什么也没发生.

Official MongoDB drivers are aware of this replica set election event, and would provide automatic reconnection and operation retries to the new primary. From the point of view of the app, nothing happened in the database side.

使用具有多个辅助副本的副本集的另一个优点是，滚动滚动停机/维护的零停机可能性.这可以通过以下方法完成:使一个辅助节点脱机，对其进行维护，然后对其他辅助节点进行维护，最后退出主节点并对其进行维护.同样，由于MongoDB官方驱动程序已意识到这些事件，因此从技术上讲，您可以对活动数据库进行维护，而影响很小，并且不会导致应用程序停机.

Another advantage of using a replica set with multiple secondaries is the possibility of zero downtime upgrade/maintenance in a rolling fashion. This can be done by taking one secondary offline, do maintenance on it, then do maintenance on the other secondaries, and finally stepping down the primary and do maintenance on it. Again since official MongoDB drivers are aware of these events, you can technically do maintenance on a live database with very minimal impact and no downtime to the app.

与单块数据库服务器(只有一个真正的大服务器)相比，这是一种不同的理念.尽管在整体部署中有某些优点(再次讨论是另一回事:))，但MongoDB在设计时就考虑到了容错分布式数据库.单个服务器的一个直接缺点是服务器必须始终保持100％正常运行，否则应用程序将被中断.设计副本集的目的是使您的应用程序可以具有100％的正常运行时间，而不必对必须具有100％的正常运行时间的单个服务器施加压力.

This is a different philosophy vs. a monolithic database server, where there is only one true big server. Although there are certain merits in a monolithic deployment (which is a different discussion again :) ), MongoDB was designed as a fault-tolerant distributed database in mind. One immediate drawback of a single server is that the server must be up 100% at all times, or else the app is disrupted. A replica set was designed so that your app can have 100% uptime without putting pressure on individual servers having to have 100% uptime.

作为奖励，副本集 可以通过将驱动程序设置为从次要对象读取来提供读取可伸缩性(写操作必须始终转到主要对象).请注意，如果要进行二级读取，应该进行仔细的设计，因为如果滥用二级读取，则可能会干扰高可用性.

As a bonus, a replica set may be able to provide read scalability by setting the driver to read from secondaries (writes must always go to the primary). Note that there should be a careful design should you want to do secondary reads, as this can potentially interfere with the high availability aspect if abused.

总而言之，副本集可以提供:

In summary, a replica set can provide:

• 高可用性和容错
• 无需停机维护
• 数据冗余以扩展读取范围

不需要硬件是100％可靠的.这就是为什么强烈建议在产品部署中使用副本集的原因.

without requiring the hardware to be 100% reliable. This is why a replica set is strongly recommended in a prod deployment.

请参见复制集部署架构有关更详细的副本集部署注意事项.

See Replica Set Deployment Architectures for more detailed replica set deployment considerations.

这篇关于为什么在生产中不建议将MongoDB实例作为副本集启动?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！