mongodb如何处理从shard组中退出的机器？
我问这个问题的原因是，我有几台小机器，其中一台喜欢随机通电。
所以，如果我在这台机器上放一个碎片，mongodb能处理它退出一段时间，然后弹出并上线吗？
对于mongodb，作为一个管理级别的用户，我需要做些什么吗？
谢谢
如果我在这台机器上放了一个碎片，mongodb能处理它退出一段时间，然后弹出并上线吗？
对于mongodb，作为一个管理级别的用户，我需要做些什么吗？
这取决于许多因素，我试图用一些上下文总结这些因素：)
开发或非关键部署
如果这不是生产或关键环境，您可以等待机器恢复，不需要特定的管理干预，除非机器由于不干净的关机而出现其他错误。您的应用程序将不得不处理任何网络或超时异常，直到集群再次"正常"，因此您可能需要进行干预以将噪音降至最低。
生产部署
单独的碎片并不能提供高可用性或数据冗余，因此理想情况下，您希望每个碎片都有一个副本集作为备份。在这种情况下，一台停机的机器(只有一个mongod实例)应该影响最小，因为经过正确考虑的副本集部署体系结构可以自动故障切换，而无需任何管理干预。
假设一个更可怕的情况是，整个碎片都不可用。。你会想采取一些行政措施来尽量减少影响。当您的碎片不可用时，MongoDB日志将非常嘈杂，并伴有网络错误，并且一些操作(如块迁移)将无法到达/从关闭的碎片迁移。
至少你应该禁用均衡器，直到所有碎片都恢复在线。下面还有一些其他考虑因素。
"向下"碎片对通过mongos进行查询/更新的影响
从应用程序的角度来看，宕机的碎片的影响将取决于您正在进行的查询和更新的类型以及您选择的碎片密钥。
如果碎片可用，定向查询或更新(路由到单个碎片的查询或更新)仍然可以成功。如果查询/更新指向一个"向下"的碎片，您的驱动程序将获得一个异常。
目标查询(路由到某些但不是所有碎片的查询)如果不需要联系被关闭的碎片，仍然可以成功。
散射/聚集查询(路由到所有碎片的查询)将在一个或多个碎片关闭时返回异常。
如果您可以在一个或多个碎片关闭的情况下从mongos接收不完整的查询结果，那么可以在查询上设置partial标志来允许这样做。一般来说，你不想使用这个选项，因为你的结果会不一致，但在紧急情况下，或者在你可以根据你对碎片密钥的选择来识别被击落碎片的影响的情况下，它会很有帮助。
碎片密钥选择的影响
选择分片密钥的目标之一是提供读&编写适合您的用例。
例如，具有大量随机性的分片密钥(例如哈希分片密钥)将文档分布在所有分片上，并最大限度地提高写入吞吐量。因此，这也使得宕机碎片的影响通常会影响所有查询/更新。
您还可以创建一个具有一定数据局部性的shard密钥(例如，将customer_id等粗略属性与timestamp等细粒度属性相结合)，以便通过针对给定客户的定向查询获得更好的读取性能。使用更有针对性的分片密钥，您可以识别受下分片影响(或未受影响)的一系列用户。
进一步阅读
MongoDB手册中有更多关于Sharding的详细信息。
共享不会给您带来冗余
在mongodb中，高可用性是通过创建副本集来实现的。碎片的每个部分都应该由至少3台机器组成一个复制集。如果其中一个失败，另两个将重新选择主服务器，并将继续提供数据。当发生故障的机器恢复时，会应用oplog，并在不丢失服务的情况下恢复数据。
但如果你不使用副本集，当你的任何一个节点出现故障时，通过mongos访问数据将失败。
因此，如果您想要HA，请使用复制集