Mongodb GridFS和克隆到另一台服务器

我有一个本地MongoDB数据库，我开始将一些文件放入GridFS中以进行缓存。我想知道的是：

我可以在另一台服务器上使用db.cloneCollection（）克隆我的fs.*集合吗？如果我这样做，该服务器上的GridFS系统会正常工作吗？本质上，我必须从另一台在GridFS中有文件的机器上“拉”出数据，我不能轻易地直接将它们添加到生产框中

编辑：我能够进入我的目标服务器，并使用来自mongo shell的以下命令将GridFS系统从我们网络上的另一个mongo系统拉过来

use DBName
db.cloneCollection("otherserver:someport","fs.files")
db.cloneCollection("otherserver:someport","fs.chunks")

---

供将来参考。

简而言之，你当然可以，它只是一个收藏，没有什么特别之处。较长的形式是解释实际情况

因此手册页面上的第一句话：

GridFS是一种用于存储和检索超过BSON文档大小限制16MB的文件的规范

GridFS不是“MongoDB”所做的事情，在服务器内部，它基本上只是两个集合，一个用于参考信息，另一个用于分解内容的“块”，因此没有单个文档超过16MB的限制。但这里最重要的是“规范”一词

因此，服务器本身根本不具备魔力。存储引用数据和块的实现都是在“驱动程序”级别完成的，实际上，您可以命名希望使用的集合，而不仅仅是接受默认值。因此，在读取和写入数据时，“驱动程序”通过拉取参考文档中包含的“块”或在数据发送到服务器时创建新的“块”来完成工作

另一个常见的误解是GridFS是将内容发送到MongoDB时处理“文件”的唯一方法。在第一句话中，它实际上是一种存储超过BSON文档16MB限制的内容的方法

MongoDB直接在文档中存储二进制数据没有问题，只要文档总量不超过16MB限制。因此，在大多数用例（网站上使用的小图像文件）中，数据最好存储在普通文档中，从而避免需要读取和写入多个集合的开销

---

因此，没有内部服务器“魔力”。这些只是普通的集合，您可以查询、聚合、mapReduce，甚至复制或克隆。

非常好的响应，我能够执行db.cloneCollection（）命令并访问fs.files和fs.chunks集合。工作得很好！