版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/LeonWang_Fly/article/details/51067205
前话
根据前人经验及留下的文档在linux服务器上安装了mongo3.2.4数据库并做了复制集，三台服务器A、B、C,配置好后A作为主节点（primary），B与C分别作为次要节点（secondary）.上线后想看看数据增长量（数据库主要用于存储日志），意外发现日志尽然存储的路径所在的挂载点竟然只有50G，OMG……灾难啊 幸好发现及时而且使用该服务的项目还不多，数据仅有3G左右，赶紧调整呗，调整要求目录切换到另一个大存储空间的挂载点下的目录，而且服务不能停，数据不能丢失
正题
进入mongo官网翻看文档，终于找见一个可行的方案。
这是三台服务器的布局
当主节点发生异常中断后，从节点之间选出一个主节点继续运行，当从节点出现异常时另外两个节点无影响，当异常节点恢复之后将与主节点进行同步。
基于上面的思路，数据库路径切换就变的简单了，我的操作如下：
1.备份并重写启动和停止mongo的脚本（重写的脚本中主要调整原来的数据存储目录为新存储目录）
2.选中一台从节点用原来的停止脚本停止mongo服务，其他两台正常运行，应用服务不受影响。然后复制原来数据目录下的所有文件到新数据目录，之后使用新的启动脚本启动服务（启动完成检查该节点停止之后写入主节点的数据是否已经同步）
3.使用相同的方法把另外一台从节点也同样完成切换，对主节点进行操作基本完全相同，不过停止服务之后需要留意其他两台从节点是否完成选举，选举出一个主节点。
操作过程中可能使用到如下命令：
--打开mongo shell
mongo
--切换到admin数据库
use admin
--授权
db.auth("root","pwd")
--查看复制集状态
db.status()操作过程中始终需要在不正在进行切换的节点上查看复制集的状态信息，切换完成后确认操作节点在恢复后数据是否完成同步。
节点10.199.199.28服务停止之后状态可能如下（关注_id:2的元素的stateStr）：
[mongodb@localhost ~]$ mongo
MongoDB shell version: 3.2.4
connecting to: test
rs0:SECONDARY> use admin
switched to db admin
rs0:SECONDARY> db.auth("root","111111")
1
rs0:SECONDARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2016-04-05T11:44:55.429Z"),
"myState" : 2,
"term" : NumberLong(-1),
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "10.199.199.179:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2960,
"optime" : Timestamp(1459856509, 1),
"optimeDate" : ISODate("2016-04-05T11:41:49Z"),
"infoMessage" : "could not find member to sync from",
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "10.199.199.27:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2959,
"optime" : Timestamp(1459856509, 1),
"optimeDate" : ISODate("2016-04-05T11:41:49Z"),
"lastHeartbeat" : ISODate("2016-04-05T11:44:54.787Z"),
"lastHeartbeatRecv" : ISODate("2016-04-05T11:44:55.106Z"),
"pingMs" : NumberLong(0),
"electionTime" : Timestamp(1459847962, 1),
"electionDate" : ISODate("2016-04-05T09:19:22Z"),
"configVersion" : 5
},
{
"_id" : 2,
"name" : "10.199.199.28:27017",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : Timestamp(0, 0),
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2016-04-05T11:44:53.542Z"),
"lastHeartbeatRecv" : ISODate("2016-04-05T11:44:50.760Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "Connection refused",
"configVersion" : -1
}
],
"ok" : 1
}每完成一个节点切换状态大致如下（主从节点可能有所不同）：
rs0:SECONDARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2016-04-05T11:39:23.203Z"),
"myState" : 2,
"term" : NumberLong(-1),
"syncingTo" : "10.100.135.28:27017",
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "10.199.199.179:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2628,
"optime" : Timestamp(1459856228, 10),
"optimeDate" : ISODate("2016-04-05T11:37:08Z"),
"syncingTo" : "10.199.199.28:27017",
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "10.199.199.27:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2627,
"optime" : Timestamp(1459856228, 10),
"optimeDate" : ISODate("2016-04-05T11:37:08Z"),
"lastHeartbeat" : ISODate("2016-04-05T11:39:22.287Z"),
"lastHeartbeatRecv" : ISODate("2016-04-05T11:39:22.868Z"),
"pingMs" : NumberLong(0),
"electionTime" : Timestamp(1459847962, 1),
"electionDate" : ISODate("2016-04-05T09:19:22Z"),
"configVersion" : 5
},
{
"_id" : 2,
"name" : "10.199.199.28:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2627,
"optime" : Timestamp(1459856228, 10),
"optimeDate" : ISODate("2016-04-05T11:37:08Z"),
"lastHeartbeat" : ISODate("2016-04-05T11:39:22.285Z"),
"lastHeartbeatRecv" : ISODate("2016-04-05T11:39:22.587Z"),
"pingMs" : NumberLong(0),
"syncingTo" : "10.199.199.27:27017",
"configVersion" : 5
}
],
"ok" : 1
}此次问题处理完，嗯mongo的用户体验棒棒哒~~