Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Data Transfer
  • Доступные трансферы
  • Начало работы
    • Все инструкции
    • Подготовка к трансферу
      • Управление эндпоинтами
      • Миграция эндпоинтов в другую зону доступности
        • Источник
        • Приемник
    • Управление трансфером
    • Работа с базами данных во время трансфера
    • Мониторинг состояния трансфера
  • Решение проблем
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • Обучающие курсы

В этой статье:

  • Сценарии передачи данных в MySQL®
  • Настройка источника данных
  • Подготовка базы данных приемника
  • Настройка эндпоинта-приемника MySQL®
  • Кластер Managed Service for MySQL®
  • Пользовательская инсталляция
  • Дополнительные настройки
  • Действия с базой данных во время трансфера
  • Решение проблем, возникающих при переносе данных
  • Размер лога одной транзакции превышает 4 ГБ
  • Не добавляются новые таблицы
  • Ошибка при трансфере из AWS RDS for MySQL®
  • Ошибка трансфера при переносе таблиц без первичных ключей
  • Ошибка обращения к бинарному логу
  • Не удается получить позицию в бинарном логе
  • Ошибка удаления таблицы при политике очистки Drop
  • Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®
  1. Пошаговые инструкции
  2. Настройка эндпоинтов
  3. MySQL
  4. Приемник

Передача данных в эндпоинт-приемник MySQL®

Статья создана
Yandex Cloud
Улучшена
Dmitry A.
Обновлена 10 апреля 2025 г.
  • Сценарии передачи данных в MySQL®
  • Настройка источника данных
  • Подготовка базы данных приемника
  • Настройка эндпоинта-приемника MySQL®
    • Кластер Managed Service for MySQL®
    • Пользовательская инсталляция
    • Дополнительные настройки
  • Действия с базой данных во время трансфера
  • Решение проблем, возникающих при переносе данных
    • Размер лога одной транзакции превышает 4 ГБ
    • Не добавляются новые таблицы
    • Ошибка при трансфере из AWS RDS for MySQL®
    • Ошибка трансфера при переносе таблиц без первичных ключей
    • Ошибка обращения к бинарному логу
    • Не удается получить позицию в бинарном логе
    • Ошибка удаления таблицы при политике очистки Drop
    • Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®

С помощью сервиса Yandex Data Transfer вы можете переносить данные в базу MySQL® и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:

  1. Ознакомьтесь с возможными сценариями передачи данных.
  2. Настройте один из поддерживаемых источников данных.
  3. Подготовьте базу данных MySQL® к трансферу.
  4. Настройте эндпоинт-приемник в Yandex Data Transfer.
  5. Создайте и запустите трансфер.
  6. Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
  7. При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.

Сценарии передачи данных в MySQL®Сценарии передачи данных в MySQL®

  1. Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.

    • Миграция кластера MySQL®;
    • Миграция со сменой хранилища: PostgreSQL в MySQL®.
    • Миграция со сменой хранилища: Object Storage в MySQL®.
  2. Поставка данных — процесс доставки произвольных данных в целевые хранилища. Процесс поставки включает извлечение данных из очереди и их десериализацию с последующей трансформацией данных в формат целевого хранилища.

    • Поставка данных из Apache Kafka® в MySQL®.

Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.

Настройка источника данныхНастройка источника данных

Настройте один из поддерживаемых источников данных:

  • PostgreSQL;
  • MySQL®;
  • Apache Kafka®;
  • Airbyte®;
  • YDS;
  • Yandex Object Storage;
  • Managed Service for YDB.

Подготовка базы данных приемникаПодготовка базы данных приемника

Managed Service for MySQL®
MySQL®
  1. Убедитесь, что мажорная версия MySQL® на приемнике не ниже версии на источнике.

  2. Установите SQL Mode, который совпадает с источником.

  3. Создайте пользователя для подключения к приемнику.

    1. Назначьте пользователю роль ALL_PRIVILEGES для базы-приемника.
  1. Если вы не планируете использовать для подключения к внешнему кластеру сервис Cloud Interconnect или VPN, разрешите подключения к такому кластеру из интернета с IP-адресов, используемых сервисом Data Transfer.

    Подробнее о настройке сети для работы с внешними ресурсами см. в концепции.

  2. Убедитесь, что мажорная версия MySQL® на приемнике не ниже версии на источнике.

  3. Убедитесь, что приемник использует подсистему хранения данных низкого уровня MyISAM или InnoDB.

  4. Установите SQL Mode, который совпадает с источником.

  5. Создайте пользователя для подключения к приемнику и выдайте ему необходимые привилегии:

    CREATE USER '<имя_пользователя>'@'%' IDENTIFIED BY '<пароль>';
    GRANT ALL PRIVILEGES ON <имя_базы>.* TO '<имя_пользователя>'@'%';
    

Настройка эндпоинта-приемника MySQL®Настройка эндпоинта-приемника MySQL®

При создании или изменении эндпоинта вы можете задать:

  • Настройки подключения к кластеру Yandex Managed Service for MySQL® или пользовательской инсталляции, в т. ч. на базе виртуальных машин Yandex Compute Cloud. Эти параметры обязательные.
  • Дополнительные параметры.

Кластер Managed Service for MySQL®Кластер Managed Service for MySQL®

Важно

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

Подключение к БД с указанием идентификатора кластера в Yandex Cloud.

Консоль управления
CLI
Terraform
API
  • Тип подключения — выберите вариант подключения к базе данных:

    • Ручная настройка — позволяет задать настройки подключения вручную.

      Выберите тип инсталляции Кластер Managed Service for MySQL и задайте настройки:

      • Кластер Managed Service for MySQL — укажите идентификатор кластера, к которому необходимо подключиться.

      • База данных — укажите имя базы данных в выбранном кластере.

      • Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.

      • Пароль — укажите пароль пользователя для доступа к базе данных.

    • Connection Manager — позволяет использовать управляемое подключение к базе данных через Yandex Connection Manager:

      • Выберите каталог, в котором находится кластер Managed Service for MySQL®.

      • Выберите тип инсталляции Кластер управляемой БД и задайте настройки:

        • Кластер Managed Service for MySQL — укажите идентификатор кластера, к которому необходимо подключиться.

        • Подключение — укажите идентификатор управляемого подключения в Connection Manager.

        • База данных — укажите имя базы данных в выбранном кластере.

      Важно

      Чтобы использовать подключение из Connection Manager, у пользователя должны быть права доступа не ниже connection-manager.user к этому подключению.

  • Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.

    Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.

  • Тип эндпоинта — mysql-target.
  • --cluster-id — идентификатор кластера, к которому необходимо подключиться.

  • --database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

  • --user — имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.

  • Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:

    • --raw-password — пароль в текстовом виде.

    • --password-file — путь к файлу с паролем.

  • Тип эндпоинта — mysql_target.
  • security_groups — группы безопасности для сетевого трафика.

    Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к кластеру. Подробнее см. в разделе Сеть в Yandex Data Transfer.

    Группы безопасности должны принадлежать той же сети, в которой размещен кластер.

    Примечание

    В Terraform сеть для групп безопасности задавать не нужно.

  • connection.mdb_cluster_id — идентификатор кластера, к которому необходимо подключиться.

  • database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

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

  • password.raw — пароль в текстовом виде.

Пример структуры конфигурационного файла:

resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
  name = "<имя_эндпоинта>"
  settings {
    mysql_target {
      security_groups = ["<список_идентификаторов_групп_безопасности>"]
      connection {
        mdb_cluster_id = "<идентификатор_кластера>"
      }
      database = "<имя_переносимой_базы_данных>"
      user     = "<имя_пользователя_для_подключения>"
      password {
        raw = "<пароль_пользователя>"
      }
      <дополнительные_настройки_эндпоинта>
    }
  }
}

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

  • securityGroups — группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer.

  • mdbClusterId — идентификатор кластера, к которому необходимо подключиться.

  • database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

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

  • password.raw — пароль пользователя для доступа к базе данных (в текстовом виде).

Пользовательская инсталляцияПользовательская инсталляция

Для случая OnPremise все поля заполняются вручную.

Консоль управления
CLI
Terraform
API
  • Тип подключения — выберите вариант подключения к базе данных:

    • Ручная настройка — позволяет задать настройки подключения вручную.

      Выберите тип инсталляции Пользовательская инсталляция и задайте настройки:

      • Хост — укажите IP-адрес или FQDN хоста, к которому необходимо подключиться.

      • Порт — укажите номер порта, который сервис Data Transfer будет использовать для подключения.

      • База данных — укажите имя базы данных в пользовательской инсталляции.

      • Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.

      • Пароль — укажите пароль пользователя для доступа к базе данных.

      • Сертификат CA — загрузите файл сертификата или добавьте его содержимое в текстовом виде, если требуется шифрование передаваемых данных, например, для соответствия требованиям PCI DSS.

        Важно

        Если не добавить сертификат, трансфер может завершиться ошибкой.

      • Идентификатор подсети — выберите или создайте подсеть в нужной зоне доступности. Трансфер будет использовать эту подсеть для доступа к источнику.

        Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.

    • Connection Manager — позволяет использовать управляемое подключение к базе данных через Yandex Connection Manager:

      • Выберите каталог, в котором создано управляемое подключение Connection Manager.

      • Выберите тип инсталляции Пользовательская инсталляция и задайте настройки:

        • Подключение — укажите идентификатор управляемого подключения в Connection Manager.

        • База данных — укажите имя базы данных в пользовательской инсталляции.

        • Идентификатор подсети — выберите или создайте подсеть в нужной зоне доступности. Трансфер будет использовать эту подсеть для доступа к источнику.

          Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.

      Важно

      Чтобы использовать подключение из Connection Manager, у пользователя должны быть права доступа не ниже connection-manager.user к этому подключению.

  • Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.

    Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в Yandex Data Transfer.

  • Тип эндпоинта — mysql-target.
  • --host — IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться.

  • --port — номер порта, который сервис Data Transfer будет использовать для подключения.

  • --ca-certificate — сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS.

    Важно

    Если не добавить сертификат, трансфер может завершиться ошибкой.

  • --subnet-id — идентификатор подсети, в которой находится хост. Трансфер будет использовать эту подсеть для доступа к хосту.

  • --database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

  • --user — имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.

  • Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:

    • --raw-password — пароль в текстовом виде.

    • --password-file — путь к файлу с паролем.

  • Тип эндпоинта — mysql_target.
  • security_groups — группы безопасности для сетевого трафика.

    Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к ВМ c базой данных. Подробнее см. в разделе Сеть в Yandex Data Transfer.

    Группы безопасности должны принадлежать той же сети, что и подсеть subnet_id, если она указана.

    Примечание

    В Terraform сеть для групп безопасности задавать не нужно.

  • on_premise.hosts — список IP-адресов или FQDN хостов, к которым необходимо подключиться. Так как поддерживается только список из одного элемента, укажите адрес хоста-мастера.

  • on_premise.port — номер порта, который сервис Data Transfer будет использовать для подключения.

  • on_premise.tls_mode.enabled.ca_certificate — сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS.

    Важно

    Если не добавить сертификат, трансфер может завершиться ошибкой.

  • on_premise.subnet_id — идентификатор подсети, в которой находится хост. Трансфер будет использовать эту подсеть для доступа к хосту.

  • database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

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

  • password.raw — пароль в текстовом виде.

Пример структуры конфигурационного файла:

resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
  name = "<имя_эндпоинта>"
  settings {
    mysql_target {
      security_groups = ["<список_идентификаторов_групп_безопасности>"]
      connection {
        on_premise {
          hosts = ["<список_хостов>"]
          port  = <порт_для_подключения>
        }
      }
      database = "<имя_переносимой_базы_данных>"
      user     = "<имя_пользователя_для_подключения>"
      password {
        raw = "<пароль_пользователя>"
      }
      <дополнительные_настройки_эндпоинта>
    }
  }
}

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

  • onPremise — параметры подключения к базе данных:
    • hosts — IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться.

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

    • tlsMode — параметры шифрования передаваемых данных, если оно требуется, например для соответствия требованиям PCI DSS.

      • disabled — отключено.
      • enabled — включено
        • caCertificate — сертификат CA.

          Важно

          Если не добавить сертификат, трансфер может завершиться ошибкой.

    • subnetId — идентификатор подсети, в которой находится хост. Трансфер будет использовать эту подсеть для доступа к хосту.

  • securityGroups — группы безопасности для сетевого трафика, правила которых применятся к ВМ и кластерам без изменения их настроек. Подробнее см. в разделе Сеть в Yandex Data Transfer.

  • database — имя базы данных. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.

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

  • password.raw — пароль пользователя для доступа к базе данных (в текстовом виде).

Дополнительные настройкиДополнительные настройки

Важно

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

Консоль управления
CLI
Terraform
API
  • Политика очистки — выберите способ очистки данных в базе-приемнике перед переносом:

    • Не очищать — выберите эту опцию, если будет производиться только репликация без копирования данных.

    • Drop — полное удаление таблиц, участвующих в трансфере (вариант по умолчанию).

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

    • Truncate — удалить только данные из таблиц, участвующих в трансфере, но оставить схему.

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

  • Расширеннные настройки:

    • Часовой пояс для подключения к базе данных — укажите идентификатор IANA Time Zone Database. По умолчанию используется локальная таймзона сервера.

    • Режимы работы SQL — укажите настройки, переопределяющие стандартное поведение MySQL®.

    • Отключение проверки ограничений — используется для ускорения репликации: настройки FOREIGN_KEY_CHECKS и UNIQUE_CHECKS устанавливаются в значение 0 (проверки не производятся).

      Важно

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

    • Схема базы данных для служебных таблиц — укажите имя схемы, в которой будут созданы служебные таблицы, необходимые для обеспечения работы трансфера.

  • --sql-mode — укажите настройки, переопределяющие стандартное поведение MySQL®

  • --skip-constraint-checks — используется для ускорения репликации: настройки FOREIGN_KEY_CHECKS и UNIQUE_CHECKS устанавливаются в значение 0 (проверки не производятся).

    Важно

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

  • --timezone — укажите идентификатор IANA Time Zone Database. По умолчанию используется UTC+0.

  • sql_mode — укажите настройки, переопределяющие стандартное поведение MySQL®. По умолчанию используется список NO_AUTO_VALUE_ON_ZERO,NO_DIR_IN_CREATE,NO_ENGINE_SUBSTITUTION.

  • skip_constraint_checks — используется для ускорения репликации: настройки FOREIGN_KEY_CHECKS и UNIQUE_CHECKS устанавливаются в значение 0 (проверки не производятся).

    Важно

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

  • timezone — укажите идентификатор IANA Time Zone Database. По умолчанию используется UTC+0.

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

  • sqlMode — укажите настройки, переопределяющие стандартное поведение MySQL®

  • skipConstraintChecks — используется для ускорения репликации: настройки FOREIGN_KEY_CHECKS и UNIQUE_CHECKS устанавливаются в значение 0 (проверки не производятся).

    Важно

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

  • timezone — укажите идентификатор IANA Time Zone Database. По умолчанию используется UTC+0.

После настройки источника и приемника данных создайте и запустите трансфер.

Действия с базой данных во время трансфераДействия с базой данных во время трансфера

  • Для трансферов в статусе Копируется любые изменения схемы данных (ALTER) на источнике или приемнике прервут трансфер.

  • Для трансферов в статусе Реплицируется схему данных на источнике можно изменять. Все операции ALTER, попавшие в бинарный лог (binlog) на источнике, автоматически применятся на приемнике. Этот процесс занимает некоторое время, поэтому трансфер может замедлиться.

Решение проблем, возникающих при переносе данныхРешение проблем, возникающих при переносе данных

Известные проблемы, связанные с использованием эндпоинта MySQL®:

  • Размер лога одной транзакции превышает 4 ГБ
  • Не добавляются новые таблицы
  • Ошибка при трансфере из AWS RDS for MySQL®
  • Ошибка трансфера при переносе таблиц без первичных ключей
  • Ошибка обращения к бинарному логу
  • Не удается получить позицию в бинарном логе
  • Ошибка удаления таблицы при политике очистки Drop
  • Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®

См. полный список рекомендаций в разделе Решение проблем.

Размер лога одной транзакции превышает 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 ГБайт).

Не удается получить позицию в бинарном логеНе удается получить позицию в бинарном логе

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

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

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

Решение:

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

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

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

  • Выведите информацию о бинарном логе с помощью запроса SHOW MASTER STATUS (для версий MySQL® 5.7 и 8.0) или SHOW BINARY LOG STATUS (для версии MySQL® 8.4). Запрос должен возвращать строку с информацией, а не пустой ответ.

Ошибка удаления таблицы при политике очистки 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. Подробнее см. в разделе Известные ограничения.

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

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

Была ли статья полезна?

Предыдущая
Источник
Следующая
Источник
Проект Яндекса
© 2025 ООО «Яндекс.Облако»