如何使用 WiredTiger 在 MongoDB 3.4 中影響文件（預）分配步驟（最大增長值）
我們在環境中部署了一些非常小的 DB（5GB）作為每個 DB 的目錄。在 dirs 下是帶有 XFS 的 LVM，當 DB 空間應該被填滿時，我們已經實現了“剎車”邏輯（這都是由於一些嚴格的磁碟配額造成的） - 我認為一點也不有趣……）。我們的解決方案在 CentOS 7.5 上的 MongoDB v3.4.19 上執行。一切看起來都很好。
一些數據庫通過單個收集有超過 60% 的已用磁碟空間，在我們的場景中，我們遇到了這種情況，在恢復 2.3GB 轉儲（全部到 5GB 數據庫目錄/=磁碟中，2GB 之後的預分配要求作業系統在（我認為) 2 策略的力量（或非常相似的東西）。
這種情況觸發了我們的觸發器，最終應該導致 DB 鎖定（這仍然比整個集群的下降更好，因為沒有剩餘空間）。與 10GB DB 的情況基本相同。（在某種程度上，我們可以說類似的情況幾乎可以以任何容量發生……）
我的問題是：我是否能夠影響 Mongo/WT 的（預）分配增長的步驟（最大大小低於~2GB）以恢復（僅）或完全恢復？
（在這種情況下，性能影響不是最高優先級。）
我通過db.adminCommand和configStrings為儲存引擎找到了一些有希望的可能性，但是我無法影響或列出一些可能的參數，也無法更改某些東西以使事情變得更好……尤其是WT 的file_extend參數通過
db.adminCommand( { setParameter: '1', wiredTigerEngineRuntimeConfig: { <parameter> } } )看起來很有希望，但我沒有找到將它傳遞給集群的方法……一些嘗試以錯誤 22 結束 - 無效參數，但我無法找到更多關於……
另一個發現，似乎只適用於 MMAP 引擎 - newCollectionsUsePowerOf2Sizes=false。
這使得將轉儲（最終是備份）還原到集群中變得更加麻煩……
希望問題得到清楚的解釋，任何提示/提示將不勝感激……如果需要一些額外的資訊，請告訴我。
更新：
我已經做了截圖，（我相信）我在上面所說的內容清晰可見……有 $ ls output (upper left), $ df 輸出（右上）和 $ mongorestore 進度（左下）。（看一次好過聽（讀）一千遍……）
開始
第一次分配（到 1.4GB - 使用 650MB）
第二次分配（到 2.4GB - 使用 1.1GB）
第三次分配（到 4.4GB - 使用 2.1GB）
在還原結束時（仍然分配 4.4GB - 使用 2.3GB）
恢復正常（釋放的額外空間）
謝謝你。
茲德內克
WiredTiger 不會預先分配數據文件。僅預分配日誌文件（每次預分配 100MB），請參閱日誌過程。
您看到的磁碟耗盡可能是由於這些日誌文件。日誌文件針對快速寫入進行了優化，它們的內容將以更永久的方式保存在每 60 秒發生一次的WiredTiger 檢查點上。通常，一旦保存在數據文件中，您應該會看到使用的磁碟更少，因為現在可以刪除日誌文件。請注意，WiredTiger 僅在檢查點之後才會刪除日誌文件，而不會在其他時間刪除。
我建議您在此恢復/數據載入過程中留出一些臨時的額外空間。一旦數據庫處於穩定狀態，您將看到更準確的大小。
2 的冪次預分配特定於 MMAPv1 儲存引擎，已棄用。這與 WiredTiger 無關。
我是否能夠影響 Mongo/WT 的（預）分配增長的步驟（最大大小低於 ~2GB）以恢復（僅）或完全恢復？
根據此處的 Google 群組論壇，每個數據文件永遠不會超過2GB。我們使用有符號**
32bit整數來索引每個文件的內部，因此我們不能使用超過2^31字節。我們對16000文件有一個軟限制，每個程序db [1]將您限制32TB在一個數據庫中。它主要用作完整性檢查，因此您可以輕鬆更改該數字並重新編譯以提高該限制。也就是說，您很快就會遇到48bit**current 的虛擬地址空間限制x86_64 cpus，其中只有47位可用於使用者空間，導致硬限制低於 128TB。此外，如果您打算使用持久性，我們會雙重映射每個文件，因此您僅限於64TB.我的意思是文件系統中的單個文件。MongoDB 中的數據庫跨越多個文件，因此這不會對數據集大小施加限制。是的，這也適用
64-bit OSs。我們在所有平台上使用相同的數據文件格式，因此您可以自由移動文件。
32-bit偏移主要是空間優化。64-bit DiskLoc它允許我們使用具有 32 位文件編號和32-bit該文件的偏移量的結構來指向單個數據庫中的任何位置。這是 mongo 在儲存pointers到磁碟時在內部使用的。