MongoDB - 我應該將日誌和數據分開到不同的驅動器嗎？
我從多個來源看到和聽到，從性能方面來說，將數據庫日誌和數據文件寫入單獨的磁碟可能是一個好主意。
推薦的方法是什麼（例如在 EC2 上）？
- 如果我們將數據文件寫入 RAID（例如 EBS 驅動器），大多數人會將日誌寫入到哪裡？
- 我是否應該只使用完全獨立的（RAIDed）驅動器集
- 我應該使用單個非 RAID 驅動器嗎？
- 我應該將數據和日誌留在同一個 RAID 上嗎？
唯一絕對推薦移動日誌的情況是，如果您必須使用直接 NFS 掛載 -通常不建議將 NFS用於 MongoDB，但特別是它不能很好地與日誌配合使用。
一般來說，期刊對您的其餘數據的訪問模式將完全不同（順序訪問與隨機訪問）。因此，從績效角度將期刊和數據分開通常是一個好主意。請注意，這是一個非常廣泛的概括，並且會根據您對 MongoDB 的使用情況而有所不同，但通常是正確的。
由於您的問題主要是關於 EC2 和 EBS 的，因此 NFS 將不會在這裡發揮作用，但我認為在更廣泛的背景下值得一提的是具體細節。
對於 EC2/EBS，您通常只需要在看到寫入 IO 爭用（或考慮到 EBS 的性質的整體 IO 爭用）時將日誌分開 - 它會將 IO 移動到不同的磁碟並釋放一些數據容量磁碟。當然，對於 EBS，您的 IO 還取決於實例上可用的網路 IO，這取決於您的實例大小（以及您是否選擇了P-IOPS），因此存在很多變數。
如果您看到高 IOWait 時間並且您的磁碟看起來是寫綁定的（請參閱 IOStat），這是您應該考慮的事情，但這只是一種臨時措施，因為與增加可用 IO 相比，這只是一個小的調整。根據您的起點，那裡有很多可用的選項，例如向 RAID 添加更多 EBS 驅動器或利用 P-IOPS 配置。您有時還可以通過更改實例類型來獲得更好的性能，從而減少網路爭用。這些中的每一個都可能比移動期刊更有效，並且更少頭痛。
為了解釋，這裡還有其他注意事項 - 快照。感謝日誌，您不再需要 fsync 和鎖定數據庫以獲得一致的快照（無論是 EBS 還是 LVM 或其他）。但是，日誌必須包含在快照中才能做到這一點。因此，無論您使用什麼節點進行備份，如果您打算在不為該節點停機的情況下進行快照，那麼您需要確保包含日誌。
最後，日誌的用途之一是促進從不干淨的關閉中恢復，例如作業系統級別的崩潰/重新啟動。如果日誌在 EC2 的臨時磁碟上，它會被這樣的重啟吹走，因此在這種情況下沒有用處。因此，使用這種配置的任何此類崩潰/重新啟動都需要從頭開始重新同步，或者如果發生這種情況，則需要從備份/快照中恢復。
總體而言，與大多數配置決策一樣，您必須權衡利弊並選擇與您的案例最相關的解決方案。希望這將為您提供足夠的資訊以做出明智的選擇。