так ладно понял, принципиальной разницы 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?

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

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

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

уже сплю )

Ах тыж хитрый ))))))

сто лямов документов? не так уж много.

ну смотря какого размера

если по мегабайту, то очень много :)

или если по 10кб, но с тремя десятками индексов

это и был намек =)

если по мегабайту, то очень много :)

Niet.

100Тб это много

100Тб это много

На одном сервере? Прилично.

100Т данных - это по любому много

тут я смотрю у всех петабайтные монгокластеры

Баз на 60 гигов, мастер. После ненормального шутдауна зпускалась _12 минут_, ппц =( Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Detected unclean shutdown - /var/db/mongo2/mongod.lock is not empty. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] Recovering data from the last clean checkpoint. Jul 30 21:13:38 conveyor mongod.37017[16636]: [initandlisten] wiredtiger_open config: create,cache_size=18G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(en abled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0), Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] Starting WiredTigerRecordStoreThread local.oplog.rs Jul 30 21:25:27 conveyor mongod.37017[16636]: [initandlisten] The size storer reports that the oplog contains 59804846 records totaling to 30178412526 bytes

Ну так рекавери жи.

12 минут?

Рекавери должен быть мгновенным - там журнал включен

Я где-то месяц назад восстанавливал минут 15 базу на 400 GB.

С журналом.

Так что вроде бы ничего необычного.

Так вот странно. По идее размер бд не должен влиять на время, если есть журнал.

Какого лешего она столько времени делает-то?

Проверить на корректность достаточно последние записи в журнале. И всё, погнали, чего еще делать?

Оно вроде весь оплог переливает снова

При recovery

Если оплога было много, займёт много времени

М.. куда переливает?

там два варианта: когда ты в репликасете и нет

помоему в репликасете в зависимости от условий, оно или делает initial synс или делает роллбек и проигрывает оплог снова