Миграция кластера Yandex Managed Service for MongoDB с версии 4.4 на 6.0 c помощью Yandex Data Transfer
Вы можете перенести продуктивную нагруженную шардированную базу данных, развернутую в кластере Managed Service for MongoDB версии 4.4, на версию 6.0.
Чтобы перенести данные:
- Подготовьте кластер-источник.
- Подготовьте кластер-приемник.
- Подготовьте трансферы.
- Активируйте трансферы.
- Проверьте работоспособность трансфера.
Если созданные ресурсы вам больше не нужны, удалите их.
Перед началом работы
Создайте кластер-приемник Managed Service for MongoDB версии 6.0, идентичный кластеру версии 4.4.
-
Создайте кластер-приемник Managed Service for MongoDB с конфигурацией, идентичной кластеру-источнику, и со следующими настройками:
- Версия кластера —
6.0
. - Имя базы данных —
db1
. - Имя пользователя —
user1
.
Для подключения к кластеру из интернета включите публичный доступ к хостам кластера.
- Версия кластера —
-
Если вы используете группы безопасности в кластере, убедитесь, что они настроены правильно и допускают подключение к нему.
-
Выдайте роль
readWrite
на базуdb1
пользователюuser1
. -
Включите шардирование кластера и добавьте нужное количество шардов.
-
Если у вас еще нет Terraform, установите его.
-
Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.
-
Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.
-
В той же рабочей директории разместите файл с расширением
.tf
и содержимым:resource "yandex_mdb_mongodb_cluster" "old" { }
-
Запишите идентификатор кластера MongoDB версии 4.4 в переменную окружения:
export MONGODB_CLUSTER_ID=<идентификатор_кластера>
Идентификатор можно запросить вместе со списком кластеров в каталоге.
-
Импортируйте настройки кластера MongoDB версии 4.4 в конфигурацию Terraform:
terraform import yandex_mdb_mongodb_cluster.old ${MONGODB_CLUSTER_ID}
-
Получите импортированную конфигурацию:
terraform show
-
Скопируйте ее из терминала и вставьте в файл с расширением
.tf
. -
Расположите файл в новой директории
imported-cluster
. -
Измените скопированную конфигурацию так, чтобы из нее можно было создать новый кластер:
- Укажите новое имя кластера в строке
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
. - (Опционально) Внесите дополнительные изменения, если вам нужна не идентичная, а кастомизированная копия кластера.
- Укажите новое имя кластера в строке
-
Добавьте в файл ресурс для создания базы данных:
resource "yandex_mdb_mongodb_database" "db1" { cluster_id = yandex_mdb_mongodb_cluster.<имя_кластера>.id name = "db1" }
Где
<имя_кластера>
— новое имя кластера, указанное в ресурсеyandex_mdb_mongodb_cluster
. -
Добавьте в файл ресурс для создания пользователя
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
. -
В директории
imported-cluster
получите данные для аутентификации. -
В этой же директории настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в директорию
imported-cluster
и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле. -
Проверьте корректность файлов конфигурации Terraform:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Создайте необходимую инфраструктуру:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления
. -
Ограничения по времени
Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for MongoDB:
- создание, в т. ч. путем восстановления из резервной копии, — 30 минут;
- изменение — 60 минут.
Операции, длящиеся дольше указанного времени, прерываются.
Как изменить эти ограничения?
Добавьте к описанию кластера блок timeouts
, например:
resource "yandex_mdb_mongodb_cluster" "<имя_кластера>" {
...
timeouts {
create = "1h30m" # Полтора часа
update = "2h" # 2 часа
}
}
Подготовьте кластер-источник
-
Создайте пользователя с ролью
readWrite
на базу данных в источнике, которая будет реплицироваться. -
Удалите из базы неиспользуемые коллекции.
-
Отключите в коллекциях признак уникальности индексов. Он будет включен после переноса данных.
-
Оцените нагрузку на базу данных. Если она превышает 10 000 операций на запись в секунду, запланируйте несколько трансферов:
- Определите список особо нагруженных коллекций.
- Распределите коллекции между несколькими трансферами.
-
Задайте размер хранения oplog с запасом 15–20 % от размера диска кластера. Это позволит Data Transfer считывать изменения из кластера-источника на протяжении всего процесса копирования данных.
Подробнее об oplog читайте в документации MongoDB
.
Подготовьте кластер-приемник
Если в базе-источнике есть шардированные коллекции, подготовьте базу-приемник. Для индексов не указывайте уникальность.
Подготовьте трансферы
-
Создайте эндпоинт-источник для каждого запланированного трансфера и укажите параметры эндпоинта:
-
Тип базы данных —
MongoDB
. -
Тип подключения —
Кластер Managed Service for MongoDB
. -
Кластер Managed Service for MongoDB —
<имя_кластера-источника_MongoDB>
из выпадающего списка. -
Источник аутентификации —
<имя_базы_данных_кластера-источника>
. -
Пользователь —
<имя_пользователя>
. -
Пароль —
<пароль>
. -
Список включённых коллекций — для каждого эндпоинта укажите список включенных коллекций в соответствии с планом распределения по трансферам.
-
Список исключённых коллекций — укажите коллекции Time Series
, если они существуют в базе данных. Data Transfer не поддерживает перенос таких коллекций.
-
-
Создайте эндпоинт-приемник для каждого запланированного трансфера и укажите параметры эндпоинта:
-
Тип базы данных —
MongoDB
. -
Тип подключения —
Кластер Managed Service for MongoDB
. -
Кластер Managed Service for MongoDB —
<имя_кластера-приемника_MongoDB>
из выпадающего списка. -
Источник аутентификации —
db1
. -
Пользователь —
user1
. -
Пароль —
<пароль>
. -
База данных —
db1
.
Если в базе-приемнике созданы шардированные коллекции, выберите политику очистки
Не очищать
илиTRUNCATE
.Выбор политики
DROP
приведет к тому, что при активации трансфера сервис удалит из базы-приемника все данные, в т. ч. шардированные коллекции, и создаст вместо них новые, нешардированные. -
-
Создайте трансферы типа Копирование и репликация, использующие созданные эндпоинты.
Чтобы ускорить копирование больших коллекций (более 1 ГБ), включите параллельное копирование в настройках трансфера:
- Количество воркеров —
5
или более. - Количество потоков —
8
или более.
Коллекция разделится на указанное количество частей, которые будут копироваться параллельно.
Чтобы параллельное копирование работало, тип данных
поля_id
у всех документов коллекции должен быть одинаковым. Если трансфер обнаруживает неоднородность типов, то коллекция не разбивается на части и переносится в одном потоке. При необходимости перед началом трансфера удалите из коллекции документы с отличающимися типами данных.Примечание
Если после активации трансфера в коллекцию добавится документ с отличающимся типом данных, трансфер перенесет его на стадии репликации, после параллельного копирования. Но при повторной активации трансфер не сможет разбить коллекцию на части, так как требование к типу поля
_id
во всех документах коллекции не будет выполнено. - Количество воркеров —
Активируйте трансферы
- Активируйте трансферы.
- Дождитесь перехода трансферов в статус Реплицируется.
- Переведите кластер-источник в режим «только чтение».
- Если в базе-источнике вы отключали уникальные индексы, включите их в базе-приемнике.
- Переключите нагрузку на кластер-приемник.
- На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum data transfer delay для каждого трансфера. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
- Деактивируйте трансферы и дождитесь их перехода в статус Остановлен.
Проверьте работоспособность трансфера
-
Подключитесь к базе данных
db1
в кластере-приемнике Managed Service for MongoDB. -
Убедитесь, что в базе данных
db1
появились коллекции с данными:show collections db.<имя_коллекции>.find()
Удалите созданные ресурсы
Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:
Кластер Managed Service for MongoDB версии 6.0
удалите в зависимости от способа его создания:
Удалите кластер Managed Service for MongoDB.
Если вы создавали кластер с помощью Terraform:
-
В терминале перейдите в директорию с планом инфраструктуры.
-
Удалите конфигурационный файл с расширением
.tf
. -
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
Все ресурсы, которые были описаны в удаленном конфигурационном файле, будут удалены.
-