James
04.05.2016
14:14:44
mongo-master ~ # mongo
MongoDB shell version: 3.0.10
connecting to: test
actr:PRIMARY> rs.status()
{
"set" : "actr",
"date" : ISODate("2016-05-04T13:45:03.798Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "1.2.3.4:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1124613,
"optime" : Timestamp(1462369502, 3),
"optimeDate" : ISODate("2016-05-04T13:45:02Z"),
"electionTime" : Timestamp(1461245375, 1),
"electionDate" : ISODate("2016-04-21T13:29:35Z"),
"configVersion" : 47573,
"self" : true
},
{
"_id" : 1,
"name" : "1.2.3.5:27017",
"health" : 1,
"state" : 9,
"stateStr" : "ROLLBACK",
"uptime" : 143156,
"optime" : Timestamp(1461243514, 7),
"optimeDate" : ISODate("2016-04-21T12:58:34Z"),
"lastHeartbeat" : ISODate("2016-05-04T13:45:02.126Z"),
"lastHeartbeatRecv" : ISODate("2016-05-04T13:45:03.306Z"),
"pingMs" : 0,
"syncingTo" : "1.2.3.4:27017",
"configVersion" : 47573
},
{
"_id" : 2,
"name" : "1.2.3.6:27017",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 1123842,
"lastHeartbeat" : ISODate("2016-05-04T13:45:02.809Z"),
"lastHeartbeatRecv" : ISODate("2016-05-04T13:45:03.146Z"),
"pingMs" : 0,
"configVersion" : 47573
}
],
"ok" : 1
}
actr:PRIMARY> db.printReplicationInfo()
configured oplog size: 51200.00352478027MB
log length start to end: 2425597secs (673.78hrs)
oplog first event time: Wed Apr 06 2016 15:28:25 GMT+0300 (MSK)
oplog last event time: Wed May 04 2016 17:15:02 GMT+0300 (MSK)
now: Wed May 04 2016 17:15:02 GMT+0300 (MSK)
Alex
04.05.2016
14:19:33
mb
Google
Alex
04.05.2016
14:19:39
https://docs.mongodb.org/manual/core/replica-set-rollbacks/
James
04.05.2016
14:20:07
какие советы будут
я подумываю о разрыве реплики и поторном копировании базы
и ещё момент
мастер останавливать не вкоме случае нельзя
тоесть при копировании я скопирую лок файл
не может ли эта байда быть из за него?
Alex
04.05.2016
14:22:12
Попробуйте убрать файлы rollback'a, они там где-то рядом с файлами бд. Только не удаляйте, а просто переместите куда нить. Но это на свой страх и риск. Но раз вы неделю потерю данных не обнаружили, вряд ли там что-то ценное, даже если оно там есть
When a rollback does occur, MongoDB writes the rollback data to BSON files in the rollback/ folder under the database’s dbPath directory.
в принципе, данные не потеряны, вы можете почитать их bsondump'ом
James
04.05.2016
14:24:27
это про слейв речь так?
Alex
04.05.2016
14:25:07
про тот, который сейчас ROLLBACK
James
04.05.2016
14:25:11
слей
Google
Alex
04.05.2016
14:25:27
он был MASTER
ну, праймари
James
04.05.2016
14:25:58
почему
у меня слейв в роллбэке
Alex
04.05.2016
14:26:34
смысл процесса rollback почитайте по ссылке
James
04.05.2016
14:27:32
спасибо за инфу
вот есть там папочка роллбек
и там есть файлы bson
их тупо перенести с папки?
все?
Alex
04.05.2016
14:28:02
если кратко: вот работает primary, и внезапно падает. Секондари становится праймари. Бывший праймари поднимается и видит, что он упал, но какая-то часть данных не успела уйти на секондари перед его падением. И он пытается сделать роллбек, т.е досинкать те данные, которые не успели уйти с него на секондари
James
04.05.2016
14:28:25
ну собсно это понятно
Alex
04.05.2016
14:28:29
да. попробуйте =) Возможно, надо будет перезапустить роллбека
James
04.05.2016
14:28:43
монгу?
Alex
04.05.2016
14:28:45
да
James
04.05.2016
14:28:49
ок
Alex
04.05.2016
14:29:11
Поэтому я и говорю, что тот, который сейчас ROLLBACK - это бывший праймари.
Dan
04.05.2016
14:31:39
Как получится - отпишитесь пожалуйста
James
04.05.2016
14:31:59
переместил файлы и рестартонул
Alex
04.05.2016
14:34:05
и как оно
Google
Alex
04.05.2016
14:34:06
,
?
James
04.05.2016
14:34:25
рестартонулась
Alex
04.05.2016
14:34:34
уже не плохо =)
James
04.05.2016
14:34:37
жрет опаративу 96%
локально не могу подкл пишет коннектинг и все
на мастере "stateStr" : "(not reachable/healthy)",
Alex
04.05.2016
14:35:51
Подождите немного. оно не понятно чем занималось неделю. Если репликации не было, то реплика давно устарела и останется только заново её инитить
логи, rs.status() ?
James
04.05.2016
14:37:42
"stateStr" : "ROLLBACK",
в папке роллбек файлов пока нет
2016-05-04T17:36:55.980+0300 W REPL [rsBackgroundSync] replSet WARNING ignoring op on rollback no _id TODO : tickets_logs_new_201604.system.
indexes { ts: Timestamp 1461013205000|9, h: 8313529710310657556, v: 2, op: "i", ns: "tickets_logs_new_201604.system.indexes", o: { ns: "tickets_
logs_new_201604.activity_19", key: { session_id: 1, request_time: 1 }, background: true, name: "sessionIdTimeIndex" } }
2016-05-04T17:36:55.980+0300 W REPL [rsBackgroundSync] replSet WARNING ignoring op on rollback no _id TODO : tickets_logs_new_201604.system.
indexes { ts: Timestamp 1461013205000|8, h: -4939554236523807719, v: 2, op: "i", ns: "tickets_logs_new_201604.system.indexes", o: { ns: "tickets
_logs_new_201604.activity_19", key: { request_type: 1, request_time: 1 }, background: true, name: "requestTypeTimeIndex" } }
2016-05-04T17:36:55.980+0300 W REPL [rsBackgroundSync] replSet WARNING ignoring op on rollback no _id TODO : tickets_logs_new_201604.system.
indexes { ts: Timestamp 1461013205000|7, h: 6841525122677744811, v: 2, op: "i", ns: "tickets_logs_new_201604.system.indexes", o: { ns: "tickets_
logs_new_201604.activity_19", key: { request_type: 1 }, background: true, name: "requestTypeIndex" } }
2016-05-04T17:36:55.980+0300 W REPL [rsBackgroundSync] replSet WARNING ignoring op on rollback no _id TODO : tickets_logs_new_files_20160419
.system.indexes { ts: Timestamp 1461013205000|2, h: -2712932182399140590, v: 2, op: "i", ns: "tickets_logs_new_files_20160419.system.indexes", o
: { ns: "tickets_logs_new_files_20160419.fs.chunks", unique: true, key: { files_id: 1, n: 1 }, name: "files_id_1_n_1" } }
2016-05-04T17:36:59.132+0300 I REPL [rsBackgroundSync] replSet rollback found matching events at Apr 18 17:43:13:20
2016-05-04T17:36:59.132+0300 I REPL [rsBackgroundSync] replSet rollback findcommonpoint scanned : 4099281
2016-05-04T17:36:59.132+0300 I REPL [rsBackgroundSync] replSet rollback 3 fixup
лог на слейве
Alex
04.05.2016
14:43:40
ну подождите, может сможет протолкнуть данные. я пока больше ничем не помогу. Если у вас продуть по сети 750гб реально, похоже, нужно готовится к этому...
James
04.05.2016
14:44:13
реално
рсинком 3 часа занимает
в ссренем
Alex
04.05.2016
14:45:15
а вы где-то прочитали, что можно синкать рсинком? Да еще работающую БД?
без остановки БД это однозначно мусор
James
04.05.2016
14:45:49
а где то вычитал
Google
James
04.05.2016
14:45:53
щас уже не скажу
толи на хабрахшмабрах толи на офф сайте монги
Alex
04.05.2016
14:46:34
Не может быть такого. нет, так нельзя. вы что. У вас данные в файлы пишутся, а вы их копируете. КОнечно, там фарш получится.
James
04.05.2016
14:46:51
хм
Alex
04.05.2016
14:46:57
нет нет и нет. это нереально.
James
04.05.2016
14:47:08
ок какие у меня есть варианты?
стоп я вспомнил
Alex
04.05.2016
14:47:31
последний абзац по ссылке, которую я кидал. Очищаете dbpath на секондари и ждете
James
04.05.2016
14:47:33
я делал копию папки монгодб
Alex
04.05.2016
14:47:35
долго ждете
James
04.05.2016
14:47:37
останавливал базу
пока делал локальную копию
там простой был около 3х мин
Alex
04.05.2016
14:49:40
с остановкой БД может быть. Но надо уточнить как репликасет к таком отнесется, что у неё возниктет точная копия базы. С остановкой можно слепок сделать, да, но старый у вас уже устарел, он уже не сможет синхронизироваться
James
04.05.2016
14:50:03
эмм вот этот пункт про 300мегабайт лимит файла
Alex
04.05.2016
14:50:12
это роллбек
James
04.05.2016
14:50:13
у меня таких маленьких и нет
средний весит 2 гб
а не вру есть и 65 мегабайт
Alex
04.05.2016
14:51:29
а точно роллбеки? ну в доке написано, что монга сама не восстанавливает более 300мб, но, видимо, она дампит в файлы всё, что по её мнению нужно роллбекнуть.
Google
Alex
04.05.2016
14:51:41
файлы - это обычные файлы БД
первые маленькие, потом больше больше и потом уже по 2гб идут
James
04.05.2016
14:51:58
не не это я про мастер гвоорю
Alex
04.05.2016
14:52:41
ну у монги файлы баз по 2гб , да.
James
04.05.2016
14:52:53
в папке роллбек на слейве файлы не больше 10 мб
были
2016-05-04T17:51:47.649+0300 E REPL [rsBackgroundSync] sync producer problem: 13410 replSet too much data to roll back
2016-05-04T17:51:47.649+0300 I REPL [ReplicationExecutor] transition to SECONDARY
утакуот
Alex
04.05.2016
14:54:09
о
ну да, типа, больше 300мб не хочу
James
04.05.2016
14:55:02
ну кароче че мне делать?
в этой ситуации?
есть совет?
Alex
04.05.2016
14:55:18
[replica set sync] replSet syncThread: 13410 replSet too much data to roll back
In this situation, save the data directly or force the member to perform an initial sync. To force initial sync, sync from a “current” member of the set by deleting the content of the dbPath directory for the member that requires a larger rollback.
James
04.05.2016
14:55:45
про какого мембера идет реч?
как сделат это force the member to perform an initial sync.?
Alex
04.05.2016
14:56:07
ну в данный момент у вас 1 актуальный , один в непонятно каком состоянии
James
04.05.2016
14:56:14
верно
Alex
04.05.2016
14:56:32
выбор очевиден - очищайте "роллбека" =)
James
04.05.2016
14:56:39
очистил
Alex
04.05.2016
14:56:39
синк будет делать монга
James
04.05.2016
14:56:43
теперь жду?