Передача данных в эндпоинт-приемник MongoDB
С помощью сервиса Yandex Data Transfer вы можете переносить данные в базу MongoDB и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:
- Ознакомьтесь с возможными сценариями передачи данных.
- Настройте один из поддерживаемых источников данных.
- Подготовьте базу данных MongoDB к трансферу.
- Настройте эндпоинт-приемник в Yandex Data Transfer.
- Создайте и запустите трансфер.
- Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
- При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.
Сценарии передачи данных в MongoDB
-
Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.
-
Поставка данных — процесс доставки произвольных данных в целевые хранилища. Процесс поставки включает извлечение данных из очереди и их десериализацию с последующей трансформацией данных в формат целевого хранилища.
Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.
Настройка источника данных
Настройте один из поддерживаемых источников данных:
Полный список поддерживаемых источников и приемников в Yandex Data Transfer см. в разделе Доступные трансферы.
Подготовка базы данных приемника
-
Создайте пользователя с ролью
readWrite
на созданную базу. -
Чтобы шардировать переносимые коллекции в кластере-приемнике Yandex Managed Service for MongoDB:
-
Следуя инструкции, создайте и настройте в базе-приемнике пустые шардированные коллекции.
Сервис Data Transfer не шардирует переносимые коллекции автоматически. Шардирование больших коллекций может занять продолжительное время и снизить скорость трансфера.
-
Если шардирование происходит по ключу, отличному от
_id
(используется по умолчанию), назначьте пользователю рольmdbShardingManager
. -
При создании эндпоинта для приемника выберите политику очистки
DISABLED
илиTRUNCATE
.Выбор политики
DROP
приведет к тому, что при активации трансфера сервис удалит из базы-приемника все данные, в т. ч. шардированные коллекции, и создаст вместо них новые, нешардированные.
Подробнее о шардировании см. в документации MongoDB
. -
-
Убедитесь, что настройки сети, в которой размещен кластер, разрешают подключение к нему из интернета с IP-адресов, используемых сервисом Data Transfer
. -
Убедитесь, версия MongoDB на приемнике не ниже чем на источнике.
-
Убедитесь, что кластер MongoDB сконфигурирован таким образом, чтобы на запросы к нему он возвращал корректно разрешающиеся IP-адреса или FQDN (Fully Qualified Domain Name).
-
Настройте кластер-приемник
, чтобы к нему можно было подключиться из интернета:-
Измените в конфигурационном файле значение настройки
net.bindIp
со127.0.0.1
на0.0.0.0
:# network interfaces net: port: 27017 bindIp: 0.0.0.0
-
Перезапустите сервис
mongod
:sudo systemctl restart mongod.service
-
-
Если кластер-приемник не использует репликацию, включите ее:
-
Добавьте в конфигурационный файл
/etc/mongod.conf
настройки репликации:replication: replSetName: <имя_набора_реплик>
-
Перезапустите сервис
mongod
:sudo systemctl restart mongod.service
-
Подключитесь к MongoDB и инициализируйте набор реплик командой:
rs.initiate({ _id: "<имя_набора_реплик>", members: [{ _id: 0, host: "<IP-адрес_который_слушает_MongoDB>:<порт>" }] });
-
-
Подключитесь к кластеру и создайте базу-приемник:
use <имя_базы>
-
Создайте пользователя с правами
readWrite
на базу-приемник:use admin; db.createUser({ user: "<имя_пользователя>", pwd: "<пароль>", mechanisms: ["SCRAM-SHA-1"], roles: [ { db: "<имя_базы-приемника>", role: "readWrite" } ] });
После старта трансфер подключится к приемнику от имени этого пользователя.
-
Чтобы шардировать переносимые коллекции в кластере-приемнике:
-
Подготовьте базу данных и создайте в ней пустые коллекции с теми же именами, что и на источнике.
Сервис Data Transfer не шардирует переносимые коллекции автоматически. Шардирование больших коллекций может занять продолжительное время и снизить скорость трансфера.
-
Включите шардирование для базы-приемника:
sh.enableSharding("<имя_базы-приемника>")
-
Задайте шардирование для каждой коллекции с учетом ее пространства имен:
sh.shardCollection("<имя_базы-приемника>.<имя_коллекции>", { <имя_поля>: <1|"hashed">, ... });
Описание функции
shardCollection()
см. в документации MongoDB . -
Чтобы убедиться в том, что шардирование настроено и включено, получите список доступных шардов:
sh.status()
-
Если для шардирования используется ключ, отличный от
_id
(значение по умолчанию), назначьте системную рольclusterManager
пользователю, от имени которого сервис Data Transfer будет подключаться к кластеру-приемнику:use admin; db.grantRolesToUser("<имя_пользователя>", ["clusterManager"]);
-
При создании эндпоинта для приемника выберите политику очистки
DISABLED
илиTRUNCATE
.Выбор политики
DROP
приведет к тому, что при активации трансфера сервис удалит из базы-приемника все данные, в т. ч. шардированные коллекции, и создаст вместо них новые, нешардированные.
Подробнее о шардировании см. в документации MongoDB
. -
Настройка эндпоинта-приемника MongoDB
Data Transfer поддерживает трансферы с MongoDB, начиная с версии 3.6.
При создании или изменении эндпоинта вы можете задать:
- Настройки подключения к кластеру Yandex Managed Service for MongoDB или пользовательской инсталляции, в т. ч. на базе виртуальных машин Yandex Compute Cloud. Эти параметры обязательные.
- Дополнительные параметры.
Кластер Managed Service for MongoDB
Важно
Для создания или редактирования эндпоинта управляемой базы данных вам потребуется роль managed-mongodb.viewer
или примитивная роль viewer
, выданная на каталог кластера этой управляемой базы данных.
Подключение к БД с указанием идентификатора кластера в Yandex Cloud.
-
Кластер Managed Service for MongoDB — укажите идентификатор кластера, к которому необходимо подключиться.
-
Источник аутентификации — укажите имя базы данных в кластере.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.
- Тип эндпоинта —
mongo-target
.
-
--cluster-id
— идентификатор кластера, к которому необходимо подключиться. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
--security-group
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
mongo_target
.
-
connection.connection_options.mdb_cluster_id
— идентификатор кластера, к которому необходимо подключиться. -
subnet_id
— идентификатор подсети, в которой находится кластер. Если не указан, то кластер должен быть доступен из интернета.Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к кластеру. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности и подсеть
subnet_id
, если она указана, должны принадлежать той же сети, в которой размещен кластер.Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
auth_source
— имя базы данных в кластере. -
connection.connection_options.user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
connection.connection_options.password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
mongo_target {
security_groups = ["<список_идентификаторов_групп_безопасности>"]
subnet_id = "<идентификатор_подсети>"
connection {
connection_options {
mdb_cluster_id = "<идентификатор_кластера>"
auth_source = "<имя_базы_данных>"
user = "<имя_пользователя>"
password {
raw = "<пароль_пользователя>"
}
}
}
<дополнительные_настройки_эндпоинта>
}
}
}
Подробнее см. в документации провайдера Terraform
-
securityGroups
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
mdbClusterId
— идентификатор кластера, к которому необходимо подключиться. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль пользователя для доступа к базе данных (в текстовом виде).
Пользовательская инсталляция
Подключение к БД с явным указанием сетевых адресов и портов.
-
Хосты — укажите IP-адреса или FQDN хостов, к которым необходимо подключиться.
-
Набор реплик — укажите имя набора реплик.
-
Порт — укажите номер порта, который сервис Data Transfer будет использовать для подключения.
-
Сертификат CA — для шифрования передаваемых данных загрузите файл PEM-сертификата или добавьте его содержимое в текстовом виде.
-
Идентификатор подсети — выберите или создайте подсеть в нужной зоне доступности.
Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.
-
Источник аутентификации — укажите имя базы данных в кластере.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.
- Тип эндпоинта —
mongo-target
.
-
--host
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
--port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
--ca-certificate
— сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS . -
--subnet-id
— идентификатор подсети, в которой находится хост. -
--database
— имя базы данных. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
--security-group
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
mongo_target
.
-
on_premise.port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
connection.connection_options.on_premise.tls_mode.enabled.ca_certificate
— сертификат CA, если требуется шифрование передаваемых данных, например, для соответствия требованиям PCI DSS . -
subnet_id
— идентификатор подсети, в которой находится кластер. Если не указан, то кластер должен быть доступен из интернета.Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к ВМ c базой данных. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности должны принадлежать той же сети, что и подсеть
subnet_id
, если она указана.Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
connection.connection_options.on_premise.replica_set
— укажите имя набора реплик. -
connection.connection_options.on_premise.hosts
— укажите IP-адреса или FQDN хостов, к которым необходимо подключиться. -
auth_source
— имя базы данных в кластере. -
connection.connection_options.user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
connection.connection_options.password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
mongo_target {
security_groups = ["<список_идентификаторов_групп_безопасности>"]
subnet_id = "<идентификатор_подсети>"
connection {
connection_options {
on_premise {
hosts = [ "список хостов набора реплик" ]
port = "<порт_для_подключения>"
replica_set = "<имя_набора_реплик>"
tls_mode {
enabled {
ca_certificate = "<сертификат_в_формате_PEM>"
}
}
}
auth_source = "<имя_базы_данных>"
user = "<имя_пользователя>"
password {
raw = "<пароль_пользователя>"
}
}
}
<дополнительные_настройки_эндпоинта>
}
}
}
Подробнее см. в документации провайдера Terraform
onPremise
— параметры подключения к базе данных:-
hosts
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
tlsMode
— параметры шифрования передаваемых данных, если оно требуется, например для соответствия требованиям PCI DSS . -
subnetId
— идентификатор подсети, в которой находится хост.
-
-
securityGroups
— группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer. -
database
— имя базы данных. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль пользователя для доступа к базе данных (в текстовом виде).
Дополнительные настройки
-
База данных — укажите имя базы данных. Если значение не указывать, будет использовано имя базы данных источника.
-
Политика очистки — выберите способ очистки данных в базе-приемнике перед переносом:
-
Не очищать
— выберите эту опцию, если будет производиться только репликация без копирования данных. -
Drop
— полное удаление таблиц, участвующих в трансфере (вариант по умолчанию).Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия схемы таблиц из источника.
-
Truncate
— удалить только данные из таблиц, участвующих в трансфере, но оставить схему.Используйте эту опцию, если схема в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
-
--target-database
— укажите имя базы данных, если хотите создать коллекции в базе данных с именем, отличным от имени базы-источника.
-
database
— укажите имя базы данных, если хотите создать коллекции в базе данных с именем, отличным от имени базы-источника. -
cleanup_policy
— укажите способ очистки данных в базе-приемнике перед переносом:-
DISABLED
— не очищать (вариант по умолчанию).Выберите эту опцию, если будет производиться только репликация без копирования данных.
-
DROP
— полное удаление коллекций, участвующих в трансфере.Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия коллекции из источника.
-
TRUNCATE
— удалить только данные из коллекций, участвующих в трансфере, но оставить сами коллекции.Используйте эту опцию, если структура коллекций в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
-
-
database
— укажите имя базы данных, если хотите создать коллекции в базе данных с именем, отличным от имени базы-источника. -
cleanupPolicy
— укажите способ очистки данных в базе-приемнике перед переносом:-
DISABLED
— не очищать (вариант по умолчанию).Выберите эту опцию, если будет производиться только репликация без копирования данных.
-
DROP
— полное удаление коллекций, участвующих в трансфере.Используйте эту опцию, чтобы при любой активации трансфера в базу-приемник всегда передавалась самая последняя версия коллекции из источника.
-
TRUNCATE
— удалить только данные из коллекций, участвующих в трансфере, но оставить сами коллекции.Используйте эту опцию, если структура коллекций в базе-приемнике отличается от той, которая была бы перенесена из источника при трансфере.
-
Важно
По умолчанию сервис Data Transfer переносит коллекции без шардирования. Если вы переносите данные в шардированный кластер-приемник и хотите, чтобы коллекции шардировались:
- Подготовьте кластер-приемник для шардирования коллекций.
- Выберите политику очистки
DISABLED
илиTRUNCATE
.
Выбор политики DROP
приведет к тому, что при активации трансфера сервис удалит из базы-приемника все данные, в т. ч. шардированные коллекции, и создаст вместо них новые, нешардированные.
После настройки источника и приемника данных создайте и запустите трансфер.
Действия с базой данных во время трансфера
-
Для трансферов в статусе Копируется запрещено производить действия, которые сокращают временное окно журнала операций (oplog) на источнике. Не стоит добавлять, удалять шарды или каким-либо образом их переконфигурировать в процессе копирования, а также производить другие действия, приводящие к уменьшению временного окна журнала операций.
-
Для трансферов в статусе Реплицируется можно столкнуться с проблемой дублирования ключа в ситуациях, когда приемником выступает шардированный кластер MongoDB с индексом шардирования, отличным от
_id
. Во время работы трансфера не рекомендуется создавать на приемнике кластеры с индексами шардирования, отличными от_id
.
Решение проблем, возникающих при переносе данных
Известные проблемы, связанные с использованием эндпоинта MongoDB:
- Размер ключа коллекции превышает 5 МБ
- Размер объекта в коллекции превышает 16 МБ
- Не удалось найти ни одной таблицы
- Ошибка при трансфере шардированного кластера
- Ошибка при переносе коллекций timeseries
- Не распознается IP-адрес или FQDN внешнего кластера
См. полный список рекомендаций в разделе Решение проблем.
Размер ключа коллекции превышает 5 МБ
Текст ошибки:
Warn(replication): Usage of bulk objects in 'database <имя_БД>'
breaks change event log, transfer is stopping.
Reason: (Location<номер_позиции>) Tried to create string longer than 16MB.
Если размер ключа коллекции превышает 5 МБ, трансферы типа Репликация прерываются из-за внутренних ограничений
Решение: исключите из трансфера коллекции, превышающие лимиты MongoDB, после чего активируйте трансфер повторно.
Размер объекта в коллекции превышает 16 МБ
Текст ошибки:
Warn(replication): Usage of bulk objects in 'collection '<имя_БД>.<имя_коллекции>''
breaks change event log, transfer is stopping.
Reason: (BSONObjectTooLarge) BSONObj size: <размер_объекта> (<размер_объекта_в_hex>) is invalid.
Size muse be between 0 and 16793600(16MB).
Если размер объекта в коллекции превышает 16 МБ, трансферы типа Репликация прерываются из-за внутренних ограничений
Решение: исключите из трансфера коллекции, превышающие лимиты MongoDB, после чего активируйте трансфер повторно.
Не удалось найти ни одной таблицы
Текст ошибки:
Unable to find any tables
Из базы данных извлечено пустое число коллекций. Возможно у пользователя нет прав на базу данных, используемую в трансфере.
Решение: выдайте пользователю, от имени которого трансфер подключается к источнику, права readWrite
на базу данных для переноса.
Ошибка при трансфере шардированного кластера
Решение: задайте в параметре трансфера Настройки копирования → Настройки параллельного копирования количество воркеров, равное количеству переносимых коллекций.
Ошибка при переносе коллекций timeseries
Тексты ошибок:
Unable to find any tables
Cannot execute mongo activate hook:
Failed in accordance with configuration:
some tables from include list are missing in the source database: [<имя_коллекции>]
Сервис не поддерживает перенос коллекций Time Series
Решение: исключите из трансфера коллекции Time Series, после чего активируйте трансфер повторно.
Не распознается IP-адрес или FQDN внешнего кластера
Трансфер завершается с ошибкой:
server selection error: server selection timeout, current topology: { Type: ReplicaSetNoPrimary, Servers: [{ Addr: <неразрешающееся_FQDN>, Type: Unknown, Last error: connection() error occurred during connection handshake: dial tcp: lookup <неразрешающееся_FQDN> on <IP-адрес>: no such host }, ] }"
Ошибка трансфера связана с конфигурацией кластера MongoDB. Например, когда в описании шардов используются внутренние не разрешающиеся имена.
Решение:
Убедитесь, что кластер MongoDB сконфигурирован таким образом, чтобы на запросы к нему он возвращал корректно разрешающиеся IP-адреса или FQDN (Fully Qualified Domain Name).