и ваще, монговцы сами нам открытым текстом сказали что нехуй использовать map/reduce, валите на aggregation framework

правда они молодцы и AF не умеет output без замены коллекции

и ваще, монговцы сами нам открытым текстом сказали что нехуй использовать map/reduce, валите на aggregation framework

это в 3.0? создание коллекции локает шард?

правда они молодцы и AF не умеет output без замены коллекции

так вот это и проблема

погоди, а если rereduce со старым output делать, все равно есть временная? я чего то не замечал...

погоди, а если rereduce со старым output делать, все равно есть временная? я чего то не замечал...

у нас не очень выходит делать re/reduce там на каждем шаге надо брать старый источник

в смысле читать из коллекции

потому что данные могут приезжать в разнабой

или это только на sharded? мы просто тогда шардингом не играли, потому что просто поставили большие тачки с кучей памяти и lvm поверх iscsi

да, на sharded

в простом реплика-сете всё нормально

у нас не очень выходит делать re/reduce там на каждем шаге надо брать старый источник

ну вот может таки путь в rereduce:)

да не выйдет, яж говорю

ну ок, больно тогда, надо этим поиграть, щас ресурсы есть попднимать шарды;)

в батче могут быть данные за любое время вообще

а для того чтоб обновить временной интервал, надо прочитать все записи которые в него попадают

так как там относительно сложна математика по аггрегациям

или это только на sharded? мы просто тогда шардингом не играли, потому что просто поставили большие тачки с кучей памяти и lvm поверх iscsi

А расскажи про это

а чего рассказывать? уже все рассказал:)

и xfs поверх:)

ох и нафлудили, что то решили хоть или так?

господа, посоветуйте чем лучше бекапить базу по 3/4 тера ?

мы бэкапим снапшотом zfs. Правда, приходится останавливать монгу на минутку

но других вариантов особо нет

но слейв остановить дешево, правильно ?

у нас нет слейва. Если есть - то да, вообще красота

т.е у нас сценарий такой: стопаем монгодб (только осторожно - надо тщательно следить, что она остановилась, инит скрипты там глючные были в 2.7), снапшотим раздел с базами, запускаем монгодб, утягиваем снапшот в бакулу

объем большой ?

Если есть хидден реплика - достаточно сделать fsynclock и cp/rsync

нет хидден нету

Если есть хидден реплика - достаточно сделать fsynclock и cp/rsync

в 3.2

А зачем при снапшоте останавливать базу?

до 3.2 fsynclock ничего не гарантирует на самом деле

в 3.2

Это если wt

у меня wt

да, а зачем mmap вобще

и 3.2

он не нужен

А зачем при снапшоте останавливать базу?

потому что тебе никто не гарантирует что у тебя роллбека не будет

если монгу штатно потушить, она положит всё на диск и шанс что у тебя там чекпоинт какой-то не доехал или с журналом говно практически нулевой

но с 3.2 и wt можно и без этого, да

Ну тушить базу на проде - это прям какой-то нонсенс.

так ладно понял, принципиальной разницы lvm snapshot или zfs snapshot нету ведь ?

механика будет такой же

Ну тушить базу на проде - это прям какой-то нонсенс.

hidden replica и танцуй как хочешь

более того

если у тебя sharded cluster, других вариантов вообще нет

причём там придётся знатно поебаться чтоб у тебя он к хуям не развалился

hidden replica и танцуй как хочешь

Про hidden я чуть выше уже написал.

это я к «тушить на проде»

а вообще в монге летать без реплики это так себе затея :)

мы бэкапим снапшотом zfs. Правда, приходится останавливать монгу на минутку

у нас нет слейва. Если есть - то да, вообще красота

мы монгу с 1.8 кажется эксплуатируем

или чо там последнее было до 2.0

так ладно понял, принципиальной разницы lvm snapshot или zfs snapshot нету ведь ?

да, lvm только дольше будет вроде

если у вас по случаю будет шард, то там всё гораздо хуже

надо делать hidden member на каждый шард + конфиг сервер

и потом лочить базу, делать fsync, натурально выключать скрытых членов, отпускать лок и бекапить всех разом

шаред кластер пока в планах отсутствует

большая часть базы - архив

все равно одновременно (до милсекунды) fsync не сделать, так что oplog тянуть все равно придется, а в этом случае уже не так критично насколько одновременно сделан бекап

все равно одновременно (до милсекунды) fsync не сделать, так что oplog тянуть все равно придется, а в этом случае уже не так критично насколько одновременно сделан бекап

там до fsync важный момент: поставить всю базу в лок

там до fsync важный момент: поставить всю базу в лок

это жесть

клиенты подождут?

да

иначе твой бекап — говно

если вдруг создался новый чанк, то ты в жопе :)

чтобы чанки не создавались можно балансер отключить

потому что если у тебя в бекапе конфиг сервера этого чанка не будет, ты потерял данные

на время бекапа

там всё не так просто, увы :(

стоп, а кто будет чанки плодить при отключенном балансере?

балансер исключительно катает чанки между шардами

может случится chunk split

потому что его делает mongos

ну хз... потушить один config сервер))

хотя если chunk split вдруг и произойдет, это не повлияет на сохранность данных - они на том же шарде и останутся

А что такое сделали в 3.2, что можно делать снапшот не боясь неконсистентности потом?

интересно

ну 3.2 + wt

А что такое сделали в 3.2, что можно делать снапшот не боясь неконсистентности потом?

https://docs.mongodb.com/manual/reference/method/db.fsyncLock/#compatibility-with-wiredtiger

в теории CoW

и сделали так, чтоб ты мог поставить без ебли базу во write lock

и оно сделает fsync сливая данные на диск

после этого ты можешь сделать бекап и потом сделать unlock

всё это время запись будет стоять раком

о

круто. спасибо

в теории CoW

^^ CoW в wt был изначально, вобщем-то за это его и купили. но в 3.2 это всё в порядок привели

Хотя штатный шутдаун на пару минут ночью для бекапа - для нас не критично

單槍匹馬 ⠀ ⠀⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀ ⠀ ⠀⠀⠀⠀ who are you?

О! Рома не спит, привет!

Это очень клёвый, наш человек ) нуждается в консультации по Монге. У него нода за сто лямов перешла, нужен так сказать совет на практике

О! Рома не спит, привет!

уже сплю )