MongoDB的filemd5是否有能力设置readPreference

我有一个使用GridFS构build的Node / Meteor中的文件存储服务，它被复制到多个容器中。 我目前试图find的是，如果这段代码实际上意识到读/写一致性 

db.command({ filemd5: someFileId, root: 'fs' }, function callback(err, results) { ... })

我正在上传文件块，并将所有块合并成一个单一的文件，该命令执行。 我有一种感觉，它是使用次要成员（我有几个md5值是空文件 – d41d8cd98f00b204e9800998ecf8427e ）。 是否有任何文档或附加设置？

这两个参数是文档中描述的唯一选项.. https://docs.mongodb.com/manual/reference/command/filemd5/

UPDATE
合并块的确切代码在第三方包中： 

  cursor = files.find( { 'metadata._Resumable.resumableIdentifier': file.metadata._Resumable.resumableIdentifier length: $ne: 0 }, { fields: length: 1 metadata: 1 sort: 'metadata._Resumable.resumableChunkNumber': 1 } )

https://github.com/vsivsi/meteor-file-collection/blob/master/src/resumable_server.coffee#L26

然后有111-119行首先执行filemd5，然后在文件上运行更新 

  @db.command md5Command, (err, results) -> if err lock.releaseLock() return callback err # Update the size and md5 to the file data files.update { _id: fileId }, { $set: { length: file.metadata._Resumable.resumableTotalSize, md5: results.md5 }}, (err, res) => lock.releaseLock() callback err

https://github.com/vsivsi/meteor-file-collection/blob/master/src/resumable_server.coffee#L111-L119

在写完最后一个块之后， cursor = files.find()会与所有合并的东西一起启动，因此如果读取的优先级是secondaryPreferred那么它们可能不会在那里？ 该代码是否应该重构为仅使用主要？

GridFS创build2个集合： files和chunks 。

一个典型的files条目如下所示： 

 { "_id" : ObjectId("58cfbc8b6900bb31c7b1b8d9"), "length" : 4, "chunkSize" : 261120, "uploadDate" : ISODate("2017-03-20T11:27:07.812Z"), "md5" : "d3b07384d113edec49eaa6238ad5ff00", "filename" : "foo.txt" }

filemd5pipe理命令应该简单地返回相关文件文件的md5字段（以及块的数量）。

files.md5
由filemd5命令返回的完整文件的MD5散列。 该值具有stringtypes。

来源： GridFS文档

它应该表示完整文件的哈希，或者至less是最初保存的哈希。

什么是文件集合文档的“md5”字段，它是如何使用的？
“md5”保存从用户文件的原始内容计算出来的MD5校验和。 从历史上看，GridFS并没有使用确认的写入，所以这个校验是有必要的，以确保写入正确。 在确认写入的情况下，MD5校验和仍然有助于确保GridFS中的文件没有被破坏。 直接访问GridFS下“文件”和“块”集合的第三方可能会不经意间或恶意地对文件进行更改，使GridFS无法使用这些文件。 将文件集合文档中的MD5与重新计算的MD5进行比较可以检测到这种错误和损坏。 但是，驱动程序现在假定存储的文件没有损坏，并且想要使用MD5值检查损坏的应用程序必须自行完成。

来源： GridFS规范

如果以不使用驱动程序mongoc_gridfs_file_save （例如，streaming）的方式进行更新，则不会更新md5字段。

其实，进一步阅读规范：

为什么存储MD5校验和而不是根据需要创build散列？ 当文件最初上传到GridFS时，必须计算MD5校验和，因为这是我们唯一保证有整个未损坏文件的时间。 从GridFS中读取文件即可进行计算，这将确保我们的读取操作成功，但是对系统中文件的状态不做任何保证。 对存储的MD5校验和进行的成功检查可以确保存储的文件与原始文件匹配，并且没有发生损坏。

这就是我们正在做的。 只有mongoc_gridfs_file_save才会计算文件的md5总和并将其存储。 任何其他入口点（如stream）都希望用户创build了所有支持的mongoc_gridfs_file_opt_t并正确计算了md5

来源： JIRA问题

Interesting Posts