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 в этом случае?
  • Вопрос задан
  • 3648 просмотров
Пригласить эксперта
Ответы на вопрос 1
egor_nullptr
@egor_nullptr
* Вывести проблемную ноду из реплики
* Удалить всё то, что она успела вытащить с PRIMARY
* Вывести арбитра из реплики
* Добавить первую ноду на общих правах

как-то так
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы