Передача данных в эндпоинт-приемник MySQL®
- Сценарии передачи данных в MySQL®
- Настройка источника данных
- Подготовка базы данных приемника
- Настройка эндпоинта-приемника MySQL®
- Действия с базой данных во время трансфера
- Решение проблем, возникающих при переносе данных
- Размер лога одной транзакции превышает 4 ГБ
- Не добавляются новые таблицы
- Ошибка при трансфере из AWS RDS for MySQL®
- Ошибка трансфера при переносе таблиц без первичных ключей
- Ошибка обращения к бинарному логу
- Ошибка удаления таблицы при политике очистки Drop
- Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®
С помощью сервиса Yandex Data Transfer вы можете переносить данные в базу MySQL® и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:
- Ознакомьтесь с возможными сценариями передачи данных.
- Настройте один из поддерживаемых источников данных.
- Подготовьте базу данных MySQL® к трансферу.
- Настройте эндпоинт-приемник в Yandex Data Transfer.
- Создайте и запустите трансфер.
- Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
- При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.
Сценарии передачи данных в MySQL®
-
Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.
-
Поставка данных — процесс доставки произвольных данных в целевые хранилища. Процесс поставки включает извлечение данных из очереди и их десериализацию с последующей трансформацией данных в формат целевого хранилища.
Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.
Настройка источника данных
Настройте один из поддерживаемых источников данных:
Подготовка базы данных приемника
-
Убедитесь, что мажорная версия MySQL® на приемнике не ниже версии на источнике.
-
Установите SQL Mode, который совпадает с источником.
-
Создайте пользователя для подключения к приемнику.
- Назначьте пользователю роль
ALL_PRIVILEGES
для базы-приемника.
- Назначьте пользователю роль
-
Если вы не планируете использовать для подключения к внешнему кластеру сервис Cloud Interconnect или VPN, разрешите подключения к такому кластеру из интернета с IP-адресов, используемых сервисом Data Transfer
.Подробнее о настройке сети для работы с внешними ресурсами см. в концепции.
-
Убедитесь, что мажорная версия MySQL® на приемнике не ниже версии на источнике.
-
Убедитесь, что приемник использует подсистему хранения данных низкого уровня MyISAM или InnoDB.
-
Установите SQL Mode
, который совпадает с источником. -
Создайте пользователя для подключения к приемнику и выдайте ему необходимые привилегии:
CREATE USER '<имя_пользователя>'@'%' IDENTIFIED BY '<пароль>'; GRANT ALL PRIVILEGES ON <имя_базы>.* TO '<имя_пользователя>'@'%';
Настройка эндпоинта-приемника MySQL®
При создании или изменении эндпоинта вы можете задать:
- Настройки подключения к кластеру Yandex Managed Service for MySQL® или пользовательской инсталляции, в т. ч. на базе виртуальных машин Yandex Compute Cloud. Эти параметры обязательные.
- Дополнительные параметры.
Кластер Managed Service for MySQL®
Важно
Для создания или редактирования эндпоинта управляемой базы данных вам потребуется роль managed-mysql.viewer
или примитивная роль viewer
, выданная на каталог кластера этой управляемой базы данных.
Подключение к БД с указанием идентификатора кластера в Yandex Cloud.
-
Кластер Managed Service for MySQL — укажите идентификатор кластера, к которому необходимо подключиться.
-
База данных — укажите имя базы данных в выбранном кластере. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в 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 все поля заполняются вручную.
-
Хост — укажите IP-адрес или FQDN хоста, к которому необходимо подключиться.
-
Порт — укажите номер порта, который сервис Data Transfer будет использовать для подключения.
-
Сертификат CA — загрузите файл сертификата или добавьте его содержимое в текстовом виде, если требуется шифрование передаваемых данных, например, для соответствия требованиям PCI DSS
. -
Идентификатор подсети — выберите или создайте подсеть в нужной зоне доступности. Трансфер будет использовать эту подсеть для доступа к приемнику.
Если значение в этом поле задано для обоих эндпоинтов, то обе подсети должны быть размещены в одной зоне доступности.
-
База данных — укажите имя базы данных в выбранном кластере. Оставьте поле пустым, если хотите создать таблицы в базах данных с теми же именами, что и на источнике. В этом случае явно задайте схему БД для служебных таблиц в дополнительных настройках.
-
Пользователь — укажите имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных.
-
Пароль — укажите пароль пользователя для доступа к базе данных.
-
Группы безопасности — выберите облачную сеть для размещения эндпоинта и группы безопасности для сетевого трафика.
Это позволит применить к ВМ и кластерам в выбранной сети указанные правила групп безопасности без изменения настроек этих ВМ и кластеров. Подробнее см. в разделе Сеть в 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
— пароль пользователя для доступа к базе данных (в текстовом виде).
Дополнительные настройки
Важно
Настройки Политика очистки и Схема базы данных для служебных таблиц можно задать только через Консоль управления.
-
Политика очистки — выберите способ очистки данных в базе-приемнике перед переносом:
-
Не очищать
— выберите эту опцию, если будет производиться только репликация без копирования данных. -
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 ГБ
Текст ошибки:
Last binlog file <имя_файла:размер_файла> is more than 4GB
Если размер лога одной транзакции превышает 4 ГБ, активация трансферов Репликация или Копирование и репликация завершается ошибкой из-за внутренних ограничений
Решение: активируйте трансфер повторно.
Не добавляются новые таблицы
В трансфер типа Копирование и репликация не добавляются новые таблицы.
Решение:
- Деактивируйте и активируйте трансфер повторно.
- Создайте таблицы в базе-приемнике вручную.
- Создайте отдельный трансфер типа Копирование и добавьте в него только вновь созданные таблицы. При этом исходный трансфер типа Копирование и репликация можно не деактивировать.
Ошибка при трансфере из AWS RDS for MySQL®
В трансферах типа Копирование и репликация и Репликация из источника Amazon RDS for MySQL®
Пример ошибки:
Failed to execute LoadSnapshot:
Cannot load table "name": unable to read rows and push by chunks:
unable to push changes: unable to execute per table push:
error: err: sql: transaction has already been committed or rolled back
rollback err: sql: transaction has already been committed or rolled back
Ошибка вызвана коротким временем хранения файлов бинарного лога MySQL® в Amazon RDS.
Решение:
Увеличьте время хранения бинарного лога с помощью команды:
call mysql.rds_set_configuration('binlog retention hours', <кол-во_часов>);
Максимальное значение времени хранения — 168 ч (7 дней). Значение по умолчанию — NULL
(файлы бинарного лога не сохраняются). Подробнее см. в документации Amazon RDS
Ошибка трансфера при переносе таблиц без первичных ключей
Текст ошибки:
Primary key check failed: 14 Tables errors: Table no key columns found
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся.
Решение: подготовьте источник в соответствии с разделом Подготовка к трансферу.
Ошибка обращения к бинарному логу
В трансферах типа Копирование и репликация может возникнуть ошибка:
Warn(replication): failed to run (abstract1 source):
failed to run canal: failed to start binlog sync:
failed to get canal event: ERROR 1236 (HY000): Could not find first log file name in binary log index file
Ошибка возникает, если необходимые для репликации файлы бинарного лога недоступны. Обычно это связано с добавлением в бинарный лог новых изменений, из-за чего размер файла превышает допустимый. В этом случае часть старых данных лога удаляется.
Решение:
Увеличьте допустимый размер файлов бинарного лога в настройках MySQL® с помощью параметра Mdb preserve binlog bytes.
Минимальное значение — 1073741824
(1 ГБайт), максимальное значение — 107374182400
(100 ГБайт), по умолчанию — 1073741824
(1 ГБайт).
Ошибка удаления таблицы при политике очистки Drop
Текст ошибки:
ERROR: cannot drop table <имя_таблицы> because other objects depend on it (SQLSTATE 2BP01)
При политике очистки Drop
трансфер удаляет таблицы в несколько итераций:
-
Трансфер последовательно пытается удалить все таблицы. Каскадное удаление не используется, так как может привести к удалению таблиц, не участвующих в трансфере. Если таблицу невозможно удалить, например, из-за связанности внешними ключами, возникает ошибка, но трансфер продолжит удаление таблиц.
-
Во время следующей итерации трансфер пытается удалить оставшиеся таблицы. Если блокирующие дочерние таблицы были удалены в предыдущей итерации, таблица со связанностью внешними ключами удаляется. В этом случае ошибка устраняется в процессе работы Data Transfer, дополнительных действий не требуется.
-
Если во время очередной итерации трансфер не удалил ни одной таблицы, процесс удаления таблиц завершается. При этом:
- Трансфер продолжит работу, если все таблицы были удалены.
- Трансфер прервется с ошибкой, если остались неудаленные таблицы.
Решение:
-
Если дочерние таблицы не участвуют в других трансферах и их перенос не противоречит целям трансфера, добавьте эти таблицы:
- В список включенных таблиц в параметрах эндпоинта-источника.
- В список объектов для переноса в параметрах трансфера.
-
Удалите блокирующие дочерние таблицы в базе-приемнике вручную.
-
Используйте политику очистки
Truncate
. -
Пересоздайте базу в приемнике.
Важно
Это приведет к потере всех данных в базе.
Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®
Сдвиг времени наблюдается, так как эндпоинт-источник применяет часовой пояс UTC+0 для данных с типом DATETIME
. Подробнее см. в разделе Известные ограничения.
Решение: Примените нужный часовой пояс на уровне приемника вручную.
ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc