Инструментарий arenadata_toolkit

Дарья Барышева

При установке кластера ADB в базе данных автоматически создается схема arenadata_toolkit. Эта схема предназначена для сбора информации о работе кластера. Входящие в состав схемы таблицы и представления позволяют просмотреть результаты проводимых по расписанию операций VACUUM/ANALYZE, данные о размещении файлов БД, показатели "перекоса данных" (skew) и другое. Кроме этого, с ADB поставляется набор взаимодействующих со схемой arenadata_toolkit скриптов, которые в автоматическом режиме (согласно настроенному расписанию) выполняют различные операции по управлению кластером.

ПРИМЕЧАНИЕ

В пользовательских БД, которые добавляются после установки ADB, схема arenadata_toolkit создается автоматически при первом запуске скрипта operation.py.

Содержимое схемы arenadata_toolkit

Таблицы

Входящие в состав arenadata_toolkit таблицы описаны ниже.

daily_operation

 

Таблица arenadata_toolkit.daily_operation содержит информацию об операциях VACUUM и ANALYZE, проводимых над таблицами базы данных автоматически по расписанию. Содержимое таблицы обновляется ежедневно при запуске соответствующих скриптов vacuum, analyze, vacuum_analyze_pg_catalog.

Столбец Описание

schema_name

Название схемы

table_name

Название таблицы

action

Название операции. Возможные значения:

  • ANALYZE

  • VACUUM

status

Статус операции. Возможные значения:

  • SCS — успешно.

  • ERROR — с ошибкой.

time

Длительность операции (в секундах)

processed_dttm

Дата и время операции
db_files_current

 

Таблица arenadata_toolkit.db_files_current содержит актуальную на момент последнего запуска скрипта collect_table_stats информацию о файлах БД на всех сегментах кластера с привязкой к таблицам, индексам и другим объектам БД (при возможности определения таких связей). Таблица перезаписывается при каждом запуске скрипта.

Столбец Описание

oid

Внутренний идентификатор таблицы (OID)

table_name

Название таблицы

table_schema

Название схемы

type

Тип таблицы. См. pg_class.relkind

storage

Тип хранения данных в таблице. См. pg_class.relstorage

table_parent_table

Название родительской таблицы (NULL при отсутствии). Актуально для партиций

table_parent_schema

Схема родительской таблицы (NULL при отсутствии). Актуально для партиций

table_database

Название базы данных, которой принадлежит таблица

table_tablespace

Название табличного пространства, которому принадлежит таблица

content

Номер сегмента, где физически расположен файл с данными. См. gp_segment_configuration.content

segment_preferred_role

Роль, назначенная сегменту при инициализации системы. См. gp_segment_configuration.preferred_role

hostname

Имя хоста, на котором расположен файл с данными

address

Адрес хоста, используемый для доступа к конкретному сегменту на сегмент-хосте. Может совпадать со значением hostname в системах, не использующих настройку имен хостов для каждого интерфейса (per-interface)

file

Полный путь к файлу с данными

modifiedtime

Время последней модификации файла с данными, возвращаемое системной командой stat. Значение этой временной метки изменяется при модификациях файла: например, при выполнении команд mknod, truncate, utime и write (если записано больше нуля байтов). Значение метки не изменяется при записи или установке информации об inode (владельце файла, группе, количестве жестких ссылок, режиме доступа и т.д.)

file_size

Размер файла с данными в байтах

tablespace_location

Место хранения табличного пространства в файловой системе
db_files_history

 

Таблица arenadata_toolkit.db_files_history хранит историю изменений файлов БД на всех сегментах кластера с привязкой к таблицам, индексам и другим объектам БД (при возможности определения таких связей). Таблица может быть полезна для отслеживания динамики изменения размера БД. Структура таблицы полностью идентична arenadata_toolkit.db_files_current за исключением дополнительного поля collecttime, описанного ниже.

Содержимое arenadata_toolkit.db_files_history обновляется ежедневно при каждом запуске скрипта collect_table_stats (путем копирования актуальных данных из arenadata_toolkit.db_files_current). Таблица не очищается.

Столбец Описание

collecttime

Дата и время сбора информации
operation_exclude

 

Таблица arenadata_toolkit.operation_exclude содержит информацию о схемах БД, к которым не требуется применять операции VACUUM и ANALYZE при запуске соответствующих скриптов vacuum и analyze.

Столбец Описание

schema_name

Название схемы

Представления

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

adb_skew_coefficients

 

Представление arenadata_toolkit.adb_skew_coefficients отображает информацию о наличии "перекосов" (skew) в распределении данных, полученную путем расчета коэффициента вариации (Coefficient of Variation, CV). В отличие от взятого за основу представления Greenplum gp_skew_coefficients, adb_skew_coefficients учитывает физический размер файлов данных таблиц, а не количество их строк, что является более быстрым и точным подходом.

Столбец Описание

skcoid

Внутренний идентификатор таблицы (OID)

skcnamespace

Название схемы, в которой размещена таблица

skcrelname

Название таблицы

skccoeff

Коэффициент вариации (Coefficient of Variation, CV) распределения табличных данных между сегментами, рассчитанный как отношение среднеквадратичного отклонения <file_size> к среднему значению <file_size> по всем сегментам, где <file_size> — это размер файлов текущей таблицы на одном сегменте. Величина skccoeff определяет равномерность распределения данных между сегментами кластера и наличие "перекосов" (skew) при обработке запросов к таблицам. Чем ниже показатель, тем лучше. При высоких значениях параметра рекомендуется пересмотреть политики распределения данных (см. Рекомендации по равномерному распределению данных). Например, если по крайней мере один сегмент кластера хранит более 25% табличных данных по сравнению с другими сегментами, значение skccoeff будет более 10. Однако критичный уровень коэффициента определяется для каждого окружения индивидуально
__db_files_current

 

Представление arenadata_toolkit.__db_files_current позволяет получить ту же информацию, которая регулярно записывается в таблицу db_files_current, но по состоянию на текущий момент — не дожидаясь очередного запуска соответствующего скрипта. Столбцы представления идентичны столбцам таблицы за исключением одного, приведенного ниже.

Столбец Описание

changed_dttm

Время последнего изменения файла с данными, возвращаемое системной командой stat. Значение этой временной метки изменяется при записи информации об inode (владельце, группе, количестве жестких ссылок, режиме доступа и т.д.)
__db_files_current_unmapped

 

Представление arenadata_toolkit.__db_files_current_unmapped выводит информацию о таких файлах БД на всех сегментах кластера, для которых на текущий момент невозможно установить связь с таблицами, индексами и другими объектами БД. То есть это файлы, для которых при автоматическом заполнении таблицы db_files_current остаются незаполненными (NULL) такие поля, как oid, table_name, table_schema и т.д.

Однако необходимо учитывать, что представление __db_files_current_unmapped может показывать файлы, временно оставшиеся без связи. Например, файлы данных таблиц, созданных в транзакции, но еще не закоммиченных. Либо файлы удаленных таблиц, для которых еще не был выполнен CHECKPOINT (после чего такие файлы будут удалены).

Назначение всех столбцов представления можно посмотреть в описании таблицы db_files_current.

Скрипты для обслуживания кластера

Обзор

Скрипты, поставляемые с кластером ADB для его обслуживания, отображаются на вкладке Primary configuration страницы конфигурирования сервиса ADB. Для просмотра списка скриптов необходимо раскрыть узел Crontab → Crontab maintenance scripts в дереве конфигурационных настроек.

Список скриптов для управления кластером ADB
Список скриптов для управления кластером ADB
ВНИМАНИЕ

Если необходима настройка кастомных скриптов, используйте системный crontab (например, /etc/cron.d/custom_gpadmin) под пользователем, отличным от gpadmin. Секция Crontab → Crontab maintenance scripts в ADCM для этой цели не предназначена. В противном случае при переводе переключателя Crontab в неактивное состояние и реконфигурации ADB кастомные скрипты, добавленные через ADCM, будут удалены.

Для запуска скриптов используется планировщик cron. Запуск производится от имени системного пользователя (по умолчанию gpadmin). В интерфейсе ADCM каждый скрипт описывается в виде отдельной строки, включающей:

  • Время запуска скрипта — cron-выражение, описывающее периодичность выполнения скрипта.

  • Путь к скрипту — полный путь к скрипту. В настоящий момент используются два основных скрипта:

    • run_sql_to_gpssh.sh — передает результат выбранного SQL-запроса как bash-команду через gpssh. В качестве аргумента требуется указать путь к SQL-скрипту.

    • operation.py — Python-скрипт, который выполняет различные операции на уровне кластера ADB. Тип операции определяется первым аргументом (например, vacuum, analyze и т.д.).

    Каждый из перечисленных скриптов может, в свою очередь, обращаться к иным SQL-запросам, скриптам и внутренним функциям схемы arenadata_toolkit. Все используемые bash-, Python- и SQL-скрипты хранятся в директории /home/gpadmin/<Arenadata_configs_directory_name>/, где <Arenadata_configs_directory_name> — значение конфигурационного параметра сервиса ADB Advanced → Arenadata configs directory name (по умолчанию arenadata_configs).

  • Аргументы — входные параметры, необходимые для запуска скрипта (при их наличии). Аргументы, доступные для скрипта operation.py, перечислены ниже.

Аргументы скрипта operation.py
Аргумент Описание Значение по умолчанию

Первый позиционный аргумент в списке (без alias)

Имя запрашиваемой операции:

  • vacuum_system_db

  • remove_orphaned_temp_schemas

  • vacuum

  • analyze

  • collect_table_stats

  • vacuum_analyze_pg_catalog

Описание каждой операции приведено в таблице Описание скриптов для обслуживания ADB

 — 

--loglevel

Уровень логирования. Возможные значения:

  • 2 — INFO;

  • 3 — WARNING;

  • 4 — ERROR;

  • 5 — CRITICAL.

Информацию об уровнях логирования можно получить в документации Python

2

--processes

Число процессов-обработчиков. Возможные значения: 1 — 10

10

--timelimit

Период времени, по истечении которого работа скрипта останавливается (в минутах)

 — 

--excludedb

Список БД, которые необходимо исключить из обработки — в дополнение к тем, что игнорируются скриптом operation.py по умолчанию:

  • template0

  • template1

  • postgres

  • gpperfmon

 — 

--vacuum-order

Порядок, в котором команда VACUUM будет применяться к таблицам в пользовательских БД. Параметр может использоваться только при вызове операции vacuum. Возможные значения:

  • newest-first — таблицы, по которым в pg_catalog.pg_stat_last_operation нет данных о проведении операции VACUUM, будут обрабатываться первыми. Для обработки используется функция arenadata_toolkit.adb_vacuum_strategy_newest_first.

  • newest-last — таблицы, по которым в pg_catalog.pg_stat_last_operation нет данных о проведении операции VACUUM, будут обрабатываться последними. Для обработки используется функция arenadata_toolkit.adb_vacuum_strategy_newest_last.

  • Имя кастомной функции в формате <schema_name>.<function_name>. Сигнатура кастомной функции должна быть идентична двум функциям, упомянутым выше, и возвращать список строк, каждая из которых содержит имя схемы и имя таблицы. Если указанная функция отсутствует в каких-либо БД, операция VACUUM к ним не применяется, а в логе сохраняется соответствующее предупреждение. Дополнительную информацию можно получить в разделе Пример использования кастомной функции для VACUUM.

newest-first

Логи запуска скриптов сохраняются в директории /home/gpadmin/<Arenadata_configs_directory_name>/operation_log/ (для скрипта operation.py) и файле gzip_pg_log.log (для скрипта gzip_pg_log.sql). Периодичность очистки логов можно настроить с помощью конфигурационного параметра сервиса ADB Crontab → Delete old maintenane script logs. Значение параметра по умолчанию — 30 дней.

РЕКОМЕНДАЦИЯ

Вносить изменения в скрипты не рекомендуется. Однако, если для какого-либо скрипта требуется обновить время запуска либо добавить/изменить аргументы, следуйте шагам ниже:

  1. Внесите необходимые изменения в секцию Crontab → Crontab maintenance scripts на вкладке Primary configuration страницы конфигурирования сервиса ADB.

  2. Нажмите кнопку Save.

  3. Примените действие Reconfigure к сервису ADB.

Большинство скриптов так или иначе взаимодействует со схемой arenadata_toolkit. Назначение скриптов описано ниже.

Описание скриптов для обслуживания ADB
Номер Скрипт Описание Время запуска в формате HH:mm (UTC)

0

run_sql_to_gpssh.sh → gzip_pg_log.sql

Для каждого сегмента кластера архивирует CSV-логи, которые хранятся в <data_directory>/pg_log и не изменялись более 3 дней (где <data_directory> — директория с данными сегмента)

01:00

1

operation.py → vacuum_system_db

Запускает операцию VACUUM FREEZE для системных БД postgres и template1 (путем запуска vaccumdb -F)

02:00

2

operation.py → remove_orphaned_temp_schemas

Во всех пользовательских БД удаляет более не используемые временные схемы, имена которых начинаются на pg_temp_ и pg_toast_temp_

03:00

3

operation.py → vacuum

06:00

4

operation.py → analyze

11:00

5

operation.py → collect_table_stats

Для всех пользовательских БД:

  1. Собирает актуальную статистику по файлам данных в разрезе сегментов (размер, расположение и т.д.) и пытается определить связи файлов с таблицами, индексами и другими объектами БД. Для этого вызывает представления (view) схемы arenadata_toolkit, которые обращаются к системным таблицам gp_segment_configuration, pg_class, pg_namespace, pg_tablespace, pg_database.

  2. Сохраняет полученную информацию в таблице arenadata_toolkit.db_files_current, предварительно очищая ее содержимое. Некоторые табличные столбцы могут остаться пустыми (NULL), если для файлов не определены соответствующие объекты БД на предыдущем шаге (например, oid, table_name и т.д.).

  3. Добавляет новые данные в таблицу arenadata_toolkit.db_files_history (копируя их из arenadata_toolkit.db_files_current).

21:00

6

operation.py → vacuum_analyze_pg_catalog

  • Запускает операции VACUUM и ANALYZE для схемы pg_catalog во всех пользовательских БД.

  • Записывает результат операции в таблицу arenadata_toolkit.daily_operation.

00:04

08:04

16:04

Пример использования кастомной функции для VACUUM

Ниже приведен пример использования кастомной функции, определяющей порядок, в котором должны обрабатываться таблицы пользовательских БД при выполнении операции VACUUM (см. --vacuum-order в таблице Аргументы скрипта operation.py):

  1. Создайте необходимую функцию, удовлетворяющую следующим условиям:

    • Наличие одного входного параметра типа text. При запуске скрипта operation.py в качестве этого параметра всегда передается значение VACUUM. В теле функции он может не использоваться.

    • Функция должна возвращать набор строк со столбцами table_schema (имя схемы БД) и table_name (имя таблицы БД). Это отсортированный перечень таблиц БД, к которым следует применить операцию VACUUM.

    Например, приведенная ниже функция сортирует таблицы по имени схемы, а затем по имени самой таблицы в алфавитном порядке.

    CREATE OR REPLACE FUNCTION public.adb_vacuum_strategy_custom(actionname text)
	RETURNS TABLE (table_schema name, table_name name)
	LANGUAGE sql
	STABLE
AS $$
	SELECT nspname, relname
	FROM pg_catalog.pg_class c
	JOIN pg_catalog.pg_namespace n ON relnamespace = n.oid
	LEFT JOIN pg_catalog.pg_partition_rule ON parchildrelid = c.oid
	WHERE relkind = 'r' AND relstorage != 'x' AND parchildrelid IS NULL
	AND nspname NOT IN (SELECT schema_name FROM arenadata_toolkit.operation_exclude)
	ORDER BY nspname, relname;

$$
EXECUTE ON MASTER;
    ВНИМАНИЕ

    Функцию необходимо добавить во все пользовательские БД, к которым будет применяться операция VACUUM, т.е. во все БД за исключением системных (template0, template1, postgres, gpperfmon) и тех, что опционально могут быть указаны в аргументе --excludedb скрипта operation.py.

  2. Убедитесь в работоспособности функции:

    SELECT * FROM public.adb_vacuum_strategy_custom('VACUUM');

    Результат:

       table_schema    |    table_name
-------------------+-------------------
 arenadata_toolkit | daily_operation
 arenadata_toolkit | db_files_current
 arenadata_toolkit | db_files_history
 arenadata_toolkit | operation_exclude
 diskquota         | quota_config
 diskquota         | state
 diskquota         | table_size
 diskquota         | target
 kadb              | offsets
 madlib            | migrationhistory
 public            | spatial_ref_sys
 public            | test
 public            | test2
 public            | test3
(14 rows)

  3. В интерфейсе ADCM откройте вкладку Primary configuration страницы конфигурирования сервиса ADB.

  4. Раскройте узел Crontab → Crontab maintenance scripts в дереве конфигурационных настроек и нажмите на описание скрипта, выполняющего операцию vacuum.

    Переход к редактированию аргументов скрипта
    Переход к редактированию аргументов скрипта

  5. В открывшемся окне добавьте в конец строки аргумент --vacuum-order <schema_name>.<function_name>. Пример: --vacuum-order public.adb_vacuum_strategy_custom. Нажмите Apply.

    ВАЖНО

    Имя кастомной функции заполняется в формате <schema_name>.<function_name>, где <schema_name> — имя схемы, в которой создана функция; <function_name> — имя функции. Обратите внимание, что передача аргументов в функцию не поддерживается.
    Добавление аргумента --vacuum-order
    Добавление аргумента --vacuum-order

  6. Нажмите Save для сохранения изменений конфигурации и примените действие Reconfigure к сервису ADB.

    Сохранение изменений в конфигурации ADB
    Сохранение изменений в конфигурации ADB

  7. После запуска скрипта operation.py согласно установленному расписанию просмотрите содержимое лога, созданного в директории /home/gpadmin/<Arenadata_configs_directory_name>/operation_log/ (по умолчанию /home/gpadmin/arenadata_configs/operation_log/). В названии лога фиксируется дата и время запуска — например, 2024-01-24_10:05:01.172592.log.

    Убедитесь, что порядок обработки таблиц соответствует тому, что определен в кастомной функции. Для этого просмотрите записи лога с пометкой DO, означающие запуск команды VACUUM для соответствующих таблиц.

    Обратите внимание, что порядок событий с одинаковой временной отметкой в логе может отличаться от фактического. В этом случае обратите внимание на идентификаторы процессов-обработчиков PoolWorker: чем меньше номер, тем раньше начало обработки.

    Фрагмент лога по операции VACUUM
    2024-01-24 10:05:02,281: INFO: PoolWorker-1: pid=10232: DO: 'vacuum "arenadata_toolkit"."daily_operation";' for 'adb'
2024-01-24 10:05:02,281: INFO: PoolWorker-2: pid=10233: DO: 'vacuum "arenadata_toolkit"."db_files_current";' for 'adb'
2024-01-24 10:05:02,281: INFO: PoolWorker-3: pid=10234: DO: 'vacuum "arenadata_toolkit"."db_files_history";' for 'adb'
2024-01-24 10:05:02,281: INFO: PoolWorker-5: pid=10239: DO: 'vacuum "diskquota"."quota_config";' for 'adb'
2024-01-24 10:05:02,282: INFO: PoolWorker-7: pid=10243: DO: 'vacuum "diskquota"."table_size";' for 'adb'
2024-01-24 10:05:02,281: INFO: PoolWorker-4: pid=10236: DO: 'vacuum "arenadata_toolkit"."operation_exclude";' for 'adb'
2024-01-24 10:05:02,282: INFO: PoolWorker-6: pid=10241: DO: 'vacuum "diskquota"."state";' for 'adb'
2024-01-24 10:05:02,283: INFO: PoolWorker-8: pid=10245: DO: 'vacuum "diskquota"."target";' for 'adb'
2024-01-24 10:05:02,284: INFO: PoolWorker-9: pid=10247: DO: 'vacuum "kadb"."offsets";' for 'adb'
2024-01-24 10:05:02,285: INFO: PoolWorker-10: pid=10249: DO: 'vacuum "madlib"."migrationhistory";' for 'adb'
2024-01-24 10:05:02,341: INFO: PoolWorker-5: pid=10239: DONE: 'vacuum "diskquota"."quota_config";' for 'adb'
2024-01-24 10:05:02,347: INFO: PoolWorker-10: pid=10249: DONE: 'vacuum "madlib"."migrationhistory";' for 'adb'
2024-01-24 10:05:02,347: INFO: PoolWorker-2: pid=10233: DONE: 'vacuum "arenadata_toolkit"."db_files_current";' for 'adb'
2024-01-24 10:05:02,350: INFO: PoolWorker-8: pid=10245: DONE: 'vacuum "diskquota"."target";' for 'adb'
2024-01-24 10:05:02,351: INFO: PoolWorker-6: pid=10241: DONE: 'vacuum "diskquota"."state";' for 'adb'
2024-01-24 10:05:02,352: INFO: PoolWorker-7: pid=10243: DONE: 'vacuum "diskquota"."table_size";' for 'adb'
2024-01-24 10:05:02,353: INFO: PoolWorker-9: pid=10247: DONE: 'vacuum "kadb"."offsets";' for 'adb'
2024-01-24 10:05:02,513: INFO: PoolWorker-5: pid=10239: DO: 'vacuum "public"."spatial_ref_sys";' for 'adb'
2024-01-24 10:05:02,546: INFO: PoolWorker-5: pid=10239: DONE: 'vacuum "public"."spatial_ref_sys";' for 'adb'
2024-01-24 10:05:02,607: INFO: PoolWorker-7: pid=10243: DO: 'vacuum "public"."test";' for 'adb'
2024-01-24 10:05:02,633: INFO: PoolWorker-4: pid=10236: DONE: 'vacuum "arenadata_toolkit"."operation_exclude";' for 'adb'
2024-01-24 10:05:02,647: INFO: PoolWorker-7: pid=10243: DONE: 'vacuum "public"."test";' for 'adb'
2024-01-24 10:05:02,692: INFO: PoolWorker-9: pid=10247: DO: 'vacuum "public"."test2";' for 'adb'
2024-01-24 10:05:02,692: INFO: PoolWorker-10: pid=10249: DO: 'vacuum "public"."test3";' for 'adb'
2024-01-24 10:05:02,967: INFO: PoolWorker-9: pid=10247: DONE: 'vacuum "public"."test2";' for 'adb'
2024-01-24 10:05:02,972: INFO: PoolWorker-10: pid=10249: DONE: 'vacuum "public"."test3";' for 'adb'
2024-01-24 10:05:03,054: INFO: PoolWorker-3: pid=10234: DONE: 'vacuum "arenadata_toolkit"."db_files_history";' for 'adb'
2024-01-24 10:05:03,202: INFO: PoolWorker-1: pid=10232: DONE: 'vacuum "arenadata_toolkit"."daily_operation";' for 'adb'
    ВАЖНО

    • Если в какой-либо БД функция отсутствует, в лог записывается сообщение вида This function <schema_name>.<function_name> does not exist in the database.

    • Если аргумент --vacuum-order имеет недопустимое значение (отличное от newest-first/newest-last и при этом не содержащее точку), в лог записывается сообщение --vacuum-order parameter is only valid for vacuum action or invalid function name.

    В обоих случаях операция VACUUM не будет применяться к БД, при обработке которых зафиксированы ошибки.
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней