Вопросы и ответы про Managed Service for MongoDB
Общие вопросы
-
Какую версию MongoDB использует Managed Service for MongoDB?
-
Что происходит, когда версия СУБД становится неподдерживаемой (deprecated)?
-
Как рассчитывается стоимость потребления для хоста базы данных?
-
Как изменить вычислительные ресурсы и объем хранилища для кластера БД?
-
Когда выполняется резервное копирование? Доступен ли кластер БД во время резервного копирования?
-
Можно ли изменить срок хранения автоматических резервных копий?
-
За какими метриками и процессами можно следить с помощью мониторинга?
Вопросы о MongoDB
-
Что случится с кластером, если выйдет из строя один из хостов?
-
Можно ли развернуть кластер MongoDB в нескольких зонах доступности?
-
Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?
-
Можно ли подключиться к хостам кластера по SSH или получить на хостах права суперпользователя?
Общие вопросы
Что такое Managed Service for MongoDB?
Managed Service for MongoDB — это сервис, который помогает вам создавать, эксплуатировать и масштабировать базы данных MongoDB в облачной инфраструктуре.
С Managed Service for MongoDB вы можете:
- создавать базы данных с необходимыми параметрами производительности;
- масштабировать вычислительные мощности и выделенный объем хранилища для баз данных;
- получать журналы работы баз данных.
Managed Service for MongoDB берет на себя трудоемкие задачи администрирования инфраструктуры MongoDB:
- предоставляет мониторинг потребляемых ресурсов;
- автоматически создает резервные копии баз данных;
- обеспечивает отказоустойчивость за счет автоматического переключения на резервные реплики;
- своевременно обновляет программное обеспечение СУБД.
Вы взаимодействуете с кластером БД в Managed Service for MongoDB как с обычной базой данных в вашей локальной инфраструктуре. Благодаря этому вы можете управлять внутренними настройками БД в соответствии с требованиями вашего приложения.
Какую часть работы по управлению и сопровождению баз данных берет на себя Managed Service for MongoDB?
При создании кластеров Managed Service for MongoDB выделяет ресурсы, устанавливает СУБД и создает базы данных.
Для созданных и запущенных баз данных Managed Service for MongoDB автоматически создает резервные копии, а также устанавливает исправления и обновления СУБД.
Также Managed Service for MongoDB обеспечивает репликацию данных между хостами БД (как внутри, так и между зонами доступности) и автоматически переключает нагрузку на резервную реплику в случае аварии.
Для каких задач стоит использовать Managed Service for MongoDB, а для каких — виртуальные машины с базами данных?
Yandex Cloud предлагает два варианта работы с базами данных:
- Managed Service for MongoDB позволяет вам эксплуатировать шаблонные базы данных, не заботясь об администрировании.
- Виртуальные машины Yandex Compute Cloud дают возможность создавать и настраивать собственные базы данных. Такой подход позволяет использовать любые СУБД, подключаться к базам данных по SSH и так далее.
Что такое хост базы данных и кластер базы данных?
Хост БД — это изолированная среда базы данных в облачной инфраструктуре с выделенными вычислительными ресурсами и зарезервированным объемом хранилища данных.
Кластер БД — это один или более хостов БД, между которыми можно настроить репликацию.
Как начать работу с Managed Service for MongoDB?
Managed Service for MongoDB доступен всем зарегистрированным пользователям Yandex Cloud.
Чтобы создать кластер базы данных в Managed Service for MongoDB, необходимо определиться с его характеристиками:
- Класс хостов (характеристики производительности — процессоры, память и т. п.).
- Тип диска и его объем (резервируется в полном объеме при создании кластера).
- Сеть, к которой будет подключен ваш кластер.
- Количество хостов для кластера и зона доступности для каждого из них.
Подробные инструкции см. в разделе Как начать работать с Managed Service for MongoDB.
Сколько хостов БД может содержать кластер?
Минимальное количество хостов в кластере зависит от:
- выбранных платформы и класса хостов;
- выбранного типа диска.
Максимальное количество хостов в кластере ограничено только запрошенными вычислительными ресурсами и объемом хранилища для кластера.
Подробнее см. в разделе Квоты и лимиты.
Как получить доступ к запущенному хосту базы данных?
Вы можете подключаться к базам данных Managed Service for MongoDB способами, стандартными для СУБД.
Подробнее о подключении к кластерам.
Сколько кластеров можно создать в рамках одного облака?
Технические и организационные ограничения MDB приведены в разделе Квоты и лимиты.
Как происходит обслуживание кластеров БД?
Под обслуживанием в Managed Service for MongoDB понимается:
- автоматическая установка обновлений и исправлений СУБД для хостов БД (в т. ч. для выключенных кластеров);
- изменение класса хостов и объема хранилища;
- другие сервисные работы Managed Service for MongoDB.
Подробнее см. в разделе Техническое обслуживание.
Какую версию MongoDB использует Managed Service for MongoDB?
Managed Service for MongoDB поддерживает MongoDB версий 5.0 и 6.0 Community Edition.
Что происходит, когда выпускается новая версия СУБД?
При выходе новых минорных версий программное обеспечение кластеров обновляется после короткого периода тестирования. Владельцев затронутых кластеров БД заранее оповещают о сроках проведения работ и доступности баз данных.
Что происходит, когда версия СУБД становится неподдерживаемой (deprecated)?
Если поддержка версии СУБД прекращается, через месяц владельцы кластеров БД, созданных с этой версией, получают оповещение по электронной почте.
Создание новых хостов с СУБД неподдерживаемых версий становится невозможным. Через семь дней после оповещения для минорных версий и через месяц для мажорных версий проводится автоматическое обновление кластеров БД до следующей поддерживаемой версии. Неподдерживаемые мажорные версии обновляются, даже если у вас отключено автоматическое обновление.
Как рассчитывается стоимость потребления для хоста базы данных?
В Managed Service for MongoDB стоимость потребления рассчитывается исходя из следующих параметров:
- Выбранный класс хостов.
- Объем хранилища, зарезервированного для хоста БД.
- Объем резервных копий кластера БД. Объем резервных копий, равный объему хранилища, не тарифицируется. Хранение резервных копий сверх этого объема оплачивается по тарифам.
- Количество часов работы хоста БД. Неполные часы округляются до целого значения. Стоимость часа работы для каждого класса хостов приведена в разделе Правила тарификации.
Как изменить вычислительные ресурсы и объем хранилища для кластера БД?
Вы можете изменять вычислительные ресурсы и объем хранилища в консоли управления
Характеристики кластера изменяются в течение 30 минут. В этот период также могут быть включены другие сервисные работы по кластеру, например, установка обновлений.
Включено ли резервное копирование хостов БД по умолчанию?
Да, по умолчанию резервное копирование включено. Для MongoDB полное резервное копирование выполняется один раз в сутки с возможностью восстановления до любой сохраненной резервной копии.
По умолчанию резервные копии хранятся семь дней.
Когда выполняется резервное копирование? Доступен ли кластер БД во время резервного копирования?
Окно резервного копирования — это интервал времени, в течение которого выполняется ежедневное полное резервное копирование кластера БД. Окно резервного копирования — 01:00−05:00 по московскому времени.
Во время окна резервного копирования кластеры остаются полностью доступными.
Можно ли изменить срок хранения автоматических резервных копий?
При создании или изменении кластера можно задать срок хранения автоматических резервных копий.
За какими метриками и процессами можно следить с помощью мониторинга?
Для всех типов СУБД можно отслеживать:
- загрузку процессора, памяти, сети, дисков в абсолютных величинах;
- загрузку памяти, сети, дисков в процентах от установленных лимитов для класса хостов соответствующего кластера;
- объем данных кластера БД и остаток свободного места в хранилище данных.
Для всех хостов БД можно отслеживать метрики, специфические для типа соответствующей СУБД. Например, для MongoDB можно отслеживать:
- количество запросов в секунду;
- размер использованного дискового пространства;
- количество соединений и т. д.
Мониторинг можно осуществлять с минимальной гранулярностью в пять секунд.
Как настроить алерт, который срабатывает при заполнении определенного процента дискового пространства?
Создайте алерт с метрикой disk.used_bytes
в сервисе Yandex Monitoring. Метрика показывает размер использованного дискового пространства в кластере Managed Service for MongoDB.
Для disk.used_bytes
используются пороги для оповещения. Их рекомендуемые значения:
Alarm
— 90% дискового пространства.Warning
— 70% дискового пространства.
Значения порогов задаются только в байтах. Например, рекомендуемые значения для диска размером в 100 ГБ:
Alarm
—96636764160
байтов (90%).Warning
—75161927680
байтов (70%).
Вопросы о MongoDB
Почему стоит использовать MongoDB в Managed Service for MongoDB, а не собственную установку на виртуальной машине?
Managed Service for MongoDB автоматизирует рутинное обслуживание БД:
- быстрое развертывание БД с необходимыми доступными ресурсами;
- резервное копирование данных;
- регулярное обновление ПО;
- обеспечение отказоустойчивости кластеров БД;
- мониторинг и статистика использования БД.
Что случится с кластером, если выйдет из строя один из хостов?
Если в кластере БД больше 1 реплики, при потере одного хоста кластер продолжит работу.
Данные могут потеряться только если вышел из строя единственный хост в кластере.
Можно ли развернуть кластер MongoDB в нескольких зонах доступности?
Да. Кластер БД может состоять из хостов, расположенных как в разных зонах, так и в разных регионах доступности.
Как проводится резервное копирование для кластеров MongoDB?
Резервные копии создаются каждые 24 часа и хранятся 7 дней после создания. Восстановить данные можно только на момент создания копии.
Как устроена репликация для MongoDB?
Managed Service for MongoDB использует стандартный механизм репликации MongoDB: если в кластере есть больше 1 активного хоста, среди них автоматически выбирается первичный сервер, обрабатывающий запросы на запись.
Подробнее о том, как организована репликация в MongoDB, читайте в документации СУБД
Какие ограничения накладываются на кластеры БД MongoDB?
Подробнее об ограничениях в Managed Service for MongoDB см. в разделе Квоты и лимиты.
Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?
Вероятно, максимальные значения IOPS и пропускной способности (bandwidth) хранилища недостаточны для обработки текущего количества запросов. В этом случае срабатывает троттлинг и быстродействие всего кластера падает.
Максимальные IOPS и bandwidth прирастают на фиксированную величину при увеличении размера хранилища на определенный шаг. Шаг и прирост зависят от типа дисков:
Тип дисков | Шаг, ГБ | Прирост макс. IOPS (чтение/запись) | Прирост макс. bandwidth (чтение/запись), МБ/с |
---|---|---|---|
network-hdd |
256 | 300/300 | 30/30 |
network-ssd |
32 | 1000/1000 | 15/15 |
network-ssd-nonreplicated |
93 | 28000/5600 | 110/82 |
Чтобы увеличить максимальные значения IOPS и bandwidth и снизить вероятность троттлинга, расширьте размер хранилища при изменении кластера.
Если вы используете хранилище с типом диска network-hdd
, рассмотрите возможность перехода на network-ssd
или network-ssd-nonreplicated
путем восстановления кластера из резервной копии.
Как получить доступ к служебной коллекции local.oplog.rs?
Чтобы предоставить пользователю доступ к чтению oplog
, выдайте ему роль mdbReplication
в БД admin
. Для этого выполните команду в интерфейсе командной строки Yandex Cloud:
yc managed-mongodb user update <имя_пользователя> \
--cluster-name <имя_кластера> \
--permission database=admin,role=mdbReplication,role=<другая_роль>,... \
--permission database=<имя_другой_БД>,role=<роль>,...
Чтобы избежать удаления уже назначенных ролей пользователя, в команде перечислите как существующие, так и добавляемые роли.
Можно ли подключиться к хостам кластера по SSH или получить на хостах права суперпользователя?
Подключиться к хостам через SSH не получится, как и получить права суперпользователя. Это сделано в целях безопасности и отказоустойчивости пользовательских кластеров, так как прямые изменения внутри хоста могут привести к его полной неработоспособности.