« Rev
@mongodb_ru   204
Fwd »


yopp
Вам необходимо обновиться до 3.2.19
yopp
Пока можете обновить только ту реплику, на которую вы хотите initial sync сделать
Anonymous
я могу обновиться только для этой реплики?
Anonymous
ок!
yopp
Второй момент: какой общий размер данных в реплике?вы уверены что у вас хватает места на новой реплике?
Anonymous
да, хватит, т.к. на праймари вся папка весит меньше 80 гб
yopp
После того как обновите, удалить содержимое dbpath и попробуйте снова
Anonymous
но, primary трогать я не могу.
Anonymous
После того как обновите, удалить содержимое dbpath и попробуйте снова
ок, я ведь без труда найду как апгрейднуть без удаления?
yopp
Это от вашей платформы зависит и от того как вы монгу ставили
yopp
Если платформа официально поддерживается и для неё есть пакеты, то простота обновления будет зависеть от вашего менеджера пакетов
Anonymous
понял. Пошел делать, спасибо!
yopp
Про ваш вопрос с журналом: да, так можно, но у вас проблема где-то в другом месте. У меня есть смутные воспоминания о похожей проблеме, которую исправили в одной из версий. В любом случае, поддержка 3.2 заканчивается в сентябре этого года, вам нужно обновляться до 3.6
yopp
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)
Anonymous
Да, мы так и планируем, спасибо..
yopp
Да, кстати, 3.0 — EOLd
Anonymous
RIP
Anonymous
Сразу после апгрейда он запустился сам и начал синхронизацию
Anonymous
и уже через минуты 2-3 журнал весит 2 г
Anonymous
вру, он затирает периодически)
Anonymous
все круто.
yopp
вру, он затирает периодически)
Да, это нормальное поведение
yopp
После того как синхронизацию закончите, запланируйте обновление второй ноды. И не забудьте арбитра воткнуть
Anonymous
Понял. Арбитр есть. Что-то может произойти если остальные ноды не пропатчить?
yopp
Как минимум похожая история с журналом
yopp
Заканчивающейся на ходу место на primary это так себе развлечение :)
Anonymous
да, подозреваю, что подобное может произойти, если праймари упадет и начнет синх с secondary
Anonymous
который переизберется.
yopp
никому не пожелаю :)
Обычно на secondary данные чуть плотнее хранятся и будет какое-то окно
yopp
Так что если мониторинг настроен — можно практически безболезненно пережить, если есть возможность добавить быстро места
yopp
А вот если не отловить, то будет немного грустно. Но симлинки спасают
Anonymous
кстати, я не сразу узнал , что упал секондари безвозвратно, как лучше настроить оповещение?
yopp
Втыкаем новый диск, копируем например индексы и делаем симлинк в dbpath
Max
у меня при репликации такое было, когда приходилось STOP-ать сигналами процесс, чтобы выкроить минуты для досинхронизации массива на новый диск чтобы синхронизация репликасета не успела занять место
yopp
Можно через mongo cloud, там в бесплатном тарифе кажется мониторинг бесплатный
Anonymous
а может на уровне логов, через OSSEC , есть опыт?
yopp
Ньюрелики всякие и вивид кортексы
yopp
Да как вам удобнее
Max
часа 3 в диком ужасе :)) Кстати, @dd_bb , про симлинки понятно, что идея корявая, но... есть пара индексов, редкоиспользуемых. Они оч большие, под терабайт, и хранятся на дорогом и быстром диске. есть идея сам индекс на медленный диск + симлинк в ориниальном месте. должно ж работать?
Max
Она должна быть ограничена скоростью медленного диска. или есть еще чтото, что может повлиять?
yopp
Она будет ограничена random read iops вашего хранилища
Max
да, это понимаю. спасибо.
yopp
Вы можете это на одной из реплик попробовать
yopp
Но вы уже шардить же начали
Max
точно но один кусочек шарда пока оч мал - там менее 40 гиг данных потому думал взять там secondary и на нем попробовать индекс мелкий и должен легко и быстро уехать на отдельный диск
yopp
Лучше в шардинг инвестировать. Вы можете в одну зону несколько шардов воткнуть, они равномерно по себе данные размажут
yopp
Вы объективно близки к пределу вертикального масштабирования, дальше только увеличение операционной сложности или удорожание железа. Это практически всегда тупиковый путь
Max
то есть addShard и на него такой же тег навесить? чтобы 2 шарда были с одинаковым тегом, а они там уже между собой расползутся как надо?
yopp
Лучше переходить к «много дешевого железа»
Max
осталось донести до начальства потому что оно сказало "стопаем все активности по шардингу" мы психуем, пытаемся расслабиться и ждём, когда всё *бнется, простите за речь
yopp
Почему сказало?
Max
нет доверия нам - мне и программерам реально это огромнейшая глупость, но менеджерские качества руководства "за спиной" обсуждать будет некрасиво
Max
учитывая то, что шардинг уже подняли, данные уже частично расшардили, приложуху под шарды подкрутили и так далее.
Max
sad but true, короче.
yopp
А доверия по какой причине нет? После шардинга что-то для бизнеса ухудшилось?
yopp
Или в срок не успели?
Max
потому что "у вас не было опыта работы с базой в 12тб" "я поищу когото, кто умеет"
yopp
Дайте им уже мою почту :)
Max
ну а то, что с этим с самого начала, пока база была пара метров и вообще была миграция с sql,.. и что оно работает, и работает хорошо - это не в счёт проще платить больше денег за диски в амазон у богатых свои причуды, я не знаю, какпояснить иначе
Max
Дайте им уже мою почту :)
Поднимался вопрос, они когото из местных ищут это значит, что будет пара достаточно бесполезных митингов, и выяснится, что мы все делаем правильно. не впервой.
yopp
Местных это где?
Mykola
Нубский вопрос mongo крешнулась, после перегрузки скорость записили упала сильно. Индексов было на 128gb ram сейчас больше 16gb не поднимаеться. Даже не знаю с чего начать копать, подскажите. Моngo 3.6 на Azure. mongod --dbpath /datadrive/mongo/data/db --nojournal пробую так все равно медленно.
Oleg
Какой должен быть индекс?
Viktor
Стоит проверить наличие файлов индекса
Mykola
Как узнать где mongo ищет путь к mongodb:///opt/bitnami/mongodb/tmp/mongodb-27017.sock/ в какомто конфигурационном файле ?.
Mykola
Вообще ОПА. Что могло стать причинойб пропали все узеры даже админ (по мимо ручного удаления)
Alex
опять база без авторизации ?
Mykola
опять база без авторизации ?
Я хз. Остальной народ еще спит, я полез чинить, Все юзеры похерились. Все теперь я иду спать.
Александр 🌲🙏🏽
Друзья, подскажите. Коллекция с документами, в которых есть массив с документами и в каждом том документе может быть тоже массив — это плохая практика или нет?
Александр 🌲🙏🏽
Просто вот двойной $ оператор уже недоступен, поэтому работа с элементами в том самом глубоком массиве уже затруднена становится.
Александр 🌲🙏🏽
Как быть?
Александр 🌲🙏🏽
Вот вопрос если что — https://stackoverflow.com/questions/48967418/multiple-arrays-of-objects-inside-array-of-objects-in-mongodb
« Rev
@mongodb_ru   204
Fwd »