MongoDB复制和EBS vs短暂

Question

我已经阅读了所有关于在AWS上部署Mongo的推荐做法的MongoDB相关文档，但我不明白建议使用RAID-10 (pdf)在EBS上安装以避免数据丢失。

这似乎承认复制不起作用。为什么不应该使用短暂的驱动器和5个服务器集群进行复制来运行Mongo？

1. 性能更高，本地磁盘上的延迟可预测。
2. 如果服务器出现故障，EBS支持的商店无论如何都必须与副本重新同步。当然你有数据，但它已经过时了。
3. 使用EBS可以实现更复杂的设置。如果要拍摄快照，则需要使用LVM或其他层，因为EBS快照不能在RAID之间工作。您需要监控和管理RAID阵列，并在出现故障或其中一个EBS卷出现性能问题时进行重建。

如果有备份和大型副本集，使用EBS可以防止什么？它几乎承认副本集不会保护你免受数据损失。 （暂时忽略写入已发送到辅助节点的竞争条件，并且在发送确认之前主节点发生故障）。

Answer 1

  

为什么不应该使用短暂的驱动器和5个服务器进行复制来运行Mongo？

AWS并不完美，它可能会出现网络故障，从而导致整个设备停机。短暂记忆你会丢失所有数据。加上块设备可以在重启节点后继续使用。

这是一些事情，我相信还有更多。

  

如果服务器出现故障，EBS支持的商店无论如何都必须与副本重新同步。

只有在它消失之后，如果那是相当长的时间，那么可能更容易将目录从一个副本复制到另一个副本。

  

使用EBS可以实现更复杂的设置。如果要拍摄快照，则需要使用LVM或其他图层，因为EBS快照不能在RAID之间工作。

在AWS本身并不真正需要RAID，我的意思是他们对每个块设备进行RAID操作，而副本集就像丢弃设备一样好。每个节点可以使用一个块设备。

  

如果有备份和大型副本集，使用EBS可以防止什么？

它可以保护您的理智，恢复10个奇数成员的大量数据备份，并重置所有防火墙/用户权限和操作系统等等，可能......好......讨厌。

我的意思是想象每次重新启动它都需要重新设置操作系统。

  

它几乎承认副本集不会保护你免受数据冲击。

嗯，你必须误读一些brecaue，而不是他们所保证的。确实，使用repilica集合丢失数据更加困难（如果设置正确），但它们实际上是为了提供高可用性（HA）而设计的。

备份和jornalling以及其他一致性方法旨在不丢失数据。

Answer 2

那你在哪里看到在EBS上为mongodb运行RAID10的建议？他们的文档将其列为一个选项，但特别推荐仅使用EBS和预配置IOPS。

  

对于几乎所有部署，EBS将是更好的选择。对于生产系统，我们建议使用

     

  
• EBS优化的EC2实例
  
• 预配置IOPS（PIOPS）EBS卷
  

http://docs.mongodb.org/ecosystem/platforms/amazon-ec2/

我们在EC2上运行所有mongodb实例，并且所有实例都使用配置IO的生产实例使用EBS存储卷。原因如下：

1. 将失败的成员带回来的速度更快。如果一个实例失败并需要停止并重新启动（不是频繁但确实发生），我们可以分离存储并将其重新附加到另一个实例。 Mongod很好，通过日志恢复，然后与主服务器重新同步，因为失败后只有数据增量。当您拥有可能需要数小时才能从头开始恢复的大型数据集时，这是一个大问题。将数据存储在短暂的驱动器上并不能提供此功能。
2. 备份更容易（至少对于1 TB以下的副本集）。使用单个EBS存储卷（最高1 TB），我们可以拍摄实时二级存储的快照。只要日志位于同一存储卷上，备份就会保持一致。对于必须脱机备份的备份，无需专用辅助备份。
3. 除了多个TB副本集或性能之外，不需要RAID。 EBS已经在幕后提供RAID以实现冗余。当副本集在存储中增长超过1 TB时，我们确实使用RAID，但就是这样，并且还没有达到高IOPS EBS卷提供足够性能的程度。
4. 预配置IOPS可以很好地控制性能与成本。能够选择额定高达4000 IOPS的EBS存储使我们能够扩大生产系统的性能（以更高的成本），同时仍然可以获得EBS存储的优势。我们以较低的成本为测试系统使用常规EBS卷。
5. 复制生产数据以便在大型数据集中更容易在测试环境中使用。快照卷，从快照创建新的存储卷，然后启动并运行。

对于某些高性能情况，我当然可以想象使用短暂存储（特别是SSD成本下降）的未来部署，但EBS对我们来说相当可靠和可靠。当然，您的经验和需求会有所不同，但对于我们来说，遵循MongoDB的建议对我们很有帮助。实际上它足够可靠，对于某些环境，我们已经转移到1个主要，1个辅助和仲裁，这有助于节省成本。如果没有简单的恢复和在主要和次要上使用EBS卷的整体可靠性，可能不会这样做。