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)

этот стейт уже больше недели. перед запуском всё было скопировано через rsync

вот это вы зря. Больше недели это однозначно не нормальное время, по доке, данных для ролбека не может быть больше 300ьи

mb

https://docs.mongodb.org/manual/core/replica-set-rollbacks/

какие советы будут

я подумываю о разрыве реплики и поторном копировании базы

и ещё момент

мастер останавливать не вкоме случае нельзя

тоесть при копировании я скопирую лок файл

не может ли эта байда быть из за него?

Попробуйте убрать файлы 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'ом

это про слейв речь так?

про тот, который сейчас ROLLBACK

слей

он был MASTER

ну, праймари

почему

у меня слейв в роллбэке

смысл процесса rollback почитайте по ссылке

спасибо за инфу

вот есть там папочка роллбек

и там есть файлы bson

их тупо перенести с папки?

все?

если кратко: вот работает primary, и внезапно падает. Секондари становится праймари. Бывший праймари поднимается и видит, что он упал, но какая-то часть данных не успела уйти на секондари перед его падением. И он пытается сделать роллбек, т.е досинкать те данные, которые не успели уйти с него на секондари

ну собсно это понятно

да. попробуйте =) Возможно, надо будет перезапустить роллбека

монгу?

да

ок

Поэтому я и говорю, что тот, который сейчас ROLLBACK - это бывший праймари.

Как получится - отпишитесь пожалуйста

переместил файлы и рестартонул

и как оно

,

?

рестартонулась

уже не плохо =)

жрет опаративу 96%

локально не могу подкл пишет коннектинг и все

на мастере "stateStr" : "(not reachable/healthy)",

Подождите немного. оно не понятно чем занималось неделю. Если репликации не было, то реплика давно устарела и останется только заново её инитить

логи, rs.status() ?

"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

лог на слейве

ну подождите, может сможет протолкнуть данные. я пока больше ничем не помогу. Если у вас продуть по сети 750гб реально, похоже, нужно готовится к этому...

реално

рсинком 3 часа занимает

в ссренем

а вы где-то прочитали, что можно синкать рсинком? Да еще работающую БД?

без остановки БД это однозначно мусор

а где то вычитал

щас уже не скажу

толи на хабрахшмабрах толи на офф сайте монги

Не может быть такого. нет, так нельзя. вы что. У вас данные в файлы пишутся, а вы их копируете. КОнечно, там фарш получится.

хм

нет нет и нет. это нереально.

ок какие у меня есть варианты?

стоп я вспомнил

последний абзац по ссылке, которую я кидал. Очищаете dbpath на секондари и ждете

я делал копию папки монгодб

долго ждете

останавливал базу

пока делал локальную копию

там простой был около 3х мин

с остановкой БД может быть. Но надо уточнить как репликасет к таком отнесется, что у неё возниктет точная копия базы. С остановкой можно слепок сделать, да, но старый у вас уже устарел, он уже не сможет синхронизироваться

эмм вот этот пункт про 300мегабайт лимит файла

это роллбек

у меня таких маленьких и нет

средний весит 2 гб

а не вру есть и 65 мегабайт

а точно роллбеки? ну в доке написано, что монга сама не восстанавливает более 300мб, но, видимо, она дампит в файлы всё, что по её мнению нужно роллбекнуть.

файлы - это обычные файлы БД

первые маленькие, потом больше больше и потом уже по 2гб идут

не не это я про мастер гвоорю

ну у монги файлы баз по 2гб , да.

в папке роллбек на слейве файлы не больше 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

утакуот

о

ну да, типа, больше 300мб не хочу

ну кароче че мне делать?

в этой ситуации?

есть совет?

[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.

про какого мембера идет реч?

как сделат это force the member to perform an initial sync.?

ну в данный момент у вас 1 актуальный , один в непонятно каком состоянии

верно

выбор очевиден - очищайте "роллбека" =)

очистил

синк будет делать монга

теперь жду?