Первый реальный проект в docker-е запускаю наконец-то

Правда это legacy, а не новый проект. Надо же как-то сервер обновить под ним:)

Но монга вполне завелась. Теперь осталось скопировать ей файлы базки под контейнер и можно сносить 2.4 с того хоста...

Официальный монговский образ для докера самый старый 2.6 только, кстати...

База одна что ли? Без реплик?

Ну там да, тупо с журналом

Там и редис-а было бы достаточно

Но с монгой удобней

как арбитра заставить поменять местами мастер и слейв?

На мастере сделать rs.stepDown(). Причём тут арбитр?

чота я пропустил!

превед!

коллеги подскажите почему такая разница в размере между mmap и wiredtrigger

потому что компрессия ;)

кто-то уже с инкрементальными бекапами разобрался?

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

но они все чота умерли. У меня есть идея написать тупую писалку оплога, когда переодически цепляется как hidden member и тянет оплог к себе. а дальше сохраняй себе дифф с предыдущей пачкой

А чем постоянный hidden member плохо?

Делай с него бэкапы сколько угодно

Можно его на cow fs посадить, тогда можно будет откатить куда угодно ...

Делай с него бэкапы сколько угодно

Просто бекапы это всё понятно

Но когда у тебя кластер в террабайт особо не на бекапишься.

На zfs можно посадить, да. Но это надо zfs, а он не всегда и везде есть. В ZoL например недавно баг с попорченными снепшотами всплыл

btrfs страшно

А больше вариантов особо и нет.

Так что хочется на уровне приложения это делать

Есть thin lvm или как его там.

Имхо cow сделать не проблема. В крайнем случае можно Солярис взять

Опять же, даже если бэкапить руками и дифать, если уж хочется, то все равно не вижу смысла эту реплику отключать и подключать. Пусть бежит себе и бэкапит.

Опять же на уровне приложения можно версионировать данные прямо в монге, тогда вопрос восстановления нужной версии ложится на пользователя. Т.е. делать cow прямо в монге.

Кстати, в линуксе есть совершенно крутая штука: reflink

Имхо cow сделать не проблема. В крайнем случае можно Солярис взять

Это хорошо когда его можно взять.

Потом например на vmware при создании снепшота монга портит данные

На mmap ещё куда ни шло, а на WT нода требует полного ре-синка

ну тыж сам тут советуешь fs-level снепшоты :)

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

мне кажется тут ключевое слово vmware

т.е. ты делаешь снапшот машины, а оно потом не может обратно? это как вообще?

есть старая инсталяция монги, которую очень давно развернули на vCenter

ну кстати, это может быть, если в памяти что-то осталось, что со временем связано

там полный набор, сетевой сторадж, автоматическая миграция и вот это всё

есть старая инсталяция монги, которую очень давно развернули на vCenter

ну вот монгу как раз перенести не проблема от слова совсем

куда ты её собрался переносить?

ну если не нравится:)

мне год потребовалось чтоб утвердить обновление с 2.4 до 3.0 :)

там всё по регламентам

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

какое в жопу версионирование в монге

ты о чём

на уровне приложения же

это идиотизм

решений 100500 и готовых и способов это сделать самостоятельно

и это не решает задачу инкрементальных бекапов

Так что хочется на уровне приложения это делать

дай мне исходники приложения сначла

тогда на уровне приложения никак

и потом по регламенту утверди внесение таких изменений

инкрементальные бэкапы - это проигрывание операций, не?

т.е.берем бэкап, а потом пишем весь лог после него

ты понимаешь что не всё можно на уровне приложения бекапить?

например я посмотрю как ты забекапишь атомарный inc

у тебя нет уровня приложения, успокойся

я тебе в целом

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

oplog

оптимистичные транзакции слышал?

oplog

я про него

…

и я про него. вот собственно вопрос есть ли готовые решения которые умеют сохранять и проигрывать oplog, кроме MongoDB Cloud Backup Manager

в облако нельзя

например я посмотрю как ты забекапишь атомарный inc

вот на уровне приложения это абстракто, не видимо дя верхнего слоя, переписывается на оптимистичную транзакцию

вот на уровне приложения это абстракто, не видимо дя верхнего слоя, переписывается на оптимистичную транзакцию

я посмотрю как ты аналитику на оптимистичных транзакциях сделаешь :)

и я про него. вот собственно вопрос есть ли готовые решения которые умеют сохранять и проигрывать oplog, кроме MongoDB Cloud Backup Manager

я не искал:) думаю, можно написать;)

и как оно будет потом работать

я посмотрю как ты аналитику на оптимистичных транзакциях сделаешь :)

вапще легко

когда у тебя два клиента пишет сто записей в час, наверное да

аналитика обычно читает и вставляет (ну, правильно написанная) там апдейты не нужны, ну, кроме map/reduce

а там нет уровня приложения, к сожалению;)

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

map/reduce в монге на sharded кластере, хахахаха

когда у тебя два клиента пишет сто записей в час, наверное да

на инсерты срать при оптимистичных транзакциях, они ничего не ломают

удачи

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

а вот так нельзя делать аналитику

а вот так нельзя делать аналитику

ой, вот давай мы пропустим про нельзя, когда ты даже не видел приложения? и судишь по одной фразе, окей? :)

map/reduce в монге на sharded кластере, хахахаха

парвильно написанные редьюсы - единственное решение для аналитики

иначе монга не нужна

парвильно написанные редьюсы - единственное решение для аналитики

теперь возьми сделай map/reduce с output на шардед кластере

и сделай их несколько десятков параллельных

и мы после этого поговорим

ой, вот давай мы пропустим про нельзя, когда ты даже не видел приложения? и судишь по одной фразе, окей? :)

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

теперь возьми сделай map/reduce с output на шардед кластере

output куда?

в коллекцию

там в приложении пре-аггрегация

клиенты пишут в жирную коллекцию с событиями

батчами

в коллекцию

прекрасно, так я и делал, только надо правильно писать reduce и делать rereduce для map по новым данным

и потом батч отправляется в map/reduce и раскладывается про «разрешениям»