前話

根據前人經驗及留下的文件在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）：

[[email protected] ~]$ 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的使用者體驗棒棒噠~~