[Документация Yandex Cloud](../../index.md) > [Yandex Data Transfer](../index.md) > Решение проблем

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

В этом разделе описаны типичные проблемы, которые могут возникать при [активации](../operations/transfer.md#activate) или во время работы [трансферов](../concepts/index.md#transfer), и методы их решения.

* [Проблемы, возникающие при работе с сервисом Data Transfer](#overview)
* [Общие](#common)
* [Ошибки, отображаемые на временной шкале](#timeline)
* [Трансформация данных](#data-transform)
* [Ошибки в API](#api)
* [Сеть](#network)
* [ClickHouse®](#clickhouse)
* [MongoDB](#mongodb)
* [MySQL®](#mysql)
* [Object Storage](#object-storage)
* [OpenSearch](#opensearch)
* [PostgreSQL](#postgresql)
* [Greenplum®](#greenplum)
* [Куда заявить о проблеме](#support)

## Проблемы, возникающие при работе с сервисом Data Transfer {#overview}
Чтобы вовремя обнаружить проблему:

1. Следите за состоянием трансфера на вкладке **Мониторинг** страницы управления трансфером или в сервисе [Yandex Monitoring](../../monitoring/concepts/index.md).
1. [Настройте алерты](../operations/monitoring.md#monitoring-integration) в сервисе Yandex Monitoring для получения уведомлений о сбоях в работе трансфера.
1. [Запрашивайте](../../support/request.md) записи о том, что происходило с вашими ресурсами, из логов сервисов Yandex Cloud.
1. Используйте [мобильное приложение](https://yandex.cloud/ru-kz/mobile-app) Yandex Cloud для отслеживания состояния трансферов.

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

| Источник проблемы | Проблема | Решение |
|-------------------|----------|---------|
| Эндпоинт | Отсутствие сетевой доступности или прав доступа к эндпоинту | Проверьте чтение из источника с помощью графиков: [Maximum data transfer delay](../operations/monitoring.md#sinker.pusher.time.row_max_lag_sec), [Number of source events](../operations/monitoring.md#publisher.data.changeitems) и [Reads](../operations/monitoring.md#publisher.data.bytes).</br>Проверьте запись в приемник с помощью графиков: [Maximum data transfer delay](../operations/monitoring.md#sinker.pusher.time.row_max_lag_sec), [Number of source events](../operations/monitoring.md#publisher.data.changeitems), [Number of target events](../operations/monitoring.md#sinker.pusher.data.changeitems) и [Reads](../operations/monitoring.md#publisher.data.bytes).</br>Если данные читаются и записываются, проверьте [ограничения на работу с СУБД](../operations/transfer.md).</br>Уточните требования для [подготовки](../operations/prepare.md) и [настройки](../operations/index.md) эндпоинта.</br>Поищите уже готовое [решение проблемы](#common). |
| Эндпоинт или трансфер | Недостаток физических ресурсов трансфера или эндпоинтов | Если данные читаются и записываются, проверьте, достаточно ли физических ресурсов на графиках: [CPU](../operations/monitoring.md#proc.cpu%7Cproc.guarantee.cpu) и [RAM](../operations/monitoring.md#proc.ram%7Cproc.guarantee.mem). |
| Данные | Неактуальные данные из-за изменений в схеме данных | Ознакомьтесь с различными сценариями передачи данных в разделе [Практические руководства Data Transfer](../tutorials/index.md). |
| Данные | Неактуальные данные из-за большого объема данных | Увеличьте количество воркеров для [параллельного копирования](../concepts/sharded.md) или [репликации](../operations/transfer.md#create).</br>Разделите таблицы на несколько трансферов. |

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

![image](../../_assets/data-transfer/restore-transfer.svg)

## Общие {#common}

### Длительное время активации трансфера {#long-time}

**Решение:** при [активации](../operations/transfer.md#activate) трансфер долго находится в статусе **Создается**, это не ошибка. Время необходимо для создания ресурсов Yandex Compute Cloud, которые выделяются отдельно для каждого трансфера. Для некоторых источников извлекается схема базы данных, что также требует времени.

### Гонка транзакций при инкрементальном копировании {#increment-copy}

При инкрементальном копировании возможны гонки транзакций — ситуации, когда транзакции завершаются не в том же порядке, в котором начались. При этом трансфер может не учесть более ранние транзакции. Подробнее читайте в разделе [Время ожидания завершения транзакций](../concepts/regular-incremental-copy.md#increment-delay).

**Решение**: увеличьте значение времени ожидания завершения транзакций в [настройках трансфера](../operations/transfer.md#update). Рекомендуемое значение и значение по умолчанию — `15` секунд.

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

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

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

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

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

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

### Нехватка ресурсов {#insufficiency-resources}

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

```text
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) на ВМ трансфера, то возможны следующие решения:

* Снизить количество потоков на воркер в [настройках трансфера](../operations/transfer.md#update-copy-repl). Количество воркеров при этом можно увеличить, чтобы сохранить общий уровень [шардирования](../concepts/sharded.md) (параллельной загрузки) на стадии копирования. Т.к. потоки делят ресурсы воркера между собой, уменьшение числа потоков на воркер увеличит количество ресурсов, доступных каждому потоку. Эта мера позволит снизить вероятность ООМ потока.

* Для [трансферов в стадии GA](../transfer-matrix.md) можно увеличить вычислительные ресурсы в [настройке трансфера](../operations/transfer.md#update) **Среда выполнения**. Такие трансферы [тарифицируются](../pricing.md), поэтому увеличение вычислительных ресурсов приведет к увеличению стоимости передачи данных.

* Для [трансферов в стадии Preview](../transfer-matrix.md) самостоятельно изменить вычислительные ресурсы нельзя: обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support) или к вашему аккаунт-менеджеру.

Если причиной ошибки `pod instance restarted` не является OOM, обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support).

### Отсутствие необходимых прав у пользователя {#permission-denied}

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

```text
Warn(Activate): failed to load schema using pg_dump:
unable to execute pg_dump to get sequence data:
Unable to exec pg_dump: exit status 1;
stderr: pg_dump: error: query failed: ERROR: permission denied for
```

**Решение:** [подготовьте источник](../operations/prepare.md#source) и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не удается обработать имя объекта {#unable-to-parse-obj}

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

```text
failed to list and filter tables in source:
filter failed: unable to filter transfer objects:
unable to parse obj: <имя.какого-либо.объекта>:
identifier '<имя.какого-либо.объекта>' contains 3 parts instead of maximum two
```

Ошибка возникает, если в списке объектов для переноса есть имя, разделенное двумя или более точками.

**Решение:** возьмите имя объекта в двойные кавычки — `"<имя.какого-либо.объекта>"`.

### Ошибка подключения к пользовательской базе данных {#failed-to-connect}

Текст ошибки (на примере MySQL®):

```text
failed to initialize LocalWorker:
failed to create source: unable to create *mysql.MysqlSource:
unable to create new mysql source: failed to create canal: failed to check bin log row format:
failed to connect to the database: handleAuthResult: ERROR 1045 (28000):
Access denied for user '<имя_пользователя>'@'<IP_адрес>' (using password: YES)
```

Ошибка возникает, если в параметрах эндпоинта для пользовательской инсталляции БД не указан сертификат CA.

Он требуется для безопасного TLS-соединения между сервисом Data Transfer и сервером пользовательской БД. При подключении Data Transfer проверяет, что сертификат действителен, а центр сертификации (CA), который его выдал, надежен. Без сертификата подключение завершается ошибкой.


**Решение:** укажите сертификат CA в параметрах эндпоинта для пользовательской инсталляции БД.

### В кластере не найдены работоспособные хосты {#no-alive-hosts}

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

```
No alive hosts found for cluster
```

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

Возможны следующие решения:

* Проверьте состояние кластера:

  * Перейдите в [консоль управления](https://kz.console.yandex.cloud) и проверьте состояние вашего кластера управляемых БД. Убедитесь, что кластер и его хосты находятся в состоянии **Alive** или **Running**.

  * Если кластер или его хосты не работают, посмотрите логи кластера, выясните причину и устраните ее.

* Убедитесь, что конфигурация сети, подсети, групп безопасности и таблиц маршрутизации позволяет Data Transfer получить доступ к хостам кластера.

* Если кластер был временно недоступен, например во время обслуживания или из-за сбоя, дождитесь его полного восстановления и повторите попытку активации трансфера.

* Убедитесь, что в эндпоинте указан правильный идентификатор кластера или FQDN хоста.

### Ошибка Operation canceled {#operation-canceled}

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

**Решение**: перезапустите трансфер. 

Трансфер может запускаться несколько минут, это время нужно для бронирования и запуска ресурсов.

### Ошибка Unknown user {#unknown-user}

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

Возможны следующие решения:

* Проверьте имя пользователя в настройках эндпоинта. Обратите внимание на регистр символов, если СУБД чувствительна к нему.

* Проверьте имя базы данных в настройках эндпоинта.

* Убедитесь что пользователь с указанным именем действительно создан в базе данных, к которой подключается Data Transfer.


### Ошибка No such host {#no-such-host}

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

```
lookup <host>.mdb.yandexcloud.net on <Ip>: no such host
```

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

**Решение:** перезапустите трансфер.

### Снижение скорости трансфера {#speed-degrade}

**Проблема**:

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

**Решение**:

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


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

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

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

Для создания или редактирования эндпоинта управляемой базы данных необходима сервисная или примитивная [роль `viewer`](../../iam/roles-reference.md#viewer), выданная на каталог кластера этой управляемой базы данных.


**Решение:**

[Получите](../../iam/operations/roles/grant.md) сервисную или примитивную роль `viewer` для работы с указанным кластером.


## Ошибки, отображаемые на временной шкале трансфера {#timeline}

### Трансфер записывает не все прочитанные данные {#no-items-in-memory}

Количество событий, записываемых в приемник, меньше, чем прочитанных из источника. Это может говорить о недостаточной пропускной способности приемника.

**Решение:** увеличьте пропускную способность приемника. Подробнее о [факторах](../concepts/copy-speed.md), которые на нее влияют.

### Время переноса данных выросло или слишком велико {#transfer-time-sound}

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

**Решение:** увеличьте пропускную способность приемника. Подробнее о [факторах](../concepts/copy-speed.md), которые на нее влияют.

### Лаг репликации растет {#row-max-lag-constant}

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

**Решение:**

  * [Проверьте настройки приемника](../operations/endpoint/index.md#get).
  
  * Если пара источник-приемник находятся на стадии [GA](../../overview/concepts/launch-stages.md) и [тарифицируются](../pricing.md), увеличьте объем вычислительных ресурсов в блоке настроек трансфера **Среда выполнения**.

  * Чтобы узнать больше о состоянии трансфера, изучите [логи](../metrics.md) в сервисе Monitoring.
  * Чтобы выявить проблемы в работе источника и приемника, проведите диагностику их производительности.


> Пример: как [изменить объем вычислительных ресурсов](../operations/transfer.md#update) для трансфера и [провести диагностику производительности](../../managed-mysql/operations/performance-diagnostics.md) для кластера Managed Service for MySQL®.

### Репликация часто перезапускается {#replication-restarts}

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

**Решение:**

 * Чтобы выявить проблемы в работе источника и приемника, проведите диагностику их производительности.
 
 * Если пара источник-приемник находятся на стадии [GA](../../overview/concepts/launch-stages.md) и [тарифицируются](../pricing.md), увеличьте объем памяти в блоке настроек трансфера **Среда выполнения**.


> Пример: как [изменить объем вычислительных ресурсов](../operations/transfer.md#update) для трансфера и [провести диагностику производительности](../../managed-mysql/operations/performance-diagnostics.md) для кластера Managed Service for MySQL®.

## Трансформация данных {#data-transform}

### Не работает фильтр строк для APPEND-ONLY источников {#filtr-append-only-sources}

При выполнении трансфера не работает трансформер [Фильтр строк для APPEND-ONLY источников](../concepts/data-transformation.md#append-only-sources).

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

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

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

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

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

## Ошибки в API {#api}

### "code": 13 {#code13}

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

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

**Решение**: обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support) или к вашему аккаунт-менеджеру с `request_id` запроса. Если вы используете `curl` для вызовов [API](../../glossary/rest-api.md), добавьте флаг `-v` для упрощения диагностики ошибки.


## Сеть {#network}

### Ошибка Connection refused {#connection-refused}

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

```text
connect: connection refused
```

Сервису не удалось установить TCP-соединение по указанному хосту и порту. Сервер на стороне источника или приемника доступен по сети, но отклонил попытку подключения.  

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

* Неверно указаны хост и порт. 

    **Решение:** Проверьте правильность написания хоста и порта.

* Указанный порт не прослушивается;

    **Решение:** Убедитесь, что настройки вашей СУБД позволяют принимать подключения извне на указанный порт.

### Ошибка Failed to connect to…

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

```
Failed to connect to <адрес_хоста>
```

Ошибка возникает, если в качестве имени хоста базы данных было указано `localhost` или другое неверное значение. Yandex Data Transfer работает из своей сетевой среды (специализированные виртуальные машины в Yandex Cloud) и не может разрешить имя `localhost` в контексте вашего сервера базы данных. `localhost` всегда указывает на ту же машину, на которой запущена программа, пытающаяся его разрешить.

**Решение:**

1. Если база данных находится на виртуальной машине в Yandex Cloud, укажите её внутренний IP-адрес или FQDN.

1. Если база данных находится вне Yandex Cloud, укажите её публичный IP-адрес или FQDN, доступный из интернета.

1. Для кластеров управляемых баз данных в Yandex Cloud рекомендуется при настройке эндпоинта выбирать **Тип инсталляции** — **Кластер Managed Service for <СУБД>**. В таком случае вы выбираете кластер управляемых БД из списка, а сервис сам определяет актуальные FQDN его хостов.

1. Если вы подключаетесь к кластеру управляемых БД в Yandex Cloud как к пользовательской инсталляции через FQDN конкретного хоста, убедитесь, что адрес хоста введен корректно.

### Отсутствие общих зон доступности {#common-network}

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

```text
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, но не имеют общих [зон доступности](../../overview/concepts/geo-scope.md).

**Решение:**

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

### Пересечение диапазонов IP-адресов {#ip-collision}

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

```text
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-адресов.

### Отсутствие соединения с сервером {#subnet-without-nat}

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

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

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

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

**Решение:** уберите настройку эндпоинта, указывающую на подсеть, и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Блокировка IP-адреса трансфера {#blocked-ip}

**Решение:** разрешите соединение с трансфером по [адресам и диапазонам](../../overview/concepts/public-ips.md#virtual-private-cloud), которые использует Data Transfer.

### Ошибка доступа к кластеру {#transfer-error}

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

```text
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:
```
**Решение:** проверьте доступность кластера в вашей [подсети](../concepts/network.md).
Чаще всего проблема заключается в отсутствии необходимых правил в группе безопасности.


### Отсутствие прав на работу с подсетями и группами безопасности при создании эндпоинта {#vpc-user}

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

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

**Решение:** назначьте пользователю роль [`vpc.user`](../../vpc/security/index.md) на каталог, в котором находится подсеть.


### Ошибка Connection timed out

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

**Возможны следующие решения**:

1. Проверьте доступность хоста с помощью команды `ping` (если разрешен ICMP) или `telnet <хост> <порт>` с виртуальной машины в той же сети, где находится кластер управляемых БД.

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

1. Если вы подключаетесь к кластеру управляемых БД в другом облаке Yandex Cloud, убедитесь, что в кластере включен публичный доступ.

1. Если вы подключаетесь к хосту вне Yandex Cloud, убедитесь в его публичной доступности или наличии настроенного VPN/Interconnect.

1. Если вы подключаетесь к пользовательской инсталляции, убедитесь, что сетевые брандмауэры (на маршрутизаторах, в облачной сети) и локальные брандмауэры на хосте не блокируют трафик.

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

## ClickHouse® {#clickhouse}

### Не добавляются новые таблицы {#no-new-tables}

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

**Решение:**

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

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

        ```sql
        __data_transfer_commit_time timestamp,
        __data_transfer_delete_time timestamp
        ```

    1. Используйте движок `ReplacingMergeTree`:
        
        ```sql
        ENGINE = ReplacingMergeTree
        ```

1. [Создайте](../operations/transfer.md#create) отдельный трансфер типа _**Копирование и репликация**_ и добавьте в список объектов для переноса только новые таблицы. При этом исходный трансфер типа _**Копирование и репликация**_ можно не деактивировать. [Активируйте](../operations/transfer.md#activate) новый трансфер, а после перехода в статус **Реплицируется** [деактивируйте](../operations/transfer.md#deactivate) его.

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

   {% note info %}

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

   {% endnote %}

### Ошибка SSL is required

Ошибка возникает при подключении к кластеру Managed Service for ClickHouse® как к пользовательской инсталляции через [FQDN](../../managed-clickhouse/concepts/network.md#hostname) хоста ClickHouse®, если вы не включили опцию **SSL** в настройках эндпоинта. Кластер Managed Service for ClickHouse® по умолчанию требует SSL-шифрование для подключений по FQDN хоста. 

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

**Решение:**

В настройках эндпоинта активируйте опцию **SSL**.

Для кластеров MDB и других источников, использующих сертификаты, выданные публичными CA, обычно не требуется загружать CA-сертификат.

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

### Неподдерживаемый диапазон дат {#date-range}

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

```text
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®](https://clickhouse.com/docs/ru/sql-reference/data-types/datetime64).
* Для полей с типом `DateTime` — с 1970-01-01 по 2106-02-07. Подробнее в [документации ClickHouse®](https://clickhouse.com/docs/ru/sql-reference/data-types/datetime).

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

* Приведите все даты в базе-источнике к поддерживаемому в ClickHouse® диапазону.
* В [параметрах эндпоинта-источника](../operations/endpoint/index.md#update) исключите таблицу с некорректными датами из трансфера.
* В [параметрах трансфера](../operations/transfer.md#update) укажите трансформер [Преобразовать значения в строки](../concepts/data-transformation.md#convert-to-string). В этом случае при трансфере изменится тип поля.

### Нехватка ресурсов или растущая задержка передачи данных {#pod-restarted}

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

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

    ```text
    pod instance restarted
    ```

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

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

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

**Решение:**

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

Дополнительно в случае трансфера типа **Копирование** [активируйте](../operations/transfer.md#activate) его повторно. Трансферы других типов перезапустятся автоматически.

### Превышение количества блоков данных {#partition-blocks}

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

```text
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 ...
```

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

```text
pod instance restarted
```

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

**Решение:** увеличьте параметр `max_partitions_per_insert_block` для учетной записи, под которой трансфер подключается к приемнику. Для приемника Managed Service for ClickHouse® параметр можно изменить в [настройках пользователя](../../managed-clickhouse/concepts/settings-list.md#setting-partitions-per-insert-block). Для пользовательской инсталляции ClickHouse® можно создать профиль настроек и назначить его учетной записи:

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

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

### Не удалось найти ни одной таблицы {#no-tables}

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

```text
Unable to find any tables
```

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

**Решение:**

* Проверьте наличие таблиц. Убедитесь, что вы верно указали базу данных источника и в базе данных источника действительно есть таблицы, которые вы собираетесь переносить.

* Проверьте права пользователя. Подробнее о нужных правах и их назначении смотрите [Подготовка базы данных источника](../operations/endpoint/source/clickhouse.md#prepare).

### Не работает шардирование при трансфере из ClickHouse® в ClickHouse® {#ch-ch-no-sharding}

Для трансферов из ClickHouse® в ClickHouse® шардирование не поддерживается.

**Решение:**

Возможный обходной путь: создайте на кластере-приемнике распределенную таблицу и выполните трансфер в нее, выбрав политику очистки `Truncate` или `Не очищать`.


## MongoDB {#mongodb}

{% note warning %}

Для пользователей Yandex Cloud в [регионе Казахстан](../../overview/concepts/region.md) эндпоинты Data Transfer для баз данных MongoDB и Elasticsearch доступны только в пользовательской инсталляции. Сервисы управляемых баз данных для этих эндпоинтов не поддерживаются.

{% endnote %}

### Размер ключа коллекции превышает 5 МБ {#string-size}

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

```text
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 на размер пользовательских объектов.

**Решение:** [исключите](../operations/endpoint/source/mongodb.md) из трансфера коллекции, превышающие лимиты MongoDB, после чего [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Размер объекта в коллекции превышает 16 МБ {#object-size}

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

```text
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 на размер пользовательских объектов.

**Решение:** [исключите](../operations/endpoint/source/mongodb.md) из трансфера коллекции, превышающие лимиты MongoDB, после чего [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не удалось найти ни одной таблицы {#no-tables}

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

```text
Unable to find any tables
```

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

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

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

**Решение**: задайте в [параметре трансфера](../operations/transfer.md#update) **Настройки копирования** → **Настройки параллельного копирования** количество [воркеров](../concepts/index.md#worker), равное количеству переносимых коллекций.

### Ошибка при переносе коллекций timeseries {#timeseries}

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

```text
Unable to find any tables
```

```text
Cannot execute mongo activate hook: 
Failed in accordance with configuration: 
some tables from include list are missing in the source database: [<имя_коллекции>]
```

Сервис не поддерживает перенос коллекций `Time Series`.

**Решение:** [исключите](../operations/endpoint/source/mongodb.md#additional-settings) из трансфера коллекции Time Series, после чего [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не распознается IP-адрес или FQDN внешнего кластера {#cluster-config-issue}

Трансфер завершается с ошибкой:

```text
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 (Managed Service for MongoDB). Например, когда в описании шардов используются внутренние не разрешающиеся имена.

**Решение:** 

Убедитесь, что кластер MongoDB сконфигурирован таким образом, чтобы на запросы к нему он возвращал корректно разрешающиеся IP-адреса или FQDN (Fully Qualified Domain Name).

### Ошибка на стадии копирования данных {#history-lost}

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

```text
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 (Managed Service for MongoDB) превышает размер временного окна журнала операций (oplog). Текущий размер временного окна можно проверить в консоли управления на графике **Oplog window** [страницы мониторинга кластера](../../storedoc/operations/monitoring.md).


**Решение:**

* Увеличьте размер oplog (по умолчанию 5 % от размера диска кластера). Чтобы увеличить размер oplog в кластере-источнике Yandex StoreDoc, обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support). Чтобы изменить размер oplog в случае пользовательской инсталляции источника, смотрите документацию MongoDB.
* Включите [параллельное копирование данных](../concepts/sharded.md) для ускорения стадии копирования.
* Ограничьте список объектов для переноса в [настройках трансфера](../operations/transfer.md#create).

После этого [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Данные в источнике не подходят для шардирования {#cannot-get-delimiters}

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

```text
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` встречаются данные разных типов, и поэтому его нельзя использовать для шардирования.

**Решение**:

Укажите в [настройках трансфера](../operations/transfer.md#update-copy-repl) **Настройки копирования** → **Настройки параллельного копирования** 1 воркер и 1 поток, чтобы отключить шардирование.

После этого [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Прерывание трансфера с ошибкой: cursor.Decode returned error {#invalid-length}

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

```text
cursor.Decode returned error: invalid length
```

Такая ошибка может возникать при использовании типов бинарных данных `unsigned_byte(2) Binary` и `unsigned_byte(3) UUID`, которые в соответствии со [спецификацией BSON](https://bsonspec.org/spec.html) помечены как устаревшие (deprecated).

Пример использования типа `unsigned_byte(2) Binary`:

```text
Binary.createFromBase64('<строка в Base64>', 2)
```

**Решение:** Для корректной работы трансфера используйте бинарный подтип 0 вместо подтипа 2 и бинарный подтип 4 вместо подтипа 3.

Например, после замены выражения выше на `Binary.createFromBase64('<строка в Base64>', 0)` ошибка не возникает.

## MySQL® {#mysql}

### Размер лога одной транзакции превышает 4 ГБ {#binlog-size}

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

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

Если размер лога одной транзакции превышает 4 ГБ, активация трансферов _**Репликация**_ или _**Копирование и репликация**_ завершается ошибкой из-за [внутренних ограничений](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_max_binlog_cache_size) MySQL® на размер лога одной транзакции.

**Решение:** [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не добавляются новые таблицы {#no-new-tables}

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

**Решение:**

* [Деактивируйте](../operations/transfer.md#deactivate) и [активируйте](../operations/transfer.md#activate) трансфер повторно.
* Создайте таблицы в базе-приемнике вручную.
* [Создайте](../operations/transfer.md#create) отдельный трансфер типа _**Копирование**_ и добавьте в него только вновь созданные таблицы. При этом исходный трансфер типа _**Копирование и репликация**_ можно не деактивировать.

### Ошибка при трансфере из AWS RDS for MySQL® {#aws-binlog-time}

В трансферах типа _**Копирование и репликация**_ и _**Репликация**_ из источника [Amazon RDS for MySQL®](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html) может возникнуть ошибка загрузки таблиц.

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

```text
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.

**Решение:**

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

```sql
call mysql.rds_set_configuration('binlog retention hours', <количество_часов>);
```

Максимальное значение времени хранения — 168 ч (7 дней). Значение по умолчанию — `NULL` (файлы бинарного лога не сохраняются). Подробнее в [документации Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_set_configuration.html).

### Ошибка трансфера при переносе таблиц без первичных ключей {#primary-keys}

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

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

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

**Решение:** подготовьте источник в соответствии с разделом [Подготовка к трансферу](../operations/prepare.md).

### Ошибка обращения к бинарному логу {#binlog-bytes}

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

```text
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
```

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

**Решение:**

[Увеличьте](../../managed-mysql/operations/update.md#change-mysql-config) допустимый размер файлов бинарного лога в настройках MySQL® с помощью параметра [Mdb preserve binlog bytes](../../managed-mysql/concepts/settings-list.md#setting-mdb-preserve-binlog-bytes).

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

### Не удается получить позицию в бинарном логе {#binlog-position}

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

```text
unable to get binlog position: Storage <адрес_источника> is not master
```

Ошибка может возникнуть при активации трансферов с типами _**Репликация**_ и _**Копирование и репликация**_, если источником данных является пользовательская инсталляция MySQL® и в ней неправильно настроена репликация на основе позиции в бинарном лог-файле.

**Решение:**

Выполните проверки в MySQL®:

* Убедитесь, что в качестве источника репликации используется мастер.

* Убедитесь, что для параметра [log_bin](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#option_mysqld_log-bin) указан правильный путь к расположению бинарного лог-файла.

* Выведите информацию о бинарном логе с помощью запроса [SHOW MASTER STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-master-status.html) (для версий MySQL® 5.7 и 8.0) или [SHOW BINARY LOG STATUS](https://dev.mysql.com/doc/refman/8.4/en/show-binary-log-status.html) (для версии MySQL® 8.4). Запрос должен возвращать строку с информацией, а не пустой ответ.

### Ошибка удаления таблицы при политике очистки Drop {#drop-table-error}

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

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

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

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

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

**Решение:**

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

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

* Удалите блокирующие дочерние таблицы в базе-приемнике вручную.
* Используйте политику очистки `Truncate`.
* Пересоздайте базу в приемнике.

    {% note warning %}

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

    {% endnote %}

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

Сдвиг времени наблюдается, так как эндпоинт-источник применяет часовой пояс UTC+0 для данных с типом `DATETIME`. Подробнее читайте в разделе [Известные ограничения](../operations/endpoint/source/mysql.md#known-limitations).

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

### Не удалось найти ни одной таблицы {#no-tables}

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

```text
Unable to find any tables
```

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

**Решение:**

* Проверьте наличие таблиц. Убедитесь, что вы верно указали базу данных источника и в базе данных источника действительно есть таблицы, которые вы собираетесь переносить.

* Проверьте права пользователя. Подробнее о нужных правах и их назначении смотрите [Подготовка базы данных источника](../operations/endpoint/source/mysql.md#prepare).

## Object Storage {#object-storage}

### Ошибка при обновлении данных в источнике {#update-not-supported}

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

```text
Push failed: kind: update not supported
```

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

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

## OpenSearch {#opensearch}

### Прерывание трансфера с ошибкой {#ambiguous-resolution-os}

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

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

Index -1 out of bounds for length 0
```

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

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

**Решение:**

В [дополнительных настройках эндпоинта-приемника](../operations/endpoint/target/opensearch.md#additional-settings) включите опцию **Исправить невалидные ключи в документах** и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Превышение лимита максимального количества полей {#exceeding-fields-limit}

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

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

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

**Решение:** [увеличьте в базе данных приемника](../operations/endpoint/target/opensearch.md#prepare) максимальное количество полей с помощью параметра `index.mapping.total_fields.limit`.

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

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

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

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

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

1. Если значение ключа содержит `.`, она экранируется `\`: `some.key` --> `some\.key`.
1. Значения всех первичных ключей преобразуются в строку: `<some_key1>.<some_key2>.<...>`.
1. Полученная строка преобразуется функцией [url.QueryEscape](https://pkg.go.dev/net/url#QueryEscape).
1. Если длина итоговой строки не превышает 512 символов, то она используется в качестве `_id`. Если длина больше 512 символов, то она хешируется алгоритмом [SHA-1](https://datatracker.ietf.org/doc/html/rfc3174), и в качестве `_id` используется полученный хеш.

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

**Решение:**

1. Установите первичный ключ для одного или нескольких столбцов на источнике или в правилах конвертации эндпоинта.
1. [Запустите](../operations/transfer.md#activate) трансфер.

### Прерывание трансфера с ошибкой mapper_parsing_exception {#data-types}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### Ошибка SSL is required {#ssl-required}

Ошибка возникает при подключении к кластеру Managed Service for OpenSearch как к пользовательской инсталляции через [FQDN](../../managed-opensearch/concepts/network.md#hostname) хоста OpenSearch, если вы не включили опцию **SSL** в настройках эндпоинта. Кластер Managed Service for OpenSearch по умолчанию требует SSL-шифрование для подключений по FQDN хоста. 

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

**Решение:**

В настройках эндпоинта активируйте опцию **SSL**.

Для кластеров MDB и других источников, использующих сертификаты, выданные публичными CA, обычно не требуется загружать CA-сертификат.

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

### Не удалось найти ни одной таблицы {#no-tables}

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

```text
Unable to find any tables
```

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

**Решение:**

* Проверьте наличие индекса. Убедитесь, что вы верно указали название индекса и в источнике действительно есть индекс, который вы собираетесь переносить.

* Убедитесь, что пользователь имеет нужные права для работы с индексом.

## PostgreSQL {#postgresql}

### Не удалось найти ни одной таблицы {#no-tables}

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

```text
Unable to find any tables
```

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

**Решение:**

* Проверьте наличие таблиц. Убедитесь, что вы верно указали базу данных источника и в базе данных источника действительно есть таблицы, которые вы собираетесь переносить.

* Проверьте права пользователя. Подробнее о нужных правах и их назначении — [Подготовка базы данных источника](../operations/endpoint/source/postgresql.md#prepare).

### Остановка сессии мастер-транзакции трансфера {#master-trans-stop}

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

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

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

* На источнике работает cron-задание или другое приложение, которое периодически завершает слишком длительные сессии.
* Кто-то вручную завершил мастер-транзакцию.
* Ресурсов CPU на источнике не хватает для выполнения запроса.
* В настройке кластера PostgreSQL [Session duration timeout](../../managed-postgresql/concepts/settings-list.md#setting-session-duration-timeout) установлено ограничение на время жизни активной сессии.

**Решение:** отключите такое cron-задание, добавьте дополнительные ресурсы для CPU на источник, а также установите значение параметра **Session duration timeout** равным `0` на время трансфера. После внесения изменений [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Превышение квоты на длительность соединения {#conn-duration-quota}

В Yandex Managed Service for PostgreSQL существует квота на длительность соединения — 12 часов.
​
​**Решение:** если перенос базы данных требует больше времени, [измените настройку кластера](../../managed-postgresql/operations/update.md#change-postgresql-config) Yandex Managed Service for PostgreSQL [Session duration timeout](../../managed-postgresql/concepts/settings-list.md#setting-session-duration-timeout).

### Превышение количества подключений к базе данных {#conn-limit}

В PostgreSQL есть [ограничение на количество подключений пользователя](../../managed-postgresql/concepts/settings-list.md#setting-conn-limit) к базе данных. Если для трансфера количество подключений превышает это ограничение, то трансфер будет работать неправильно или не будет работать вовсе.

**Решение**: настройте [количество подключений пользователя](../concepts/work-with-endpoints.md#postgresql-connection-limit) к базе данных.

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

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

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

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

**Решение:** вручную исключите из трансфера все представления, записав их в [параметре эндпоинта-источника](../operations/endpoint/source/postgresql.md#additional-settings) **Фильтр таблиц** → **Список исключённых таблиц**, после чего [активируйте](../operations/transfer.md#activate) трансфер повторно.

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

**Решение:** подготовьте источник в соответствии с разделом [Подготовка к трансферу](../operations/prepare.md#source-pg).

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

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

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

Трансфер прерывается при указании списка таблиц определенной схемы в виде `<схема>.*`. Это происходит из-за особенностей работы утилиты `pg_dump`, которая используется для переноса схемы. При указании таблиц всей схемы `<схема>.*` в [параметре эндпоинта-источника](../operations/endpoint/source/postgresql.md#additional-settings) **Фильтр таблиц** → **Список включенных таблиц** типы PostgreSQL из этой схемы не извлекаются, даже если в схеме есть таблицы, зависящие от этих типов.

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

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

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

```text
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`, чтобы трансфер не удалил эти объекты.

### Низкая скорость трансфера  {#low-speed}

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

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

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

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

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

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

    Параллельность доступна только для таблиц, которые содержат первичный ключ. При использовании ключа [типа `serial`](https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-SERIAL) части таблиц читаются по диапазонам. Другие типы ключей позволяют равномерно распределять таблицы в соответствии со специальным алгоритмом.

    **Решение:** настройте [параллельное копирование](../concepts/sharded.md) и [активируйте трансфер](../operations/transfer.md#activate) повторно.

### Не переносятся таблицы-наследники {#successor-tables}

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

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

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

Для увеличения скорости трансфера при переносе таблиц-наследников настройте [параллельное копирование](../concepts/sharded.md).

### Не хватает слотов репликации в базе данных источника {#replication-slots}

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

```text
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)
```

**Решение:** увеличьте количество [слотов репликации](https://www.postgresql.org/docs/current/logical-replication-config.html) в базе-источнике (по умолчанию `10`).

### Перестали переноситься данные после изменения эндпоинта-источника {#no-data-transfer}

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

**Решение:**

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

    1\. Создайте в базе-приемнике новые таблицы с `Primary Key` и без `Foreign key`.
    2\. Добавьте новые таблицы в **Список включенных таблиц** в [параметрах эндпоинта-источника](../operations/endpoint/source/postgresql.md#additional-setting).
    3\. Перенесите дамп с историческими данными в базу-приемник.
    4\. При появлении в логах ошибок решите их согласно конкретной ошибке.
    5\. Если ошибок нет, но логи пусты, обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support) или к вашему аккаунт-менеджеру для снятия дампа горутин. Это может помочь восстановить репликацию без повторного запуска трансфера.

* [Деактивируйте](../operations/transfer.md#deactivate) и [активируйте](../operations/transfer.md#activate) трансфер повторно.
* [Создайте](../operations/transfer.md#create) отдельный трансфер типа _**Копирование**_ для новых таблиц. При этом исходный трансфер можно не деактивировать.

### Ошибка трансфера при смене хоста-мастера {#master-change}

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

**Решение:** увеличьте лимит в [дополнительном параметре эндпоинта-источника](../operations/endpoint/source/postgresql.md#additional-setting) **Максимальный размер WAL для слота репликации** и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не хватает истории в WAL для продолжения репликации при смене хоста-мастера {#no-wal-story}

При смене хоста-мастера в кластере-источнике трансферы типа _**Репликация**_ или _**Копирование и репликация**_ могут завершиться ошибкой:

```text
ERROR: requested WAL segment pg_wal/0000000E0000022700000087 has already been removed (SQLSTATE 58P01)
```

Ошибка возникает, если хранимой в [WAL](https://www.postgresql.org/docs/current/wal-intro.html) на новом мастере истории недостаточно для продолжения репликации с того же места.

**Решение**: увеличьте в кластере-источнике значение [настройки](../../managed-postgresql/concepts/settings-list.md#setting-wal-keep-size) `Wal keep size`. В качестве минимального значения рекомендуется взять среднее значение из графика **Source buffer size** в [мониторинге Data Transfer](../operations/monitoring.md). Если на диске достаточно свободных ресурсов, укажите значение настройки с запасом.

### Ошибка при трансфере вложенных транзакций {#inner-tables}

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

**Решение:**

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

### Ошибка трансфера таблиц с отложенными ограничениями {#deferrable-constr}

Ошибка возникает в трансферах типа **Репликация** или **Копирование и репликация**, так как обновление таблиц и транзакций с отложенными (`DEFERRABLE`) ограничениями не поддерживается Data Transfer. Подробнее об отложенных ограничениях в [документации PostgreSQL](https://www.postgresql.org/docs/current/sql-set-constraints.html).

**Решение:** замените тип ограничений в таких таблицах на `IMMEDIATE` и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Не удается создать слот репликации на стадии активации {#lock-replication}

В начале работы трансфера создается один или несколько [слотов репликации](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS) в базе-источнике. При этом объекты базы блокируются. Если какой-то объект заблокирован другой транзакцией, возникнет конкурирующая блокировка, и трансфер завершится с ошибкой.

**Решение:**

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

   ```sql
   SELECT
     activity.pid,
     activity.usename,
     activity.query,
     blocking.pid AS blocking_id,
     blocking.query AS blocking_query
   FROM
     pg_stat_activity AS activity
     JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(
       pg_blocking_pids(activity.pid)
     )
   WHERE
     activity.query like '%<идентификатор_трансфера>%';
   ```

   Идентификатор трансфера можно получить со [списком трансферов в каталоге](../operations/transfer.md#list).

   Ответ:

   ```text
          pid      |      usename       |      query      |         blocking_id          |    blocking_query
   ----------------+--------------------+-----------------+------------------------------+----------------------
   <PID_трансфера> | <имя_пользователя> | <текст_запроса> | <PID_блокирующей_транзакции> | <блокирующий_запрос>
   (1 row)
   ```

1. Остановите транзакцию командой:

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

1. [Активируйте трансфер](../operations/transfer.md#activate) повторно.

### Чрезмерное увеличение журнала WAL {#excessive-wal}

Рост журнала WAL может происходить при работе трансферов типов **Копирование и репликация** и **Репликация**. Увеличение размера WAL можно заметить по:

* увеличению занятого места на диске кластера-источника (график **Disk usage on primary**);
* увеличению объема WAL-файлов на кластере-источнике (график **Total size of WAL files**);
* росту на графиках **[Source buffer size](../operations/monitoring.md#publisher.consumer.log_usage_bytes)** или **[Maximum data transfer delay](../operations/monitoring.md#sinker.pusher.time.row_max_lag_sec)** в мониторинге Data Transfer.

**Решение:**

Действуйте в зависимости от текущей стадии трансфера:

   Стадия трансфера | Причина роста WAL | Рекомендуемое действие                                                                            
   --------|-----|---------------------------------------------------------
   Копирование | Рост WAL ожидаем.  |  Дождитесь перехода трансфера на стадию репликации.                          
   Репликация | В базе-источнике присутствуют долгие транзакции (выполняющиеся более 5 минут). Такие запросы вызывают рост журнала WAL и мешают его архивации. | Дождитесь завершения транзакции или завершите сессии самостоятельно. Найти долгие транзакции можно с помощью запроса:<br>```SELECT pid, now() - pg_stat_activity.query_start```<br>```AS duration, query, state```<br>```FROM pg_stat_activity```<br>```WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes'```<br>```AND state != 'idle';```
   Репликация | На источнике наблюдается большой поток изменений, который трансфер не успевает обрабатывать. | [Проверьте](../metrics.md) утилизацию ресурсов трансфера. Если ресурсы утилизированы полностью, то увеличьте их, уменьшите количество потоков или разделите один трансфер на несколько трансферов. [Проверьте](../metrics.md) утилизацию ресурсов источника и приемника. Если ресурсы утилизированы полностью, то увеличьте их.
   Репликация | На источнике в переносимых объектах была изменена схема (добавлены или удалены поля в таблицах, изменены типы и т.п.). Данные перестали записываться в приемник из-за несоответствия схем. | Самостоятельно повторите изменения схемы на приемнике.

### Ошибка при репликации из внешнего источника {#external-replication}

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

```text
[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
```

**Решение:** подготовьте источник в соответствии с разделом [Подготовка к трансферу](../operations/prepare.md#source-pg).

### Ошибка трансфера при переносе таблиц без первичных ключей {#primary-keys}

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

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

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

**Решение:** подготовьте источник в соответствии с разделом [Подготовка к трансферу](../operations/prepare.md).

### Повторяющееся значение ключа нарушает уникальное ограничение {#duplicate-key}

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

```text
ERROR: duplicate key value violates unique constraint "<название_ограничения>" (SQLSTATE 23505)
```

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

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

* Для эндпоинта-приемника [включите расширенную настройку](../operations/endpoint/target/postgresql.md#additional-settings) **Сохранение границ транзакций**. Data Transfer откроет транзакцию, применит пришедшие события, но выполнит коммит транзакции, только когда начнет получать данные следующей транзакции.

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

* Отключите в базе-приемнике ограничения. В определенный момент времени возможно нарушение ограничений (например, когда применена часть транзакции из базы-источника в базе-приемнике). Но Data Transfer гарантирует согласованность данных в итоге (eventually consistency) — когда вторая часть транзакции применится в базе-приемнике, нарушения ограничений не будет.

### Ошибка удаления таблицы при политике очистки Drop {#drop-table-error}

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

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

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

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

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

**Решение:**

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

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

* Удалите блокирующие дочерние таблицы в базе-приемнике вручную.
* Используйте политику очистки `Truncate`.
* Пересоздайте базу в приемнике.

    {% note warning %}

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

    {% endnote %}

### Ошибка при переносе таблиц с генерируемыми столбцами {#generated-columns}

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

```text
ERROR: column "<имя_столбца>" is a generated column (SQLSTATE 42P10)
```

Ошибка может возникнуть, если из базы-источника переносится таблица, которая содержит генерируемые столбцы. Например, если генерируемый столбец определен как столбец идентификаторов (`GENERATED ... AS IDENTITY`), то ошибка возникнет при репликации данных. Если генерируемый столбец вычисляемый, то ошибка возникнет независимо от типа трансфера. Подробнее о генерируемых столбцах в [документации PostgreSQL](https://www.postgresql.org/docs/current/ddl-generated-columns.html).

**Решение**: в [параметрах эндпоинта-источника](../operations/endpoint/source/postgresql.md#additional-settings) исключите из трансфера таблицы, которые содержат генерируемые столбцы.

## Yandex Managed Service for YDB {#ydb}

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

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

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

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

Трансфер прерывается из-за ограничения облачной [квоты](https://kz.console.yandex.cloud/cloud?section=quotas) на количество операций с Managed Service for YDB.

**Решение:**

1. Увеличьте в [квотах Managed Service for YDB](../../ydb/concepts/limits.md) на облако с нужной базой данных значение характеристики **Количество схемных операций в минуту** и [активируйте](../operations/transfer.md#activate) трансфер повторно.

## Yandex Data Streams {#yds}

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

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

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

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

Трансфер прерывается из-за ограничения облачной [квоты](https://kz.console.yandex.cloud/cloud?section=quotas) на количество операций с Managed Service for YDB.

**Решение:**

1. Увеличьте в [квотах Managed Service for YDB](../../ydb/concepts/limits.md) на облако с нужной базой данных значение характеристики **Количество схемных операций в минуту** и [активируйте](../operations/transfer.md#activate) трансфер повторно.

### Редиректы Cloud Functions {#redirects}

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

```text
redirect to SOME_URL is requested but no redirects are allowed.
```

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

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

**Решение:**

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


## Greenplum® {#greenplum}

### Почему я не могу задать количество потоков больше N в трансфере из Greenplum® в Greenplum®? {#threads_limit}

Если в трансфере из Greenplum® в Greenplum® не используется прямое чтение с сегментов, количество потоков не может превышать минимальное число сегментов в участвующих кластерах.

[Подробнее об особенностях работы с источником Greenplum®](../operations/endpoint/source/greenplum.md#advanced).

### Ошибка external table has more URLs than segments {#external_table_url_limit}

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

```pgsql
Unable to select and insert with external WRITABLE table: ERROR: external table has more URLs than available primary segments that can write into them
```

Ошибка возникает, если заданное количество потоков больше количества таблиц.

**Решение:** задайте количество потоков, не превышающее количество таблиц.

### Как узнать количество сегментов в кластере? {#gp_segment_configuration}

Вы можете узнать количество сегментов:

* В [консоли управления](https://kz.console.yandex.cloud). Для этого откройте нужный кластер и перейдите на вкладку ![hosts.svg](../../_assets/console-icons/cube.svg) **Хосты**.

* При помощи SQL-запроса:

  ```pgsql
  SELECT COUNT(*) FROM gp_segment_configuration WHERE role='p' AND content >= 0;
  ```

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

Если проблему не удалось решить с помощью приведенных советов, обратитесь в [техническую поддержку](https://kz.center.yandex.cloud/support).

_ClickHouse® является зарегистрированным товарным знаком [ClickHouse, Inc](https://clickhouse.com)._