iCHEF 某一服務架設的 MongoDB，在 2020 已快到 AWS EBS 容量上限，為避免觸頂反彈，我們採取了一系列行動（詳見 排解 MongoDB 掛在 AWS EBS 的硬碟用量上限 by Keith），本篇詳述其中一路：升級 MongoDB。
原則
- 抱持隨時還有下次升/降級的心態
- 別跟 MongoDB 裝熟，一步步的更動都停下來觀察紀錄效能的變化
基於以上兩點，我們決定不要做任何原地升級，事後來看這可能是最重要的決策，不僅保留了退路，也讓我們能隨時回頭前後比較、反覆演練找到最順暢的流程。缺點是短時間會多花一點錢，新的機器也需要注意一些較隱密系統的設定，以免上線時被流量打垮。
概觀流程
- 利用 DNS 簡化未來切換 DB server host 的成本，例如 AWS Route 53
- v2.6（Primary+Secondary+Arbitary）→
v2.6（P+S）+ v3.0（S+S+A）→
v2.6（S+S）+ v3.0（P+S+A） - DNS 指向新的 v3.0 Primary host，迎接新生
- 停止 v2.6 機器
- v3.0 穩定後，再依照上述 2 ~ 4，升到 v3.6
一點細節
- 一定要演練降版流程，測試環境的成功不等於線上環境的成功保證。
- 從頭 Sync 新機器可能耗時非常久，以 15T 為例，一台就需要 77 小時
- 加入新節點時，善用 priority, votes, hidden 參數，避免偶數節點時可能造成的問題。
- 最後要成為 Primary 的新機器，建議先當 Secondary 一段時間，經過線上真實流量和情境的洗禮，快取都暖身完畢再上陣。
- Sync 時的 source 也會消耗一定 IO 和 CPU，如原機器本就緊繃，建議要先升級原機器基礎能力。
- 記得調整新機器允許 MongoDB 開啟的檔案和 process 數量上限。
成果
我們在使用者無感的狀態下成功完成了升級，將近 16% 的壓縮率，也讓我們在硬碟費用和定期硬碟快照上都省下大筆花費。
更重要的是，擺脫了有各種匪夷所思 bug 的 v2.6 MongoDB，大快人心。
