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

логи, 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 актуальный , один в непонятно каком состоянии

верно

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

очистил

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

теперь жду?

да

если не начала синкать (rs.status), то перезапустите её

слейв?

конечно

я уже перезапустил

в статусе должно появитсья, типа, "синкаюсь я"

вроде даже %

возможно в логах проценты

не помню сейча с

оно? syncing from: 1.2.3.4:27017

да. А статусстр?

"_id" : 1, "name" : "1.2.3.5:27017", "health" : 1, "state" : 9, "stateStr" : "ROLLBACK", "uptime" : 1389, "optime" : Timestamp(1461243514, 7), "optimeDate" : ISODate("2016-04-21T12:58:34Z"), "lastHeartbeat" : ISODate("2016-05-04T14:59:54.343Z"), "lastHeartbeatRecv" : ISODate("2016-05-04T14:59:54.747Z"), "pingMs" : 0, "syncingTo" : "1.2.3.4:27017", "configVersion" : 47573

\\\

хм

а где syncing from?

в логах

а файлы начали создаваться?

в роллбэке?

нет. роллбека больше не должно быть

в каталоге бд

у вас сейчас должна заново вся реплика перекачаться

нет

файлов

я вынужден уйти с раб места

еще раз: у вас сервер, который .5, сам восстановить базу не смог. Вы очищаете весь dbpath, т.е все базы на нем удаляете. Монга должна это увидеть и начать полное восстановление реплики, с нуля