« Rev
@mongodb_ru   345
Fwd »


yopp
печальненько
Alexey
рано или поздно запись в чанк после нескольких месяцев заканчивается, потому что ID протухает, но они все равно там лежат и неправильно балансируют
yopp
пришло время планировать смену шард ключа, потому что 9тб будет легче перелить чем 11 и уж тем-более чем 20
Alexey
пока можно попробовать приложить подорожник вроде поднятия размера чанка, но вот проблема в том, что пока непонятно как их размер посчитать
yopp
ето будет нетривиально, да
yopp
простой, но долгий вариант: добавить ко всем документам значение convertShardKeyToHashed
yopp
сложный, но побыстрее: взять снепшот, взять утилиту wt, пройтись по всему индексу составив heatmap ключей (значение — количество ключей в индексе), найти самые толстые и по ссылке на документ посмотреть какие id туда попадают
yopp
сделать выборку документов по этому id и посчитать размер jumbo чанка
Alexey
простой, но долгий вариант: добавить ко всем документам значение convertShardKeyToHashed
да...тоже такая идея посещала. Перевести все известные id в hash этой функции, потом по соответствию искать эти диапазоны
yopp
очень муторный: расковырять исходники и найти как монга сама считает размер чанка, чтоб принять решение о его делении
yopp
ещё аналитический вариант: в софте считать heatmap
yopp
т.е. завести где-то счётчик id -> число документов
yopp
можно попробовать запустить агрегацию на все 9тб :)
yopp
не обязательно на самом деле на все 9
yopp
если у вас есть какой-то индекс, по которому можно ограничить выборку, то можно попробовать shard local запрос сделать с таким индексом
yopp
т.е. известно где находится jumbo chunk, весь шард не надо сканировать
yopp
3к шардов?
yopp
или 3к jumbo chunk?
Alexey
Jumbo чанков
yopp
есть конечно ещё вариант: медленно увеличивать размер чанка :)
yopp
и смортреть как уменьшается число jumbo
Alexey
а вот вопрос касательно этого. Надо их апдейтить, чтоб снять флаг? или балансировщик сам снимет?
yopp
а вот хз
Nick
гдето была инструкция по борьбе с jumbo
Nick
https://docs.mongodb.com/manual/tutorial/clear-jumbo-flag/#update-chunks-collection
Alexey
да...видел. там пишут апдейтить, но после деления, скорее всего и после увеличения тоже надо
Nick
а каой сейчас размер чанка?
Oleg
извините за, наверняка, глупый вопрос... я правильно понимаю - коллекции - аналог таблицы, а документ - аналог строки в реляционной бд?
Alexey
а каой сейчас размер чанка?
был 128. недавно поднял до 256
Vova
что?
Да ты правильно понимаешь
Vova
Только так или иначе работает по другому
V
ребят расскажите как тут быть Мне программист говорит что базу публично (иметь внешний доступ ) к ней категорически запрещено и что ее сразу взломают какой бы там пароль не стоял , как тут вообще быть
Vova
При правильной настройке ничего не взломают
V
он сказал что ни фаервол ни пароли не спасут и что
V
скажи это zero-day
а что за zero-day
V
он вообще говорит пробрасывай ssh
Vova
Если уж так говорить, то ничто не безопасно
Vova
Ссш тоже взломают когда-то если ещё не взломали
V
я вообще хочу пароли поставить на базы только чтобы от внутренних сотрудников отобрать доступы а то они лазиют и напрямую данные в ней меняют
V
а он говорит что это херово так как им неудобно
V
вообще ктото тут слегка занимается вопросами безопасности баз данных (монго )
V
есть какой то минимальный набор требований для минимизации рисков
Vova
Выдать можно каждому личный аккаунт и настроить какие права он будет иметь. Например, только на чтение или чтение + запись
V
но вопрос уже стал шире простого ограничения для внутренниго использование
Vova
а что за zero-day
Атака такая
V
вот есть приложение а у него хранятся ключи доступа
V
и получается получил доступ к приложению получил ключи и получил доступ к базе
AstraSerg
Ссш тоже взломают когда-то если ещё не взломали
ssh легко и эффективно защищается fail2ban-ом
V
я как то не нахожу вообще уже аргументов против его настойчивости что базу можно защитить только если ее закрыть навсегда и не давать публичного доступа ни под каким предлогом
Vova
Вопрос зашёл в тему защиты ОС, это уже не совсем по адресу)
V
ну если остановится на базе данных
V
кто что думает про то что базу вломают если ее открыть или как минимум буду проблемы
Vova
Базу можно повесить слушать на какой-то порт и все будут через этот порт к ней подключаться и входить под своими логином/паролем. А доступ к самому серверу нужно полностью ограничить от третьих лиц
V
микс теории и практики
V
просто программист из visa пришел и там вот имел частую походу практику такую
Vova
Ну вообще те же mlab.com и mongodb atlas открывают внешний доступ к бд, поскольку они так делают, я думаю, это безопасно. Но опять же взломать можно практически всё) Если нужно только чтение с базы, возможно, стоит глянуть в сторону обёртки какой-то над базой данных, в виде АПИ например. В таком случае базу можно сделать полностью локальной.
yopp
«абсолютной безопасности» не бывает, разговоры про «безопасность» имеют смысл только в контексте конкретной модели угроз
yopp
если модели угроз нет, говорить смысла нет.
V
если модели угроз нет, говорить смысла нет.
а что такое модель угроз , как ее составить
yopp
https://en.wikipedia.org/wiki/Threat_model
Yaroslav
Гайз подскажите , снял дамп с монги версии 3.3 накатил его на реплика сет монги версии 4.0.1 , в итоге проверяю count у коллекции и он отличается , на старой и новой монги . при этом на новой , куда не кто не пишет , он больше , это нормально ?))
Юрий
Здравствуйте. Тоже вопрос про дамп. mongodump пишет Failed: error writing data for collection collname to disk: error reading collection: Failed to parse: { ... что это может быть?
AstraSerg
Юрий
Здравствуйте. Тоже вопрос про дамп. mongodump пишет Failed: error writing data for collection collname to disk: error reading collection: Failed to parse: { ... что это может быть?
кажется нашёл причину. https://dba.stackexchange.com/questions/215534/mongodump-unrecognized-field-snapshot разные версии удаленной базы и моего локального mongodump
Yaroslav
Ошибок не было? Может в логах что?
я не сколько раз позапускал и каждый раз не которые данные просто не доконца накатывались, я так понял ошибки происходит на моменте построения индексов . В логах самой монги ошибок нету
Yaroslav
Но я вот сейчас последний раз накатил дамп и все встало как надо расхождений по количеству данных нету
AstraSerg
Но я вот сейчас последний раз накатил дамп и все встало как надо расхождений по количеству данных нету
Для надёжности проверьте не только количество, но ещё сексумму какую-нибудь проверьте
Yaroslav
Для надёжности проверьте не только количество, но ещё сексумму какую-нибудь проверьте
ага . сейчас что нибудь придумаю , а то как то не надежно все выглядит , спасибо
« Rev
@mongodb_ru   345
Fwd »