При какой операции?

при подключении, решил тем что указал кластер тру

Вопрос: есть коллекция на пол террабайта. Приведёт ли дроп этой коллекции к тупняку всего инстанса? У кого есть опыт?

Вопрос: есть коллекция на пол террабайта. Приведёт ли дроп этой коллекции к тупняку всего инстанса? У кого есть опыт?

простите что не в тему, но "Херасе коллекция!"

Вопрос: есть коллекция на пол террабайта. Приведёт ли дроп этой коллекции к тупняку всего инстанса? У кого есть опыт?

если именно дроп и это шард, то небольшой тупняк будет

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

само удаление коллекции это удаление коллекции из таблицы и удаление файлов хранилища

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

Здравствуйте, подскажите пожалуйста. Необходимо сделать Initial Sync , но при нем забивается журнал и кончается свободное место. Можно ли запустить реплику с —nojournal , после синхронизации проверить статус реплики в Primary , что все ок, и перезапустить Secondary с журналированием?

Здравствуйте, подскажите пожалуйста. Необходимо сделать Initial Sync , но при нем забивается журнал и кончается свободное место. Можно ли запустить реплику с —nojournal , после синхронизации проверить статус реплики в Primary , что все ок, и перезапустить Secondary с журналированием?

Эм. Вы уверены что у вас именно с журналом проблемы?

Как вы это диагностировали?

Да, во время синхронизации в логах пишет , что не хватает свободного места и падает

После этого, сколько занимает папка journal?

95 Гб

А весь dbpath?

Какая версия монги?

вся папка 120 гб

3.2

Журнал в 100гб это не нормальная ситуация.

А какой размер данных в реплике?

там много миллионов записей

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

Если вы будете точнее отвечать на вопросы, шансы получить помощ повышаются

ок, извините,

Какая конкретно у вас версия?

v3.2.6

Вам необходимо обновиться до 3.2.19

Пока можете обновить только ту реплику, на которую вы хотите initial sync сделать

я могу обновиться только для этой реплики?

ок!

Второй момент: какой общий размер данных в реплике?вы уверены что у вас хватает места на новой реплике?

да, хватит, т.к. на праймари вся папка весит меньше 80 гб

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

но, primary трогать я не могу.

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

ок, я ведь без труда найду как апгрейднуть без удаления?

ок, я ведь без труда найду как апгрейднуть без удаления?

текущей версии

Это от вашей платформы зависит и от того как вы монгу ставили

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

понял. Пошел делать, спасибо!

Про ваш вопрос с журналом: да, так можно, но у вас проблема где-то в другом месте. У меня есть смутные воспоминания о похожей проблеме, которую исправили в одной из версий. В любом случае, поддержка 3.2 заканчивается в сентябре этого года, вам нужно обновляться до 3.6

Stable: 3.6.2 (Jan 10, 2018), Bugfix: 3.4.13 (Feb 10, 2018) 3.6.2: https://docs.mongodb.com/manual/release-notes/3.6/#january-10-2018 3.4.13: https://docs.mongodb.com/manual/release-notes/3.4/#feb-10-2018 3.2.19: https://docs.mongodb.com/manual/release-notes/3.2/#feb-6-2018 (End of life: September 2018)

Да, мы так и планируем, спасибо..

Да, кстати, 3.0 — EOLd

RIP

Сразу после апгрейда он запустился сам и начал синхронизацию

и уже через минуты 2-3 журнал весит 2 г

вру, он затирает периодически)

все круто.

вру, он затирает периодически)

Да, это нормальное поведение

После того как синхронизацию закончите, запланируйте обновление второй ноды. И не забудьте арбитра воткнуть

Понял. Арбитр есть. Что-то может произойти если остальные ноды не пропатчить?

Как минимум похожая история с журналом

Заканчивающейся на ходу место на primary это так себе развлечение :)

Заканчивающейся на ходу место на primary это так себе развлечение :)

никому не пожелаю :)

да, подозреваю, что подобное может произойти, если праймари упадет и начнет синх с secondary

который переизберется.

никому не пожелаю :)

Обычно на secondary данные чуть плотнее хранятся и будет какое-то окно

Так что если мониторинг настроен — можно практически безболезненно пережить, если есть возможность добавить быстро места

А вот если не отловить, то будет немного грустно. Но симлинки спасают

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

Втыкаем новый диск, копируем например индексы и делаем симлинк в dbpath

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

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

¯\_(ツ)_/¯

Можно через mongo cloud, там в бесплатном тарифе кажется мониторинг бесплатный

а может на уровне логов, через OSSEC , есть опыт?

Ньюрелики всякие и вивид кортексы

Да как вам удобнее

часа 3 в диком ужасе :)) Кстати, @dd_bb , про симлинки понятно, что идея корявая, но... есть пара индексов, редкоиспользуемых. Они оч большие, под терабайт, и хранятся на дорогом и быстром диске. есть идея сам индекс на медленный диск + симлинк в ориниальном месте. должно ж работать?

часа 3 в диком ужасе :)) Кстати, @dd_bb , про симлинки понятно, что идея корявая, но... есть пара индексов, редкоиспользуемых. Они оч большие, под терабайт, и хранятся на дорогом и быстром диске. есть идея сам индекс на медленный диск + симлинк в ориниальном месте. должно ж работать?

Да, должно. Но только производительность индекса будет непредсказуема

Она должна быть ограничена скоростью медленного диска. или есть еще чтото, что может повлиять?

Она будет ограничена random read iops вашего хранилища

да, это понимаю. спасибо.

Вы можете это на одной из реплик попробовать

Но вы уже шардить же начали

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

Лучше в шардинг инвестировать. Вы можете в одну зону несколько шардов воткнуть, они равномерно по себе данные размажут

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

то есть addShard и на него такой же тег навесить? чтобы 2 шарда были с одинаковым тегом, а они там уже между собой расползутся как надо?

Лучше переходить к «много дешевого железа»

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

100%

то есть addShard и на него такой же тег навесить? чтобы 2 шарда были с одинаковым тегом, а они там уже между собой расползутся как надо?

Да

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

Почему сказало?

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

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

sad but true, короче.

А доверия по какой причине нет? После шардинга что-то для бизнеса ухудшилось?

Или в срок не успели?

потому что "у вас не было опыта работы с базой в 12тб" "я поищу когото, кто умеет"

Дайте им уже мою почту :)

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

Дайте им уже мою почту :)

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

Местных это где?

Нубский вопрос mongo крешнулась, после перегрузки скорость записили упала сильно. Индексов было на 128gb ram сейчас больше 16gb не поднимаеться. Даже не знаю с чего начать копать, подскажите. Моngo 3.6 на Azure. mongod --dbpath /datadrive/mongo/data/db --nojournal пробую так все равно медленно.