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

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

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

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

2. Создайте пользователя с доступом к базе источника. В настройках пользователя укажите для параметра Max execution time значение не менее 1000000.

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

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

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. Оцените общее количество баз данных для трансфера и общую нагрузку на Yandex StoreDoc. Если нагрузка на базы выше 10 000 операций на запись в секунду, создайте несколько эндпоинтов и трансферов. Подробнее см. в разделе Передача данных из эндпоинта-источника MongoDB/Yandex StoreDoc (Managed Service for MongoDB).

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

1. Включите режим полного бинарного лога на источнике, установив значение FULL или NOBLOB для параметра Binlog row image.

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

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

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

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

4. Для типов трансфера Репликация и Копирование и репликация таблицы без уникальных индексов не переносятся.

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

   Чтобы сохранить работоспособность трансфера при переносе базы, содержащей таблицы без уникальных индексов:

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

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

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

        SELECT
            tab.table_schema AS database_name,
            tab.table_name AS table_name,
            tab.table_rows AS table_rows,
            tco.*
        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
        )
        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®.

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

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

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

  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. Выдайте пользователю права на чтение таблиц, которые нужно скопировать.

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

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

     CREATE USER <имя_пользователя> IDENTIFIED BY <пароль>;
     ALTER USER <имя_пользователя> DEFAULT tablespace USERS TEMPORARY tablespace TEMP;
     ALTER USER <имя_пользователя> quote unlimited on USERS;
     
     GRANT 
         CREATE SESSION,
         execute_catalog_role,
         SELECT ANY TRANSACTION,
         SELECT ANY DISCTIONARY,
         CREATE PROCEDURE,
         LOGMINING 
     TO <имя_пользователя>;
     

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

     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 SELECT ON dba_objects TO <имя_пользователя>;
     GRANT SELECT ON dba_extents TO <имя_пользователя>;
     
     GRANT EXECUTE ON SYS.DBMS_LOGMNR TO <имя_пользователя>;
     GRANT SELECT ON SYSTEM.LOGMNR_COL$ TO <имя_пользователя>;
     GRANT SELECT ON SYSTEM.LOGMNR_OBJ$ TO <имя_пользователя>;
     GRANT SELECT ON SYSTEM.LOGMNR_USER$ TO <имя_пользователя>;
     GRANT SELECT ON SYSTEM.LOGMNR_UID$ TO <имя_пользователя>;
     

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

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

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

• Если вы работаете в CDB-среде, выполните следующие настройки:

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

     CREATE USER C##<имя_пользователя> IDENTIFIED BY <пароль> CONTAINER=all;
     ALTER USER C##<имя_пользователя> DEFAULT TABLESPACE USERS temporary tablespace TEMP CONTAINER=all;
     ALTER USER C##<имя_пользователя> quota unlimited on USERS CONTAINER=all;
     ALTER USER C##<имя_пользователя> SET container_data = (cdb$root, <имя_вашей_PCB>) CONTAINER=current;
     
     GRANT 
         CREATE SESSION,
         execute_catalog_role,
         SELECT ANY TRANSACTION,
         SELECT ANY DICTIONALY,
         CREATE PROCEDURE,
         LOGMINING,
         SET CONTAINER
     TO C##<имя_пользователя> CONTAINER=ALL;
     

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

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

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

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

     GRANT SELECT ON V$DATABASE TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON V$LOG TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON V$LOGFILE TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON V$ARCHIVED_LOG TO C##<имя_пользователя> CONTAINER=ALL;
     
     GRANT SELECT ON dba_objects TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON dba_extents TO C##<имя_пользователя> CONTAINER=ALL;
     
     GRANT EXECUTE ON SYS.DBMS_LOGMNR TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON SYSTEM.LOGMNR_COL$ TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON SYSTEM.LOGMNR_OBJ$ TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON SYSTEM.LOGMNR_USER$ TO C##<имя_пользователя> CONTAINER=ALL;
     GRANT SELECT ON SYSTEM.LOGMNR_UID$ TO C##<имя_пользователя> CONTAINER=ALL;
     

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

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

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

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

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

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

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

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

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

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

   Если в таблице нет первичных ключей, тогда в логической репликации не будет событий изменений строк (UPDATE, DELETE).

   • Во время трансфера из PostgreSQL в PostgreSQL, если у вас в источнике трансфера не будет исключена таблица без первичных ключей, то вы увидите ошибку:

      failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed: "public"."MY_TBL": no key columns found
     

   • Во время трансфера из PostgreSQL в другую базу данных, если у вас будет добавлена таблица без первичных ключей, то вы увидите ошибку:

     failed to run (abstract1 source): Cannot parse logical replication message: failed to reload schema: primary key check failed: Tables: n / N check failed:
     "public"."MY_TBL": no key columns found
     

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

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

7. Найдите и завершите слишком долгие 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.

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

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

10. Настройте мониторинг WAL-лога.

    Для трансферов типа Репликация и Копирование и репликация используется логическая репликация. Для этого сам трансфер создает слот репликации со значением slot_name, равным идентификатору трансфера, который можно получить, выбрав трансфер в списке ваших трансферов. WAL может расти по разным причинам: из-за долгой транзакции или из-за проблемы на трансфере. Поэтому рекомендуется настроить мониторинг WAL-лога на стороне источника.

    1. Для мониторинга размера использованного хранилища или диска настройте алерт средствами мониторинга (см. описание disk.used_bytes).

    2. Задайте максимальный размер WAL при репликации в настройке Max slot wal keep size. Редактирование данной настройки доступно начиная с 13 версии PostgreSQL. Если вы хотите экстренно запретить операции чтения трансферу, то удалите слот репликации.

       Важно

       При значении настройки -1 (размер не ограничен) открытые логические слоты репликации, из которых не считывается информация, будут препятствовать удалению WAL-файлов. В результате WAL-файлы займут все дисковое пространство и вы потеряете возможность подключаться к кластеру.

    3. Настройте алерт средствами Yandex Monitoring на метрику, которая используется для Total size of WAL files. Пороговые значения должны быть меньше, чем указаны для метрики disk.used_bytes, так как на диске, кроме данных, хранятся временные файлы, WAL-лог и другие типы данных. Текущий размер слота можно мониторить средствами БД через запрос, указав правильный slot_name, равный идентификатору трансфера:

       SELECT slot_name, pg_size_pretty(pg_current_wal_lsn() - restart_lsn), active_pid, catalog_xmin, restart_lsn, confirmed_flush_lsn
       FROM pg_replication_slots WHERE slot_name = '<идентификатор_трансфера>'
       

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

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

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

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

3. Если в кластере включено управление пользователями через SQL, выдайте созданному пользователю права:

   GRANT CLUSTER ON *.* TO <имя_пользователя>
   GRANT SELECT, INSERT, ALTER DELETE, CREATE TABLE, CREATE VIEW, DROP TABLE, TRUNCATE, dictGet ON <имя_базы_данных>.* TO <имя_пользователя>
   GRANT SELECT(macro, substitution) ON system.macros TO <имя_пользователя>
   

   Если управление пользователями через SQL выключено, права назначаются через консоль управления и CLI.

4. Создайте группу безопасности и настройте ее.

5. Назначьте кластеру Managed Service for ClickHouse® созданную группу безопасности.

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

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

• Убедитесь, что количество колонок в источнике не превышает максимальное количество полей в индексах Elasticsearch. Максимальное количество полей задается в параметре index.mapping.total_fields.limit и по умолчанию составляет 1000.

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

  Пример запроса для настройки шаблона

  curl \
      --user <имя_пользователя_Elasticsearch>:<пароль> \
      --header 'Content-Type: application/json' \
      --request PUT "https://<FQDN_кластера_Elasticsearch>:9200/_template/index_defaults" \
      --data '
          {
              "index_patterns": "cdc*",
              "settings": {
                  "index": {
                      "mapping": {
                          "total_fields": {
                              "limit": "2000"
                          }
                      }
                  }
              }
          }'
  

  При такой настройке шаблона, все новые индексы с маской cdc* смогут содержать до 2000 полей.

  Для настройки шаблона можно также использовать интерфейс Kibana.

  Проверить текущее значение параметра index.mapping.total_fields.limit можно с помощью интерфейса Kibana, либо выполнив запрос:

  curl \
      --user <имя_пользователя_Elasticsearch>:<пароль> \
      --header 'Content-Type: application/json' \
      --request GET 'https://<FQDN_кластера_Elasticsearch>:9200/<название_индекса>/_settings/*total_fields.limit?include_defaults=true'
  

• По умолчанию при трансфере данных в единичный индекс задействуется только один хост. Чтобы распределить нагрузку между хостами при передаче больших объемов данных, настройте шаблон, по которому создаваемые индексы будут заранее разбиты на шарды.

  Пример запроса для настройки шаблона

  curl \
      --user <имя_пользователя_Elasticsearch>:<пароль> \
      --header 'Content-Type: application/json' \
      --request PUT 'https://<FQDN_кластера_Elasticsearch>:9200/_template/index_defaults' \
      --data '
          {
              "index_patterns": "cdc*",
              "settings" : {
                  "index" : {
                      "number_of_shards" : 15,
                      "number_of_replicas" : 1
                  }
              }
          }'
  

  При такой настройке шаблона, все новые индексы с маской cdc* будут разбиты на 15 шардов.

  Для настройки шаблона можно также использовать интерфейс Kibana.

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

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

   Важно

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

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

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

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

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

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

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

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

1. Создайте базу данных.

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

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

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

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

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

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

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

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

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

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

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

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

• Убедитесь, что количество колонок в источнике не превышает максимальное количество полей в индексах OpenSearch. Максимальное количество полей задается в параметре index.mapping.total_fields.limit и по умолчанию составляет 1000.

  Важно

  Превышение лимита приведет к ошибке Limit of total fields [1000] has been exceeded и остановке трансфера.

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

  Пример запроса для настройки шаблона

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request PUT "https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_template/index_defaults" \
  --data '
      {
          "index_patterns": "cdc*",
          "settings": {
              "index": {
                  "mapping": {
                      "total_fields": {
                          "limit": "2000"
                      }
                  }
              }
          }
      }'
  

  При такой настройке шаблона все новые индексы с маской cdc* смогут содержать до 2000 полей.

  Для настройки шаблона можно также использовать интерфейс OpenSearch Dashboards.

  Чтобы проверить текущее значение параметра index.mapping.total_fields.limit, выполните запрос:

  curl \
      --user <имя_пользователя_OpenSearch>:<пароль> \
      --header 'Content-Type: application/json' \
      --request GET 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/<название_индекса>/_settings/*total_fields.limit?include_defaults=true'
  

• По умолчанию при трансфере данных в единичный индекс задействуется только один хост. Чтобы распределить нагрузку между хостами при передаче больших объемов данных, настройте шаблон, по которому создаваемые индексы будут заранее разбиты на шарды.

  Пример запроса для настройки шаблона

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_template/index_defaults' \
  --data '
      {
          "index_patterns": "cdc*",
          "settings" : {
              "index" : {
                  "number_of_shards" : 15,
                  "number_of_replicas" : 1
              }
          }
      }'
  

  При такой настройке шаблона, все новые индексы с маской cdc* будут разбиты на 15 шардов.

  Для настройки шаблона можно также использовать интерфейс OpenSearch Dashboards.

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

  • Когда размер индекса превысит 50 ГБ.
  • Когда возраст индекса превысит 30 дней.

  Создать и включить политику можно с помощью запросов. Подробнее о политиках см. в документации OpenSearch.

  Пример запроса для создания политики

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_plugins/_ism/policies/rollover_policy' \
  --data '
      {
          "policy": {
              "description": "Example rollover policy",
              "default_state": "rollover",
              "schema_version": 1,
              "states": [
                  {
                      "name": "rollover",
                      "actions": [
                          {
                              "rollover": {
                                  "min_index_age": "30d",
                                  "min_primary_shard_size": "50gb"
                              }
                          }
                      ],
                      "transitions": []
                  }
              ],
              "ism_template": {
                  "index_patterns": ["log*"],
                  "priority": 100
              }
          }
      }'
  

  Пример запроса для назначения политике псевдонима

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_index_template/ism_rollover' \
  --data '
      {
          "index_patterns": ["log*"],
          "template": {
              "settings": {
                  "plugins.index_state_management.rollover_alias": "log"
              }
          }
      }'
  

  Пример запроса для создания индекса с псевдонимом политики

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request PUT 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/log-000001' \
  --data '
      {
          "aliases": {
              "log": {
                  "is_write_index": true
              }
          }
      }'
  

  Пример запроса для проверки, прикреплена ли политика к индексу

  curl \
  --user <имя_пользователя_OpenSearch>:<пароль> \
  --header 'Content-Type: application/json' \
  --request GET 'https://<адрес_хоста_OpenSearch_с_ролью_DATA>:9200/_plugins/_ism/explain/log-000001?pretty'
  

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

2. При трансфере из PostgreSQL включите те же расширения в базе приемника, что и в базе источника.

   Если в базе источника расширения установлены в пользовательскую схему, и эти расширения используются в DDL переносимых объектов, то вручную создайте в приемнике DDL. В этих DDL обращение к функции должно быть без указания схемы. В политике очистки эндпоинта-приемника установите значение Truncate, чтобы трансфер не удалил эти объекты.

3. Выберите политику очистки таблиц трансфера Drop.

   Если вы вручную создали в приемнике DDL, используйте политику Truncate. При политике Truncate эти DDL не будут удалены.

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

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

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

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

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

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

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

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

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