作者回复: 如果是一次性迁移，直接导出到CSV文件然后使用mongoimport命令。100MB或者几个T都是这样。 如果是持续迁移，那需要一些专门的工具，比如说我们公司的tapdata产品。

作者回复: 停掉均衡以后，备份可以保证每个节点各自是准确的。但是各个节点之间时间点很难保证在同一点上，所以每个节点恢复以后那个状态不是完全同步的。这个没有致命风险，但是确实有数据不一致的可能性。如果要做到完全一致，需要使用MongoDB 企业版 Ops Manager的分片备份功能。

作者回复: 这个方法可以做备份，但是不是最严格的。严格的备份能够提供指定时间点的恢复。比如说，如果你发现13：01分的时候有个误删操作，使用好的分片备份机制，可以恢复到13：00的准确状态。而通过mongodump是没有这种保障机制的。

作者回复: 可以通过历史数据备份+oplog 重放来恢复，抱歉回复完了。

作者回复: dump的话单独备份是不需要的。除非你另有别的用途

作者回复: 你是如何在查询和分析，可以稍微明确一些吗？

作者回复: 可以的，大致步骤是： 1）用snapshot或者关机复制文件方式进行全量备份 2）使用mongodump 备份 oplog 库 3）恢复全量备份 4） 使用 mongorestore 的 --oplogFile --oplogLimit 参数来恢复指定的oplog 时间点 可以参考下面这个英文博客 https://alexmarquardt.com/2017/01/25/mongodb-point-in-time-restore/

作者回复: 如果两个情况下，你的请求量是完全一样的，比如说，同样的请求，查的是同一个集合，一样的并发，那么影响不大，因为其他集合的数据只是在硬盘上，不会被调用到内存里。如果你对其他9个集合也有访问，那性能自然就不相同了。

作者回复: 1） 应该先修复副本集再做删除动作，可以删掉坏掉的那个节点的数据，让它自动恢复数据。 2） 这个要看mongoshake团队，有个钉钉群，你可以搜一下加群问。

作者回复: 这两种方式比较简单，一个是复制文件，一个是操作系统命令，就没有特别讲了。