Быстрый старт

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

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

При развертывании в кластере 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 из сети 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 из сети 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 из сети Tarantool CDC (по умолчанию порт 5432).
• Созданы таблицы, дублирующие формат исходных.

• Создан пользователь с ролью public и правами session, create, write, execute.
• Для кластера Tarantool EE должен быть установлен модуль CRUD и включены роли crud-router и crud-storage для соответствующих экземпляров.
• В зависимости от сценария использования в кластере Tarantool EE могут быть выделены отдельные экземпляры с ролью crud-router для эксклюзивного использования Tarantool CDC и минимизации задержек при работе с кластером для других потребителей.
• Могут использоваться все экземпляры с ролью crud-router, но в таком случае будет иметь место взаимное влияние между запросами Tarantool CDC и запросами потребителей.
• Доступно подключение ко всем экземплярам Tarantool c ролью crud-router по HOST из сети Tarantool CDC, в зависимости от выбранного сценария.
• Созданы таблицы, дублирующие формат исходных.

Данные, поступающие в коннектор 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/source-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. Найти раздел tarantool-cdc.
6. Перейти в раздел с нужной версией релиза и скачать следующие артефакты:
   • главный архив (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 в необходимой конфигурации и обеспечить подключение к внешней БД;
• удалить 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. Запустите Helm-чарт.

Конфигурация 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-чарта.

Пример:

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

После развертывания можно отслеживать состояние:

• Обработчиков Tarantool CDC с помощью панели мониторинга Grafana. Файл конфигурации для Grafana входит в пакет поставки и имеет название вида tarantool-cdc-dashboard_revX.json.

• Кластера Tarantool TQE на Stateboard в Tarantool Cluster Manager. Для этого нужно:

  1. В Kubernetes настроить форвардинг HTTP-портов, указав номер порта из параметра tqe.tarantool.tcm.parameters.http.port в конфигурации Helm-чарта:

      
     kubectl port-forward <pod_name> 8081:8081

     Список запущенных подов можно посмотреть командой kubectl get pods. Название нужного пода имеет вид <cdc>-tcm-<code>, где:

     • cdc - название релиза, указанное при запуске команды helm install;
     • code - случайный набор букв, сгенерированный Kubernetes при запуске пода.

     Пример названия пода: cdc-tcm-dblkjdflgskndbglks.

  2. В конфигурации Helm-чарта указать следующие параметры (секция tqe.tarantool):

     • ttConfigEtcdPrefix - префикс для подключения к кластеру ETCD. Рекомендуется задавать то же значение, что и для параметра storage.etcd.prefix в конфигурации ТСМ.
     • ttConfigEtcdHttpRequestTimeout - время ожидания HTTPS-запросов (в сек) от узлов Tarantool к ETCD. Рекомендуется задавать то же значение, что и для параметра storage.etcd.dial-timeout в конфигурации ТСМ.

     Пример:

      
     tqe:  tarantool:    ttConfigEtcdPrefix: "/cdc"    ttConfigEtcdHttpRequestTimeout: 3

  3. В интерфейсе ТСМ выбрать кластер, название которого задано в параметре tqe.tarantool.tcm.initialSettings.cluster в конфигурации Helm-чарта. См. список Cluster в левом верхнем углу интерфейса.

Для обновления развернутого кластера 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