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

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

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

Процедура создания резервной копии находится в проработке.

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

Добавление новых экземпляров Scheduler может понадобиться, когда системе не хватает пропускной способности для маршрутизации или мощности для SQL-вычислений.

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

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

Для экземпляров 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 часов).

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

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

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

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

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

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

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

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

• 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.

См. документацию 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.