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

Миграция кластера Yandex Managed Service for MongoDB с версии 4.4 на 6.0 c помощью Yandex Data Transfer

Статья создана
Обновлена 2 декабря 2024 г.

Важно

Этот документ не применим для пользователей Yandex Cloud в регионе Казахстан. См. полный перечень поддерживаемых эндпоинтов в Data Transfer.

Вы можете перенести продуктивную нагруженную шардированную базу данных, развернутую в кластере Managed Service for MongoDB версии 4.4, на версию 6.0.

Чтобы перенести данные:

  1. Подготовьте кластер-источник.
  2. Подготовьте кластер-приемник.
  3. Подготовьте трансферы.
  4. Активируйте трансферы.
  5. Проверьте работоспособность трансфера.

Если созданные ресурсы вам больше не нужны, удалите их.

Перед началом работы

Создайте кластер-приемник Managed Service for MongoDB версии 6.0, идентичный кластеру версии 4.4.

  1. Создайте кластер-приемник Managed Service for MongoDB с конфигурацией, идентичной кластеру-источнику, и со следующими настройками:

    • Версия кластера — 6.0.
    • Имя базы данных — db1.
    • Имя пользователя — user1.

    Для подключения к кластеру из интернета включите публичный доступ к хостам кластера.

  2. Если вы используете группы безопасности в кластере, убедитесь, что они настроены правильно и допускают подключение к нему.

  3. Выдайте роль readWrite на базу db1 пользователю user1.

  4. Включите шардирование кластера и добавьте нужное количество шардов.

  1. Если у вас еще нет Terraform, установите его.

  2. Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.

  3. Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его.

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

  5. В той же рабочей директории разместите файл с расширением .tf и содержимым:

    resource "yandex_mdb_mongodb_cluster" "old" { }

  6. Запишите идентификатор кластера MongoDB версии 4.4 в переменную окружения:

    export MONGODB_CLUSTER_ID=<идентификатор_кластера>

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

  7. Импортируйте настройки кластера MongoDB версии 4.4 в конфигурацию Terraform:

    terraform import yandex_mdb_mongodb_cluster.old ${MONGODB_CLUSTER_ID}

  8. Получите импортированную конфигурацию:

    terraform show

  9. Скопируйте ее из терминала и вставьте в файл с расширением .tf.

  10. Расположите файл в новой директории imported-cluster.

  11. Измените скопированную конфигурацию так, чтобы из нее можно было создать новый кластер:

    • Укажите новое имя кластера в строке resource и параметре name.
    • Укажите в параметре version версию 6.0.
    • Удалите параметры created_at, health, id, sharded и status.
    • В блоках host удалите параметры health и name.
    • Если в блоке maintenance_window указано значение параметра type = "ANYTIME", удалите параметр hour.
    • Если есть блоки user, удалите их. Пользователи БД добавляются с помощью отдельного ресурса yandex_mdb_mongodb_user.
    • Если есть блоки database, удалите их. Базы данных добавляются с помощью отдельного ресурса yandex_mdb_mongodb_database.
    • (Опционально) Внесите дополнительные изменения, если вам нужна не идентичная, а кастомизированная копия кластера.

  12. Добавьте в файл ресурс для создания базы данных:

    resource "yandex_mdb_mongodb_database" "db1" {
  cluster_id = yandex_mdb_mongodb_cluster.<имя_кластера>.id
  name       = "db1"
}

    Где <имя_кластера> — новое имя кластера, указанное в ресурсе yandex_mdb_mongodb_cluster.

  13. Добавьте в файл ресурс для создания пользователя user1:

    resource "yandex_mdb_mongodb_user" "user1" {
  cluster_id = yandex_mdb_mongodb_cluster.<имя_кластера>.id
  name       = "user1"
  password   = "<пароль_пользователя>"
  permission {
    database_name = "db1"
    roles         = ["readWrite"]
  }
  depends_on = [
    yandex_mdb_mongodb_database.db1
  ]
}

    Где <имя_кластера> — новое имя кластера, указанное в ресурсе yandex_mdb_mongodb_cluster.

  14. В директории imported-cluster получите данные для аутентификации.

  15. В этой же директории настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его.

  16. Поместите конфигурационный файл в директорию imported-cluster и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.

  17. Проверьте корректность файлов конфигурации Terraform:

    terraform validate

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

  18. Создайте необходимую инфраструктуру:

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

      terraform plan

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

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

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

        terraform apply

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

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

    В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления.

Ограничения по времени

Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for MongoDB:

  • создание, в т. ч. путем восстановления из резервной копии, — 30 минут;
  • изменение — 60 минут.

Операции, длящиеся дольше указанного времени, прерываются.

Как изменить эти ограничения?

Добавьте к описанию кластера блок timeouts, например:

resource "yandex_mdb_mongodb_cluster" "<имя_кластера>" {
  ...
  timeouts {
    create = "1h30m" # Полтора часа
    update = "2h"    # 2 часа
  }
}

Подготовьте кластер-источник

  1. Создайте пользователя с ролью readWrite на базу данных в источнике, которая будет реплицироваться.

  2. Удалите из базы неиспользуемые коллекции.

  3. Отключите в коллекциях признак уникальности индексов. Он будет включен после переноса данных.

  4. Оцените нагрузку на базу данных. Если она превышает 10 000 операций на запись в секунду, запланируйте несколько трансферов:

    1. Определите список особо нагруженных коллекций.
    2. Распределите коллекции между несколькими трансферами.

  5. Задайте размер хранения oplog с запасом 15–20 % от размера диска кластера. Это позволит Data Transfer считывать изменения из кластера-источника на протяжении всего процесса копирования данных.

    Подробнее об oplog читайте в документации MongoDB.

Подготовьте кластер-приемник

Если в базе-источнике есть шардированные коллекции, подготовьте базу-приемник. Для индексов не указывайте уникальность.

Подготовьте трансферы

  1. Создайте эндпоинт-источник для каждого запланированного трансфера и укажите параметры эндпоинта:

    • Тип базы данных — MongoDB.

    • Тип подключения — Кластер Managed Service for MongoDB.

    • Кластер Managed Service for MongoDB — <имя_кластера-источника_MongoDB> из выпадающего списка.

    • Источник аутентификации — <имя_базы_данных_кластера-источника>.

    • Пользователь — <имя_пользователя>.

    • Пароль — <пароль>.

    • Список включённых коллекций — для каждого эндпоинта укажите список включенных коллекций в соответствии с планом распределения по трансферам.

    • Список исключённых коллекций — укажите коллекции Time Series, если они существуют в базе данных. Data Transfer не поддерживает перенос таких коллекций.

  2. Создайте эндпоинт-приемник для каждого запланированного трансфера и укажите параметры эндпоинта:

    • Тип базы данных — MongoDB.

    • Тип подключения — Кластер Managed Service for MongoDB.

    • Кластер Managed Service for MongoDB — <имя_кластера-приемника_MongoDB> из выпадающего списка.

    • Источник аутентификации — db1.

    • Пользователь — user1.

    • Пароль — <пароль>.

    • База данных — db1.

    Если в базе-приемнике созданы шардированные коллекции, выберите политику очистки Не очищать или TRUNCATE.

    Выбор политики DROP приведет к тому, что при активации трансфера сервис удалит из базы-приемника все данные, в т. ч. шардированные коллекции, и создаст вместо них новые, нешардированные.

  3. Создайте трансферы типа Копирование и репликация, использующие созданные эндпоинты.

    Чтобы ускорить копирование больших коллекций (более 1 ГБ), включите параллельное копирование в настройках трансфера:

    • Количество воркеров — 5 или более.
    • Количество потоков — 8 или более.

    Коллекция разделится на указанное количество частей, которые будут копироваться параллельно.

    Чтобы параллельное копирование работало, тип данных поля _id у всех документов коллекции должен быть одинаковым. Если трансфер обнаруживает неоднородность типов, то коллекция не разбивается на части и переносится в одном потоке. При необходимости перед началом трансфера удалите из коллекции документы с отличающимися типами данных.

    Примечание

    Если после активации трансфера в коллекцию добавится документ с отличающимся типом данных, трансфер перенесет его на стадии репликации, после параллельного копирования. Но при повторной активации трансфер не сможет разбить коллекцию на части, так как требование к типу поля _id во всех документах коллекции не будет выполнено.

Активируйте трансферы

  1. Активируйте трансферы.
  2. Дождитесь перехода трансферов в статус Реплицируется.
  3. Переведите кластер-источник в режим «только чтение».
  4. Если в базе-источнике вы отключали уникальные индексы, включите их в базе-приемнике.
  5. Переключите нагрузку на кластер-приемник.
  6. На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum data transfer delay для каждого трансфера. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
  7. Деактивируйте трансферы и дождитесь их перехода в статус Остановлен.

Проверьте работоспособность трансфера

  1. Подключитесь к базе данных db1 в кластере-приемнике Managed Service for MongoDB.

  2. Убедитесь, что в базе данных db1 появились коллекции с данными:

    show collections
db.<имя_коллекции>.find()

Удалите созданные ресурсы

Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:

Кластер Managed Service for MongoDB версии 6.0 удалите в зависимости от способа его создания:

  1. В терминале перейдите в директорию с планом инфраструктуры.

    Важно

    Убедитесь, что в директории нет Terraform-манифестов с ресурсами, которые вы хотите сохранить. Terraform удаляет все ресурсы, которые были созданы с помощью манифестов в текущей директории.

  2. Удалите ресурсы:

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

      terraform destroy

    2. Подтвердите удаление ресурсов и дождитесь завершения операции.

    Все ресурсы, которые были описаны в Terraform-манифестах, будут удалены.

Предыдущая
Миграция данных в Managed Service for MongoDB
Следующая
Шардирование коллекций MongoDB