Передача данных из эндпоинта-источника MySQL®
- Сценарии передачи данных из MySQL®
- Подготовка базы данных источника
- Настройка эндпоинта-источника MySQL®
- Настройка приемника данных
- Действия с базой данных во время трансфера
- Решение проблем, возникающих при переносе данных
- Размер лога одной транзакции превышает 4 ГБ
- Не добавляются новые таблицы
- Ошибка при трансфере из AWS RDS for MySQL®
- Ошибка трансфера при переносе таблиц без первичных ключей
- Ошибка обращения к бинарному логу
- Ошибка удаления таблицы при политике очистки Drop
- Сдвиг времени в типе данных DATETIME при трансфере в ClickHouse®
С помощью сервиса Yandex Data Transfer вы можете переносить данные из базы MySQL® и реализовывать различные сценарии переноса, обработки и трансформации данных. Для реализации трансфера:
- Ознакомьтесь с возможными сценариями передачи данных.
- Подготовьте базу данных MySQL® к трансферу.
- Настройте эндпоинт-источник в Yandex Data Transfer.
- Настройте один из поддерживаемых приемников данных.
- Создайте и запустите трансфер.
- Выполняйте необходимые действия по работе с базой и контролируйте трансфер.
- При возникновении проблем, воспользуйтесь готовыми решениями по их устранению.
Сценарии передачи данных из MySQL®
-
Миграция — перенос данных из одного хранилища в другое. Часто это перенос базы из устаревших локальных баз в управляемые облачные.
-
Захват изменений данных — это процесс отслеживания изменений в базе данных и поставка этих изменений потребителям. Применяется для приложений, которые чувствительны к изменению данных в реальном времени.
-
Загрузка данных в витрины — процесс трансфера подготовленных данных в хранилища с целью последующей визуализации.
-
Загрузка данных в масштабируемое хранилище Object Storage позволяет удешевить хранение и облегчает обмен данных с контрагентами.
Подробное описание возможных сценариев передачи данных в Yandex Data Transfer см. в разделе Практические руководства.
Подготовка базы данных источника
-
Включите режим полного бинарного лога на источнике, установив значение
FULL
илиNOBLOB
для параметра Binlog row image . -
(Опционально) Настройте лимит на размер отправляемых кусков данных (chunk) с помощью параметра Max allowed packet.
-
Создайте пользователя для подключения к источнику.
-
Выдайте пользователю привилегию
ALL_PRIVILEGES
для базы-источника. -
Выдайте пользователю административные привилегии
REPLICATION CLIENT
иREPLICATION SLAVE
.
-
-
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся. Чтобы сохранить работоспособность трансфера при переносе базы с такими таблицами:
-
Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
-
Создайте первичные ключи (
PRIMARY KEY
) в тех мигрируемых таблицах, где их нет.-
Чтобы получить список таблиц без первичного ключа, выполните запрос:
SELECT tab.table_schema AS database_name, tab.table_name AS table_name, tab.table_rows AS table_rows FROM information_schema.tables tab LEFT JOIN information_schema.table_constraints tco ON (tab.table_schema = tco.table_schema AND tab.table_name = tco.table_name AND tco.constraint_type = 'PRIMARY KEY') WHERE tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') AND tco.constraint_type IS NULL AND tab.table_type = 'BASE TABLE';
-
Изучите структуру таблиц без первичного ключа, которые необходимо перенести на приемник:
SHOW CREATE TABLE <имя_базы>.<имя_таблицы>;
-
Добавьте простой или составной первичный ключ к таблицам, которые необходимо перенести на приемник:
ALTER TABLE <имя_таблицы> ADD PRIMARY KEY (<столбец_или_группа_столбцов>);
-
Если в переносимой на приемник таблице нет столбца или группы столбцов, подходящих на роль первичного ключа, создайте новый столбец:
ALTER TABLE <имя_таблицы> ADD id BIGINT PRIMARY KEY AUTO_INCREMENT;
-
Примечание
Если создание первичного ключа завершается ошибкой
Creating index 'PRIMARY' required more than 'innodb_online_alter_log_max_size' bytes of modification log. Please try again
, увеличьте в настройках СУБД значение параметраInnodb log file size
. -
-
Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Репликация и Копирование и репликация). Подробнее см. в описании дополнительных настроек эндпоинта для источника MySQL®.
-
Убедитесь, что настройки сети, в которой размещен кластер, разрешают подключение к нему из интернета с IP-адресов, используемых сервисом Data Transfer
. -
Убедитесь, что источник использует подсистему хранения данных низкого уровня MyISAM или InnoDB. При использовании других подсистем трансфер может завершиться с ошибкой.
-
Включите режим полного бинарного лога
на источнике, установив значениеFULL
илиNOBLOB
для параметраbinlog_row_image
. -
Задайте строковый формат бинарного лога
на источнике, установив значениеROW
для параметраbinlog_format
. -
Если источник репликации — кластер, который находится за балансером, включите для него GTID-режим (
GTID-MODE = ON
).Если по какой-то причине включить GTID-режим невозможно, убедитесь, что шаблон имен бинарных логов содержит имя хоста.
В обоих случаях это позволит продолжить репликацию в случае смены хоста-мастера.
-
(Опционально) Настройте лимит
на размер отправляемых кусков данных (chunk) с помощью параметраmax_allowed_packet
. -
Создайте пользователя для подключения к источнику и выдайте ему необходимые привилегии:
CREATE USER '<имя_пользователя>'@'%' IDENTIFIED BY '<пароль>'; GRANT ALL PRIVILEGES ON <имя_базы>.* TO '<имя_пользователя>'@'%'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '<имя_пользователя>'@'%';
-
Для типов трансфера Репликация и Копирование и репликация таблицы без первичных ключей не переносятся. Чтобы сохранить работоспособность трансфера при переносе базы с такими таблицами:
-
Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
-
Создайте первичные ключи (
PRIMARY KEY
) в тех мигрируемых таблицах, где их нет.-
Чтобы получить список таблиц без первичного ключа, выполните запрос:
SELECT tab.table_schema AS database_name, tab.table_name AS table_name, tab.table_rows AS table_rows FROM information_schema.tables tab LEFT JOIN information_schema.table_constraints tco ON (tab.table_schema = tco.table_schema AND tab.table_name = tco.table_name AND tco.constraint_type = 'PRIMARY KEY') WHERE tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') AND tco.constraint_type IS NULL AND tab.table_type = 'BASE TABLE';
-
Изучите структуру таблиц без первичного ключа, которые необходимо перенести на приемник:
SHOW CREATE TABLE <имя_базы>.<имя_таблицы>;
-
Добавьте простой или составной первичный ключ к таблицам, которые необходимо перенести на приемник:
ALTER TABLE <имя_таблицы> ADD PRIMARY KEY (<столбец_или_группа_столбцов>);
-
Если в переносимой на приемник таблице нет столбца или группы столбцов, подходящих на роль первичного ключа, создайте новый столбец:
ALTER TABLE <имя_таблицы> ADD id BIGINT PRIMARY KEY AUTO_INCREMENT;
-
Примечание
Если создание первичного ключа завершается ошибкой
Creating index 'PRIMARY' required more than 'innodb_online_alter_log_max_size' bytes of modification log. Please try again
, увеличьте в настройках СУБД значение параметраinno_db_log_file_size
. -
-
Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Репликация и Копирование и репликация). Подробнее см. в описании дополнительных настроек эндпоинта для источника MySQL®.
Настройка эндпоинта-источника 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-source
.
-
--cluster-id
— идентификатор кластера, к которому необходимо подключиться. -
--database
— имя базы данных. Оставьте поле пустым, если хотите перенести таблицы из нескольких баз данных одновременно. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
mysql_source
.
-
security_groups
— группы безопасности для сетевого трафика.Правила групп безопасности применяются к трансферу. Они позволяют открыть сетевой доступ с ВМ трансфера к кластеру. Подробнее см. в разделе Сеть в Yandex Data Transfer.
Группы безопасности должны принадлежать той же сети, в которой размещен кластер.
Примечание
В Terraform сеть для групп безопасности задавать не нужно.
-
connection.mdb_cluster_id
— идентификатор кластера, к которому необходимо подключиться. -
database
— имя базы данных. Оставьте поле пустым, если хотите перенести таблицы из нескольких баз данных одновременно. -
user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
password.raw
— пароль в текстовом виде.
Пример структуры конфигурационного файла:
resource "yandex_datatransfer_endpoint" "<имя_эндпоинта_в_Terraform>" {
name = "<имя_эндпоинта>"
settings {
mysql_source {
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-source
.
-
--host
— IP-адрес или FQDN хоста-мастера, к которому необходимо подключиться. -
--port
— номер порта, который сервис Data Transfer будет использовать для подключения. -
--ca-certificate
— сертификат CA, если требуется шифрование передаваемых данных, например для соответствия требованиям PCI DSS . -
--subnet-id
— идентификатор подсети, в которой находится хост. -
--database
— имя базы данных. Оставьте поле пустым, если хотите перенести таблицы из нескольких баз данных одновременно. -
--user
— имя пользователя, под которым сервис Data Transfer будет подключаться к базе данных. -
Чтобы задать пароль пользователя для доступа к базе данных, используйте один из параметров:
-
--raw-password
— пароль в текстовом виде. -
--password-file
— путь к файлу с паролем.
-
- Тип эндпоинта —
mysql_source
.
-
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_source {
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
— пароль пользователя для доступа к базе данных (в текстовом виде).
Дополнительные настройки
-
Фильтр таблиц:
-
Список включённых таблиц — будут передаваться данные только из таблиц этого списка. Задается с помощью регулярных выражений.
Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
Список исключённых таблиц — данные таблиц из этого списка передаваться не будут. Задается с помощью регулярных выражений.
Регулярные выражения для включенных и исключенных таблиц должны соответствовать правилам именования идентификаторов в MySQL®. Подробнее читайте в документации MySQL®
. Экранирование двойных кавычек не требуется.Важно
Если имя включаемой или исключаемой таблицы совпадает с именем базы данных, для корректной работы фильтра укажите таблицу в формате
<имя_БД>.<имя_таблицы>
. -
-
Перенос схемы — позволяет выбрать элементы схемы БД, которые будут перенесены в процессе активации или деактивации трансфера.
-
Расширеннные настройки:
-
Часовой пояс для подключения к базе данных — указывается как идентификатор IANA Time Zone Database
. По умолчанию используется локальная таймзона сервера. -
База данных для служебных таблиц — база данных для технических таблиц (
__tm_keeper
,__tm_gtid_keeper
). По умолчанию это БД, из которой происходит перенос данных.
-
-
--include-table-regex
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка. Задается с помощью регулярных выражений.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
--exclude-table-regex
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут. Задается с помощью регулярных выражений. -
--timezone
— часовой пояс базы, указывается как идентификатор IANA Time Zone Database . По умолчанию используется UTC+0. -
Настройки переноса схемы:
--transfer-before-data
— при активации трансфера.--transfer-after-data
— при деактивации трансфера.
-
include_table_regex
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка. Задается с помощью регулярных выражений.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
exclude_table_regex
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут. Задается с помощью регулярных выражений. -
timezone
— часовой пояс базы, указывается как идентификатор IANA Time Zone Database . По умолчанию используется UTC+0. -
object_transfer_settings
— настройки переноса схемы:view
— представления;routine
— процедуры и функции;trigger
— триггеры.
Для каждой сущности может быть задано одно из значений:
BEFORE_DATA
— перенос на этапе активации трансфера;AFTER_DATA
— перенос на этапе деактивации трансфера;NEVER
— не переносить.
-
includeTablesRegex
— список включенных таблиц. Будут передаваться данные только из таблиц этого списка. Задается с помощью регулярных выражений.Добавление новых таблиц при редактировании эндпоинта, использующегося в трансферах типа Копирование и репликация или Репликация в статусе Реплицируется, не приведет к загрузке истории данных по этим таблицам. Чтобы добавить таблицу с ее историческими данными, используйте поле Список объектов для переноса в настройках трансфера.
-
excludeTablesRegex
— список исключенных таблиц. Данные таблиц из этого списка передаваться не будут. Задается с помощью регулярных выражений. -
timezone
— часовой пояс базы, указывается как идентификатор IANA Time Zone Database . По умолчанию используется UTC+0. -
objectTransferSettings
— настройки переноса схемы при активации и деактивации трансфера (значенияBEFORE_DATA
иAFTER_DATA
, соответственно).
Настройки переноса схемы при активации и деактивации трансфера
В процессе работы трансфера схема базы данных переносится с источника на приемник. Перенос выполняется в два этапа:
-
На стадии активации.
Этап выполняется перед копированием или репликацией для создания схемы на приемнике. На этом этапе вы можете включить перенос представлений, хранимых процедур и функций, триггеров.
-
На стадии деактивации.
Этот этап выполняется в конце работы трансфера, при его деактивации. Если трансфер постоянно работает в режиме репликации, то финальная стадия переноса будет выполнена только при остановке репликации. На этом этапе вы можете включить перенос представлений, хранимых процедур и функций, триггеров.
На финальной стадии предполагается, что при деактивации трансфера на источнике нет пишущей нагрузки. Это можно гарантировать переводом в режим «только чтение» (read-only). На этой стадии схема базы данных на приемнике приводится в состояние, когда она будет консистентна схеме на источнике.
Известные ограничения
Если вы настраиваете трансфер из кластера MySQL® в кластер ClickHouse®, учитывайте особенности переноса данных с типами для хранения даты и времени
- Данные с типом
TIME
переносятся как строки, часовые пояса источника и приемника не учитываются. - При переносе данных с типом
TIMESTAMP
применяется часовой пояс, указанный в настройках источника MySQL® или в дополнительных настройках эндпоинта. Подробнее см. в документации MySQL® . - Эндпоинт-источник присваивает данным с типом
DATETIME
часовой пояс UTC+0.
Для трансфера из MySQL® в базу данных другого вида не поддерживается перенос полей с типом DECIMAL
, чтобы избежать потери точности данных. Для трансфера из MySQL® в MySQL® такого ограничения нет.
Настройка приемника данных
Настройте один из поддерживаемых приемников данных:
- PostgreSQL;
- MySQL®;
- ClickHouse®;
- Greenplum®;
- Yandex Managed Service for YDB;
- Yandex Object Storage;
- Apache Kafka®;
- YDS;
- Elasticsearch;
- OpenSearch.
Полный список поддерживаемых источников и приемников в Yandex Data Transfer см. в разделе Доступные трансферы.
После настройки источника и приемника данных создайте и запустите трансфер.
Действия с базой данных во время трансфера
-
Для трансферов в статусе Копируется любые изменения схемы данных (
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
. Подробнее см. в разделе Известные ограничения.
Решение: Примените нужный часовой пояс на уровне приемника вручную.
Greenplum® и Greenplum Database® являются зарегистрированными товарными знаками или товарными знаками VMware, Inc в США и/или других странах.
ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc