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

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

Существуют следующие способы установки Tarantool CDC:

• Развертывание в кластере Kubernetes - рекомендуется, если среда развертывания построена на Kubernetes. В результате такого развертывания Tarantool CDC управляется при помощи Helm-чарта и других инструментов Kubernetes. Этот документ описывает именно этот способ установки.
• Развертывание при помощи инструментов Tarantool ATE - рекомендуется, если в среде развертывания нет платформенной оркестрации. В результате такого развертывания управление и тонкая настройка Tarantool CDC осуществляется через файлы конфигурации, сервисы и скрипты 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-x.x.x.tar.gz. Он содержит: a. Архив с Docker-образом Универсального Обработчика потоков данных tarantool-cdc/cdc-worker-all; b. Архив с helm-чартом.

2. Архив с примерами конфигурации для Helm-чарта (имеет название вида tarantool-cdc-helm-samples-x.x.x.tar.gz).

3. Файл конфигурации для панели мониторинга Grafana (имеет название вида tarantool-cdc-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-x.x.x.tar.gz);
   • Архив с примерами конфигурации Helm-чарта (tarantool-cdc-helm-samples-x.x.x.tar.gz);
   • Файл конфигурации для панели мониторинга Grafana (tarantool-cdc-dashboard_revX.json).

   

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

Эта команда разворачивает Kubernetes ресурсы Tarantool CDC в соответствии с параметрами 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. Убедитесь, что в журналах Универсальных Обработчиков отсутствуют ошибки подключения к базам данных:

   • В списке выберите по очереди каждый из подов, у которого в имени есть worker
   • Нажмите клавишу L.

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

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

После запуска Tarantool CDC можно отслеживать состояние работы Универсальных Обработчиков 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