Подключиться
Yandex Data Transfer

Подготовка к трансферу

Статья создана
,
улучшена

Подготовка источника

Источники Airbyte®

Источник AWS CloudTrail

Получите идентификатор ключа и секретный ключ доступа AWS, следуя инструкции AWS.

Подробнее см. в документации Airbyte®.

Источник BigQuery

  1. Создайте учетную запись Google Cloud.
  2. Добавьте учетную запись в качестве участника в проект Google Cloud с ролью BigQuery User.
  3. Создайте ключ учетной записи Google Cloud.

Подробнее см. в документации Airbyte®.

Источник S3

Если вы используете частный бакет в качестве источника, предоставьте разрешения read и list учетной записи, которую будете использовать для подключения.

Подробнее см. в документации Airbyte®.

Источник Apache Kafka®

Создайте пользователя с ролью ACCESS_ROLE_CONSUMER на топике-источнике.

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

  2. Настройте доступ к кластеру-источнику из Yandex Cloud.

  3. Настройте права доступа пользователя к нужному топику.

  4. (опционально) Чтобы использовать авторизацию по логину и паролю, настройте SASL-аутентификацию.

Источник ClickHouse

  1. Убедитесь, что переносимые таблицы используют движки семейства MergeTree. Будут перенесены только эти таблицы и материализованные представления (MaterializedView).
  2. Создайте пользователя с доступом к базе источника.

  1. Убедитесь, что переносимые таблицы используют движки семейства MergeTree. Будут перенесены только эти таблицы и материализованные представления (MaterializedView).

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

  3. Настройте доступ к кластеру-источнику из Yandex Cloud.

  4. Создайте пользователя с доступом к базе источника.

Источник Greenplum®

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

    CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

  2. Настройте кластер-источник так, чтобы созданный пользователь мог подключаться ко всем хостам-мастерам кластера.

  3. Если предполагается использовать шардированное копирование, настройте кластер-источник так, чтобы созданный пользователь мог подключаться ко всем хостам-сегментам кластера в режиме прямого доступа (utility mode). Для этого убедитесь, что для кластера включена настройка "Доступ из Data Transfer".

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

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

    Таблицы, для которых не выданы необходимые привилегии, недоступны для Data Transfer. Эти таблицы обрабатываются так же, как если бы они отсутствовали.

    В этом примере привилегии выдаются на все таблицы в выбранной схеме:

    GRANT SELECT ON ALL TABLES IN SCHEMA <название схемы> TO <имя пользователя>;
GRANT USAGE ON SCHEMA <название схемы> TO <имя пользователя>;

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

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

    CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

  3. Настройте кластер-источник так, чтобы созданный пользователь мог подключаться ко всем хостам-мастерам кластера.

  4. Если предполагается использовать шардированное копирование, настройте кластер-источник так, чтобы созданный пользователь мог подключаться ко всем хостам-сегментам кластера в режиме прямого доступа (utility mode).

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

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

    Таблицы, для которых не выданы необходимые привилегии, недоступны для Data Transfer. Эти таблицы обрабатываются так же, как если бы они отсутствовали.

    В этом примере привилегии выдаются на все таблицы базы данных:

    GRANT SELECT ON ALL TABLES IN SCHEMA <название схемы> TO <имя пользователя>;
GRANT USAGE ON SCHEMA <название схемы> TO <имя пользователя>;

Data Transfer взаимодействует с Greenplum® по-разному в зависимости от настроек трансфера и содержимого кластера-источника. Подробная информация доступна в разделе настройка эндпоинта-источника Greenplum®.

Источник MongoDB

  1. Оцените общее количество баз данных для трансфера и общую нагрузку на Managed Service for MongoDB. Если нагрузка на базы выше 10 000 транзакций на запись в секунду, создайте несколько эндпоинтов и трансферов. Подробнее см. в разделе Настройка эндпоинта-источника MongoDB.
  2. Создайте пользователя с ролью readWrite на каждую базу в источнике, которая будет реплицироваться. Роль readWrite нужна для того, чтобы у трансфера было право записи в служебную коллекцию __dt_cluster_time.

  1. Оцените общее количество баз данных для трансфера и общую нагрузку на MongoDB. Если нагрузка на базы выше 10 000 транзакций на запись в секунду, создайте несколько эндпоинтов и трансферов. Подробнее см. в разделе Настройка эндпоинта-источника MongoDB.

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

  3. Убедитесь, что версия MongoDB на приемнике не ниже 4.0.

  4. Настройте доступ к кластеру-источнику из Yandex Cloud. Чтобы настроить кластер-источник для подключения из интернета:

    1. Измените в конфигурационном файле значение настройки net.bindIp со 127.0.0.1 на 0.0.0.0:

      # network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0

    2. Перезапустите сервис mongod:

      sudo systemctl restart mongod.service

  5. Если кластер-источник не использует репликацию, включите ее:

    1. Добавьте в конфигурационный файл /etc/mongod.conf настройки репликации:

      replication:
  replSetName: <имя набора реплик>

    2. Перезапустите сервис mongod:

      sudo systemctl restart mongod.service

    3. Подключитесь к MongoDB и инициализируйте набор реплик командой:

      rs.initiate({
    _id: "<имя набора реплик>",
    members: [{
        _id: 0,
        host: "<IP-адрес, который слушает mongod>:<порт>"
    }]
});

  6. Создайте пользователя с ролью readWrite на все базы в источнике, которые будут реплицироваться:

    use admin
db.createUser({
    user: "<имя пользователя>",
    pwd: "<пароль>",
    mechanisms: ["SCRAM-SHA-1"],
    roles: [
        {
            db: "<имя базы-источника 1>",
            role: "readWrite"
        },
        {
            db: "<имя базы-источника 2>",
            role: "readWrite"
        },
        ...
    ]
});

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

    Примечание

    Для MongoDB версий 3.6 и более старых достаточно выдать созданному пользователю роль read на реплицируемые базы.

  7. При использовании MongoDB версий 3.4 и 3.6 для работы трансфера необходимо, чтобы пользователь обладал правами на чтение коллекции local.oplog.rs, а также на запись с чтением коллекции __data_transfer.__dt_cluster_time. Чтобы назначить пользователю роль clusterAdmin, предоставляющую такие права, подключитесь к MongoDB и выполните команды:

    use admin;
db.grantRolesToUser("<имя пользователя>", ["clusterAdmin"]);

    Для выдачи более гранулярных прав можно назначить роль clusterMonitor, необходимую для чтения коллекции local.oplog.rs, а также дать доступ на чтение и запись системной коллекции __data_transfer.__dt_cluster_time.

Источник MySQL

  1. Включите режим полного бинарного лога на источнике с помощью параметра Binlog row image.

  2. (опционально) Настройте лимит на размер отправляемых кусков данных (chunk) с помощью параметра Max allowed packet.

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

    1. Выдайте пользователю привилегию ALL_PRIVILEGES для базы-источника.

    2. Выдайте пользователю административные привилегии REPLICATION CLIENT и REPLICATION SLAVE.

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

    • Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.

    • Создайте первичные ключи (PRIMARY KEY) в тех мигрируемых таблицах, где их нет.

      1. Чтобы получить список таблиц без первичного ключа, выполните запрос:

        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';

      2. Изучите структуру таблиц без первичного ключа, которые необходимо перенести на приемник:

        SHOW CREATE TABLE <имя базы>.<имя таблицы>;

      3. Добавьте простой или составной первичный ключ к таблицам, которые необходимо перенести на приемник:

        ALTER TABLE <имя таблицы> ADD PRIMARY KEY (<столбец или группа столбцов>);

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

        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.

  5. Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Реплицировать и Копировать и реплицировать). Подробнее см. в описании дополнительных настроек эндпоинта для источника MySQL.

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

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

  3. Включите режим полного бинарного лога на источнике с помощью параметра binlog_row_image.

  4. Если источник репликации — кластер, который находится за балансером, включите для него GTID-режим (GTID-MODE = ON).

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

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

  5. (опционально) Настройте лимит на размер отправляемых кусков данных (chunk) с помощью параметра max_allowed_packet.

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

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

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

    • Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.

    • Создайте первичные ключи (PRIMARY KEY) в тех мигрируемых таблицах, где их нет.

      1. Чтобы получить список таблиц без первичного ключа, выполните запрос:

        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';

      2. Изучите структуру таблиц без первичного ключа, которые необходимо перенести на приемник:

        SHOW CREATE TABLE <имя базы>.<имя таблицы>;

      3. Добавьте простой или составной первичный ключ к таблицам, которые необходимо перенести на приемник:

        ALTER TABLE <имя таблицы> ADD PRIMARY KEY (<столбец или группа столбцов>);

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

        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.

  8. Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Реплицировать и Копировать и реплицировать). Подробнее см. в описании дополнительных настроек эндпоинта для источника MySQL.

Источник Oracle

  1. Создайте пользователя, от имени которого трансфер подключится к источнику:

    CREATE USER <имя пользователя> IDENTIFIED BY <пароль>;
GRANT CREATE SESSION TO <имя пользователя>;

  2. Чтобы подготовить источник к трансферу типа Копировать:

    • Выдайте права созданному пользователю:

      GRANT SELECT ON V$DATABASE TO <имя пользователя>;
GRANT SELECT ON DBA_EXTENTS TO <имя пользователя>;
GRANT SELECT ON DBA_OBJECTS TO <имя пользователя>;
GRANT FLASHBACK ANY TABLE TO <имя пользователя>;

      Права FLASHBACK можно выдать не на все таблицы (ANY TABLE), а только на те, которые нужно скопировать.

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

  3. Чтобы подготовить источник к трансферу типа Реплицировать:

    • Выдайте права созданному пользователю:

      GRANT SELECT ON V$DATABASE TO <имя пользователя>;
GRANT SELECT ON V$LOG TO <имя пользователя>;
GRANT SELECT ON V$LOGFILE TO <имя пользователя>;
GRANT SELECT ON V$ARCHIVED_LOG TO <имя пользователя>;
GRANT EXECUTE ON SYS.DBMS_LOGMNR TO <имя пользователя>;

    • Выдайте пользователю права на чтение таблиц, которые нужно реплицировать.

    • Включите Minimal Supplemental Logging с первичными ключами, для этого выполните:

      ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

  4. (опционально) Если вы работаете в CDB-среде, выполните дополнительные настройки:

    1. Создайте пользователя Common User:

      CREATE USER C##<имя пользователя> IDENTIFIED BY <пароль> CONTAINER=ALL;
GRANT CREATE SESSION TO C##<имя пользователя>;

      Примечание

      Имя пользователя Common User должно иметь префикс С##.

      Можно указать только контейнер cdb$root и контейнер с таблицами, которые нужно перенести.

    2. Чтобы пользователь мог переключаться на контейнер cdb$root, выдайте ему права ALTER SESSION:

      GRANT ALTER SESSION TO C##<имя пользователя>;

    3. Выдайте доступ на чтение нужного PDB-контейнера пользователю:

      GRANT SELECT ANY TABLE TO C##<имя пользователя> CONTAINER=<имя PDB-контейнера>;

      Можно указать не все таблицы (ANY TABLE), а только те, которые нужно перенести.

Источник PostgreSQL

Примечание

При трансфере из PostgreSQL в любой тип приемника объекты типа large objects не переносятся.

Большие объекты в системе хранения TOAST и данные с типом bytea переносятся без ограничений.

  1. Настройте пользователя, от имени которого трансфер подключится к источнику:

    1. Создайте пользователя.

    2. Для типов трансфера Реплицировать и Копировать и реплицировать назначьте роль mdb_replication этому пользователю.

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

      • SELECT над всеми таблицами базы данных, которые переносит трансфер;
      • SELECT над всеми последовательностями базы данных, которые переносит трансфер;
      • USAGE на схемы этих таблиц и последовательностей.
      • ALL PRIVILEGES (CREATE и USAGE) на задаваемую параметром эндпоинта схему служебных таблиц __consumer_keeper и __data_transfer_mole_finder, если эндпоинт будет использоваться для типов трансфера Реплицировать или Копировать и реплицировать.

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

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

    • Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
    • Добавьте идентификатор реплики на таблицах без primary key:

      • Для таблиц с индексом установите REPLICA IDENTITY по unique key:

        ALTER TABLE MY_TBL REPLICA IDENTITY USING INDEX MY_IDX;

      • Для таблиц без индекса измените REPLICA IDENTITY:

        ALTER TABLE MY_TBL REPLICA IDENTITY FULL;

  4. Выключите перенос внешних ключей на стадии создания эндпоинта-источника. Создайте их заново после окончания трансфера.

  5. Найдите и завершите слишком долгие DDL-запросы. Для этого сделайте выборку из системной таблицы PostgreSQL pg_stat_activity:

    SELECT NOW() - query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' ORDER BY 1 DESC;

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

  6. Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Реплицировать и Копировать и реплицировать). Подробнее см. в описании дополнительных настроек эндпоинта для источника PostgreSQL.

  7. Для параллельного чтения из таблицы установите её первичный ключ в режим serial.

    После этого укажите количество инстансов и процессов в поле Рантайм в параметрах трансфера.

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

  2. Создайте пользователя, от имени которого трансфер подключится к источнику:

    • Для типа трансфера Копировать создайте пользователя командой:

      CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

    • Для типов трансфера Реплицировать и Копировать и реплицировать создайте пользователя с привилегией REPLICATION командой:

      CREATE ROLE <имя пользователя> WITH REPLICATION LOGIN ENCRYPTED PASSWORD '<пароль>';

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

    GRANT SELECT ON ALL TABLES IN SCHEMA <название схемы> TO <имя пользователя>;
GRANT USAGE ON SCHEMA <название схемы> TO <имя пользователя>;

  4. Выдайте созданному пользователю привилегии на задаваемую параметром эндпоинта схему служебных таблиц __consumer_keeper и __data_transfer_mole_finder, если эндпоинт будет использоваться для типов трансфера Реплицировать или Копировать и реплицировать:

    GRANT ALL PRIVILEGES ON SCHEMA <имя схемы> TO <имя пользователя>;

  5. Установите и включите расширение wal2json.

    Установка

    • Linux

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

    • Windows 10, 11

      1. Если у вас не установлена Microsoft Visual Studio, загрузите и установите ее. Для сборки расширения wal2json достаточно редакции Community Edition. При установке выберите компоненты:

        • MSBuild,
        • MSVC v141 x86/x64 build tools,
        • C++\CLI support for v141 build tools,
        • MSVC v141 — VS 2017 C++ x64\x86 build tools,
        • MSVC v141 — VS 2017 C++ x64\x86 Spectre-mitigated libs,
        • самая свежая версия Windows SDK для используемой версии ОС,
        • прочие зависимости, которые устанавливаются автоматически для выбранных компонентов.

        Запомните номер устанавливаемой версии Windows SDK — он понадобится при указании параметров сборки wal2json.

      2. Загрузите исходный код wal2json со страницы проекта.

      3. Распакуйте архив с исходным кодом в каталог C:\wal2json\.

      4. Перейдите в каталог C:\wal2json.

      5. В рамках одной сессии PowerShell внесите изменения в файл wal2json.vcxproj:

        • замените строки C:\postgres\pg103 на путь к каталогу с установленной версией PostgreSQL, например:

          (Get-Content .\wal2json.vcxproj).replace('C:\postgres\pg103', 'C:\PostgreSQL\14') | `
 Set-Content .\wal2json.vcxproj

        • замените параметр сборки /MP на /MT, например:

          (Get-Content .\wal2json.vcxproj).replace('/MP', '/MT') | Set-Content .\wal2json.vcxproj

        • укажите в параметре <WindowsTargetPlatformVersion> номер версии установленного компонента Windows SDK:

          (Get-Content .\wal2json.vcxproj).replace('<WindowsTargetPlatformVersion>8.1', '<WindowsTargetPlatformVersion><установленная версия Windows SDK>') | `
 Set-Content .\wal2json.vcxproj

        1. Укажите значение переменной окружения, необходимой для сборки wal2json, например, для Visual Studio Community Edition 2022:

          $VCTargetsPath='C:\Program Files\Microsoft Visual Studio\2022\Comminuty\MSBuild\Microsoft\VC\v150'

        2. Запустите сборку:

          & 'C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild.exe' /p:Configuration=Release /p:Platform=x64

        3. Скопируйте файл wal2json.dll из каталога build/release в каталог lib установленной версии PostgreSQL.

    Настройка

    1. В файле postgresql.conf измените значение параметра wal_level на logical:

      wal_level = logical

    2. Перезапустите PostgreSQL.

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

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

    • Не переносите таблицы без первичных ключей. Для этого добавьте их в список исключенных таблиц в настройках эндпоинта для источника.
    • Добавьте идентификатор реплики на таблицах без primary key:

      • Для таблиц с индексом установите REPLICA IDENTITY по unique key:

        ALTER TABLE MY_TBL REPLICA IDENTITY USING INDEX MY_IDX;

      • Для таблиц без индекса измените REPLICA IDENTITY:

        ALTER TABLE MY_TBL REPLICA IDENTITY FULL;

  8. Выключите перенос внешних ключей на стадии создания эндпоинта-источника. Создайте их заново после окончания трансфера.

  9. Найдите и завершите слишком долгие DDL-запросы. Для этого сделайте выборку из системной таблицы PostgreSQL pg_stat_activity:

    SELECT NOW() - query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' ORDER BY 1 DESC;

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

  10. Выключите перенос триггеров на стадии активации трансфера и включите его на стадии деактивации (для типов трансфера Реплицировать и Копировать и реплицировать). Подробнее см. в описании дополнительных настроек эндпоинта для источника PostgreSQL.

  11. Для параллельного чтения из таблицы установите её первичный ключ в режим serial.

    После этого укажите количество инстансов и процессов в поле Рантайм в параметрах трансфера.

  12. Если на источнике настроена репликация через Patroni, добавьте в его конфигурацию блок ignore_slots:

    ignore_slots:
  - database: <имя базы данных, для которой настроен трансфер>
    name: <имя слота репликации>
    plugin: wal2json
    type: logical

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

    В противном случае начало этапа репликации завершится ошибкой:

    Warn(Termination): unable to create new pg source: Replication slotID <имя слота репликации> does not exist.

Примечание

Об особенностях переноса данных из PostgreSQL в ClickHouse трансферами типа Реплицировать и Копировать и реплицировать см. в разделе Асинхронная репликация данных из PostgreSQL в ClickHouse.

Источник Yandex Data Streams

  1. Создайте сервисный аккаунт с ролью yds.editor.

  2. Создайте поток данных.

  3. (опционально) Создайте функцию обработки.

    Пример функции обработки
    const yc = require("yandex-cloud");
const { Parser } = require("@robojones/nginx-log-parser");
module.exports.handler = async function (event, context) {
    const schema =
        '$remote_addr - $remote_user [$time_local] "$request" $status $bytes_sent "$http_referer" "$http_user_agent"';
    const parser = new Parser(schema);
    return {
        Records: event.Records.map((record) => {
            const decodedData = new Buffer(record.kinesis.data, "base64")
                .toString("ascii")
                .trim();
            try {
                const result = parser.parseLine(decodedData);
                if (result.request == "") {
                    // empty request - drop message
                    return {
                        eventID: record.eventID,
                        invokeIdentityArn: record.invokeIdentityArn,
                        eventVersion: record.eventVersion,
                        eventName: record.eventName,
                        eventSourceARN: record.eventSourceARN,
                        result: "Dropped"
                    };
                }
                return {
                    // successfully parsed message
                    eventID: record.eventID,
                    invokeIdentityArn: record.invokeIdentityArn,
                    eventVersion: record.eventVersion,
                    eventName: record.eventName,
                    eventSourceARN: record.eventSourceARN,
                    kinesis: {
                        data: new Buffer(JSON.stringify(result)).toString(
                            "base64"
                        ),
                    },
                    result: "Ok"
                };
            } catch (err) {
                // error - fail message
                return {
                    eventID: record.eventID,
                    invokeIdentityArn: record.invokeIdentityArn,
                    eventVersion: record.eventVersion,
                    eventName: record.eventName,
                    eventSourceARN: record.eventSourceARN,
                    result: "ProcessingFailed",
                };
            }
        })
    };
};

  4. (опционально) Подготовьте файл схемы данных в формате JSON.

    Пример файла со схемой данных:

    [
    {
        "name": "<имя поля>",
        "type": "<тип>"
    },
    ...
    {
        "name": "<имя поля>",
        "type": "<тип>"
    }
]

    Список допустимых типов:

    • any
    • boolean
    • datetime
    • double
    • int8
    • int16
    • int32
    • int64
    • string
    • uint8
    • uint16
    • uint32
    • uint64
    • utf8

Подготовка приемника

Приемник ClickHouse

  1. Создайте базу-приемник.

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

  2. Создайте пользователя с доступом к базе приемника.

    После старта трансфер подключится к приемнику от имени этого пользователя.

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

  2. Создайте базу-приемник. Ее имя должно совпадать с именем базы-источника. Если нужно перенести несколько баз данных, создайте для каждой из них отдельный трансфер.

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

    После старта трансфер подключится к приемнику от имени этого пользователя.

Приемник Greenplum®

  1. Отключите на приемнике следующие настройки:

    • проверку целостности внешних ключей;
    • триггеры;
    • другие ограничения (constraints).

    Важно

    Не включайте эти настройки до окончания трансфера. Это обеспечит целостность данных по внешним ключам.

  2. Создайте пользователя:

    CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

  3. Выдайте созданному пользователю все привилегии на базу данных, схемы и переносимые таблицы:

    GRANT ALL PRIVILEGES ON DATABASE <имя базы> TO <имя пользователя>;

    Если база не пустая, то пользователь должен быть ее владельцем (owner):

    ALTER DATABASE <имя базы> OWNER TO <имя пользователя>;

    После старта трансфер подключится к приемнику от имени этого пользователя.

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

  2. Отключите на приемнике следующие настройки:

    • проверку целостности внешних ключей;
    • триггеры;
    • другие ограничения (constraints).

    Важно

    Не включайте эти настройки до окончания трансфера. Это обеспечит целостность данных по внешним ключам.

  3. Создайте пользователя:

    CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

  4. Выдайте созданному пользователю все привилегии на базу данных, схемы и переносимые таблицы:

    GRANT ALL PRIVILEGES ON DATABASE <имя базы> TO <имя пользователя>;

    Если база не пустая, то пользователь должен быть ее владельцем (owner):

    ALTER DATABASE <имя базы> OWNER TO <имя пользователя>;

    После старта трансфер подключится к приемнику от имени этого пользователя.

Приемник MongoDB

  1. Создайте базу данных с тем же именем, что и на источнике.

  2. Создайте пользователя с ролью readWrite на созданную базу.

  3. Чтобы шардировать переносимые коллекции в кластере-приемнике Yandex Managed Service for MongoDB:

    1. Следуя инструкции, создайте и настройте в базе-приемнике пустые шардированные коллекции с теми же именами, что и на источнике.

      Сервис Data Transfer не шардирует переносимые коллекции автоматически. Шардирование больших коллекций может занять продолжительное время и снизить скорость трансфера.

    2. Если шардирование происходит по ключу, отличному от _id (используется по умолчанию), назначьте пользователю роль mdbShardingManager.

    3. При создании эндпоинта для приемника выберите политику очистки DISABLED или TRUNCATE.

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

    Подробнее о шардировании см. в документации MongoDB.

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

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

  3. Настройте кластер-приемник, чтобы к нему можно было подключиться из интернета:

    1. Измените в конфигурационном файле значение настройки net.bindIp со 127.0.0.1 на 0.0.0.0:

      # network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0

    2. Перезапустите сервис mongod:

      sudo systemctl restart mongod.service

  4. Если кластер-приемник не использует репликацию, включите ее:

    1. Добавьте в конфигурационный файл /etc/mongod.conf настройки репликации:

      replication:
  replSetName: <имя набора реплик>

    2. Перезапустите сервис mongod:

      sudo systemctl restart mongod.service

    3. Подключитесь к MongoDB и инициализируйте набор реплик командой:

      rs.initiate({
    _id: "<имя набора реплик>",
    members: [{
        _id: 0,
        host: "<IP-адрес, который слушает mongod>:<порт>"
    }]
});

  5. Подключитесь к кластеру и создайте базу-приемник с тем же именем, что и на источнике:

    use <имя базы>

  6. Создайте пользователя с правами readWrite на базу-приемник:

    use admin;
db.createUser({
    user: "<имя пользователя>",
    pwd: "<пароль>",
    mechanisms: ["SCRAM-SHA-1"],
    roles: [
        {
            db: "<имя базы-приемника>",
            role: "readWrite"
        }
    ]
});

    После старта трансфер подключится к приемнику от имени этого пользователя.

  7. Чтобы шардировать переносимые коллекции в кластере-приемнике:

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

      Сервис Data Transfer не шардирует переносимые коллекции автоматически. Шардирование больших коллекций может занять продолжительное время и снизить скорость трансфера.

    2. Включите шардирование для базы-приемника:

      sh.enableSharding("<имя базы-приемника>")

    3. Задайте шардирование для каждой коллекции с учетом ее пространства имен:

      sh.shardCollection("<имя базы-приемника>.<имя коллекции>", { <имя поля>: <1|"hashed">, ... });

      Описание функции shardCollection() см. в документации MongoDB.

    4. Чтобы убедиться в том, что шардирование настроено и включено, получите список доступных шардов:

      sh.status()

    5. Если для шардирования используется ключ, отличный от _id (значение по умолчанию), назначьте системную роль clusterManager пользователю, от имени которого сервис Data Transfer будет подключаться к кластеру-приемнику:

      use admin;
db.grantRolesToUser("<имя пользователя>", ["clusterManager"]);

    6. При создании эндпоинта для приемника выберите политику очистки DISABLED или TRUNCATE.

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

    Подробнее о шардировании см. в документации MongoDB.

Приемник MySQL

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

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

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

    1. Назначьте пользователю роль ALL_PRIVILEGES для базы-приемника.

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

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

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

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

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

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

Приемник Yandex Object Storage

  1. Создайте бакет нужной вам конфигурации.
  2. Создайте сервисный аккаунт с ролью storage.uploader.

Приемник PostgreSQL

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

  2. Отключите на приемнике следующие настройки:

    • проверку целостности внешних ключей;
    • триггеры;
    • другие ограничения (constraints).

    Важно

    Не включайте эти настройки до окончания трансфера. Это обеспечит целостность данных по внешним ключам.

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

  3. Включите те же расширения в базе приемника, что и в базе источника.

  4. Создайте пользователя с доступом к базе приемника.

    После старта трансфер подключится к приемнику от имени этого пользователя.

  5. Если в приемнике включена опция сохранение границ транзакций, выдайте созданному пользователю все привилегии на создание служебной таблицы __data_transfer_lsn в текущей схеме (обычно public) на приёмнике:

    GRANT ALL PRIVILEGES ON SCHEMA <имя схемы> TO <имя пользователя>;

  6. Убедитесь, что на приемнике выбрана политика очистки DROP таблиц трансфера.

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

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

  3. Отключите на приемнике следующие настройки:

    • проверку целостности внешних ключей;
    • триггеры;
    • другие ограничения (constraints).

    Важно

    Не включайте эти настройки до окончания трансфера. Это обеспечит целостность данных по внешним ключам.

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

  4. Включите те же расширения в базе приемника, что и в базе источника.

  5. Убедитесь, что на приемнике выбрана политика очистки DROP таблиц трансфера.

  6. Создайте пользователя:

    CREATE ROLE <имя пользователя> LOGIN ENCRYPTED PASSWORD '<пароль>';

  7. Выдайте созданному пользователю все привилегии на базу данных, схемы и переносимые таблицы:

    GRANT ALL PRIVILEGES ON DATABASE <имя базы> TO <имя пользователя>;

    Если база не пустая, то пользователь должен быть ее владельцем (owner):

    ALTER DATABASE <имя базы> OWNER TO <имя пользователя>;

    После старта трансфер подключится к приемнику от имени этого пользователя.

  8. Если в приемнике включена опция сохранение границ транзакций, выдайте созданному пользователю все привилегии на создание служебной таблицы __data_transfer_lsn в текущей схеме (обычно public) на приёмнике:

    GRANT ALL PRIVILEGES ON SCHEMA <имя схемы> TO <имя пользователя>;

Сервис не переносит материализованные представления (MATERIALIZED VIEW). Подробнее см. в разделе Особенности работы сервиса с источниками и приемниками.

Приемник Yandex Managed Service for YDB

Создайте сервисный аккаунт с ролью ydb.editor.

Airbyte® является зарегистрированным товарным знаком Airbyte, Inc в США и/или других странах.

Greenplum® и Greenplum Database® являются зарегистрированными товарными знаками или товарными знаками VMware, Inc в США и/или других странах.

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