Комментарии 11
Было бы очень интересно узнать, как делать консистентный бекап такой базы.
Вопрос создания полноценного консистентного бэкапа на таких объемах практически утопичен. Можно лишь говорить о создании неких работающих снэпшотов. И тут есть несколько вариантов - использовать штатный Ops Manager. Либо создавать копию прямым копированием реплики, предварительно исключив ее из RS. А можно просто держать необходимое кол-во реплик в RS. Так как одновременный отказ всех реплик в RS маловероятен. Ну или сочетание этих методик.
Так вот про то и речь...
Как сказано в документации:
To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.
Это к тому, что разворачивание sharded cluster на старте проекта может обернуться головной болью с резервным копированием. И, возможно, вариант с прикручиванием шардинга уже потом, когда проект перерастает возможности реплики (т.е. случай, описанный в статье) - не так уж и плох. Просто надо мониторить нагрузку в процессе роста, что делают не только лишь все.
Логично бы снимать резервные копии с выделенных для этой цели реплик. Вот как их остановить в один момент для получения бэкапов в более или менее один момент времени… Альтернативный вариант — файловая система со снапшотами, может быть даже на общем для всех узлов хранилище. Но какой профит от центральной СХД и шарда из монг — довольно интересный вопрос.
В трансляции задали резонные вопросы, из которых следует:
- Рассчитывать на появление коллизий в SHA256 — надо быть очень большим пессимистом
- на первом этапе не было железа для реализации шардов на нескольких серверах, но был диск для "партиций"
- Основная гигантская коллекция была просто key-value без дополнительных индексов
И кто помешал не городить велосипеды, а просто репартиционировать коллекцию средствами монги, а затем, при переходе к шардам, и шардировать — не ясно совсем. При том, что в итоге в эксплуатации осталась и старая база с программными партициями, а значит и логика в коде
вероятность коллизий у SHA256 действительно низкая, но ненулевая. Просто пренебречь данным фактом недопустимо.
не понимаю как наличие диска решит вопрос шардирования. Топология в режиме шардированной СУБД имеет ряд дополнительных элементов, таких как Config Servers, mongos. etc, которые требуют вычислительных мощностей. Таким образом, без шардирования на уровне приложения все равно не получилось бы обойтись в той ситуации. Это был фактически единственный вариант. Все остальные требовали либо ДТ, либо доп инфраструктуры...
resharding средствами MongoDB на таких объемах требует длительного ДТ и сопровождается множеством артефактов типа дублей документов и прочее. Более того, оценить точные сроки и длительность этой процедуры просто невозможно. Таких инструментов в СУБД к сожалению нет. В ситуации когда production должен работать 24х7 такие риски были совершенно неприемлемы.
Интересно, почему изначально была выбрана MongoDB, если у неё, по сути, есть только один достаточно существенный плюс - это простое шардирование из коробки? Но, как указано в статье, никто в самом начале даже не думал про шардирование.
Не совсем так, шардирование было изначально было заложено в архитектуре решения, но переход на целевую топологию долго откладывали.
Плюс mongodb очень хороша при достаточно быстро меняющихся условиях за счет отсутствия схемы, когда у сущностей появляются новые атрибуты и прочее
Плюс производительность у mongodb очень приличная (до 80K на вставке)
Еще один большой плюс - широкий набор библиотек и инструментов и очень крутая документация
100 гб - бигдата... Ну.. .
Как выжить под нагрузкой, имея 100 ТБ в нешардированной MongoDB