总体思路
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/