开始需要在 MongoDB 上扩展相对随机访问的工作流，iotop 表明我们正在充分利用我们的 IO。看起来 AWS 允许您在不停机的情况下将卷类型切换到可配置的 IOPS（并添加更多 IOPS），但在主数据库节点上执行此操作是否有任何缺点或危险？当某件事听起来好得难以置信时...
答案1
这应该是无缝的。
当然，您希望为可能出现的问题做好准备，因此对卷进行快照并确保您有一个备份计划是有意义的，但是......
当卷处于此
optimizing状态时，您的卷性能将介于源配置规格和目标配置规格之间。过渡卷性能将不低于源卷性能。如果您正在降级 IOPS，过渡卷性能将不低于目标卷性能。http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html
过程很顺利，可能的原因是EBS已经具有内部复制。
您可能不知道您的卷始终存在于两个地方，副本位于同一可用区的不同硬件上。如果卷发生故障，副本将接管并成为主卷，并在集群内寻找新的存储节点进行自我复制，以继续保留退款。
事实上，在正常运行中，如果主卷丢失了副本，它会搜索新的复制目标，并且 I/O 会冻结，直到获取目标为止——通常在几毫秒内。EBS 卷永远不会在没有副本的情况下运行，即使这对用户来说是隐藏的。
因此，从字里行间中看出——并不是为了贬低这里涉及的真正魔力——得出这样的结论似乎是合理的：相对于 EBS 在日常操作中透明复制的复杂性和精密性……工程师们所做的可能并没有太大的不同：他们利用了相同机制的部分，但卷会将自身复制到能够提供新卷属性的设备上。复制完成后，副本将接管……或者可能是分阶段进行的：考虑到您的 EBS 卷从来都不在单个磁盘上（即使忘记复制，EBS 一开始也会在多个存储设备上配置单个“卷”），记录的行为开始变得有意义。
因此，真正的“好得令人难以置信的部分”实际上是 EBS 一直在悄悄做的事情的自然延伸。
当然，这很大程度上只是我个人的猜测，但根据 EBS 的公开信息，这似乎是合理的。
另外：一个重要的EBS 中断几年前，某个地区的一个可用区就出现了这种情况，其中一个关键因素是“重新镜像”尝试的风暴，因为卷认为它们已经丢失了副本，并开始疯狂地搜索具有足够容量的新节点以同意成为它们的新副本。