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

1. Настройте кластер-источник таким образом, чтобы к нему можно было подключиться из интернета.
2. Настройте права доступа для учетной записи на нужный топик.
3. Чтобы использовать авторизацию по логину и паролю, настройте SASL-аутентификацию.

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

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

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

   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
      

3. Если кластер-источник не использует репликацию, включите ее. Для этого:

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

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

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

      sudo systemctl restart mongod.service
      

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • Создать первичные ключи (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.

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

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

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

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

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

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

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

3. Установите плагин wal2json.

4. (Опционально) если источник репликации — кластер, установите на его хосты плагин pg_tm_aux. Это позволит продолжить репликацию даже после смены хоста-мастера.

5. Таблицы без первичных ключей или идентификаторов реплик не переносятся в режиме репликации (для типов трансфера Реплицировать и Копировать и реплицировать). Чтобы сохранить работоспособность трансфера при переносе базы с такими таблицами, можно:

   • Не переносить такие таблицы, добавив их в черный список в настройках эндпоинта-источника. Данные из таблиц черного списка передаваться не будут.
   • Добавить идентификатор реплики на таблицах без 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;
       

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

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

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

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

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

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

   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
      

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

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

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

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

      sudo systemctl restart mongod.service
      

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

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

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

   use <имя базы>
   

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

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

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

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

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

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

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

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

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

2. Отключите на приемнике:

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

   Это необходимо для обеспечения целостности данных по внешним ключам.

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

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

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

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

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

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

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

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