Решение проблем в Data Transfer

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

• Проблемы, возникающие при работе с сервисом Data Transfer
• Общие
• Трансформация данных
• Ошибки в API
• Сеть
• ClickHouse®
• Elasticsearch
• MongoDB
• MySQL®
• Object Storage
• OpenSearch
• PostgreSQL
• Yandex Managed Service for YDB
• Yandex Data Streams
• Куда заявить о проблеме

Проблемы, возникающие при работе с сервисом Data TransferПроблемы, возникающие при работе с сервисом Data Transfer

Чтобы вовремя обнаружить проблему:

1. Следите за состоянием трансфера на вкладке Мониторинг страницы управления трансфером или в сервисе Yandex Monitoring.
2. Настройте алерты в сервисе Yandex Monitoring для получения уведомлений о сбоях в работе трансфера.
3. Запрашивайте записи о том, что происходило с вашими ресурсами, из логов сервисов Yandex Cloud.
4. Используйте мобильное приложение Yandex Cloud для отслеживания состояния трансферов.

Если при переносе данных работа сервиса Data Transfer была нарушена, попробуйте локализовать и проанализировать проблему. Часть решений приводится в этой статье или других разделах документации.

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

ОбщиеОбщие

Длительное время активации трансфераДлительное время активации трансфера

Решение: при активации трансфер долго находится в статусе Создается, это не ошибка. Время необходимо для создания ресурсов Yandex Compute Cloud, которые выделяются отдельно для каждого трансфера. Для некоторых источников извлекается схема базы данных, что также требует времени.

Гонка транзакций при инкрементальном копированииГонка транзакций при инкрементальном копировании

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

Решение: увеличьте значение времени ожидания завершения транзакций в настройках трансфера. Рекомендуемое значение и значение по умолчанию — 15 секунд.

Дубликаты строк в базе-приемникеДубликаты строк в базе-приемнике

Возможные причины:

• В базе-приемнике есть данные до начала трансфера.

  Решение: удалите данные из базы-приемника перед активацией трансфера или установите в эндпоинте-приемнике тип политики очистки Drop.

• В таблицах базы-приемника нет первичного ключа.

  Решение: убедитесь, что таблицы в базе-приемнике имеют первичные ключи.

Нехватка ресурсовНехватка ресурсов

Текст ошибки:

Warn(Activate): Snapshot loading failed:
snapshot tasks failed: main uploader failed:
errors detected on secondary workers: secondary worker #3 failed:
pod instance restarted 5h41m39.092446028s ago

Решение:

Если причиной ошибки pod instance restarted стала нехватка оперативной памяти (OOM) на ВМ трансфера, то возможны следующие решения:

• Снизить количество потоков на воркер в настройках трансфера. Количество воркеров при этом можно увеличить, чтобы сохранить общий уровень шардирования (параллельной загрузки) на стадии копирования. Т.к. потоки делят ресурсы воркера между собой, уменьшение числа потоков на воркер увеличит количество ресурсов, доступных каждому потоку. Эта мера позволит снизить вероятность ООМ потока.

• Для трансферов в стадии GA можно увеличить вычислительные ресурсы в настройке трансфера Среда выполнения. Такие трансферы тарифицируются, поэтому увеличение вычислительных ресурсов приведет к увеличению стоимости передачи данных.

• Для трансферов в стадии Preview самостоятельно изменить вычислительные ресурсы нельзя: обратитесь в техническую поддержку или к вашему аккаунт-менеджеру.

Если причиной ошибки pod instance restarted не является OOM, обратитесь в техническую поддержку.

Снижение скорости трансфераСнижение скорости трансфера

Проблема:

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

Решение:

Используйте политику очистки Drop или Truncate.

Ошибка создания или редактирования эндпоинта управляемой базы данныхОшибка создания или редактирования эндпоинта управляемой базы данных

Текст ошибки:

Can't authorize usage of managed <тип_БД>, you need permission <get-разрешение_MDB> to folder <идентификатор_папки_с_кластером>

Для создания или редактирования эндпоинта управляемой базы данных необходима сервисная или примитивная роль viewer, выданная на каталог кластера этой управляемой базы данных.

Решение:

Получите сервисную или примитивную роль viewer для работы с указанным кластером.

Трансформация данныхТрансформация данных

Не работает фильтр строк для APPEND-ONLY источниковНе работает фильтр строк для APPEND-ONLY источников

При выполнении трансфера не работает трансформер Фильтр строк для APPEND-ONLY источников.

Возможные причины:

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

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

• Если в фильтре указана строковая колонка, то тип этой колонки в фильтруемой таблице должен быть UTF8 для источников, где парсер явно указывает типы колонок (например, для YDS). Колонки типа STRING трансформером не поддерживаются.

  Решение: для строковой колонки в фильтруемой таблице укажите тип UTF8.

Ошибки в APIОшибки в API

Пример ошибки:

{"code": 13, "message": "internal"}

Решение: обратитесь в техническую поддержку или к вашему аккаунт-менеджеру с request_id запроса. Если вы используете curl для вызовов API, добавьте флаг -v для упрощения диагностики ошибки.

СетьСеть

Отсутствие общих зон доступностиОтсутствие общих зон доступности

Текст ошибки:

Warn(Activate): YC: unable to resolve instance group:
unable to resolve net topology: neither source nor target subnet found:
No common availability zone found for the source and target endpoints:
source zones: [<имя_зоны_источника>], target zones: [<имя_зоны_приемника>]

Ошибка возникает, если хосты источника и приемника находятся внутри Yandex Cloud, но не имеют общих зон доступности.

Решение:

• Добавьте хост в один из кластеров таким образом, чтобы у хостов появилась общая зона доступности.
• Настройте маршрутизацию через подсети в одной зоне:
  • Убедитесь, что у сети эндпоинта из зоны доступности 2 есть подсеть в зоне 1. Если нет — создайте такую.
  • Измените тип эндпоинта из зоны 2 на Пользовательская инсталляция.
  • Укажите у этого эндпоинта подсеть из зоны 1.
  • В качестве хоста укажите внутренний IP-адрес эндпоинта (нужно указывать без номера порта), который находится в подсети зоны 2.

Пересечение диапазонов IP-адресовПересечение диапазонов IP-адресов

Текст ошибки:

YC: unable to resolve instance group:
unable to resolve net topology: subnet address space collision detected:
subnet <идентификатор_подсети_1> [<диапазон_IP-адресов_подсети_1>]
collides with subnet <идентификатор_подсети_2> [<диапазон_IP-адресов_подсети_2>]

Ошибка возникает, если хосты источника и приемника находятся внутри Yandex Cloud в разных подсетях, но имеют пересекающиеся диапазоны IP-адресов.

Решение: создайте новый кластер-приемник и убедитесь, что задействованные в трансфере подсети его хостов и хостов кластера-источника не пересекаются по диапазонам IP-адресов.

Отсутствие соединения с серверомОтсутствие соединения с сервером

​Отсутствие соединения из-за указания подсети без настроенного NAT-шлюза.

Текст ошибки:

Can't connect to server: Can't ping server:
dial tcp <адрес_хоста_одного_из_эндпоинтов>:<порт>: connect: connection timed out

Трансфер, у которого один из эндпоинтов on_premise, а у второго указана подсеть, в которой не настроен NAT-шлюз, прерывается.

Решение: уберите настройку эндпоинта, указывающую на подсеть, и активируйте трансфер повторно.

Блокировка IP-адреса трансфераБлокировка IP-адреса трансфера

Решение: разрешите соединение с трансфером по адресам и диапазонам, которые использует Data Transfer.

Ошибка доступа к кластеруОшибка доступа к кластеру

Текст ошибки, возникающей при создании трансфера:

Cannot retrieve table information from the source database: failed to resolve storage: failed to create a PostgreSQL storage: unable to get master host: unable to create postgres service client: All hosts are unavailable:

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

Отсутствие прав на работу с подсетями и группами безопасности при создании эндпоинтаОтсутствие прав на работу с подсетями и группами безопасности при создании эндпоинта

Текст ошибки:

Create endpoint failed: rpc error: code = PermissionDenied desc = Failed permission check: No permission to use VPC Security Groups: Permission denied

или

Failed permission check: No permission to use VPC Subnets: Permission denied

Решение: назначьте пользователю роль vpc.user на каталог, в котором находится подсеть.

ClickHouse®ClickHouse®

Не добавляются новые таблицыНе добавляются новые таблицы

​В трансфер типа Копирование и репликация не добавляются новые таблицы.

Решение:

1. Создайте таблицы в базе-приемнике вручную. Чтобы трансфер работал, при создании таблицы:

   1. Добавьте в нее служебные поля трансфера:

      __data_transfer_commit_time timestamp,
      __data_transfer_delete_time timestamp
      

   2. Используйте движок ReplacingMergeTree:

      ENGINE = ReplacingMergeTree
      

2. Создайте отдельный трансфер типа Копирование и репликация и добавьте в список объектов для переноса только новые таблицы. При этом исходный трансфер типа Копирование и репликация можно не деактивировать. Активируйте новый трансфер, а после перехода в статус Реплицируется деактивируйте его.

   Чтобы добавить другие таблицы, замените ими список объектов для переноса в созданном отдельном трансфере, вновь активируйте его, а после перехода в статус Реплицируется деактивируйте.

   Примечание

   Так как два трансфера одновременно переносили данные, то в новых таблицах на приемнике присутствуют дубликаты записей. Чтобы скрыть их, выполните запрос SELECT * from TABLE <имя_таблицы> FINAL, а чтобы удалить — запрос OPTIMIZE TABLE <имя_таблицы>.

Не переносятся данныеНе переносятся данные

При попытке перенести данные из источника ClickHouse® выводится ошибка:

Syntax error: failed at position 25 ('-'): <детали_ошибки>. Expected one of: token, Dot, UUID, alias, AS, identifier, FINAL, SAMPLE, INTO OUTFILE, FORMAT, SETTINGS, end of query

Решение:

Yandex Data Transfer не может переносить базы данных, в названии которых есть дефис. Переименуйте базу данных, если есть такая возможность.

Неподдерживаемый диапазон датНеподдерживаемый диапазон дат

Если в переносимых данных есть даты вне поддерживаемых диапазонов, ClickHouse® возвращает ошибку:

TYPE_ERROR [target]: failed to run (abstract1 source): failed to push items from 0 to 1 in batch:
Push failed: failed to push 1 rows to ClickHouse shard 0:
ClickHouse Push failed: Unable to exec changeItem: clickhouse:
dateTime <имя_поля> must be between 1900-01-01 00:00:00 and 2262-04-11 23:47:16

Поддерживаемые диапазоны дат в ClickHouse®:

• Для полей с типом DateTime64 — с 1900-01-01 по 2299-12-31. Подробнее см. в документации ClickHouse®.
• Для полей с типом DateTime — с 1970-01-01 по 2106-02-07. Подробнее см. в документации ClickHouse®.

Решение: используйте один из вариантов:

• Приведите все даты в базе-источнике к поддерживаемому в ClickHouse® диапазону.
• В параметрах эндпоинта-источника исключите таблицу с некорректными датами из трансфера.
• В параметрах трансфера укажите трансформер Преобразовать значения в строки. В этом случае при трансфере изменится тип поля.

Нехватка ресурсов или растущая задержка передачи данныхНехватка ресурсов или растущая задержка передачи данных

При переносе данных в приемник ClickHouse® могут возникнуть следующие проблемы:

1. Трансфер прерывается с ошибкой. Текст ошибки:

   pod instance restarted
   

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

Возможная причина:

Слишком большой интервал записи в настройках эндпоинта-приемника, что вызывает нехватку оперативной памяти (OOM) на ВМ трансфера.

Решение:

Установите в консоли управления значение настройки эндпоинта-приемника Интервал записи равным 10 секунд или меньше.

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

Превышение количества блоков данныхПревышение количества блоков данных

При переносе данных в приемник ClickHouse® трансфер прерывается с ошибкой. Текст ошибки:

ERROR Unable to Activate ... 
unable to upload tables: unable to upload data objects: unable upload part <имя таблицы> (): 
unable to start \*clickhouse.HTTPSource event source: failed to push events to destination: 
unable to push http batch: <имя таблицы>: failed: INSERT INTO ...

Дополнительно может выводиться ошибка:

pod instance restarted

Ошибки возникают при попытке вставить в базу-приемник ClickHouse® больше блоков данных, чем позволяет настройка max_partitions_per_insert_block.

Решение: увеличьте параметр max_partitions_per_insert_block для учетной записи, под которой трансфер подключается к приемнику. Для приемника Managed Service for ClickHouse® параметр можно изменить в настройках пользователя. Для пользовательской инсталляции ClickHouse® можно создать профиль настроек и назначить его учетной записи:

CREATE SETTINGS PROFILE max_partitions
SETTINGS max_partitions_per_insert_block = <значение_настройки>

ALTER USER <имя_пользователя> PROFILE 'max_partitions'

ElasticsearchElasticsearch

Прерывание трансфера с ошибкойПрерывание трансфера с ошибкой

Тексты ошибок:

object field starting or ending with a [.] makes object resolution ambiguous <описание_поля>

Index -1 out of bounds for length 0

Трансфер прерывается из-за того, что ключи в передаваемых документах невалидны для приемника Elasticsearch. К невалидным относятся пустые ключи, а также ключи:

• состоящие из пробелов;
• состоящие из точек;
• с точкой в начале или конце;
• с точками, стоящими друг за другом;
• с точками, разделенными пробелами.

Решение:

В дополнительных настройках эндпоинта-приемника включите опцию Исправить некорректные ключи в документах и активируйте трансфер повторно.

Дублирование документов на приемникеДублирование документов на приемнике

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

Все документы, передаваемые из одной таблицы источника, попадают в один индекс с именем <schemaName.tableName> на приемнике. При этом по умолчанию приемник автоматически генерирует идентификаторы документов (_id). В результате одинаковые документы получают разные идентификаторы и дублируются.

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

Генерация происходит следующим образом:

1. Если значение ключа содержит ., она экранируется \: some.key --> some\.key.
2. Значения всех первичных ключей преобразуются в строку: <some_key1>.<some_key2>.<...>.
3. Полученная строка преобразуется функцией url.QueryEscape.
4. Если длина итоговой строки не превышает 512 символов, то она используется в качестве _id. Если длина больше 512 символов, то она хешируется алгоритмом SHA-1, и в качестве _id используется полученный хеш.

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

Решение:

1. Установите первичный ключ для одного или нескольких столбцов на источнике или в правилах конвертации эндпоинта.
2. Запустите трансфер.

MongoDBMongoDB

Размер ключа коллекции превышает 5 МБРазмер ключа коллекции превышает 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 на размер пользовательских объектов.

Решение: исключите из трансфера коллекции, превышающие лимиты MongoDB, после чего активируйте трансфер повторно.

Размер объекта в коллекции превышает 16 МБРазмер объекта в коллекции превышает 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 на размер пользовательских объектов.

Решение: исключите из трансфера коллекции, превышающие лимиты MongoDB, после чего активируйте трансфер повторно.

Не удалось найти ни одной таблицыНе удалось найти ни одной таблицы

Текст ошибки:

Unable to find any tables

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

Решение: выдайте пользователю, от имени которого трансфер подключается к источнику, права readWrite на базу данных для переноса.

Ошибка при трансфере шардированного кластераОшибка при трансфере шардированного кластера

Решение: задайте в параметре трансфера Настройки копирования → Настройки параллельного копирования количество воркеров, равное количеству переносимых коллекций.

Ошибка при переносе коллекций timeseriesОшибка при переносе коллекций 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 внешнего кластераНе распознается 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).

Ошибка на стадии копирования данныхОшибка на стадии копирования данных

Трансфер типа Копирование и репликация на стадии копирования завершается с ошибкой:

encountered non-recoverable resume token error. Sync cannot be resumed from this state and must be terminated and re-enabled to continue functioning: (ChangeStreamHistoryLost) Resume of change stream was not possible, as the resume point may no longer be in the oplog.

Ошибка ChangeStreamHistoryLost возникает, когда общее время копирования данных кластера-источника MongoDB превышает размер временного окна журнала операций (oplog). Текущий размер временного окна можно проверить в Консоли управления на графике Oplog window страницы мониторинга кластера.

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

Решение:

• Увеличьте размер oplog (по умолчанию 10 % от размера диска кластера). Чтобы увеличить размер oplog в кластере-источнике Managed Service for MongoDB, обратитесь в техническую поддержку. Чтобы изменить размер oplog в случае пользовательской инсталляции источника, см. документацию MongoDB.
• Включите параллельное копирование данных для ускорения стадии копирования.
• Ограничьте список объектов для переноса в настройках трансфера.

После этого активируйте трансфер повторно.

Данные в источнике не подходят для шардированияДанные в источнике не подходят для шардирования

Активация трансфера из источника MongoDB завершается с ошибкой:

ERROR: Unable to Activate
error: "failed to execute mongo activate hook: Snapshot loading failed: unable to sharded upload tables: unable to sharded upload(main worker) tables: unable to shard tables for operation id_операции: unable to split table, err: cannot get delimiters: there are two or more types of objects in the sharding index"

Ошибка cannot get delimiters: there are two or more types of objects in the sharding index означает, что на источнике в коллекции в поле id встречаются данные разных типов, и поэтому его нельзя использовать для шардирования.

Решение:

Укажите в настройках трансфера Настройки копирования → Настройки параллельного копирования 1 воркер и 1 поток, чтобы отключить шардирование.

После этого активируйте трансфер повторно.

MySQL®MySQL®

Размер лога одной транзакции превышает 4 ГБРазмер лога одной транзакции превышает 4 ГБ

Текст ошибки:

Last binlog file <имя_файла:размер_файла> is more than 4GB

Если размер лога одной транзакции превышает 4 ГБ, активация трансферов Репликация или Копирование и репликация завершается ошибкой из-за внутренних ограничений MySQL® на размер лога одной транзакции.

Решение: активируйте трансфер повторно.

Не добавляются новые таблицыНе добавляются новые таблицы

​В трансфер типа Копирование и репликация не добавляются новые таблицы.

Решение:

• Деактивируйте и активируйте трансфер повторно.
• Создайте таблицы в базе-приемнике вручную.
• Создайте отдельный трансфер типа Копирование и добавьте в него только вновь созданные таблицы. При этом исходный трансфер типа Копирование и репликация можно не деактивировать.

Ошибка при трансфере из AWS RDS for MySQL®Ошибка при трансфере из AWS RDS for MySQL®

В трансферах типа Копирование и репликация и Репликация из источника Amazon RDS for MySQL® может возникнуть ошибка загрузки таблиц.

Пример ошибки:

Failed to execute LoadSnapshot: 
Cannot load table "name": unable to read rows and push by chunks: 
unable to push changes: unable to execute per table push: 
error: err: sql: transaction has already been committed or rolled back 
rollback err: sql: transaction has already been committed or rolled back

Ошибка вызвана коротким временем хранения файлов бинарного лога MySQL® в Amazon RDS.

Решение:

Увеличьте время хранения бинарного лога с помощью команды:

call mysql.rds_set_configuration('binlog retention hours', <кол-во_часов>);

Максимальное значение времени хранения — 168 ч (7 дней). Значение по умолчанию — NULL (файлы бинарного лога не сохраняются). Подробнее см. в документации Amazon RDS.

Ошибка трансфера при переносе таблиц без первичных ключейОшибка трансфера при переносе таблиц без первичных ключей

Текст ошибки:

Primary key check failed: 14 Tables errors: Table no key columns found

Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся.

Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.

Ошибка обращения к бинарному логуОшибка обращения к бинарному логу

В трансферах типа Копирование и репликация может возникнуть ошибка:

Warn(replication): failed to run (abstract1 source):
failed to run canal: failed to start binlog sync:
failed to get canal event: ERROR 1236 (HY000): Could not find first log file name in binary log index file

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

Решение:

Увеличьте допустимый размер файлов бинарного лога в настройках MySQL® с помощью параметра Mdb preserve binlog bytes.

Минимальное значение — 1073741824 (1 ГБайт), максимальное значение — 107374182400 (100 ГБайт), по умолчанию — 1073741824 (1 ГБайт).

Ошибка удаления таблицы при политике очистки DropОшибка удаления таблицы при политике очистки Drop

Текст ошибки:

ERROR: cannot drop table <имя_таблицы> because other objects depend on it (SQLSTATE 2BP01)

При политике очистки Drop трансфер удаляет таблицы в несколько итераций:

1. Трансфер последовательно пытается удалить все таблицы. Каскадное удаление не используется, так как может привести к удалению таблиц, не участвующих в трансфере. Если таблицу невозможно удалить, например, из-за связанности внешними ключами, возникает ошибка, но трансфер продолжит удаление таблиц.

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

3. Если во время очередной итерации трансфер не удалил ни одной таблицы, процесс удаления таблиц завершается. При этом:

   • Трансфер продолжит работу, если все таблицы были удалены.
   • Трансфер прервется с ошибкой, если остались неудаленные таблицы.

Решение:

• Если дочерние таблицы не участвуют в других трансферах и их перенос не противоречит целям трансфера, добавьте эти таблицы:

  • В список включенных таблиц в параметрах эндпоинта-источника.
  • В список объектов для переноса в параметрах трансфера.

• Удалите блокирующие дочерние таблицы в базе-приемнике вручную.

• Используйте политику очистки Truncate.

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

  Важно

  Это приведет к потере всех данных в базе.

Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®

Сдвиг времени наблюдается, так как эндпоинт-источник применяет часовой пояс UTC+0 для данных с типом DATETIME. Подробнее см. в разделе Известные ограничения.

Решение: Примените нужный часовой пояс на уровне приемника вручную.

Object StorageObject Storage

Ошибка при обновлении данных в источникеОшибка при обновлении данных в источнике

Текст ошибки:

Push failed: kind: update not supported

Object Storage поддерживает только вставку новых данных, но не поддерживает их обновление. Если в источнике происходит обновление данных, трансфер завершится с ошибкой.

Решение: используйте источники, которые поддерживают только вставку данных, или выберите вместо Object Storage другой приемник.

OpenSearchOpenSearch

Прерывание трансфера с ошибкойПрерывание трансфера с ошибкой

Тексты ошибок:

object field starting or ending with a [.] makes object resolution ambiguous <описание_поля>

Index -1 out of bounds for length 0

Трансфер прерывается из-за того что ключи в передаваемых документах невалидны для приемника OpenSearch. К невалидным относятся пустые ключи, а также ключи:

• состоящие из пробелов;
• состоящие из точек;
• с точкой в начале или конце;
• с точками, стоящими друг за другом;
• с точками, разделенными пробелами.

Решение:

В дополнительных настройках эндпоинта-приемника включите опцию Исправить невалидные ключи в документах и активируйте трансфер повторно.

Превышение лимита максимального количества полейПревышение лимита максимального количества полей

Текст ошибки:

Limit of total fields [<значение_лимита>] has been exceeded

Трансфер прерывается, если количество колонок в базе данных источника превышает максимальное количество полей в индексах OpenSearch базы данных приемника.

Решение: увеличьте в базе данных приемника максимальное количество полей с помощью параметра index.mapping.total_fields.limit.

Дублирование документов на приемникеДублирование документов на приемнике

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

Все документы, передаваемые из одной таблицы источника, попадают в один индекс с именем <schemaName.tableName> на приемнике. При этом по умолчанию приемник автоматически генерирует идентификаторы документов (_id). В результате одинаковые документы получают разные идентификаторы и дублируются.

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

Генерация происходит следующим образом:

1. Если значение ключа содержит ., она экранируется \: some.key --> some\.key.
2. Значения всех первичных ключей преобразуются в строку: <some_key1>.<some_key2>.<...>.
3. Полученная строка преобразуется функцией url.QueryEscape.
4. Если длина итоговой строки не превышает 512 символов, то она используется в качестве _id. Если длина больше 512 символов, то она хешируется алгоритмом SHA-1, и в качестве _id используется полученный хеш.

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

Решение:

1. Установите первичный ключ для одного или нескольких столбцов на источнике или в правилах конвертации эндпоинта.
2. Запустите трансфер.

Прерывание трансфера с ошибкой can't index documentПрерывание трансфера с ошибкой can't index document

Текст ошибки:

Push failed: can't index document: got an indexation error

В аудитных логах разных сервисов поле details может содержать данные разных типов. В целевое поле details в OpenSearch записываются данные только того типа, который пришел первым. Остальные данные не принимаются из-за несовместимости типов, поэтому трансфер прерывается.

Решение: разделите поток, чтобы данные из разных сервисов попадали в разные индексы.

Для этого при создании трансфера в блоке Трансформация данных:

• Трансформер — выберите Трансформер разделения на подтаблицы.
• Список колонок — введите event_source.

Прерывание трансфера с ошибкой mapper_parsing_exceptionПрерывание трансфера с ошибкой mapper_parsing_exception

Текст ошибки:

mapper_parsing_exception failed to parse field [details.tags] of type [text]

Трансфер прерывается из-за несовместимости типов данных на источнике и приемнике.

Решение: перенесите данные в новый индекс OpenSearch, в котором тип поля details изменен на flat_object.

1. Деактивируйте трансфер.

2. Создайте новый индекс в OpenSearch:

   curl \
   --user <имя_пользователя_OpenSearch>:<пароль> \
   --header 'Content-Type: application/json' \
   --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/<название_нового_индекса>/_settings' \
   --data '{"index.mapping.total_fields.limit": 2000}'
   

3. Измените тип поля details:

   curl \
   --user <имя_пользователя_OpenSearch>:<пароль> \
   --header 'Content-Type: application/json' \
   --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/<название_нового_индекса>/_mapping' \
   --data '
       {
           "properties": {
               "details": {
                   "type": "flat_object"
               }
           }
       }'
   

4. Перенесите данные из исходного индекса в новый:

   curl \
   --user <имя_пользователя_OpenSearch>:<пароль> \
   --header 'Content-Type: application/json' \
   --request POST 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_reindex' \
   --data '
       {
       "source":{
           "index":"<название_исходного_индекса>"
       },
       "dest":{
           "index":"<название_нового_индекса>"
       }
       }'
   

5. Удалите исходный индекс:

   curl \
   --user <имя_пользователя_OpenSearch>:<пароль> \
   --header 'Content-Type: application/json' \
   --request DELETE 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/<название_исходного_индекса>'
   

6. Присвойте новому индексу псевдоним:

   curl \
   --user <имя_пользователя_OpenSearch>:<пароль> \
   --header 'Content-Type: application/json' \
   --request POST 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_aliases' \
   --data '
       {
       "actions": [
           {
           "add": {
               "index": "<название_нового_псевдонима>",
               "alias": "<название_исходного_псевдонима>"
           }
           }
       ]
       }'
   

PostgreSQLPostgreSQL

Остановка сессии мастер-транзакции трансфераОстановка сессии мастер-транзакции трансфера

Текст ошибки:

Cannot set transaction snapshot:
ERROR: invalid snapshot identifier: "<идентификатор_снапшота>" (SQLSTATE 22023).

Возможные причины:

• На источнике работает cron-задание или другое приложение, которое периодически завершает слишком длительные сессии.
• Кто-то вручную завершил мастер-транзакцию.
• Ресурсов CPU на источнике не хватает для выполнения запроса.

Решение: отключите такое cron-задание, а также добавьте дополнительные ресурсы для CPU на источник. После внесения изменений активируйте трансфер повторно.

Превышение квоты на длительность соединенияПревышение квоты на длительность соединения

В Yandex Managed Service for PostgreSQL существует квота на длительность соединения — 12 часов.
​
​Решение: если перенос базы данных требует больше времени, измените настройку кластера Yandex Managed Service for PostgreSQL Session duration timeout.

Превышение количества подключений к базе данныхПревышение количества подключений к базе данных

В PostgreSQL есть ограничение на количество подключений пользователя к базе данных. Если для трансфера количество подключений превышает это ограничение, то трансфер будет работать неправильно или не будет работать вовсе.

Решение: настройте количество подключений пользователя к базе данных.

Ошибка трансфера при переносе представлений (VIEW)Ошибка трансфера при переносе представлений (VIEW)

Текст ошибки:

[ERROR] "... _view": no key columns found

Репликация новых данных из представлений невозможна. При трансфере PostgreSQL — PostgreSQL переносятся только те представления, которые указаны в параметре эндпоинта-источника Фильтр таблиц → Список включенных таблиц.

Решение: вручную исключите из трансфера все представления, записав их в параметре эндпоинта-источника Фильтр таблиц → Список исключённых таблиц, после чего активируйте трансфер повторно.

Ошибка добавления записи в таблицу по constraintОшибка добавления записи в таблицу по constraint

Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.

Ошибка при переносе всех таблиц схемыОшибка при переносе всех таблиц схемы

Текст ошибки:

Unable to apply DDL of type 'TABLE', name '<схема>'.'<таблица>', error:
ERROR: schema "<схема>" does not exist (SQLSTATE 3F000)

Трансфер прерывается при указании списка таблиц определенной схемы в виде <схема>.*. Это происходит из-за особенностей работы утилиты pg_dump, которая используется для переноса схемы. При указании таблиц всей схемы <схема>.* в параметре эндпоинта-источника Фильтр таблиц → Список включенных таблиц типы PostgreSQL из этой схемы не извлекаются, даже если в схеме есть таблицы, зависящие от этих типов.

Решение: создайте типы PostgreSQL в базе-приемнике вручную.

Невозможно создать объекты с участием функций расширенияНевозможно создать объекты с участием функций расширения

Текст ошибки:

Unable to apply DDL of type 'TABLE', <имя_объекта>, error:
failed to push non-row item 0 of kind "pg:DDL" in batch:
Push failed: ERROR: function <имя_схемы>.<имя_функции>() does not exist 
(SQLSTATE 42883)

В Managed Service for PostgreSQL в базе-приемнике невозможно установить расширение в пользовательскую схему. Поэтому трансфер прерывается, если в пользовательской инсталляции Managed Service for PostgreSQL есть расширения, установленные в пользовательскую схему, и эти расширения используются в DDL переносимых объектов.

Решение: проверьте DDL объектов, имена которых указаны в ошибке. Если в этих объектах есть вызов функций из пользовательской схемы, вручную создайте в приемнике DDL, которые вызывают функции без указания схемы. В политике очистки эндпоинта-приемника установите значение Truncate, чтобы трансфер не удалил эти объекты.

Низкая скорость трансфера Низкая скорость трансфера

​Может возникать у трансферов типа Копирование или Копирование и репликация из PostgreSQL в PostgreSQL.

Возможные причины:

• Протокол записи.

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

  Решение: установите в эндпоинте-приемнике тип политики очистки Drop и исключите другие пишущие процессы.

• Параллельность чтения таблиц.

  Параллельность доступна только для таблиц, которые содержат первичный ключ в режиме serial.

  Решение: настройте параллельное копирование и активируйте трансфер повторно.

Не переносятся таблицы-наследникиНе переносятся таблицы-наследники

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

Решение: установите следующие параметры эндпоинта-источника:

1. Включите опцию Объединить наследуемые таблицы в расширенных настройках.
2. Укажите в поле Список включенных таблиц все таблицы-наследники, данные которых нужно перенести.
3. Убедитесь, что у пользователя есть доступ к таблицам-наследникам.

Для увеличения скорости трансфера при переносе таблиц-наследников настройте параллельное копирование.

Не хватает слотов репликации в базе данных источникаНе хватает слотов репликации в базе данных источника

Текст ошибки:

Warn(Activate): failed to create a replication slot "<идентификатор_трансфера>" at source:
failed to create a replication slot:
failed to create a replication slot:
ERROR: all replication slots are in use
(SQLSTATE 53400)

Решение: увеличьте количество слотов репликации в базе-источнике (по умолчанию 10).

Перестали переноситься данные после изменения эндпоинта-источникаПерестали переноситься данные после изменения эндпоинта-источника

После добавления таблиц в Список включенных таблиц в параметрах эндпоинта-источника трансфер перезапустился и перестал переносить данные.

Решение:

• Создайте таблицы в базе-приемнике вручную.

  1. Создайте в базе-приемнике новые таблицы с Primary Key и без Foreign key.
  2. Добавьте новые таблицы в Список включенных таблиц в параметрах эндпоинта-источника.
  3. Перенесите дамп с историческими данными в базу-приемник.
  4. При появлении в логах ошибок решите их согласно конкретной ошибке.
  5. Если ошибок нет, но логи пусты, обратитесь в техническую поддержку или к вашему аккаунт-менеджеру для снятия дампа горутин. Это может помочь восстановить репликацию без повторного запуска трансфера.

• Деактивируйте и активируйте трансфер повторно.

• Создайте отдельный трансфер типа Копирование для новых таблиц. При этом исходный трансфер можно не деактивировать.

Ошибка трансфера при смене хоста-мастераОшибка трансфера при смене хоста-мастера

Ошибка возникает в трансферах типа Репликация или Копирование и репликация из-за отсутствия нужных частей Write-Ahead Log (WAL). Это происходит, когда отставание логической репликации WAL с текущего мастера на реплику превышает доступный объем WAL на других хостах. Поэтому при переключении мастера на эту реплику слот репликации не может синхронизироваться с WAL на новом мастере.

Решение: увеличьте лимит в дополнительном параметре эндпоинта-источника Максимальный размер WAL для слота репликации и активируйте трансфер повторно.

Ошибка при трансфере вложенных транзакцийОшибка при трансфере вложенных транзакций

Трансфер PostgreSQL версий ниже 14 не поддерживает перенос таблиц с примененными транзакциями, которые вложены более 1024 раз и на каждом уровне вложенности есть изменения для репликации. Количество вложенностей определяется по числу вложенных конструкций begin; .. commit;.

Решение:

• Используйте PostgreSQL версии 14 или выше.
• Исключите из трансфера транзакции с таким уровнем вложенности.

Ошибка трансфера таблиц с отложенными ограничениямиОшибка трансфера таблиц с отложенными ограничениями

Ошибка возникает в трансферах типа Репликация или Копирование и репликация, так как обновление таблиц и транзакций с отложенными (DEFERRABLE) ограничениями не поддерживается Data Transfer. Подробнее об отложенных ограничениях см. в документации PostgreSQL.

Решение: замените тип ограничений в таких таблицах на IMMEDIATE и активируйте трансфер повторно.

Не удается создать слот репликации на стадии активацииНе удается создать слот репликации на стадии активации

В начале работы трансфера создается один или несколько слотов репликации в базе-источнике. При этом объекты базы блокируются. Если какой-то объект заблокирован другой транзакцией, возникнет конкурирующая блокировка, и трансфер завершится с ошибкой.

Решение:

1. Найдите PID процесса, конкурирующего за блокировки с трансфером:

   /* поиск PID трансфера */
   SELECT active_pid
     FROM pg_replication_slots
     WHERE slot_name = '<ID_трансфера>';
   
   /* поиск PID блокирующего процесса */
   SELECT pid, pg_blocking_pids(pid) as blocked_by
     FROM pg_stat_activity
     WHERE cardinality(pg_blocking_pids(pid)) > 0;
   

           pid      | blocked_by
   -----------------+-------------------
    <PID_трансфера> | {<PID_блокирующей_транзакции>}
   (1 row)
   

2. Посмотрите блокирующий запрос:

   SELECT query, usename
     FROM pg_stat_activity
     WHERE pid = <PID_блокирующей_транзакции>;
   

3. (Опционально) Остановите транзакцию командой:

   SELECT pg_terminate_backend(<PID_блокирующей_транзакции>);
   

4. Активируйте трансфер повторно.

Чрезмерное увеличение журнала WALЧрезмерное увеличение журнала WAL

В базе данных источника PostgreSQL размер журнала Write-Ahead Log (WAL) достигает значения десятков гигабайт из-за долгих запросов (выполняющихся более 5 минут). Такие запросы блокируют журнал WAL и не дают ему продвинуться вперед и очиститься.

Увеличение размера журнала WAL можно заметить по:

• увеличению места, занимаемого базой данных источника;
• возрастанию графика Read buffer size в мониторинге Data Transfer.

Решение:

1. Найдите сессии запросов, выполняющиеся дольше 5 минут:

   SELECT now()-xact_start, query, pid FROM pg_stat_activity
   WHERE (now()-xact_start)>'5minute'::interval AND STATE != 'idle'
   ORDER BY 1 DESC;
   

2. Завершите найденные сессии. Старайтесь не допускать появления таких запросов.

Ошибка при репликации из внешнего источникаОшибка при репликации из внешнего источника

Текст ошибки:

[XX000] ERROR: could not connect to the publisher:
SSL error: certificate verify failed FATAL:
no pg_hba.conf entry for replication connection
from host "<IP-адрес_хоста_PostgreSQL>", user "postgres", SSL off

Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.

Ошибка трансфера при переносе таблиц без первичных ключейОшибка трансфера при переносе таблиц без первичных ключей

Текст ошибки:

Primary key check failed: 14 Tables errors: Table no key columns found

Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся.

Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.

Ошибка удаления таблицы при политике очистки DropОшибка удаления таблицы при политике очистки Drop

Текст ошибки:

ERROR: cannot drop table <имя_таблицы> because other objects depend on it (SQLSTATE 2BP01)

При политике очистки Drop трансфер удаляет таблицы в несколько итераций:

1. Трансфер последовательно пытается удалить все таблицы. Каскадное удаление не используется, так как может привести к удалению таблиц, не участвующих в трансфере. Если таблицу невозможно удалить, например, из-за связанности внешними ключами, возникает ошибка, но трансфер продолжит удаление таблиц.

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

3. Если во время очередной итерации трансфер не удалил ни одной таблицы, процесс удаления таблиц завершается. При этом:

   • Трансфер продолжит работу, если все таблицы были удалены.
   • Трансфер прервется с ошибкой, если остались неудаленные таблицы.

Решение:

• Если дочерние таблицы не участвуют в других трансферах и их перенос не противоречит целям трансфера, добавьте эти таблицы:

  • В список включенных таблиц в параметрах эндпоинта-источника.
  • В список объектов для переноса в параметрах трансфера.

• Удалите блокирующие дочерние таблицы в базе-приемнике вручную.

• Используйте политику очистки Truncate.

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

  Важно

  Это приведет к потере всех данных в базе.

Yandex Managed Service for YDBYandex Managed Service for YDB

Прерывание трансфера с ошибкойПрерывание трансфера с ошибкой

Трансфер типа Репликация или Копирование и репликация прерывается с ошибкой.

Текст ошибки:

/Ydb.PersQueue.V1.PersQueueService/AddReadRule failed: OVERLOADED

Трансфер прерывается из-за ограничения облачной квоты на количество операций с Managed Service for YDB.

Решение:

1. Увеличьте в квотах Managed Service for YDB на облако с нужной базой данных значение характеристики Количество схемных операций в минуту и активируйте трансфер повторно.

Yandex Data StreamsYandex Data Streams

Прерывание трансфера с ошибкойПрерывание трансфера с ошибкой

Трансфер типа Репликация или Копирование и репликация прерывается с ошибкой.

Текст ошибки:

/Ydb.PersQueue.V1.PersQueueService/AddReadRule failed: OVERLOADED

Трансфер прерывается из-за ограничения облачной квоты на количество операций с Managed Service for YDB.

Решение:

1. Увеличьте в квотах Managed Service for YDB на облако с нужной базой данных значение характеристики Количество схемных операций в минуту и активируйте трансфер повторно.

Редиректы Cloud FunctionsРедиректы Cloud Functions

В трансферах из Data Streams или Apache Kafka® в редких случаях может возникнуть ошибка:

redirect to SOME_URL is requested but no redirects are allowed.

Возможная причина:

На источнике настроено использование функции Cloud Functions, которая возвращает не данные, а редирект на другой URL.

Решение:

По соображениям безопасности такие редиректы запрещены. Воздержитесь от использования редиректов в Cloud Functions в трансферах.

Куда заявить о проблемеКуда заявить о проблеме

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

ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.