Но вообще посмотрите стоит ли вам шард заводить

Если вы в io не уперлись, то дешевле докинуть дисков

С шардом будут сложности с резервным копированием. Сейчас сложилась дурацкая ситуация что для 4.2 нет открытых инструметов для Point-in-time бекапов. Только через OpsManager

А он в интерпрайз лицензии

и ¯\_(ツ)_/¯

Если вы в io не уперлись, то дешевле докинуть дисков

отказоустойчивость нужна. у меня глаз дергается, когда я смотрю на этот ужос)

Шард не добавит отказоустойчивости

я понимаю, что без реплики это просто доп место на диске

Если у вас нет проблем с io, то вам хватит просто разнести реплику на разные физические хосты и докинуть дисков/памяти

Если у вас нет проблем с io, то вам хватит просто разнести реплику на разные физические хосты и докинуть дисков/памяти

до смешного - сервак не выключить на maintanance

Да, понимаю. :)

Там есть размер кеша и read in/read out

15mb used если вы про Cache Usage Это в самый пик. До этого я писал им как-то просто узнать в чём проблема, меня пнули и сказали, что вам нужно поболтать с инженерами (не бесплатно, но первый месяц подарим), я подумал, что сам поищу сначала :D

Кстати, напоминаю что в этот четверг, 14 ноября, в Москве, будет митап MongoDB и Яндекс.Облако С местами уже немного напряженно, у вас последний шанс :) Подробности и регистрация

Вроде как теперь это моя зона ответственности, но она в таком состоянии, что я отвечать за стабильность работы текущего сетапа просто не готов. это всё до первого отказа железки/ошибки девелоперов/что-то еще. даже бэкапов еще неделю назад не было(

Кстати, напоминаю что в этот четверг, 14 ноября, в Москве, будет митап MongoDB и Яндекс.Облако С местами уже немного напряженно, у вас последний шанс :) Подробности и регистрация

При условии прохождения фэйс-контроля от Яндекса :)

При условии прохождения фэйс-контроля от Яндекса :)

Если у вас проблемы возникли, напишите Анне @annapesh

Не, я прошел, спасибо большое! :) Знакомые не прошли некоторые :)

так что кластер, сначала тестовый, с тестом апгрейда. потом прод)

Привет! Пишите, кто не получил подтверждение. Сегодня проверим

Привет! Пишите, кто не получил подтверждение. Сегодня проверим

Спасибо, я сообщу ребятам :)

С шардом будут сложности с резервным копированием. Сейчас сложилась дурацкая ситуация что для 4.2 нет открытых инструметов для Point-in-time бекапов. Только через OpsManager

эта статья не про то? или как раз про то, но только до 4.2? https://tech.willhaben.at/mongodb-incremental-backups-dff4c8f54d58

эта статья не про то? или как раз про то, но только до 4.2? https://tech.willhaben.at/mongodb-incremental-backups-dff4c8f54d58

> Disclaimer These scripts come without warranty of any kind. Use them at your own risk. I assume no liability for the accuracy, correctness, completeness, or usefulness of any information provided by this site, or for any sort of damage using these scripts may cause. это не очень надёжный механизм

Я вижу что он использует oplog но не очень понимаю, что ему это даёт

«инкрементальность»

«инкрементальность»

мне механизм не очень понятен. что он достигает используя oplog с определенного места. делает дамп определенной части операций?

Но конкретно этот скрипт абсолютно ненадежен, потому что он не учитывает того факта, что оплог это capped коллекция и при резком увеличении объёме документов точка в которой сделан бэкап последний раз может выпасть из оплога. А там даже проверки на это нет

Спасибо, я сообщу ребятам :)

Пусть в личку мне напишут

Пусть в личку мне напишут

Deal, спасибо большое)

мне механизм не очень понятен. что он достигает используя oplog с определенного места. делает дамп определенной части операций?

Да, таким образом он получают дельту изменений между двумя точками во времени

Но сам алгоритм очень плохо реализован

топорно, это даже мне понятно)

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

Вариант, но в шарде надо сделать так, чтоб снепшоты на всех нодах были в одной точке

А это очень сложно, если не тормозить временно запись

С shard-wide транзакциями в 4.2 я пока вообще не очень понимаю как они это в opsmanager делают

возможно используют какие-то фичи wiredtiger, чтоб сделать PiT снепшоты

Можно сделать вторые реплики кажого шарды и разместить их на одной виртуалке, с которой и снимать снапшоты. и сразу вопрос - можно как-то сконфигурировать реплику так, что бы она точно никогда не стала primary, а всегда оставалась репликой, как slave в sql db.

Можно сделать вторые реплики кажого шарды и разместить их на одной виртуалке, с которой и снимать снапшоты. и сразу вопрос - можно как-то сконфигурировать реплику так, что бы она точно никогда не стала primary, а всегда оставалась репликой, как slave в sql db.

Ничем не поможет

Можно, сконфигурировать конечно: https://docs.mongodb.com/manual/core/replica-set-priority-0-member/

Кстати, напоминаю что в этот четверг, 14 ноября, в Москве, будет митап MongoDB и Яндекс.Облако С местами уже немного напряженно, у вас последний шанс :) Подробности и регистрация

Спасибо, зарегистрировался)

Ничем не поможет

у меня будут обе реплики на одной фс, значит в снапшоте будет коректное состояние. хотя может лагнуть репликация, поэтому не поможет?

у меня будут обе реплики на одной фс, значит в снапшоте будет коректное состояние. хотя может лагнуть репликация, поэтому не поможет?

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

Простой пример вы вставляете два зависимых документа, которые едут на два разных шарда. У реплик с которых делаются бэкапы разный лаг. Одна операция попадает в бэкап, а другая нет.

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

Простой пример вы вставляете два зависимых документа, которые едут на два разных шарда. У реплик с которых делаются бэкапы разный лаг. Одна операция попадает в бэкап, а другая нет.

да, это я и имел в виду под лагом репликации.

Лаг есть всегда. Физика запрещает не иметь его :)

добрый вечер, подскажите пожалуйста, где я ошибся? я хочу вытащить все документы у которых в rules содержатся подобные объекты, которые в переменной query из документа sample код: https://codepen.io/reetou/pen/MWWqjEL?editors=0010

Лаг есть всегда. Физика запрещает не иметь его :)

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

Да. Если вы себе можете это позволить :)

О чём в документации и написано: https://docs.mongodb.com/manual/tutorial/backup-sharded-cluster-with-filesystem-snapshots/

Да. Если вы себе можете это позволить :)

видимо придётся, если мы хотим бекапы 🙂

Проще не использовать шард, пока это возможно

Это палка о двух концах, но с 4.2 есть другой позитивный момент: можно поменять значение шард ключа и ошибка в выборе чуть менее болезнена

Проще не использовать шард, пока это возможно

И просто перенести монгу на другой сервак с бОльшим объемом дисков. похоже, это целесообразнее.

на три разных сервера, да :)

на три разных сервера, да :)

на два, третий - vpc с Priority 0. прокатит такое?)

зависит от ваших требований по отказоустойчивости

зависит от ваших требований по отказоустойчивости

получается primary + secondary для n+1 и третий для бекапа. вроде норм

если primary вылетит, единственный secondary станет primary?

нет

если нет кворума

статегия всего с двумя нодами она не самая удачная

если нет кворума

да, я про кворум. с elk опыт есть)

p=0 позволяет ноде голосовать, но она не может инициировать выборы

добрый вечер, подскажите пожалуйста, где я ошибся? я хочу вытащить все документы у которых в rules содержатся подобные объекты, которые в переменной query из документа sample код: https://codepen.io/reetou/pen/MWWqjEL?editors=0010

у вас в примере в документе 1 элемент в массиве поддокументов, а в запрсое $all с тремя

киньте пример в play.db-ai.co

ок, спасибо, ща

плюс у вас там два positional $, хотя не вижу чтоб был $elemMatch

$ это плейсхолдер для индекса элемента который попал под $elemMatch

p=0 позволяет ноде голосовать, но она не может инициировать выборы

и не может стать primary? тогда при вылете primary кворум будет достигнут двумя голосами за второй dedicated с p=1, так?

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

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

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

возможно у меня дойдут руки протестировать такой сценарий. сразу после настройки elk кластера =) может через месяц. отпишусь, если будет о чём)

и благодарю за мысль отказаться от шарда. видимо так и будет 🙂

если я 2 коллекции (между которыми взаимосвязь в виде отсылки к ObjectID, перенесу в другую бд - эта взаимосвязь сохранится? если я помню, то там перегенерятся айдишники?

Ты можешь записать свои ид

если я 2 коллекции (между которыми взаимосвязь в виде отсылки к ObjectID, перенесу в другую бд - эта взаимосвязь сохранится? если я помню, то там перегенерятся айдишники?

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

а как копировать целиком с айди? я думал просто insert

пройтись циклом по тем что хочу перенести и инсерт

а как копировать целиком с айди? я думал просто insert

не удалять _id :)