Связаться с намиПодключиться

Миграция хостов кластера MongoDB в другую зону доступности

Статья создана
Обновлена 30 января 2025 г.

Хосты кластера Managed Service for MongoDB располагаются в зонах доступности Yandex Cloud. Чтобы перенести хосты из одной зоны в другую:

  1. Создайте подсеть в зоне доступности, в которую вы переносите хосты.

  2. Добавьте хост в кластер:

    1. Перейдите на страницу каталога и выберите сервис Managed Service for MongoDB.

    2. Нажмите на имя нужного кластера Managed Service for MongoDB и перейдите на вкладку Хосты.

    3. Нажмите кнопку  Создать хост.

    4. Укажите параметры хоста:

      • Зону доступности, куда переносятся хосты.
      • Новую подсеть.
      • Выберите опцию Публичный доступ, если хост должен быть доступен извне Yandex Cloud.

    5. Нажмите Сохранить.

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

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

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

    yc managed-mongodb host add \
   --cluster-name <имя_кластера> \
   --host type=<тип_хоста>,`
         `zone-id=<зона_доступности>,`
         `subnet-id=<ID_новой_подсети>,`
         `assign-public-ip=<публичный_доступ_к_хосту:_true_или_false>

    Особенности команды:

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

      resource "yandex_mdb_mongodb_cluster" "<имя_кластера>" {
  ...
  host {
    type             = "<тип_хоста>"
    zone_id          = "<зона_доступности>"
    subnet_id        = "<идентификатор_новой_подсети>"
    assign_public_ip = <публичный_доступ_к_хосту:_true_или_false>
    ...
  }
}

      Возможные значения параметра type: MONGOD, MONGOINFRA, MONGOS или MONGOCFG. Тип хоста зависит от типа шардирования.

      В параметре zone укажите зону, куда вы переносите хосты.

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

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

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

        terraform validate

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

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

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

        terraform plan

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

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

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

          terraform apply

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

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

    1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

      export IAM_TOKEN="<IAM-токен>"

    2. Воспользуйтесь методом Cluster.AddHosts и выполните запрос, например, с помощью cURL:

      curl \
   --request POST \
   --header "Authorization: Bearer $IAM_TOKEN" \
   --header "Content-Type: application/json" \
   --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/<идентификатор_кластера>/hosts:batchCreate' \
   --data '{
            "hostSpecs": [
              {
                "zoneId": "<зона_доступности>",
                "subnetId": "<идентификатор_подсети>",
                "assignPublicIp": <публичный_адрес_хоста:_true_или_false>,
                "type": "<тип_хоста>",
                "shardName": "<имя_шарда>",
                "hidden": <видимость_хоста:_true_или_false>,
                "secondaryDelaySecs": "<задержка_в_секундах>",
                "priority": "<приоритет_назначения_хоста_мастером>",
                "tags": "<метки_хоста>"
              }
            ]
          }'

      Где hostSpecs — массив новых хостов. Один элемент массива содержит настройки для одного хоста:

      • zoneId — зона доступности.
      • subnetId — идентификатор подсети.
      • assignPublicIp — доступность хоста из интернета по публичному IP-адресу.
      • type— тип хоста в шардированном кластере: MONGOD, MONGOINFRA, MONGOS или MONGOCFG. Если кластер нешардированный, укажите MONGOD.
      • shardName — имя шарда в шардированном кластере.
      • hidden— будет ли хост виден или скрыт.
      • secondaryDelaySecs — время отставания хоста от мастера.
      • priority — приоритет назначения хоста мастером при выходе из строя основного мастера.
      • tags— метки хоста.

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

    3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

    1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

      export IAM_TOKEN="<IAM-токен>"

    2. Клонируйте репозиторий cloudapi:

      cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi

      Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

    3. Воспользуйтесь вызовом ClusterService.AddHosts и выполните запрос, например, с помощью gRPCurl:

      grpcurl \
   -format json \
   -import-path ~/cloudapi/ \
   -import-path ~/cloudapi/third_party/googleapis/ \
   -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \
   -rpc-header "Authorization: Bearer $IAM_TOKEN" \
   -d '{
         "cluster_id": "<идентификатор_кластера>",
         "host_specs": [
           {
             "zone_id": "<зона_доступности>",
             "subnet_id": "<идентификатор_подсети>",
             "assign_public_ip": <публичный_адрес_хоста:_true_или_false>,
             "type": "<тип_хоста>",
             "shard_name": "<имя_шарда>",
             "hidden": <видимость_хоста:_true_или_false>,
             "secondary_delay_secs": "<задержка_в_секундах>",
             "priority": "<приоритет_назначения_хоста_мастером>",
             "tags": "<метки_хоста>"
           }
         ]
      }' \
   mdb.api.cloud.yandex.net:443 \
   yandex.cloud.mdb.mongodb.v1.ClusterService.AddHosts

      Где host_specs — массив новых хостов. Один элемент массива содержит настройки для одного хоста:

      • zone_id — зона доступности.
      • subnet_id — идентификатор подсети.
      • assign_public_ip — доступность хоста из интернета по публичному IP-адресу.
      • type— тип хоста в шардированном кластере: MONGOD, MONGOINFRA, MONGOS или MONGOCFG. Если кластер нешардированный, укажите MONGOD.
      • shard_name — имя шарда в шардированном кластере.
      • hidden— будет ли хост виден или скрыт.
      • secondary_delay_secs — время отставания хоста от мастера.
      • priority — приоритет назначения хоста мастером при выходе из строя основного мастера.
      • tags— метки хоста.

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

    4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

  3. Чтобы успешно выполнять подключение к базе данных после миграции, укажите FQDN нового хоста в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN прежнего хоста в первоначальной зоне.

    Чтобы узнать FQDN, получите список хостов в кластере:

    yc managed-mongodb host list --cluster-name <имя_кластера>

    FQDN указан в выводе команды, в столбце NAME.

    О том, как получить FQDN хоста в Консоли управления, см. инструкцию.

  4. Удалите хосты в первоначальной зоне доступности:

    1. Перейдите на страницу каталога и выберите сервис Managed Service for MongoDB.
    2. Нажмите на имя нужного кластера Managed Service for MongoDB и выберите вкладку Хосты.
    3. Нажмите на значок в строке нужного хоста, выберите пункт Удалить и подтвердите удаление.

    Выполните команду для каждого хоста:

    yc managed-mongodb host delete <FQDN_хоста> --cluster-name <имя_кластера>

    1. В конфигурационном файле Terraform с планом инфраструктуры удалите из описания кластера блоки host с первоначальной зоной доступности.

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

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

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

        terraform validate

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

    3. Введите слово yes и нажмите Enter.

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

        terraform plan

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

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

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

          terraform apply

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

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

    1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

      export IAM_TOKEN="<IAM-токен>"

    2. Воспользуйтесь методом Cluster.DeleteHosts и выполните запрос, например, с помощью cURL:

      curl \
   --request POST \
   --header "Authorization: Bearer $IAM_TOKEN" \
   --header "Content-Type: application/json" \
   --url 'https://mdb.api.cloud.yandex.net/managed-mongodb/v1/clusters/<идентификатор_кластера>/hosts:batchDelete' \
   --data '{
             "hostNames": [
               "<имя_хоста>"
             ]
           }'

      Где hostNames — массив с именами удаляемых хостов. Чтобы узнать имя нужного хоста, получите список хостов в кластере.

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

    3. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

    1. Получите IAM-токен для аутентификации в API и поместите токен в переменную среды окружения:

      export IAM_TOKEN="<IAM-токен>"

    2. Клонируйте репозиторий cloudapi:

      cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi

      Далее предполагается, что содержимое репозитория находится в директории ~/cloudapi/.

    3. Воспользуйтесь вызовом ClusterService.DeleteHosts и выполните запрос, например, с помощью gRPCurl:

      grpcurl \
   -format json \
   -import-path ~/cloudapi/ \
   -import-path ~/cloudapi/third_party/googleapis/ \
   -proto ~/cloudapi/yandex/cloud/mdb/mongodb/v1/cluster_service.proto \
   -rpc-header "Authorization: Bearer $IAM_TOKEN" \
   -d '{
         "cluster_id": "<идентификатор_кластера>",
         "host_names": [
           "<имя_хоста>"
         ]
       }' \
   mdb.api.cloud.yandex.net:443 \
   yandex.cloud.mdb.mongodb.v1.ClusterService.DeleteHosts

      Где host_names — массив с именами удаляемых хостов. Чтобы узнать имя нужного хоста, получите список хостов в кластере.

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

    4. Убедитесь, что запрос был выполнен успешно, изучив ответ сервера.

  5. Дождитесь, когда кластер перейдет в состояние Alive. В консоли управления перейдите на страницу каталога и выберите сервис Managed Service for MongoDB. Состояние кластера отображается в столбце Доступность.

Примечание

Для кластеров, хосты которых располагаются в зоне доступности ru-central1-d, недоступно:

  • использование платформы Intel Broadwell;
  • хранилище на локальных SSD-дисках при использовании платформы Intel Cascade Lake.

Особенности миграции в сервисе Yandex Data Transfer

Если кластер выступает в роли эндпоинта при передаче данных с помощью сервиса Data Transfer и используется тип трансфера Репликация или Копирование и репликация, перезапустите трансфер после миграции кластера. Так трансфер получит сведения о новой топологии кластера.

Трансферы типа Копирование перезапускать не нужно, так как во время их активации информация о новой топологии передается автоматически.

Чтобы перезапустить трансфер, выберите один из двух способов:

Подробнее см. в разделе Миграция эндпоинтов и трансфера Data Transfer в другую зону доступности.

Предыдущая
Управление хостами кластера
Следующая
Управление резервными копиями