Хранилище в 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 аварийно завершит работу и кластер станет неработоспособным.

• Принудительно синхронизируйте данные между хостами. Это поможет, если из кластера был удален большой объем данных, но дисковое пространство не было освобождено (т.е. помечено как доступное к переиспользованию).