Mongodb replicaset — вечный STARTUP2?
Есть монга, нормально функционирующий replica set из трёх участников: primary, secondary, arbiter:
MongoDB shell version: 2.4.8 connecting to: test set_v2:STARTUP2> rs.status( ) { «set»: «set_v2», «date»: ISODate(«2014-02-06T08:20:54Z»), «myState»: 5, «syncingTo»: «deb-db:27017», «members»: [ { "_id": 1, «name»: «eng-db:27017», «health»: 1, «state»: 7, «stateStr»: «ARBITER», «uptime»: 169086, «lastHeartbeat»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:54Z»), «pingMs»: 50 }, { "_id": 2, «name»: «jam-db:27017», «health»: 1, «state»: 2, «stateStr»: «SECONDARY», «uptime»: 169086, «optime»: Timestamp(1391674853, 18), «optimeDate»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeat»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:53Z»), «pingMs»: 50, «syncingTo»: «deb-db:27017» }, { "_id": 3, «name»: «deb-db:27017», «health»: 1, «state»: 1, «stateStr»: «PRIMARY», «uptime»: 169086, «optime»: Timestamp(1391674852, 50), «optimeDate»: ISODate(«2014-02-06T08:20:52Z»), «lastHeartbeat»: ISODate(«2014-02-06T08:20:52Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:52Z»), «pingMs»: 50 }, { "_id": 4, «name»: «bac-db:27017», «health»: 1, «state»: 5, «stateStr»: «STARTUP2», «uptime»: 169109, «optime»: Timestamp(1391505782, 63), «optimeDate»: ISODate(«2014-02-04T09:23:02Z»), «errmsg»: «syncing to: deb-db:27017», «self»: true } ], «ok»: 1 }
Базы достаточно большие. Возникла необходимость добавить ещё одного участника. Добавил стандартным путём, но через какое-то время реплика перестала забирать дамп с primary.
Фрагмент лога на новом участнике со статусом STARTUP2:
Thu Feb 6 11:42:25.931 [rsBackgroundSync] Socket recv() timeout 212.158.000.000:27017 Thu Feb 6 11:42:25.931 [rsBackgroundSync] SocketException: remote: 212.158.000.000:27017 error: 9001 socket exception [RECV_TIMEOUT] server [212.158.000.000:27017] Thu Feb 6 11:42:25.931 [rsBackgroundSync] DBClientCursor::init call() failed Thu Feb 6 11:42:25.931 [rsBackgroundSync] replSet not trying to sync from secondary_host:27017, it is vetoed for 389 more seconds
Фрагмент лога на Primary:
Thu Feb 6 12:16:19.894 [conn6710131] query local.oplog.rs query: { ts: { $gte: Timestamp 1391505782000|63 } } cursorid:7488360248332995795 ntoreturn:0 ntoskip:0 nscanned:102 keyUpdates:0 numYields: 19063 locks(micros) r:7039453 nreturned:101 reslen:16421 39051ms
То есть похоже, что oplog очень большой и есть некий timeout для участника реплики и startup2 не влезает в этот timeout.
Как, собственно, победить и запустить новый secondary в этом случае?
MongoDB shell version: 2.4.8 connecting to: test set_v2:STARTUP2> rs.status( ) { «set»: «set_v2», «date»: ISODate(«2014-02-06T08:20:54Z»), «myState»: 5, «syncingTo»: «deb-db:27017», «members»: [ { "_id": 1, «name»: «eng-db:27017», «health»: 1, «state»: 7, «stateStr»: «ARBITER», «uptime»: 169086, «lastHeartbeat»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:54Z»), «pingMs»: 50 }, { "_id": 2, «name»: «jam-db:27017», «health»: 1, «state»: 2, «stateStr»: «SECONDARY», «uptime»: 169086, «optime»: Timestamp(1391674853, 18), «optimeDate»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeat»: ISODate(«2014-02-06T08:20:53Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:53Z»), «pingMs»: 50, «syncingTo»: «deb-db:27017» }, { "_id": 3, «name»: «deb-db:27017», «health»: 1, «state»: 1, «stateStr»: «PRIMARY», «uptime»: 169086, «optime»: Timestamp(1391674852, 50), «optimeDate»: ISODate(«2014-02-06T08:20:52Z»), «lastHeartbeat»: ISODate(«2014-02-06T08:20:52Z»), «lastHeartbeatRecv»: ISODate(«2014-02-06T08:20:52Z»), «pingMs»: 50 }, { "_id": 4, «name»: «bac-db:27017», «health»: 1, «state»: 5, «stateStr»: «STARTUP2», «uptime»: 169109, «optime»: Timestamp(1391505782, 63), «optimeDate»: ISODate(«2014-02-04T09:23:02Z»), «errmsg»: «syncing to: deb-db:27017», «self»: true } ], «ok»: 1 }
Базы достаточно большие. Возникла необходимость добавить ещё одного участника. Добавил стандартным путём, но через какое-то время реплика перестала забирать дамп с primary.
Фрагмент лога на новом участнике со статусом STARTUP2:
Thu Feb 6 11:42:25.931 [rsBackgroundSync] Socket recv() timeout 212.158.000.000:27017 Thu Feb 6 11:42:25.931 [rsBackgroundSync] SocketException: remote: 212.158.000.000:27017 error: 9001 socket exception [RECV_TIMEOUT] server [212.158.000.000:27017] Thu Feb 6 11:42:25.931 [rsBackgroundSync] DBClientCursor::init call() failed Thu Feb 6 11:42:25.931 [rsBackgroundSync] replSet not trying to sync from secondary_host:27017, it is vetoed for 389 more seconds
Фрагмент лога на Primary:
Thu Feb 6 12:16:19.894 [conn6710131] query local.oplog.rs query: { ts: { $gte: Timestamp 1391505782000|63 } } cursorid:7488360248332995795 ntoreturn:0 ntoskip:0 nscanned:102 keyUpdates:0 numYields: 19063 locks(micros) r:7039453 nreturned:101 reslen:16421 39051ms
То есть похоже, что oplog очень большой и есть некий timeout для участника реплики и startup2 не влезает в этот timeout.
Как, собственно, победить и запустить новый secondary в этом случае?
Похожие публикации
MongoDB. Почему при увеличении размера коллекции сильно увеличивается время вставки новых документов?
Нет комментариев