Руководство по установке

Настоящее Руководство содержит описание установки, обновления и удаления Tarantool Change Data Capture (Tarantool CDC), а также список системных требований.

Способы установки Tarantool CDC:

• В Kubernetes - с помощью Helm-чарта. Этот способ рекомендуется, если ваша инфраструктура уже построена на Kubernetes. Именно он описывается в данном документе.
• На серверах — с помощью Tarantool ATE. Этот способ рекомендуется, если платформенная оркестрация отсутствует. Подробное описание способа смотрите в документации Tarantool ATE.
• Развертывание для быстрого запуска - для тестирования и ознакомления с передачей данных с помощью Tarantool CDC. Этот способ не предназначен для полноценной эксплуатации. Описание этого способа смотрите в Руководстве пользователя.

Минимальные системные требования:

Для установки в кластере Kubernetes:

• Kubernetes v1.28.9 и выше.
• 1 узел управления в конфигурации:
  • Процессор: 2 ядра.
  • Оперативная память: 4 ГБ.
• 1 узел для размещения контейнеров в конфигурации:
  • Процессор: 8 ядер.
  • Оперативная память: 32 ГБ.
• Дополнительное программное обеспечение:
  • k9s или аналоги для работы с кластером.
  • helm для работы с Helm-чартом.
  • kube-prometheus-stack для мониторинга.

Docker-образы из пакета поставки собраны для платформы linux/amd64.

Для установки с помощью инструментов Tarantool ATE:

• Процессор: 4 ядра.
• Оперативная память: 10 ГБ.
• Дисковое пространство: 50 ГБ.

• Обеспечена сетевая связанность между Kubernetes-кластером Tarantool CDC и Источником/Приемником данных.

• Включена логическая репликация (wal_level=logical) для базы данных.
• Обеспечен достаточный объем дискового пространства для хранения WAL.
• Создан пользователь с правами REPLICATION и LOGIN.
• Подключение к базе данных доступно по HOST:PORT из сети Tarantool CDC (по умолчанию порт 5432).

• Tarantool EE обновлен до версии 2.11.x.
• Создан пользователь с ролью replication (для тестирования может использоваться учетная запись суперпользователя admin).
• На всех экземплярах с ролью vshard-storage или crud-storage в кластере Tarantool EE включен Extended WAL (wal_ext = { old = true, new = true }).
• Подключение ко всем экземплярам Tarantool доступно по HOST:PORT из сети Tarantool CDC.

Требования к версиям:

• Поддерживаемые версии: 11.2, 12.1, 12.2, 18c, 19c, 21c, 23c.
• Поддерживаемые издания: XE/DE, SE, SE2, PE, EE.
• Поддерживаемые платформы: Linux64, Solaris x64 (не проверялось), Solaris Sparc (не проверялось).
• Поддерживаемое хранилище: файловая система (ext4, btrfs, xfs, xfs xfs, sshfs).
• Поддерживаемые размеры блоков базы данных: 2 КБ, 4 КБ, 8 КБ, 16 КБ, 32 КБ.
• База данных должна находиться в режиме единственного экземпляра (без RAC).
• Логи (redo и archive) должны размещаться на файловой системе. Логи в ASM не поддерживаются.

Требования к базе данных (Database Object):

• Минимальные требования:

  База данных должна работать в режиме архивного журнала (ARCHIVELOG) и включать минимальное дополнительное ведение журнала (MINIMAL SUPPLEMENTAL LOGGING):

  • Режим ARCHIVELOG нужен для сохранения базой полного онлайн-журнала redo logs, который будет читать OpenLogReplicator.
  • MINIMAL SUPPLEMENTAL LOGGING добавляет информацию в логи redo logs. Строки в этих логах содержат данные только тех столбцов, которые были изменены в операции изменения.

  См. подробнее.

  Пример скрипта:

   
  SHUTDOWN IMMEDIATE;STARTUP MOUNT;ALTER DATABASE ARCHIVELOG;ALTER DATABASE OPEN;ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;ALTER SYSTEM ARCHIVE LOG CURRENT;

• Расширенные требования:

  • [OpenLogReplicator] Чтобы захватывать все транзакции из базы данных (Database Object), рекомендуется включить принудительное ведение журнала (FORCE LOGGING).

    См. подробнее.

    Пример скрипта:

     
    ALTER DATABASE FORCE LOGGING;ALTER SYSTEM ARCHIVE LOG CURRENT;

  • [OpenLogReplicator] Конфигурация FRA. Для считывателя OFFLINE-типа требуется, чтобы была настроена область быстрого восстановления (Fast Recovery Area).

    Подробнее про OFFLINE-чтение (чтение без подключения к базе данных).

    Пример скрипта:

     
    ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 50G;-- for oracle database 11ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u01/app/oracle/fast_recovery_area' scope = both;-- for oracle database 12+-- ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/opt/oracle/fra';

Требования к TABLE (дополнительные требования):

• [debezium-oracle-connector] FULL SUPPLEMENTAL LOGGING

  Это необходимо для правильного анализа событий обновления Debezium (например, UPDATE, DELETE). Уровень ведения журнала для всех столбцов гарантирует, что Oracle фиксирует состояние столбца независимо от того, изменился ли столбец при записи о повторном запуске в журнал повтора. Включение более высокого уровня ведения журнала позволяет Debezium Oracle Connector генерировать события изменений, которые предоставляют точные данные о состоянии строки "до" и "после".

  См. подробнее.

  Пример скрипта включения расширенного логирования для отдельной таблицы или для всей базы данных:

   
  -- ALTER TABLE <SCHEMA_NAME>.<TABLE_NAME> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;-- e.g. :ALTER TABLE USR1.Person ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;-- or you can alter the whole database:ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Создание сервисного пользователя в СУБД:

• Подробнее про требования OpenLogReplicator.
• Подробнее про требования Debezium.
• Пример скрипта создания пользователя, пригодного для эксплуатации OpenLogReplicator и Debezium Oracle Connector:

 
-- Create connector user for Debezium and OpenLogReplicatorCREATE TABLESPACE TBLS1 DATAFILE 'TBLS1.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M;CREATE USER USR1 IDENTIFIED BY USR1PWD DEFAULT TABLESPACE "TBLS1" TEMPORARY TABLESPACE "TEMP";ALTER USER USR1 QUOTA UNLIMITED ON TBLS1;---- Grant OpenLogReplicator needed privileges to USR1GRANT "CONNECT" TO USR1;GRANT "RESOURCE" TO USR1;GRANT SELECT, FLASHBACK ON SYS.CCOL$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.CDEF$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.COL$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.DEFERRED_STG$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.ECOL$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.LOB$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.LOBCOMPPART$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.LOBFRAG$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.OBJ$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.TAB$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.TABCOMPART$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.TABPART$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.TABSUBPART$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.TS$ TO USR1;GRANT SELECT, FLASHBACK ON SYS.USER$ TO USR1;GRANT SELECT ON SYS.V_$ARCHIVED_LOG TO USR1;GRANT SELECT ON SYS.V_$DATABASE TO USR1;GRANT SELECT ON SYS.V_$DATABASE_INCARNATION TO USR1;GRANT SELECT ON SYS.V_$LOG TO USR1;GRANT SELECT ON SYS.V_$LOGFILE TO USR1;GRANT SELECT ON SYS.V_$PARAMETER TO USR1;GRANT SELECT ON SYS.V_$STANDBY_LOG TO USR1;GRANT SELECT ON SYS.V_$TRANSPORTABLE_PLATFORM TO USR1;GRANT SELECT, FLASHBACK ON XDB.XDB$TTSET TO USR1;GRANT SELECT ANY DICTIONARY TO USR1;DECLARE    CURSOR C1 IS SELECT TOKSUF FROM XDB.XDB$TTSET;    CMD VARCHAR2(2000);BEGIN    FOR C IN C1 LOOP        CMD := 'GRANT SELECT, FLASHBACK ON XDB.X$NM' || C.TOKSUF || ' TO USR1';        EXECUTE IMMEDIATE CMD;        CMD := 'GRANT SELECT, FLASHBACK ON XDB.X$QN' || C.TOKSUF || ' TO USR1';        EXECUTE IMMEDIATE CMD;        CMD := 'GRANT SELECT, FLASHBACK ON XDB.X$PT' || C.TOKSUF || ' TO USR1';        EXECUTE IMMEDIATE CMD;    END LOOP;END;/---- Grant Debezium needed privileges to USR1GRANT SELECT_CATALOG_ROLE TO USR1 WITH admin OPTION;

Требования к конфигурации OpenLogReplicator для Debezium Oracle Connector:

• Подробнее про Debezium.
• Пример рабочей конфигурации для Oracle Database 11:

 
{  "version": "1.6.0",  "log-level": 4,  "source": [    {      "alias": "S1",      "name": "XE",      "reader": {        "type": "online",        "path-mapping": [          "/u01/app/oracle/oradata",          "/opt/oradata",          "/u01/app/oracle/fra",          "/opt/fra"        ],        "user": "USR1",        "password": "USR1PWD",        "server": "//oracledb:1521/XE"      },      "format": {        "type": "json",        "column": 2,        "db": 3,        "interval-dts": 9,        "interval-ytm": 4,        "message": 2,        "rid": 1,        "schema": 7,        "scn-all": 1,        "timestamp-all": 1      },      "filter": {        "table": [          {            "owner": "USR1",            "table": ".*"          }        ]      }    }  ],  "target": [    {      "alias": "DEBEZIUM",      "source": "S1",      "writer": {        "type": "network",        "uri": "0.0.0.0:27017"      }    }  ]}

• Создан пользователь с правами:

  • CONNECT - подключение к базе данных.
  • CREATE - создание объектов в целевой схеме.
  • SELECT, INSERT, UPDATE, DELETE, TRUNCATE - выполнение базовых операций чтения и изменения данных.

• Сетевые подключения:

  • Подключение к базе данных доступно по HOST:PORT из сети Tarantool CDC (по умолчанию порт 5432).
  • Обеспечены правильная маршрутизация и разрешение DNS-имен, указанных в конфигурации коннекторов к Приемникам данных.

• Схема целевых таблиц в Приемнике данных:

  • В приемнике созданы таблицы, дублирующие формат исходных (набор столбцов и их типы), либо совместимые с ним.

• Создан пользователь с ролью public и правами:
  • session - возможность устанавливать соединение с экземпляром Tarantool.
  • create - создание пространств и индексов.
  • write - выполнение операций вставки, обновления и удаления данных.
  • execute - выполнение хранимых процедур и вызовов crud-функций.
• Настройки кластера Tarantool EE:
  • Установлен модуль CRUD на всех экземплярах кластера.
  • Включены роли crud-router для маршрутизаторов и crud-storage для хранилищ.
• Сценарии подключения Tarantool CDC к кластеру:
  • Выделенные маршрутизаторы — в кластере выделены отдельные экземпляры с ролью crud-router только для использования Tarantool CDC. Это минимизирует задержки и исключает пересечение запросов Tarantool CDC с запросами других потребителей.
  • Общие маршрутизаторы — используются все доступные экземпляры с ролью crud-router. В этом случае запросы Tarantool CDC и других потребителей могут влиять друг на друга.
• Сетевые подключения:
  • Подключение к базе данных доступно по HOST:PORT из сети Tarantool CDC (по умолчанию порт 5432).
  • Обеспечены правильная маршрутизация и разрешение DNS-имен, указанных в конфигурации коннекторов к Приемникам данных.
• Схема целевых таблиц в Приемнике данных:
  • В приемнике созданы таблицы, дублирующие формат исходных (набор столбцов и их типы), либо совместимые с ним.

Данные, поступающие в коннектор ClickHouse, должны быть плоскими относительно мета-структур. Поля записи из Источника не должны быть вложены ни в какую другую структуру. В рамках коннекторов Debezium это означает, что из типичной структуры Debezium нужно убрать первый уровень вложенности:

 
{  "before": null,  "after": {    "id": 1,    "message": "artyom",    ...  },  "source": {    "connector": "postgresql",    ...  },  "op": "c",  ...}

И превратить ее в плоскую структуру:

 
{  "before": null,  "after_id": 1,  "after_message": "artyom",  ...  "source_connector": "postgresql",  ...  "op": "c",  ...}

Это можно сделать с помощью трансформаций, задав нужную конфигурацию обработчика данных. Трансформации можно настроить как на стороне Источника (см. пример ниже), так и на стороне Приемника.

Пример настроек для превращения данных из Источника Postgres в плоские записи:

 
WORKER_CONNECTOR_TRANSFORMS=flattenWORKER_CONNECTOR_TRANSFORMS_FLATTEN_DELIMITER="_"WORKER_CONNECTOR_TRANSFORMS_FLATTEN_TYPE=org.apache.kafka.connect.transforms.Flatten$Value

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

Например, данные из Источника приходят в формате следующей таблицы:

a. Пример для Источника Postgres:

 
CREATE TABLE IF NOT EXISTS demo_table (    id SERIAL PRIMARY KEY,    message VARCHAR(255));

b. Пример для Источника TDG:

 
{    "name": "demo_table",    "type": "record",    "fields": [        { "name": "id", "type": "int" },        { "name": "message", "type": "string" }    ],    "indexes": [        {"name": "pk", "parts": ["id"]}    ],    "affinity": [        "id"    ]}

Тогда временная таблица в ClickHouse должна иметь следующий вид:

 
CREATE TABLE IF NOT EXISTS demo_table (    `before_id` Nullable(UInt32),    `before_message` Nullable(String),    `after_id` Nullable(UInt32),    `after_message` Nullable(String),    `op` LowCardinality(String),    `source_lsn` UInt64)ENGINE = Null;

где:

• Все поля из Источника указываются два раза, с префиксами before и after соответственно. Разделитель между префиксом и именем поля должен соответствовать значению настройки WORKER_CONNECTOR_TRANSFORMS_FLATTEN_DELIMITER. Тип данных должен семантически соответствовать типу, указанному в Источнике.
• op - тип операции.
• source_lsn - номер транзакции записи.
• ENGINE можно заменить на MergeTree, если нужно сохранять промежуточные значения.

Создайте конечную таблицу, с которой будет работать пользователь ClickHouse. Она будет соответствовать временной таблице, но без дублирования полей данных, а также полей op и source_lsn.

Для временной таблицы из предыдущего раздела создайте конечную таблицу следующего вида:

 
CREATE TABLE demo_table_data(    `id` UInt32,    `message` String,    `version` UInt64,    `deleted` UInt8)ENGINE = ReplacingMergeTree(version, deleted)PRIMARY KEY (id)ORDER BY id;

Чтобы передавать данные из временной таблицы в конечную таблицу, создайте материализованное представление (MATERIALIZED VIEW).

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

 
CREATE MATERIALIZED VIEW demo_table_mvTO demo_table_dataASSELECT    if(op = 'd', before_id, after_id) AS id,    if(op = 'd', before_message, after_message) AS message,    if(op = 'd', source_lsn, source_lsn) AS version,    if(op = 'd', 1, 0) AS deletedFROM demo_tableWHERE (op = 'c') OR (op = 'r') OR (op = 'u') OR (op = 'd') OR (op = 'us');

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

Чтобы обеспечить корректную работу с событиями удаления и обновления, представление использует поле номера транзакции (source_lsn) и поле типа операции (op).

Если нет необходимости поддерживать события обновления и удаления, конфигурацию создания таблиц можно упростить:

 
CREATE TABLE IF NOT EXISTS demo_table (    `after_id` Nullable(UInt32),    `after_message` Nullable(String))ENGINE = Null;CREATE MATERIALIZED VIEW demo_table_mvTO demo_table_dataASSELECT    `after_id` as id,    `after_message` as messageFROM demo_table;CREATE TABLE demo_table_data(    id UInt32,    message String)ENGINE = MergeTree()ORDER BY id;

Пакет поставки Tarantool CDC включает:

1. Основной архив с названием вида tarantool-cdc-bundle-<os>-x.x.x.tar.gz. Где os - это название операционной системы, дистрибутив которой использован для Docker образов. Он содержит:
   • Архив с Docker-образом Универсального Обработчика cdc-worker-all-x.x.x.docker-image.tar.gz.
   • Jar-файл с java-приложением Универсального Обработчика cdc-worker-x.x.x.jar.
   • Helm-чарт.
   • Директория с файлами настройки коннекторов и преобразователей (SMT) plugins.
2. Файл конфигурации для панели мониторинга Grafana (название вида universal-workers-dashboard_revX.json).

Пакет поставки выложен в Customer zone в папке tarantool-cdc/release/linux/x86_64/.

Для получения доступа:

1. В браузере откройте веб-сайт Tarantool.
2. В верхнем меню сайта нажмите кнопку Вход. Открывается форма авторизации для входа в учетную запись.
3. Введите реквизиты для авторизации (логин и пароль).
4. Нажмите кнопку Вход.
5. В верхнем меню сайта нажмите на значок Профиль.
6. В выпадающем меню нажмите кнопку Личный кабинет.
7. В пространстве с папками продуктов в поле Search for names введите tarantool-cdc.
8. Нажмите на найденное имя продукта. Откроется страница с версиями релиза.
9. Перейдите в раздел с нужной версией релиза и скачайте следующие артефакты:
   • Основной архив (tarantool-cdc-bundle-<os>-x.x.x.tar.gz).
   • Файл конфигурации для панели мониторинга Grafana (universal-workers-dashboard_revX.json).

Для установки загрузите образы из архива tarantool-cdc-bundle-<os>-x.x.x.tar.gz в Container Registry, доступный для Kubernetes-кластера Tarantool CDC.

Tarantool CDC может быть развернут:

• С помощью инструментов Tarantool ATE. Перед развертыванием с помощью Tarantool ATE ознакомьтесь с информацией по настройке Универсального Обработчика.
• В кластере Kubernetes с помощью Helm-чарта.

При развертывании Tarantool CDC важно соблюдать требования к окружению.

Helm-чарт - это установщик, позволяющий развертывать приложение Tarantool CDC в Kubernetes. Архив с Helm-чартом входит в главный архив пакета поставки и именуется по шаблону cdc-helm-chart-x.x.x.tar.gz.

Этот Helm-чарт обеспечивает согласованную работу приложений Tarantool CDC, и упрощает управление ими в кластере Kubernetes. Он позволяет:

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

  • Параметры образов и общих настроек развертывания.
  • Конфигурации Источников и Приемников данных.
  • Правила передачи данных между ними.
  • Параметры хранения контрольных точек и размещения подов в Kubernetes.

• Удалить Tarantool CDC при необходимости.

В архив Helm-чарта входят различные файлы и папки, среди которых есть два YAML-файла:

• Chart.yaml. В этом файле находится описание Helm-чарта, а также указаны две версии:
  • version - версия Helm-чарта.
  • appVersion - версия Tarantool CDC.
• values.yaml. Этот файл является основным местом конфигурирования Helm-чарта.

Версии указаны в формате x.y.z, где x - мажорная (major) версия, y — минорная (minor) версия, а z - версия патча (patch). Версии Helm-чарта и Tarantool CDC могут отличаться по номеру патча. Мажорная и минорная части обеих версий должны совпадать.

Порядок работы с Helm-чартом при развертывании Tarantool CDC следующий:

1. Распакуйте главный архив и локально сохраните входящий в него архив с Helm-чартом.
2. Сконфигурируйте Helm-чарт.
3. Запустите CDC.

Конфигурация Helm-чарта задается с помощью файла values.yml. Этот файл должен содержать конфигурацию всех Источников и Приемников данных, а также дополнительные настройки передачи данных между ними.

Файл values.yaml состоит из нескольких разделов:

• global - содержит глобальные параметры образа: реестр, правила загрузки образов и секреты.
• securityContext - позволяет задать дополнительные параметры безопасности, такие как запуск от имени пользователя, не являющегося root, uid пользователя и так далее.
• image - содержит параметры, указывающие где и как загружать образы для развертываний Обработчиков.
• livenessProbe - описывает параметры проверок жизнеспособности. См. документацию k8s о пробах.
• startupProbe - описывает параметры проверок запуска (startup probes). См. документацию k8s о пробах.
• persistence - описывает параметры поддержки постоянного хранения для всех Обработчиках под управлением Helm-чарта.
• defaultResources - ресурсы (requests/limits CPU и ресурсы памяти), применяемые ко всем Обработчикам, для которых в элементе списка flow не заданы собственные resources. Значение flow[].resources полностью переопределяет значение по умолчанию (без объединения). Доступно с версии Tarantool CDC 0.12.1.
• defaultEnv - переменные окружения, применяемые ко всем Обработчикам по умолчанию. Значение flow[].env переопределяет отдельные переменные по имени; переменные, заданные через secretRefs, имеют приоритет над значениями по умолчанию. Доступно с версии Tarantool CDC 0.12.1.
• sources - описывает все настройки подключений к Источникам. Для каждого Источника укажите раздел common. Параметры раздела common соответствуют параметрам раздела sources в файле application.yaml Универсального Обработчика. Раздел configs содержит массив объектов с индивидуальными параметрами, которые дополняют или переопределяют настройки из раздела common. Так, если configs является пустым массивом, то конфигурация из common будет использоваться как единственная конфигурация. В противном случае каждый объект из configs будет объединен с конфигурацией из common и использован как отдельный экземпляр конфигурации Источника данных. См. подробнее о коннекторах к Источникам данных.
• sinks - описывает все настройки подключений к Приемникам. Для каждого Приемника укажите раздел common. Параметры раздела common соответствуют параметрам раздела sink в файле application.yaml Универсального Обработчика. Раздел configs содержит массив объектов с индивидуальными параметрами, которые дополняют или переопределяют настройки из раздела common. Так, если configs является пустым массивом, то конфигурация из common будет использоваться как единственная конфигурация. В противном случае каждый объект из configs будет объединен с конфигурацией из common и использован как отдельный экземпляр конфигурации Приемника данных. См. подробнее о коннекторах к Приемникам данных.
• offset - настройки работы с контрольными точками. Cоответствуют описанию раздела offset в файле application.yaml Универсального Обработчика.
• flow - список конвейеров от Источника данных к Приемнику данных. Каждый элемент списка должен соответствовать структуре:
  • source - имя Источника данных, указанное в разделе sources.
  • sink - имя Приемника данных, указанное в разделе sinks.
  • throttle - настройки для ограничителя трафика. Cоответствуют описанию раздела throttle в файле application.yaml Универсального Обработчика.
  • resources - декларация ресурсов.
  • affinity - декларация правил размещения.
  • nodeSelector - декларация селектора узлов (нод).
  • tolerations - декларация допусков.
  • matchLabels - декларация меток для селектора.
  • templateLabels - декларация меток для шаблона.

Cтруктура файла values.yaml представлена в примере ниже:

 
global:  imagePullSecrets:    - name: argocd-tarantoolsecurityContext: {}image:  repository: registry-gitlab.corp.mail.ru/tarantool/cdc/v9/tarantool-cdc/cdc-worker-all  tag: 0.11.0  pullPolicy: IfNotPresentlivenessProbe:  timeoutSeconds: 15  failureThreshold: 15  successThreshold: 1startupProbe:  timeoutSeconds: 15  failureThreshold: 15  successThreshold: 1persistence:  enabled: false  storageClassName: ""  storageSize: ""  mountPath: "/data"sources:  source-1:    common:      connector:        class: io.tarantool.connector.MockSourceConnector        mock.schema.string: |          [            {   "weight": 1,                "name": "User",                "type": "record",                "fields": [                    {                        "name": "id",                        "type": {                            "type": "int",                            "arg.properties": {                                "range": {                                    "min": 0,                                    "max": 2147483647                                }                            }                        }                    },                    {                        "name": "name",                        "type": {                            "type": "string",                            "arg.properties": {                                "regex": "[a-zA-Z]{5,255}"                            }                        }                    }                ]            }          ]    configs:      - connector:          task.id: task-1      - connector:          task.id: task-2sinks:  sink-1:    common:      connector:        class: io.tarantool.connector.MockSinkConnector        task.id: task-1        tasks.max: 1  sink-2:    common:      connector:        class: io.tarantool.connector.MockSinkConnector        task.id: task-2        tasks.max: 1offset:  storage:    type: file    file.name: "/data/offsets.dat"flow:  - source: source-1    sink: sink-1    resources:      requests:        cpu: 500m      limits:        cpu: 500m        memory: 1024Mi    throttle:      throttler.max.rps: 1000  - source: source-1    sink: sink-2    resources:      requests:        cpu: 500m      limits:        cpu: 500m        memory: 1024Mi    throttle:      throttler.max.rps: 1000

После того как конфигурация Helm-чарта задана, разверните Tarantool CDC с помощью утилиты helm:

 
helm install <release_name> <path_to_chart> --namespace <namespace> --values <path_to_values.yml>

где:

• <release_name> - название установки, например cdc.
• <path_to_chart> - путь к локально сохраненному архиву с Helm-чартом.
• <namespace> - название пространства имен (namespace).
• <path_to_values.yml> - путь к конфигурации Helm-чарта.

Эта команда разворачивает ресурсы Tarantool CDC в Kubernetes согласно параметрам Helm-чарта и его файла values.yml. После выполнения команды Kubernetes начинает создание и запуск подов Tarantool CDC (запуск всех подов может занять 1-2 минуты).

Пример:

 
helm install cdc ./helm-chart-cdc/ --namespace my-namespace --values my-values.yml

Убедиться, что компоненты Tarantool CDC успешно созданы и запущены в Kubernetes кластере можно двумя способами:

• С помощью kubectl - стандартной командной утилиты Kubernetes.
• С помощью K9s - интерактивного консольного интерфейса для работы с Kubernetes.

1. Проверьте, что Helm установил релиз Tarantool CDC в пространстве имен:

    
   helm list -n <namespace>

   Вывод команды должен показать релиз Tarantool CDC в статусе deployed (установлен).

2. Проверьте статусы подов в пространстве имен с установленным Tarantool CDC:

    
   kubectl get pods -n <namespace>

   При успешной установке все поды постепенно перейдут в статусы Running или Completed. Если под находится в статусе Init, это означает, что он еще проходит инициализацию. Тогда подождите 1–2 минуты и повторите проверку.

3. Проверьте журналы Универсальных Обработчиков и убедитесь, что в них отсутствуют ошибки подключения к Источникам или Приемникам данных:

    
   kubectl logs <worker_pod_name> -n <namespace>

   Эту проверку рекомендуется выполнить для каждого пода, в имени которого есть worker.

1. Установите локально K9s.

2. В K9s откройте список всех подов в пространстве имен с установленным Tarantool CDC:

    
   k9s -n <namespace>

3. В интерфейсе K9s откройте список подов и проверьте колонку STATUS. При успешной установке все поды Tarantool CDC должны находиться в статусе Running или Completed. Если под находится в статусе Init, это означает, что он еще проходит инициализацию. Статус такого пода самостоятельно обновится после завершения этого этапа.

4. Убедитесь, что в журналах Универсальных Обработчиков отсутствуют ошибки подключения к базам данных: a. В списке по очереди выберите каждый под, в имени которого есть worker.

   б. Нажмите клавишу L.

   В журналах не должно быть:

   • Ошибок подключения вида: connection refused, i/o timeout, failed to connect.
   • Ошибок доступа вида: access denied, authentication failed.
   • Бесконечных попыток переподключения вида: reconnecting..., retry attempt.

После запуска Tarantool CDC состояние Универсальных Обработчиков можно отслеживать с помощью панели мониторинга в Grafana.

Файл конфигурации Grafana входит в пакет поставки и имеет название вида universal-workers-dashboard_revX.json.

Для обновления развернутого кластера Tarantool CDC до нужной версии:

1. Внесите необходимые изменения в конфигурацию Helm-чарта.

2. Остановите кластер и удалите старую версию Tarantool CDC:

    
   helm uninstall <release_name>

3. Установите новую версию Tarantool CDC и запустите кластер:

    
   helm install <release_name> <path_to_chart> --namespace <namespace> --values <path_to_values.yml>

   Пример:

    
   helm install cdc ./helm-chart-cdc-NEW/ --namespace my-namespace --values my-values-NEW.yml

Для удаления развернутого кластера Tarantool CDC выполните команду:

 
helm uninstall <release_name> --namespace <namespace>

где:

• <release_name> - название релиза, например cdc.
• <namespace> - название пространства имен (namespace).

Пример:

 
helm uninstall cdc --namespace my-namespace