MongoDB的filemd5是否有能力設置readPreference

我有一個內置在Node/Meteor中的文件存儲服務，它利用了GridFS，並且它被複制到多個容器中。什麼我目前正試圖發現，是，如果這段代碼實際上是意識到了讀/寫一致性MongoDB的filemd5是否有能力設置readPreference

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

我上傳的文件塊，併合並所有塊到該命令可以在一個文件後，被執行。我有一種感覺，它使用次要成員（我有幾個md5值是空文件 - d41d8cd98f00b204e9800998ecf8427e）。是否有任何文檔或其他設置？

那些2個PARAMS在文檔中描述的唯一選擇.. 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那麼他們可能不是依然存在？該代碼是否應該重構爲僅使用主要代碼？

來源

2017-03-20 Alex K

你能你如何上傳和合並塊詳細點嗎？您可以查看mongo日誌或'files'和'chunk'集合以獲取完整的文檔詳細信息。現在，我會將文檔和內容放入答案中。 – MasterAM

@MasterAM我已經包含了原始的源代碼（這是咖啡的腳本，但應該給出一個關於在那裏運行的實際查詢） –

看了一下後，它似乎不像我預期的那樣。我無法深入挖掘時間，所以我不認爲我可以幫助你超越我答案中的參考。看起來，admin命令提供的md5不是從'files'文件中獲取的，但可能在文件保存時存儲在別處。 – MasterAM

GridFS創建2個系列：files和chunks。

典型files條目類似於以下內容：

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

的filemd5管理命令應該簡單地返回相關的檔案文件（和塊數）的md5領域。由filemd5命令返回的完整文件的

files.md5
的MD5哈希值。該值具有字符串類型。

來源：GridFS docs

應該代表完整文件的散列，或者至少是一個最初保存。

什麼是文件集合文檔的'md5'字段以及它是如何使用的？
'md5'保存從用戶文件的原始內容計算出的MD5校驗和。從歷史上看，GridFS並未使用已確認的寫入，所以此校驗對於確保寫入正確無誤是必要的。通過確認寫入，MD5校驗和仍然有助於確保GridFS中的文件未被損壞。直接訪問GridFS下的「文件」和「塊」集合的第三方可能會無意或惡意地對文件進行更改，使GridFS無法使用它們。將文件集合文檔中的MD5與重新計算的MD5進行比較，可以檢測出這些錯誤和損壞。但是，驅動程序現在假定存儲的文件沒有損壞，並且想要使用MD5值檢查損壞的應用程序本身必須這樣做。

來源：GridFS spec

如果以這樣的方式更新，使得駕駛員的mongoc_gridfs_file_save不使用（例如，流）時，md5場將不會被更新。

事實上，進一步閱讀的規格：

爲什麼存儲的MD5校驗，而不是創建哈希按需的？當文件最初上傳到GridFS時，必須計算MD5校驗和，因爲這是我們唯一保證有整個未損壞文件的時間。在GridFS中讀取文件時即時計算它可以確保我們的讀取操作成功，但是對系統中文件的狀態不做任何保證。針對存儲的MD5校驗和的成功檢查可以確保存儲的文件與原始文件匹配並且沒有發生損壞。

這就是我們正在做的。只有mongoc_gridfs_file_save會計算文件的md5總和並將其存儲。任何其他入口點，如流，期望已經創建的用戶所有支持mongoc_gridfs_file_opt_t並正確計算MD5

來源：JIRA issue

來源

2017-03-20 12:18:31 MasterAM

MongoDB的filemd5是否有能力設置readPreference

回答

相關問題