總體思路
Mongos整個分片集羣版本升級時，先確定升級mongos和config server，因爲經過測試，假如先升級sharding節點的話，會導致mongos查詢不可用，存在版本兼容性問題，報錯截圖如下
另一方面，如果先升級mongos和config server節點的話，就不存在兼容性問題，3.0的mongos和config server能夠正常讀取低版本的sharding 節點數據
環境說明
原先的mongos集羣部署情況 1mongos+3configserver+2sharding server，版本均爲2.6
目標的mongos集羣部署情況1 mongos+3configserver+2sharding server，版本均爲3.0
升級要求
升級完成後，mongos IP不變，config server的IP改變，sharding server的IP改變，目標3.0的sharding節點使用WT引擎，configsvr使用WT引擎
升級步驟
1關閉負載均衡器
mongos> sh.stopBalancer()
Waiting for active hosts...
Waiting for the balancer lock...
Waiting again for active hosts afterbalancer is off...
mongos> sh.getBalancerState()
false
2停服，主要爲了禁止以下的任何操作，如果確認沒有這些操作可以不用停服
3 關閉mongos，替換成3.0的mongos(此時的mongo shell不要替換，不然會造成config和admin庫表顯示異常，因爲mongos讀取的config server的信息，此時的config server版本還沒升級)
4 更新mongos版本 ，即mongos進程後面加上--upgrade參數
mongos --configdb <configDBstring> --upgrade
5 確認mongos更新成功，如下截圖所示
6 正常啓動mongos，確認服務正常，備份其中一個configserver
./mongodump --host 127.0.0.1-uucloudbackup -p2486Uut0oZ
7 將備份傳輸到目標物理機，並導入其中一個3.0的configserver
./mongorestore --host127.0.0.1 -uucloudbackup -pYDdkhvKKS4 dump/ --drop
8 關閉所有3.0的configserver，將data目錄傳輸到其他兩個config server
scp -r/opt/udb/instance/mongodb-3.0/udb-kpykgj/data/* [email protected]:/opt/udb/instance/mongodb-3.0/udb-rcma1q/data/
9 關閉所有節點，包括shardingserver，原來2.6的config server，已經升級好的mongos 3.0（一定要全部關閉，不然會存在緩衝信息導致衝突）
10 啓動2.6 sharding server
11 啓動3.0 的config server
12 啓動3.0的mongos，這時的—configdb改爲3.0的config server的三個ip
13 這時替換mongos所在的db的mongo shell客戶端爲3.0，並登陸mongos，確定服務正常，因爲此時的configserver已經是3.0，需要對應的3.0的mongo shell登陸
14 目前爲止，mongos和config server升級完成，啓動服務，開啓負載均衡器，sh.startBalancer()
15 挨個創建sharding server的3.0版本的secondary節點(WT引擎)
16 挨個切換替換（不用考慮修改mongos設置，mongos可自動識別當前副本集的配置信息）
17 sharding節點升級完成，整個mongos集羣升級完成
其中一個後遺症
某次將其改爲yaml格式後，mongos就會一直報中斷的錯誤，不斷刷屏，但實際上似乎對業務也沒啥影響
參考文檔
mongos集羣升級官方文檔
https://docs.mongodb.com/v3.0/release-notes/3.0-upgrade/
configsvr換IP的遷移方法
https://docs.mongodb.com/v3.0/tutorial/migrate-config-servers-with-different-hostnames/