Руководство администратора

Данное Руководство адресовано системным администраторам, занимающимся настройкой и администрированием системы Tarantool Column Store (TCS). Их круг задач включает:

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

См. документацию по инсталлятору Ansible Tarantool Enterprise, глава Автоматическое резервирование.

Для добавления нового экземпляра Scheduler с помощью инсталлятора Ansible Tarantool Enterprise:

1. Добавьте экземпляры Scheduler в инвентарь TCS.

2. Запустите плейбук tcs/install.yml, указав в переменной tarantool_shared_hosts список имен экземпляров, которые нужно установить и запустить. При необходимости задайте параметр limit.

   См. [Пример вызова плейбука tcs/install.yml для добавления экземпляра}.

3. (Обязательно!) Перезагрузите конфигурацию кластера в etcd, чтобы восстановить конфигурацию запущенных ранее экземпляров Scheduler и Storage.

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

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

См. [Настройка кластера в режиме шардирования}.

Инсталлятор Ansible Tarantool Enterprise предоставляет следующие сценарии по управлению кластером (см. соответствующие разделы в документации по инсталлятору Ansible Tarantool Enterprise):

• Tarantool 3.0: Отправка конфигурации в etcd
• Запуск экземпляр(ов)
• Остановка экземпляра(ов)
• Перезагрузка экземпляра(ов)
• Автоматическое резервирование
• Автоматическое восстановление

Tarantool Cluster Manager – это административная панель для настройки и отслеживания кластеров, а также управления ими. Основные задачи, доступные через веб-интерфейс TCM:

• Создание/остановка кластера и изменение его конфигурации:
  • Переключение лидера в наборах реплик;
  • Изменение некоторых других настроек кластера, с простоем и в runtime;
  • Исключение экземпляра из кластера.
• Управление пользователями и ролями в кластере:
  • Управление пользователями Tarantool;
  • Изменение паролей пользователей Tarantool Enterprise.
• Контролируемое аварийное переключение узлов кластера;
• Восстановление и пересоздание экземпляров;
• Проверка работоспособности кластера;
• Настройка и просмотр журналов аудита.

См. документацию по Tarantool Cluster Manager.

Схема данных задается с помощью команд SQL DDL.

Чтобы привязать экземпляры Tarantool к узлам NUMA, нужно отредактировать конфигурационные файлы сервисов SystemD.

1. Зайдите на сервер TCS с экземплярами Storage по SSH.

2. Переключитесь на пользователя tarantool:

    
   sudo su tarantool

3. Установите переменную окружения для работы с SystemD в userspace:

    
   export XDG_RUNTIME_DIR=/run/user/$(id -u)

   Объяснение: Это нужно для выполнения команд утилит SystemD (systemctl, journalctl) в userspace.

   Рекомендация: Чтобы не выполнять экспорт каждый раз, можно добавить команду export XDG_RUNTIME_DIR=/run/user/$(id -u) в файл $HOME/.profile.

4. Посмотрите список сервисов пользователя tarantool:

    
   systemctl --user list-units --type=service

   Пример вывода:

    
   tarantool@tcs-testing-1:~$ systemctl --user list-units --type=service  UNIT                               LOAD   ACTIVE SUB     DESCRIPTION  tarantool-cluster-manager.service  loaded active running Tarantool Cluster Manager  tcs-scheduler@scheduler-01.service loaded active running Tarantool Column Store scheduler API service● tcs@i-01.service                   loaded failed failed  Tarantool application tcs@i-01 #сервис инстанса стораджа

   В примере выше:

   • tcs@i-01.service – полное название сервиса для экземпляра с именем i-01;
   • tcs – название приложения Tarantool.

   В директории $HOME/.config/systemd/user находятся:

   • Шаблонный сервис для всех экзепляров tcs@.service;
   • Символическая ссылка на шаблонный сервис tcs@i-01.service.

5. Откройте шаблонный сервис для экземпляров Storage:

    
   vim $HOME/.config/systemd/user/tcs@.service

6. В шаблонном сервисе посмотрите путь до исполняемого файла tarantool:

    
   [Service]Type=simpleExecStart="/app/tarantool/tcs/bin/tcs.%i/tarantool --name %i" # запоминаем этот путьRestart=on-failure RestartSec=2

   Объяснение:

   При автоматическом развертывании TCS исполняемые файлы размещаются в разных местах в зависимости от:

   • указанных в настройках путей для размещения файлов;
   • названия приложения (app_name);
   • других параметров конфигурации.

   Вместо того чтобы пытаться угадать правильный путь к исполняемому файлу Tarantool при настройке службы (в параметре ExecStart), лучше сразу посмотреть точное расположение файла в конфигурационном файле службы vim ~/.config/systemd/user/tcs@.service.

7. Выполните команду systemctl --user edit название_сервиса_storage для того, чтобы начать редактирование (во временном буфере) файла с перезаписью опций в шаблонном сервисе:

    
   systemctl --user edit tcs@i-01

8. Добавьте перезапись опции ExecStart из секции [Service]. В новом ExecStart указан запуск процесса через утилиту numactl с нужными опциями:

    
   [Service]ExecStart=ExecStart=numactl --cpunodebind=0 --membind=0 /app/tarantool/tcs/bin/tcs.%i/tarantool --name %i

9. Сохраните файл.

   Объяснение: Это действие создаст директорию $HOME/.config/systemd/user/название_сервиса.d и файл override.conf в этой директории.

   Рекомендация: Чтобы в качестве редактора использовался vim (если он уже не используется по умолчанию), можно установить переменную окружения SYSTEMD_EDITOR=vim.

10. Выполните команду для перезагрузки конфигурации systemD:

     
    systemctl --user daemon-reload

11. Перезапустите экземпляр:

     
    systemctl --user restart tcs@i-01

12. После перезапуска можно проверить привязку к NUMA-зоне, найдя ее в файле /proc/${PID}/numa_maps.

 
# Зайти под пользователем tarantool:sudo su tarantool# Установить переменную для работы с SystemD в userspace:export XDG_RUNTIME_DIR=/run/user/$(id -u)# Посмотреть, какие есть сервисы:systemctl --user list-units --type=service# Запустить редактирование интересующего сервиса:systemctl --user edit название_интересующего_сервиса# Добавить в файл:[Service]ExecStart=ExecStart=numactl --cpunodebind=0 --membind=0 /app/tarantool/tcs/bin/tcs.%i/tarantool --name %i# Перезагрузить конфигурацию systemD:systemctl --user daemon-reload# Перезапустить экземплярsystemctl --user restart название_сервиса

Для определения IP-адреса узла в кластере TCS используются следующие параметры:

• протокол Tarantool iproto:

  • (Обязательно) iproto.listen.uri – для входящих запросов (общего назначения).
  • iproto.advertise.client – для взаимодействия с клиентами.

  Пример:

   
  iproto:  listen:    - uri: 0.0.0.0:3331  advertise:    client: 127.0.0.0:3331

• протокол HTTP:

  • (Обязательно) http.listen – для входящих запросов (общего назначения).
  • http.advertise.client – для взаимодействия с клиентами.
  • http.advertise.sharding.uri – для взаимодействия между экземплярами Scheduler и Storage.

  Пример:

   
  roles_cfg:  tcs_roles/storage:    http:      listen: 0.0.0.0:7777      advertise:        client:          127.0.0.1:7777        sharding:          uri: 127.0.0.1:7777

• протокол Apache Arrow Flight:

  • (Обязательно) arrow_flight_sql.listen – для входящих запросов (общего назначения).
  • arrow_flight_sql.advertise.client – для взаимодействия с клиентами.
  • arrow_flight_sql.advertise.sharding.uri – для взаимодействия между экземплярами Scheduler и Storage.

  Пример:

   
  roles_cfg:  tcs_roles/storage:    arrow_flight_sql:      listen: 0.0.0.0:50051      advertise:        client: 127.0.0.1:50051        sharding:          uri: 127.0.0.1:50051

Эти настройки нужны в любом режиме работы кластера.

С помощью следующего SQL-запроса к экземпляру Scheduler можно получить информацию о топологии и номерах ревизии конфигурации на всех экземплярах Storage в кластере TCS:

 
SELECT * FROM tcs_routing_map()

Для каждого экземпляра Storage в кластере возвращается:

• имя набора реплик (поле shard_name);
• имя экземпляра (поле instance_name);
• активен ли данный экземпляр (поле is_enabled);
• режим чтения/записи экземпляра (поле mode);
• номер последней примененной ревизии конфигурации (поле meta_revision).

Информация об экземплярах Scheduler и Coordinator не предоставляется.

SQL-запрос можно делать к любому экземпляру Scheduler в кластере.

Пример ответа:

 
{    "shard_name": "storages-replicaset1",    "instance_name": "storage2",    "is_enabled": true,    "mode": "RO",    "meta_revision": 0},{    "shard_name": "storages-replicaset1",    "instance_name": "storage1",    "is_enabled": true,    "mode": "RW",    "meta_revision": 0}

В этом разделе пошагово описаны типовые сценарии конфигурирования TCS.

См. также:

• Справочник по конфигурации
• Руководство по установке

Укажите следующие параметры в конфигурации TCS:

1. Настройте конфигурацию экземпляров Storage:

   a. Задайте набор реплик с экземплярами типа Storage.

   b. Для всех экземпляров Storage настройте поддержку драйверов JDBC/ADBC.

2. Настройте конфигурацию экземпляров Scheduler:

   a. Задайте набор реплик с экземплярами типа Scheduler.

   b. Для экземпляров Scheduler задайте параметр mode.proxy.target_replicaset и укажите название набора реплик Storage, куда должны перенаправляться запросы.

    
   roles_cfg:  tcs_roles/scheduler:    mode:      proxy:        target_replicaset: storages

См. Пример статического инвентаря для кластера в режиме проксирования.

1. Настройте конфигурацию экземпляров Storage:

   a. Задайте нужное количество наборов реплик (шардов) с экземплярами типа Storage.

   b. Для всех экземпляров Storage:

   • Задайте параметр enable_sharding:true.

      
     roles_cfg:  tcs_roles/storage:    enable_sharding: true

   • Настройте поддержку драйверов JDBC/ADBC.

2. Настройте конфигурацию экземпляров Scheduler:

   a. Задайте набор реплик с экземплярами типа Scheduler.

   b. Для всех экземпляров Scheduler задайте параметр mode.sharded.bucket_count и укажите число на 2-3 порядка больше количества шардов в кластере.

    
   roles_cfg:  tcs_roles/scheduler:      mode:        sharded:          bucket_count: 1000

См. Пример статического инвентаря для кластера в режиме шардирования (с роутерами).

Настройки аутентификации задаются в параметре auth.

Режим аутентификации (no, simple, ciam) задается в параметре auth.provider. Дальнейшая конфигурация зависит от выбранного режима аутентификации.

Пример конфигурации для режима simple:

 
roles_cfg:  # YAML-якорь с общей конфигурацией для всех ролей в кластере  auth: &auth_cfg    provider: simple    username: user    password: secretgroups:  storages:    roles: [tcs_roles/storage, tcs_roles/stateboard]    roles_cfg:      tcs_roles/storage:        auth: *auth_cfg        ...schedulers:  roles: [tcs_roles/scheduler, tcs_roles/cpu]  roles_cfg:    tcs_roles/scheduler:      auth: *auth_cfg      ...

Значения параметров см. в Справочнике по конфигурации.

Пример конфигурации для режима ciam:

 
roles_cfg:  # YAML-якорь с общей конфигурацией для всех ролей в кластере  auth: &auth_cfg    provider: ciam    api_url: http://localhost:4444 # здесь можно указать публичный API URL для Ory Hydra    client_id: 9536bc49-afb8-43d5-a30a-235d62f7a10f    client_secret: FVGxYwMRNxDw7tdFnj5rkuI8rY    jwks: # необязательно      refresh_min_interval_s: 600 # необязательно    jwt:      issuer: http://127.0.0.1:4444      audience: # необязательно        - "localhost"      max_ttl_s: 7200 # необязательно, по умолчанию 3600      leeway_s: 5 # необязательно, по умолчанию 60groups:  storages:    roles: [tcs_roles/storage, tcs_roles/stateboard]    roles_cfg:      tcs_roles/storage:        auth: *auth_cfg        ...schedulers:  roles: [tcs_roles/scheduler, tcs_roles/cpu]  roles_cfg:    tcs_roles/scheduler:      auth: *auth_cfg      ...

Значения параметров см. в Справочнике по конфигурации.

Для экземпляров Storage задайте параметры в разделе arrow_flight_sql:

• (обязательно) credentials – логин и пароль (параметры username и password).
• listen – идентификатор URI с номером порта для соединений по SQL-протоколу Apache Arrow Flight. По умолчанию: 0.0.0.0:50051.
• advertise.client – идентификатор URI с номером порта или доменный Unix-сокет, на котором экземпляр хранилища виден клиентским приложениям в соединениях по SQL-протоколу Apache Arrow Flight.
• advertise.sharding.uri – идентификатор URI с номером порта для связи данного экземпляра хранилища с экземплярами Scheduler по SQL-протоколу Apache Arrow Flight.
• session_expiration_secs – максимальная длительность сессии (в секундах). По умолчанию: 28800 (8 часов).

Пример:

 
roles_cfg:  tcs_roles/storage:    arrow_flight_sql:      listen: "10.95.207.113:50051"      credentials:        username: tcs        password: tcs      advertise:        client: "10.95.207.113:50051"        sharding:          uri: "10.95.207.113:50051"

TCS поддерживает подключение с шифрованием, где все запросы осуществляются по HTTPS:

• входящие внешние запросы к сервисам TCS, а также исходящие ответы;
• внутрикластерные запросы: Scheduler <-> Scheduler, Scheduler <-> Storage, Storage <-> Storage (репликация), а также запросы между экземплярами TCS и etcd.

Настройка подключения по HTTPS производится в конфигурации ролей tcs_roles/storage и tcs_roles/scheduler):

• transport — протокол приема входящих сообщений:
  • plain (по умолчанию) – входящие сообщения будут приниматься по HTTP.
  • tls – входящие сообщения будут приниматься по HTTPS. Если указано это значение, то обязательно должны быть указаны tls_cert_file и tls_key_file.
• tls_cert_file — путь к TLS-сертификату в формате PEM.
• tls_ca_file — путь к TLS-сертификату удостоверяющего центра в формате PEM (опционально, если не используется самоподписанный сертификат).
• tls_key_file — путь к приватному ключу от сертификата.
• tls_ciphers — список шифров для версий TLS до 1.2. Шифры разделяются символом :.
• tls_ciphersuites — список шифров для TLS 1.3. Шифры разделяются символом :.

Если иные настройки не указаны, то по умолчанию используются рекомендации по настройке TLS на сервере Mozilla Intermediate v5.

TCS поддерживает работу с шифрами ГОСТ TLS. Для настройки работы с шифрами ГОСТ требуются следующие настройки:

• указать шифры в tls_ciphers или tls_ciphersuites;
• установить в систему криптографический модуль и подключить его в OpenSSL. Это нужно сделать как на сервере, так и у всех клиентов.

 
storage-1:     advertise_uri: localhost:3301     http_port: 8081     memtx_memory: 2147483648 # 2gb     log: ''     roles_cfg:       tcs_roles/storage:         transport: tls         tls_cert_file: certs/cert.pem         tls_key_file: certs/key.pem

 
storage-1:     advertise_uri: localhost:3301     http_port: 8081     memtx_memory: 2147483648 # 2gb     log: ''     roles_cfg:       tcs_roles/storage:         transport: tls         tls_cert_file: certs/cert.pem         tls_ca_file: certs/ca.pem         tls_key_file: certs/key.pem

 
storage-1:     advertise_uri: localhost:3301     http_port: 8081     memtx_memory: 2147483648 # 2gb     log: ''     roles_cfg:       tcs_roles/storage:         transport: tls         tls_cert_file: certs/cert.pem         tls_key_file: certs/key.pem         tls_ciphers: 'GOST2012-MAGMA-MAGMAOMAC:GOST2012-KUZNYECHIK-KUZNYECHIKOMAC:LEGACY-GOST2012-GOST8912-GOST8912:IANA-GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89'         tls_ciphersuites: ''

Представление для чтения обновляется раз в столько миллисекунд, сколько указано в параметре tcs_roles/storage/rv_update_ms (по умолчанию, 100 мс).

С помощью параметра tcs_roles/storage/rv_gc_ms можно настроить периодичность удаления неиспользуемых представлений для чтения (по умолчанию, 1000 мс).

Для того, чтобы гарантировать актуальность возвращаемых данных в период между обновлениями представлений для чтения, можно включить использование механизма буфера дельт. Для этого нужно задать параметр enable_delta_buffer: true (по умолчанию, буфер дельт не используется).

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

• при прямом обращении на экземпляр Storage буфер дельт должен быть включен на этом экземпляре
• для шардированного кластера буфер дельт должен быть включен на экземпляре Scheduler и, опционально, на экземплярах Storage, если допускаются прямые запросы.

С помощью параметра delta_buffer_soft_memory_limit_mb задается мягкий лимит объема оперативной памяти, используемой буфером дельт (по умолчанию, лимит не задан).

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

При достижении лимита, заданного при помощи delta_buffer_soft_memory_limit_mb, TCS будет пытаться освободить уже неиспользуемые представления для чтения и связанные с ними сегменты буфера дельт, не дожидаясь наступления интервала, определенного в rv_gc_ms.

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

1. Без использования Scheduler:

 
roles_cfg:      tcs_roles/storage: {}    replicasets:      replicaset1:        replication:          failover: manual        leader: storage1        instances:          storage1:            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50051                http:                  listen: 0.0.0.0:7777                enable_delta_buffer: true            iproto:              advertise:                client: 127.0.0.1:3331              listen:                - uri: 127.0.0.1:3331      replicaset2:        ...

2. C ограничением по размеру буфера дельт:

 
roles_cfg:      tcs_roles/storage: {}    replicasets:      replicaset1:        replication:          failover: manual        leader: storage1        instances:          storage1:            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50051                http:                  listen: 0.0.0.0:7777                enable_delta_buffer: true                delta_buffer_soft_memory_limit_mb: 10240 // 10 Gb            iproto:              advertise:                client: 127.0.0.1:3331              listen:                - uri: 127.0.0.1:3331      replicaset2:        ...

3. В шардированном кластере:

 
groups:  storages:    roles:      [        tcs_roles/storage,        tcs_roles/cpu,        tcs_roles/stateboard,        roles.metrics-export,      ]    roles_cfg:      tcs_roles/storage:        enable_sharding: true    replicasets:      ### Наборы реплик Storage ###      storages-replicaset1:        replication:          failover: manual        leader: storage1        instances:          storage1:            iproto:              advertise:                client: 127.0.0.1:3341              listen:                - uri: 127.0.0.1:3341            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50041                http:                  listen: 0.0.0.0:7741          storage2:            iproto:              advertise:                client: 127.0.0.1:3342              listen:                - uri: 127.0.0.1:3342            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50042                http:                  listen: 0.0.0.0:7742      storages-replicaset2:        ...  schedulers:    roles: [tcs_roles/scheduler, tcs_roles/cpu]    roles_cfg:      tcs_roles/scheduler:        mode:          sharded:            bucket_count: 1000    replicasets:      schedulers-replicaset:        ### Наборы реплик Scheduler ###        instances:          scheduler1:            iproto:              advertise:                client: 127.0.0.1:3371              listen:                - uri: 127.0.0.1:3371            roles_cfg:              tcs_roles/scheduler:                arrow_flight_sql:                  listen: 0.0.0.0:50071                http:                  listen: 0.0.0.0:7771                enable_delta_buffer: true

4. В проксированном режиме:

 
roles_cfg:      tcs_roles/storage:        arrow_flight_sql: {}        http: {}    replicasets:      storage-replicaset1:        replication:          failover: manual        leader: storage1        instances:          storage1:            iproto:              advertise:                client: 127.0.0.1:3341              listen:                - uri: 127.0.0.1:3341            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50041                http:                  listen: 0.0.0.0:7777                enable_delta_buffer: true          storage2:            iproto:              advertise:                client: 127.0.0.1:3342              listen:                - uri: 127.0.0.1:3342            roles_cfg:              tcs_roles/storage:                arrow_flight_sql:                  listen: 0.0.0.0:50042                http:                  listen: 0.0.0.0:7778                enable_delta_buffer: true

В TCS заданы ограничения по умолчанию на максимальное время выполнения запросов:

• для всех типов запросов, кроме аналитических расчетов: 5000 мс
• для каждого счетчика в аналитических расчетах: 4500 мс

По истечении этого времени TCS прерывает обработку запроса и присылает ответ HTTP 408 Request timeout.

При необходимости эти значения можно изменить в консоли с помощью Lua-инструкций на всех серверах с Tarantool:

 
require('app.roles.tcs.storage.api').configure_http_timeout_ms({timeout_ms})require('app.roles.tcs.storage.api').configure_computation_max_duration_ms({duration_ms})

Перезагрузка при этом не требуется.

По умолчанию в TCS включена параллельная обработка в рамках каждого запроса. Это касается запросов всех видов – как на чтение, так и на запись. Для настройки служит переменная datafusion.execution.target_partitions, которая задает количество потоков обработки запроса (партиций).

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

При необходимости можно увеличить это значение, в первую очередь чтобы повысить производительность запросов с полным сканрованием (full scan) на больших наборах данных за счет параллельного чтения, сократив время их выполнения и улучшив отзывчивость системы при аналитических нагрузках.

В конфигурации можно задать вид аварийного переключения в случае сбоя экземпляра в наборе реплик:

• manual – ручной режим
• supervised – автоматический режим (требует запуска отдельного экземпляра Tarantool, который выступает в качестве координатора отказоустойчивого кластера)

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

 
failover:  call_timeout: 1  connect_timeout: 1  lease_interval: 10  probe_interval: 1  renew_interval: 10  stateboard:    keepalive_interval: 15    renew_interval: 3

Для значений параметров должна соблюдаться следующая формула:

lease_interval > probe_interval + renew_interval

Описания параметров см. в документации Tarantool.

В конфигурации TCS можно указать номер порта для передачи метрик мониторинга на HTTP-адресе /metrics с экземпляров Storage.

Можно указать следующие номера портов:

• для метрик TCS (по умолчанию 7777):

   
  http:  enabled: true  listen: 0.0.0.0:7777

• для метрик Tarantool (по умолчанию 8081):

   
  roles.metrics-export:  http:    - listen: 0.0.0.0:8081

Модель данных в TCS задается с помощью инструкций SQL DDL и не является частью конфигурации. См. подробнее в разделе Модель данных.

С помощью инструкций SET и SHOW можно установить и проверить значения переменных, которые задают правила выполнения запросов в рамках текущей сессии.

Например:

 
SET datafusion.execution.batch_size to 10000SHOW datafusion.execution.batch_size   name                             value0  datafusion.execution.batch_size  10000

Список переменных приведен в разделе Справочник по переменным.

В TCS доступны следующие виды журналов:

• Журналы событий аудита.
• Системные журналы.

В журнал событий аудита попадают события DML и DDL для экземпляров Scheduler и Storage. То, на каком экземпляре (Scheduler или Storage) создается запись аудита, зависит от режима работы кластера:

• В режиме шардирования SQL исполняется на стороне Scheduler, поэтому записи аудита появляются в журнале Scheduler.
• В режиме проксирования Scheduler только маршрутизирует запрос к Storage, но не является точкой исполнения SQL. Поэтому запись аудита создается в журнале Storage, где реально выполняются SQL-инструкции.

В системные журналы события аудита не попадают.

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

Пример конфигурации журнала аудита:

 
groups:  storages:    roles: [tcs_roles/storage, tcs_roles/cpu, roles.metrics-export]    roles_cfg:      tcs_roles/storage:        audit_log:          level: debug          file_writer:            directory: /tmp/            filename_prefix: tcs_audit

Параметр level указывает уровень событий, которые должны быть записаны в журнал. Параметр может принимать следующие значения:

• debug – запись информации с низким приоритетом;
• info – запись полезной информации (если задан этот уровень, то debug-события в журнал не включаются);
• off – запись отключена (по умолчанию).

В зависимости от выбранного уровня в журнал попадают соответствующие виды событий:

Для каждого события отображаются следующие атрибуты:

• timestamp – время события;

• level – уровень логирования;

• name – название события;

• objects – целевые сущности запроса, они определены следующим образом:

  • для ALTER TABLE RENAME TO – старое и новое имя;
  • для остальных DDL-операций – основной объект операции (например, для CREATE INDEX – имя индекса);
  • для PREPARE/EXECUTE/DEALLOCATE – имя подготовленного запроса;
  • для остальных DML-операций – все задействованные таблицы.

События аудита могут записываться только в файл. Запись в syslog не осуществляется.

В конфигурации необходимо указать директорию (directory) и префикс имени файла (filename_prefix). Например:

 
audit_log:  level: info  file_writer:    directory: ./logs/    filename_prefix: audit_log

В данном примере события аудита хранятся на диске в директории ./logs/, где каждый час создается новый файл с именем вида audit_log.2025-09-08-11.jsonl.

Конфигурация производится отдельно для каждой роли (Scheduler и Storage), а также при необходимости на уровне группы и экземпляра.

Записи доступны в формате JSON. Пример записей:

 
{"timestamp":"2026-06-18T11:31:45.708258Z","level":"INFO","message":"audit log initialized"}{"timestamp":"2026-06-18T11:31:45.708775Z","level":"INFO","name":"create_table","objects":"tcs.public.attributes"}{"timestamp":"2026-06-18T11:37:00.070271Z","level":"DEBUG","name":"insert","objects":"tcs.public.attributes"}{"timestamp":"2026-06-18T11:37:42.926327Z","level":"DEBUG","name":"select","objects":"tcs.public.attributes"}{"timestamp":"2026-06-18T11:37:42.926595Z","level":"INFO","name":"drop_table","objects":"tcs.public.attributes"}

Системные журналы экземпляров Scheduler и Storage записываются в stdout. Эти журналы можно посмотреть следующими способами:

• любым удобным способом для чтения из stdout;

• с помощью journalctl, например:

   
  journalctl | grep scheduler

• с помощью systemctl, например:

   
  # пример для AstraLinux, под пользователем tarantoolexport XDG_RUNTIME_DIR=/run/user/$(id -u)systemctl --user status tarantool_column_store-instance-01@tcs-instance-01

Можно задать уровень событий, которые должны быть записаны в журналы:

• trace, наиболее детальный уровень записи, часто чрезвычайно подробная информация.
• debug, запись информации с низким приоритетом;
• info, запись полезной информации (значение по умолчанию);
• warn, запись информации о потенциально опасных событиях;
• error, запись информации о серьезных ошибках;
• off, отключение записи в журналы.

Уровень событий можно задать с помощью переменной RUST_LOG. Это делается следующими способами:

• с помощью параметра vars.tcs_extra_env в конфигурации TCS – при установке с помощью ATE;
• напрямую через консоль – при установке вручную.

Уровень событий можно задавать как на весь хост, так и для отдельного экземпляра.

Примеры:

• при установке с помощью ATE:

   
  tarantool:  vars:    tcs_extra_env:      TOKIO_WORKER_THREADS: 1      RUST_LOG: error

• при установке вручную:

   
  RUST_LOG=error tt start

Передача метрик для мониторинга TCS осуществляется на HTTP-адресе /metrics у всех экземпляров Storage. Передаются два вида метрик:

• Метрики TCS
• Метрики Tarantool

Номера портов для передачи метрик указываются в конфигурации TCS. По умолчанию – 7777 для метрик TCS, 8081 для метрик Tarantool.

• counter – монотонно возрастающий счетчик значений. Не может быть уменьшен, но может быть сброшен до 0.
• gauge – изменяющееся значение. Может как увеличиваться, так и уменьшаться.
• histogram – распределение значений по заранее определенным группам (buckets).
• summary – агрегация гистограмм. Используется в случаях, когда невозможно заранее выделить группы, по которым необходимо распределить значение.

• tcs_storage_elapsed_compute_milliseconds – процессорное время, потраченное на вычисления на каждом узле (50-90-95-перцентиль, в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_insert_duration_milliseconds – время выполнения операций вставки данных по каждой таблице в колоночном хранилище (50-90-95-перцентиль, в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_update_duration_milliseconds – время выполнения операций изменения данных по каждой таблице в колоночном хранилище (50-90-95-перцентиль, в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_delete_duration_milliseconds – время выполнения операций удаления данных по каждой таблице в колоночном хранилище (50-90-95-перцентиль, в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_latency – время обработки запросов по HTTP-адресам /sql и /insert/{table} (в миллисекундах). Включает в себя HTTP-адрес и метод. Для HTTP-адреса /sql отображает единую гистограмму, без разбиения на таблицы и виды запросов. Тип метрики summary/histogram.

• tcs_storage_statement_duration_milliseconds – время выполнения SQL-инструкций на каждом узле (50-90-95-перцентиль, в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_statement_step_duration_milliseconds – длительность каждого шага выполнения SQL-инструкций (в миллисекундах):

  • план выполнения
  • логический план
  • оптимизация логического плана
  • предвыполнение

  Тип метрики summary/histogram.

• flightsql_handling_milliseconds – время выполнения SQL-инструкций, полученных по протоколу Arrow Flight SQL (в миллисекундах). Отображает следующую информацию:

  • grpc_service – имя gRPC-сервиса
  • grpc_method – имя gRPC-метода
  • grpc_code – код gRPC-статуса
  • statement_name – имя SQL-выражения (либо "unnamed")
  • statement_kind – тип SQL-выражения

  Тип метрики summary/histogram.

• grpc_handling_milliseconds – время выполнения вызова от gRPC-сервера (в миллисекундах). Отображает следующую информацию:

  • grpc_service – имя gRPC-сервиса
  • grpc_method – имя gRPC-метода
  • grpc_code – код gRPC-статуса

  Тип метрики summary/histogram.

• tcs_storage_plan_cache_size – общее количество SQL-планов в кеше. Тип метрики gauge.

• tcs_storage_requests_total – счетчик общего количества аналитических запросов, принятых по HTTP-адресам /sql и /insert/{table}. Включает в себя HTTP-адрес, метод и код ответа. Тип метрики counter.

• tcs_storage_readview_update_count_total – общее количество операций по обновлению представлений для чтения (read view). Тип метрики counter.

• tcs_storage_rows_inserted_total – количество вставленных строк по каждой таблице в колоночном хранилище. Учитываются все типы запросов: и через SQL-драйверы, и через HTTP-адрес /insert. Тип метрики counter.

• tcs_storage_rows_updated_total – количество обновленных строк по каждой таблице в колоночном хранилище. Тип метрики counter.

• tcs_storage_rows_deleted_total – количество удаленных строк по каждой таблице в колоночном хранилище. Тип метрики counter.

• tcs_storage_inserts_total – количество строк, записанных в таблицы с помощью запросов по HTTP-адресам /insert/{table} и /sql. Тип метрики counter.

• tcs_storage_statement_status_total – общее количество подготовленных SQL-запросов (prepared statements). Тип метрики counter.

• tcs_storage_ddl_success_count – количество успешных операций обновления схемы данных. Тип метрики counter.

• tcs_storage_ddl_failure_count – количество неуспешных операций обновления схемы данных. Тип метрики counter.

• tcs_max_rows_waiters_queue_size – количество вставок, ожидающих в очереди на удаление при настроенном вытеснении по MAX ROWS. Тип метрики counter.

• tcs_eviction_batch_size – динамически подбираемое количество строк, которое можно вытеснить в одну итерацию вытеснения за время, задаваемое параметром eviction.slice_ms. Тип метрики counter.

• tcs_ttl_rows_selected_total – количество строк, отобранных для вытеснения. Тип метрики counter.

• tcs_ttl_rows_evicted_total – количество строк, реально вытесненных в результате TTL. Тип метрики counter.

• tcs_ttl_wakeup_count_total – количество срабатываний задачи TTL. Тип метрики counter.

• tcs_evict_request_count – количество пользовательских запросов на вытеснение. Тип метрики counter.

• tcs_ttl_select_duration_milliseconds – длительность выборки данных для вытеснения (в миллисекундах). Тип метрики summary/histogram.

• tcs_ttl_evict_duration_milliseconds – длительность выполнения вытеснения (в миллисекундах). Тип метрики summary/histogram.

• tcs_storage_delta_buffer_size_mb – текущий размер буфера дельт (в мегабайтах). Тип метрики counter.

• tcs_storage_delta_buffer_conflicts_count – количество конфликтов конкурентных операций удаления или обновления строк. Тип метрики counter.

• tcs_storage_readview_lsn_max_distance – разница между LSN (Log Sequence Number) самого нового и самого старого из используемых представлений на чтение. Тип метрики counter.

• tcs_storage_delta_buffer_gc_ms – длительность очистки буфера дельт от неиспользуемых данных (в миллисекундах). Тип метрики summary/histogram.

См. документацию Tarantool.

Пример ошибки в журнале:

 
fatal runtime error: failed to initiate panic, error 5

Если возникают ошибки класса panic, то нужно перезапустить экземпляр.

Если ошибки не проходят, то нужно очистить экземпляр и перезапустить его.

Примеры ошибок в журнале:

 
# вставка с неправильным типомvalue "foo" is not of type: Int32# вставка поля, которого нетcant find field foo in fields index# обновление несуществующего поляerror: cant find field foo in fields index# обновление на неправильный тип данныхerror: value "foo" is not of type: Int32

Примеры ошибок в журнале:

 
couldn't apply the requesterror at request: ...can't initialize storage: Duplicate key exists in unique index "pk" in space "attributes" with old tuple - ...

Экземпляры Storage в TCS обычно разбиты по наборам реплик, где в каждом наборе определен свой мастер-экземпляр.

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

Чтобы спасти старые данные, нужно отложить .xlog-файлы со старого мастер-экземпляра. Скорее всего хватит последнего .xlog-файла, но для уверенности лучше найти .xlog-файл, который начинается со значения vclock, меньшего в соответствующих компонентах, чем последние виденные lsn-значения каждого из двух мастер-экземпляров.

Пример:

После конфликта видим:

• на старом мастер-экземпляре: vclock {1:150, 2:120},
• на новом мастер-экземпляре: vclock {1:110, 2:160}.

Тогда нужен xlog-файл со старого мастер-экземпляра, где vclock будет не больше {1:110, 2:120} (это минимальные lsn-значения по компонентам, которые "видели" оба мастер-экземпляра вместе).

Дальше такой xlog-файл можно только анализировать вручную (например, через tt cat). Представляет интерес самый конец этого xlog-файла – то, что потерялось со старого мастер-экземпляра. То есть записи с id равным 1 и lsn равным с 110 по 150.