Хранилище в Managed Service for MongoDB
Managed Service for MongoDB позволяет использовать сетевые и локальные диски для организации хранилища кластеров баз данных. Сетевые диски реализованы на базе сетевых блоков — виртуальных дисков в инфраструктуре Yandex Cloud. Локальные диски физически размещаются в серверах хостов БД.
При создании кластера вы можете выбирать между следующими типами хранилища:
-
Хранилище на сетевых HDD-дисках (
network-hdd
) — самый экономичный вариант для кластеров, не требовательных к скорости записи и чтения. -
Хранилище на сетевых SSD-дисках (
network-ssd
) — компромиссный вариант: медленнее, чем хранилище на локальных SSD-дисках, но, в отличие от него, обеспечивает сохранность данных при выходе из строя оборудования Yandex Cloud. -
Хранилище на нереплицируемых SSD-дисках (
network-ssd-nonreplicated
) — использует сетевые SSD-диски с повышенной производительностью, реализованной за счет устранения избыточности.Объем такого хранилища можно увеличивать только с шагом 93 ГБ.
-
Хранилище на локальных SSD-дисках (
local-ssd
) — использует самые быстрые диски.Этот тип хранилища доступен только для платформ Intel Broadwell и Intel Cascade Lake. Список классов хостов и соответствующих им платформ см. в разделе Классы хостов.
Объем такого хранилища можно увеличивать только с шагом 100 ГБ.
Особенности хранилища на локальных SSD-дисках
Хранилище на локальных SSD-дисках не обеспечивает отказоустойчивости хранения данных, а также влияет на тарификацию кластера в целом:
- Такое хранилище в кластере из одного хоста не обеспечивает отказоустойчивости: при отказе диска данные теряются безвозвратно. Поэтому при создании нового кластера Managed Service for MongoDB с использованием этого типа хранилища автоматически настраивается отказоустойчивая конфигурация из трех хостов.
- Кластер с таким хранилищем тарифицируется, даже если он остановлен. Подробнее — в правилах тарификации.
Особенности хранилища на нереплицируемых SSD-дисках
Хранилище на нереплицируемых SSD-дисках в кластере из одного хоста не обеспечивает отказоустойчивости: при отказе диска данные теряются безвозвратно. Поэтому при создании нового кластера с использованием этого типа хранилища автоматически настраивается отказоустойчивая конфигурация из трех хостов.
Выбор типа хранилища при создании кластера
Количество хостов, которые можно создать вместе с MongoDB-кластером, зависит от выбранного типа хранилища:
-
При использовании хранилища на локальных SSD-дисках (
local-ssd
) или на нереплицируемых SSD-дисках (network-ssd-nonreplicated
), вы можете создать кластер из трех или более хостов (минимум три хоста необходимо, чтобы обеспечить отказоустойчивость). -
При использовании хранилища на сетевых HDD-дисках (
network-hdd
) или сетевых SSD-дисках (network-ssd
), вы можете добавить любое количество хостов в пределах текущей квоты.
Подробнее об ограничениях на количество хостов в кластере или шарде см. в разделе Квоты и лимиты.
Управление дисковым пространством
Если хотя бы один хост в кластере Managed Service for MongoDB исчерпает все доступное ему дисковое пространство, то инстанс MongoDB на этом хосте аварийно завершит работу и хост станет неработоспособным. Если хост был первичной репликой (PRIMARY
), то эта роль перейдет на одну из вторичных реплик (SECONDARY
). Возможна ситуация, когда в результате миграции роли PRIMARY
с хоста на хост исчерпается дисковое пространство на всех хостах кластера, что приведет к неработоспособности кластера в целом.
Чтобы этого не произошло, сервис Managed Service for MongoDB отслеживает расходование дискового пространства и автоматически переводит в режим read-only (с помощью метода db.fsyncLock
) те хосты кластера, у которых:
- осталось менее 500 МБ свободного места (если размер хранилища хоста менее 600 ГБ);
- осталось менее 5 ГБ свободного места (если размер хранилища хоста 600 ГБ или более).
При переходе в режим read-only:
- На хосте запрещаются операции записи, возможны только операции чтения.
- Если хост до перевода в read-only был первичной репликой, то эта роль будет автоматически назначена другому хосту кластера, т. к. роль первичной реплики требует возможности записи на диск.
Если объем данных в кластере продолжает увеличиваться, то в read-only перейдут один за другим все хосты, и кластер перестанет принимать данные на запись.
Поддержка работоспобности кластера
Чтобы сохранить работоспособность кластера при переходе хоста в read-only:
-
Увеличьте объем диска на хосте. Если на хосте станет достаточно места, Yandex Cloud снимет режим read-only автоматически.
-
Добавьте в кластер дополнительные шарды. Режим read-only на этом хосте не снимется, но кластер сможет продолжить нормальную работу — при условии, что на остальных шардах есть свободное дисковое пространство.
-
Попросите техническую поддержку о временном снятии режима read-only с этого хоста, чтобы вручную удалить часть данных.
Внимание
Если свободное дисковое пространство снизится до нуля, MongoDB аварийно завершит работу и кластер станет неработоспособным.
-
Принудительно синхронизируйте данные между хостами. Это поможет, если из кластера был удален большой объем данных, но дисковое пространство не было освобождено (т.е. помечено как доступное к переиспользованию).