Mongodb secondary上面replSet error RS102 too stale to catch up

來源:互聯網
上載者:User

1 http://101.130.92.32:28018/_replSet  監控網站上報錯:replSet error RS102 too stale to catch up
Tue Aug 13 05:18:06 [rsSync] replSet See

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

           05:18:06 [rsSync] replSet error RS102 too stale to catch up
           05:20:07 [rsSync] replSet syncing to: 101.130.92.323:27018
           05:20:07 [rsSync] replSet error RS102 too stale to catch up, at lbgst from 101.130.92.323:27018
           05:20:07 [rsSync] replSet our last optime : Aug  6 19:18:05 52014bed:2
           05:20:07 [rsSync] replSet oldest at 101.130.92.323:27018 : Aug 10 10:58:26 52061cd2:17
           05:20:07 [rsSync] replSet See

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

           05:20:07 [rsSync] replSet error RS102 too stale to catch up
           05:22:08 [rsSync] replSet syncing to: 101.130.92.323:27018
           05:22:08 [rsSync] replSet error RS102 too stale to catch up, at lbgst from 101.130.92.323:27018
           05:22:08 [rsSync] replSet our last optime : Aug  6 19:18:05 52014bed:2
           05:22:08 [rsSync] replSet oldest at 101.130.92.323:27018 : Aug 10 10:59:17 52061d05:3e

 

2 察看狀態,發現是recovring狀態    
[bguser@346437-bgstore_db1 ~]$ /db/mongodb/bin/mongo --port 27018
MongoDB shell version: 2.0.1
connecting to: 127.0.0.1:27018/test
RECOVERING> db.printReplicationInfo();
configured oplog size:   90000MB
log length start to end: 553610secs (153.78hrs)
oplog first event time:  Wed Jul 31 2013 09:31:15 GMT+0000 (UTC)
oplog last event time:   Tue Aug 06 2013 19:18:05 GMT+0000 (UTC)
now:                     Tue Aug 13 2013 06:03:40 GMT+0000 (UTC)
RECOVERING> rs.status();
{
        "set" : "rpl",
        "date" : ISODate("2013-08-13T06:03:49Z"),
        "myState" : 3,
        "syncingTo" : "101.130.92.323:27018",
        "members" : [
                {
                        "_id" : 0,
                        "name" : "101.130.92.32:27017",
                        "hbglth" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 8433,
                        "optime" : {
                                "t" : 1376373827000,
                                "i" : 16
                        },
                        "optimeDate" : ISODate("2013-08-13T06:03:47Z"),
                        "lastHbgrtbbgt" : ISODate("2013-08-13T06:03:47Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 4,
                        "name" : "101.130.92.32:27019",
                        "hbglth" : 1,
                        "state" : 7,
                        "stateStr" : "ARBITER",
                        "uptime" : 8435,
                        "optime" : {
                                "t" : 0,
                                "i" : 0
                        },
                        "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
                        "lastHbgrtbbgt" : ISODate("2013-08-13T06:03:47Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 5,
                        "name" : "101.130.92.32:27018",
                        "hbglth" : 1,
                        "state" : 3,
                        "stateStr" : "RECOVERING",
                        "optime" : {
                                "t" : 1375816685000,
                                "i" : 2
                        },
                        "optimeDate" : ISODate("2013-08-06T19:18:05Z"),  -- 同步時間也不對,是8月6日的,今天以及國內13日了
                        "self" : true
                },
                {
                        "_id" : 6,
                        "name" : "101.130.92.323:27017",
                        "hbglth" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 8433,
                        "optime" : {
                                "t" : 1376373827000,
                                "i" : 17
                        },
                        "optimeDate" : ISODate("2013-08-13T06:03:47Z"),
                        "lastHbgrtbbgt" : ISODate("2013-08-13T06:03:47Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 7,
                        "name" : "101.130.92.323:27018",
                        "hbglth" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 8435,
                        "optime" : {
                                "t" : 1376373827000,
                                "i" : 17
                        },
                        "optimeDate" : ISODate("2013-08-13T06:03:47Z"),
                        "lastHbgrtbbgt" : ISODate("2013-08-13T06:03:47Z"),
                        "pingMs" : 0
                }
        ],
        "ok" : 1
}
RECOVERING>     

 

3 去官網上面察看資料,發現如下
http://docs.mongodb.org/manual/tutorial/resync-replica-set-member/#replica-set-resync-by-copying

•Restart the mongod with an empty data directory and let MongoDB’s normal initial syncing fbgture restore the data.
This is the more simple option, but may take longer to replace the data.

重新啟動 步驟如下:
    (1) stop the failed mongod 停止正在啟動並執行同步異常的mongodb服務
    (2) delete all data in the dbpath (including subdirectories) 刪除mongodb目錄下所有的資料檔案包括其他的子目錄
    (3) start it and it will automatically resynchronize itself from primary  啟動mongodb服務,服務會自動從primary上重新同步資料過來。
 

4 重新sync後,狀態一直是 RECOVERING沒有變成secondary,不過資料都已經同步過去了。
RECOVERING> rs.status();
{
        "set" : "rpl",
        "date" : ISODate("2013-08-13T07:58:41Z"),
        "myState" : 3,
        "syncingTo" : "101.130.92.323:27018",
        "members" : [
                {
                        "_id" : 0,
                        "name" : "101.130.92.322:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 5629,
                        "optime" : {
                                "t" : 1376380719000,
                                "i" : 84
                        },
                        "optimeDate" : ISODate("2013-08-13T07:58:39Z"),
                        "lastHeartbeat" : ISODate("2013-08-13T07:58:39Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 4,
                        "name" : "101.130.92.322:27019",
                        "health" : 1,
                        "state" : 7,
                        "stateStr" : "ARBITER",
                        "uptime" : 5629,
                        "optime" : {
                                "t" : 0,
                                "i" : 0
                        },
                        "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
                        "lastHeartbeat" : ISODate("2013-08-13T07:58:39Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 5,
                        "name" : "101.130.92.322:27018",
                        "health" : 1,
                        "state" : 3,
                        "stateStr" : "RECOVERING",
                        "optime" : {
                                "t" : 1376380721000,
                                "i" : 31
                        },
                        "optimeDate" : ISODate("2013-08-13T07:58:41Z"),
                        "self" : true
                },
                {
                        "_id" : 6,
                        "name" : "101.130.92.323:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 5629,
                        "optime" : {
                                "t" : 1376380719000,
                                "i" : 66
                        },
                        "optimeDate" : ISODate("2013-08-13T07:58:39Z"),
                        "lastHeartbeat" : ISODate("2013-08-13T07:58:39Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 7,
                        "name" : "101.130.92.323:27018",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 5629,
                        "optime" : {
                                "t" : 1376380719000,
                                "i" : 66
                        },
                        "optimeDate" : ISODate("2013-08-13T07:58:39Z"),
                        "lastHeartbeat" : ISODate("2013-08-13T07:58:39Z"),
                        "pingMs" : 0
                }
        ],
        "ok" : 1
}
RECOVERING>  

還需要繼續觀察一段時間,看是否最終會從RECOVERING變成secondary。

 

觀察了1天之後,還是RECOVRING, 日誌裡面也沒有報任何異常資訊.只好嘗試著重新啟動了下

kill 12292

/db/mongodb/bin/mongod -f /etc/mongodb/27018.conf

 

結果status變成了secondary了.

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.