MongoDB升級小結

背景

最近業務mongo升級，因為需要調整業務代碼和線下測試，工作持續了一個月才有了階段性的成果。 版本升級一定要在測試環境成功測試後再在production機器上進行版本升級。業務代碼主要是Python，在升級之前，我們已更新到了合適版本的pymongo，並線上下做了測試。 為了從2.4升級到3.0由於資料相容性的問題，需要先從2.4升級到2.6，然後再從2.6升級到3.0。 mongo沒有用yum安裝，直接拷貝的mongo的bin檔案，在機器上運行mongd啟動。下載地址 mongo沒有採用分區。 mongo2.4到2.6

這次升級在很久之前由開發人員自己完成。 升級的過程

升級從庫
主要操作：將2.4版本mongo的二進位檔案替換成2.6的程式包裡的bin目錄裡的二進位檔案，然後重啟。待mongo從recoer狀態變為secondary狀態後， 再升級下一個mongo 執行個體。可以在mongo shell中用rs.status()查看執行個體狀態。

停掉主庫

升級主庫 升級的好處 建索引是一個容易引起長時間寫鎖的問題，MongoDB 在前台建索引時需要佔用一個寫鎖（而且不會臨時放棄），如果集合的資料量很大，建索引通常要花比較長時間，特別容易引起問題。MongoDB 提供了兩種建索引的訪問，一種是 background 方式，不需要長時間佔用寫鎖，另一種是非 background 方式，需要長時間佔用鎖。使用 background 方式就可以解決問題。
但mongo2.4在建索引的時候，即使指定了background；在從庫重放時，依然會阻塞資料庫的訪問。這個問題在2.6中得到修複，這樣在運行中mongo叢集中建立索引，不用擔心阻塞。對於我們這種小步快跑的業務，真是解決了一大痛點。 mongo2.6到3.0

這次升級由DBA操作，業務側配合。此次升級，直接切換了新的資料庫引擎。 升級的過程

升級離線從庫
2.6升級到3.0前需要驗證現有的使用者schema, 在3.0中MongoDB完全棄用了之前的使用者授權驗證模式，所以在升級3.0前需要把2.6的使用者schema升級到相容3.0的格式。
停掉mongod，將2.6版本mongo的二進位檔案替換成下載的3.0程式包裡的bin目錄裡的二進位檔案，然後重新啟動mongod。

升級線上從庫
主要就是拷貝資料，重啟一個mongo3.0的執行個體。

升級主庫
因為升級期間，在mongo選主時有短時間的唯讀。為了防止資料寫失敗，在升級前，我們重發了業務代碼，所有寫mongo操作的介面進入維護狀態。
DBA操作：停掉舊的主庫，mongo叢集會重新選主；然後直接把從庫的檔案拷貝到原主庫機器，啟動一個mongo3.0的執行個體；然後把執行個體加入到replica中，最後重新將主庫歸位。 升級的好處 因為切換了儲存引擎，升級後節省了大量磁碟空間，這是最直觀的收益。 在此之前，我們業務的mongo一直是自己營運。DBA更是嫌棄我們這邊的mongo版本太老，不願意接管。這次升級之後，基本可以交付給DBA託管，少操心很多了。 小結 術業有專攻，資料庫營運還是交給DBA來做較好。 升3.0後，mongo機器的cpu負載會比升級之前高，在升級之前應加以評估，貿然升級把cpu打滿可能出現意外。 mongodb的複本集至少需要3台以上才能實現高可用，並且節點的個數最好是基數。我們實際採用的1主2線上從庫2離線從庫。 為了把對業務的影響降到最低，資料庫升級一般放在訪問低估進行。我們此次升級是在淩晨3點進行的，熬夜傷身呐。