Изменение настроек кластера

Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы изменить класс хостов для кластера:

1. Посмотрите описание команды CLI для изменения кластера:

   $ yc managed-mongodb cluster update --help
   

2. Запросите список доступных классов хостов (в колонке ZONES указаны зоны доступности, в которых можно выбрать соответствующий класс):

   $ yc managed-mongodb resource-preset list
   
   +-----------+--------------------------------+-------+----------+
   |    ID     |            ZONE IDS            | CORES |  MEMORY  |
   +-----------+--------------------------------+-------+----------+
   | s1.micro  | ru-central1-a, ru-central1-b,  |     2 | 8.0 GB   |
   |           | ru-central1-c                  |       |          |
   | ...                                                           |
   +-----------+--------------------------------+-------+----------+
   

3. Укажите нужный класс в команде изменения кластера:

   $ yc managed-mongodb cluster update <имя кластера>
        --mongod-resource-preset <ID класса>
   

   Managed Service for MongoDB запустит операцию изменения класса хостов для кластера.

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание MongoDB-кластера.

2. Измените в описании кластера Managed Service for MongoDB значение параметра resource_preset_id в блоке resources:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     resources {
         resource_preset_id = "<класс хостов MongoDB>"
         ...
     }
   }
   

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Подробнее см. в документации провайдера Terraform.

Воспользуйтесь методом API update и передайте в запросе нужные значения в параметре configSpec.mongodbSpec_4_2.mongod.resources.resourcePresetId.

Список поддерживаемых значений запрашивайте методом list для ресурсов ResourcePreset.

Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы увеличить размер хранилища для кластера:

1. Посмотрите описание команды CLI для изменения кластера:

   $ yc managed-mongodb cluster update --help
   

2. Проверьте, что в облаке хватает квоты на увеличение хранилища: откройте страницу Квоты для вашего облака и проверьте, что в секции Yandex Managed Service for MongoDB не исчерпано место в строке space.

3. Проверьте, что нужный кластер использует именно сетевое хранилище (увеличить размер локального хранилища пока невозможно). Для этого запросите информацию о кластере и найдите поле disk_type_id — его значение должно быть network-hdd или network-ssd:

   $ yc managed-mongodb cluster get <имя кластера>
   
   id: c7qkvr3u78qiopj3u4k2
   folder_id: b1g0ftj57rrjk9thribv
   ...
   config:
     mongodb_4_4:
       mongod:
         config:
           user_config: {}
         resources:
           resource_preset_id: s1.micro
           disk_size: "21474836480"
           disk_type_id: network-ssd
   ...
   

4. Укажите нужный объем хранилища в команде изменения кластера (должен быть не меньше, чем значение disk_size в свойствах кластера):

   $ yc managed-mongodb cluster update <имя кластера>
        --mongod-disk-size <размер хранилища в ГБ>
   

   Если все условия выполнены, Managed Service for MongoDB запустит операцию по увеличению объема хранилища.

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание MongoDB-кластера.

2. Измените в описании кластера Managed Service for MongoDB значение параметра disk_size в блоке resources:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     resources {
       disk_size = <размер хранилища, ГБ>
       ...
     }
   }
   

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Подробнее см. в документации провайдера Terraform.

Воспользуйтесь методом API update и передайте в запросе нужные значения в параметре configSpec.mongodbSpec_4_2.mongod.resources.diskSize.

Проверьте, что в облаке хватает квоты на увеличение хранилища: откройте страницу Квоты для вашего облака и проверьте, что в секции Yandex Managed Service for MongoDB не исчерпано место в строке space.

Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы изменить настройки MongoDB для кластера, используйте команду:

$ yc managed-mongodb cluster update-config

Например, для установки значения параметра net.maxIncomingConnections в 4096, выполните следующую команду:

$ yc managed-mongodb cluster update-config <имя кластера>
    --set net.max_incoming_connections=4096

Managed Service for MongoDB запустит операцию изменения настроек СУБД для кластера. Если изменяемая настройка применяется только с перезапуском СУБД, то Managed Service for MongoDB последовательно перезапустит СУБД на всех хостах кластера.

Воспользуйтесь методом API update и передайте в запросе нужные значения в параметре configSpec.mongodbSpec_4_2.mongod.config.

Все поддерживаемые настройки описаны в справочнике API.

Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы изменить дополнительные настройки кластера:

1. Посмотрите описание команды CLI для изменения кластера:

   yc managed-mongodb cluster update --help
   

2. Выполните команду, передав список настроек, которые хотите изменить:

   yc managed-mongodb cluster update <имя кластера> \
      --backup-retain-period-days=<срок хранения> \
      --backup-window-start <время начала резервного копирования> \
      --maintenance-window type=<weekly или anytime>
   

Вы можете изменить следующие настройки:

• --backup-retain-period — срок хранения автоматических резервных копий (в днях).

  Значение параметра <срок хранения> задается в диапазоне от 7 до 35 (по умолчанию — 7). Эта функциональность находится на стадии Preview. Подробнее см. в разделе Резервные копии.

  Изменение срока хранения затрагивает как новые автоматические резервные копии, так и уже существующие.

  Например, если изначальный срок хранения был 7 дней и оставшееся время жизни отдельной автоматической резервной копии при таком сроке — 1 день, то при увеличении срока хранения до 9 дней, оставшееся время жизни этой резервной копии будет уже 3 дня.

• --backup-window-start — время начала резервного копирования кластера, задается по UTC в формате HH:MM:SS. Если время не задано, резервное копирование начнется в 22:00 UTC.

• --maintenance-window — настройки времени технического обслуживания:
  • type=anytime — техническое обслуживание может проводиться в любое время.
  • type=weekly — техническое обслуживание выполняется по расписанию. Выберите время, когда кластер наименее нагружен запросами, и укажите через запятую в параметрах day и hour день и час начала технического обслуживания, например: type=weekly,day=wed,hour=14.

• --deletion-protection — защита кластера от непреднамеренного удаления пользователем вашего облака.

  Включенная защита от удаления кластера не помешает подключиться вручную и удалить содержимое базы данных.

Имя кластера можно получить со списком кластеров в каталоге.

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание MongoDB-кластера.

2. Чтобы изменить время начала резервного копирования, добавьте к описанию кластера Managed Service for MongoDB блок backup_window_start в секции cluster_config:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     cluster_config {
       backup_window_start {
         hours   = <Час начала резервного копирования>
         minutes = <Минута начала резервного копирования>
       }
       ...
     }
     ...
   }
   

3. Чтобы разрешить доступ из сервиса Yandex DataLens, добавьте к описанию кластера Managed Service for MongoDB блок access в секции cluster_config:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     cluster_config {
       ...
       access {
         data_lens = <Доступ из DataLens: true или false>
       }
     ...
   }
   

4. Чтобы включить защиту кластера от непреднамеренного удаления пользователем вашего облака, добавьте к описанию кластера поле deletion_protection со значением true:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     deletion_protection = <защита от удаления кластера: true или false>
   }
   

   {% include Ограничения защиты от удаления %}}

5. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

6. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Подробнее см. в документации провайдера Terraform.

Воспользуйтесь методом API update и передайте в запросе:

• Идентификатор кластера в параметре clusterId.

• Новое время начала резервного копирования в параметре configSpec.backupWindowStart.

• Настройки доступа из других сервисов в параметре configSpec.access.

• Настройки защиты от удаления кластера в параметре deletionProtection.

  Включенная защита от удаления кластера не помешает подключиться вручную и удалить содержимое базы данных.

• Список полей конфигурации кластера, подлежащих изменению, в параметре updateMask.

Идентификатор кластера можно получить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы изменить список групп безопасности для кластера:

1. Посмотрите описание команды CLI для изменения кластера:

   yc managed-mongodb cluster update --help
   

2. Укажите нужные группы безопасности в команде изменения кластера:

   yc managed-mongodb cluster update <имя кластера> \
      --security-group-ids <список групп безопасности>
   

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание MongoDB-кластера.

2. Измените в описании кластера Managed Service for MongoDB значение параметра security_group_ids:

   resource "yandex_mdb_mongodb_cluster" "<имя кластера>" {
     ...
     security_group_ids = [ <Список идентификаторов групп безопасности> ]
     ...
   }
   

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Подробнее см. в документации провайдера Terraform.

Воспользуйтесь методом API update и передайте в запросе:

• Идентификатор кластера в параметре clusterId. Чтобы узнать идентификатор, получите список кластеров в каталоге.
• Список групп в параметре securityGroupIds.
• Список настроек, которые необходимо изменить, в параметре updateMask. Если не задать этот параметр, метод API сбросит на значения по умолчанию все настройки кластера, которые не были явно указаны в запросе.