Очистка и обслуживание базы данных ТестОпс

В процессе эксплуатации объём базы данных неизбежно растёт, поэтому требуется регулярное обслуживание и контроль.

Очистка исторических данных, освобождение места в БД

Самый быстрый и надежный способ очистки исторических данных в БД - это удаление запусков.
Удаление запусков скриптом вызывает каскадное удаление по связям таблиц в БД всех связанных с ними файлов, т.е. сценарии, фикстуры, вложения, все будет удалено. 

⚠️ Удаление запусков не затрагивает тест-кейсы

Инструменты для удаления старых запусков

1. https://github.com/eroshenkoam/allure-testops-utils?tab=readme-ov-file#delete-launches-in-allure-testops

Данный скрипт используется для удаление старых запусков по всем проектам инстанса (решение по критерию что является "старым запуском" для удаления пользователь принимает в рамках требований, в разных проектах это могут быть разные даты)

Параметры, настраиваемые перед запуском скрипта:

docker run -e "ALLURE_ENDPOINT=http://localhost:8080" \
-e "ALLURE_USERNAME=admin" \
-e "ALLURE_PASSWORD=admin" \
-e "PROJECT_ID=2" \
-e "LAUNCH_FILTER=tag = \"delete\" \
-e "LAUNCH_CREATEDBEFORE=30d 0h 0m" \
ghcr.io/eroshenkoam/allure-testops-utils clean-launches

"LAUNCH_FILTER=tag = \"delete\" означает, что удаляться будут запуски только с тегом delete (приведенная фильтрация только как пример).
Чтобы оставить фильтрацию только по времени, эту строку надо поменять на LAUNCH_FILTER="true

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

DO
$do$
DECLARE
batch_size integer := 10;
cnt integer := 0;
launches_left bigint := 0;
BEGIN
DROP TABLE IF EXISTS launches_to_process;
CREATE TEMP TABLE launches_to_process AS
SELECT
l.id as id
FROM
public.launch l
WHERE
-- DEFAULT retention = 3 months
(l.project_id not in (11,19,21) and l.created_date < ( round(extract(epoch from (now() - INTERVAL '3 months') at time zone 'utc') * 1000)))
or
-- Project 11 retention = 6 months
(l.project_id = 11 and l.created_date < ( round(extract(epoch from (now() - INTERVAL '6 months') at time zone 'utc') * 1000)))
or
-- Project 19 retention = 1 month
(l.project_id = 19 and l.created_date < ( round(extract(epoch from (now() - INTERVAL '1 month') at time zone 'utc') * 1000)))
or
-- Project 21 retention = 1 month
(l.project_id = 21 and l.created_date < ( round(extract(epoch from (now() - INTERVAL '1 month') at time zone 'utc') * 1000)))
order by id asc;
LOOP
launches_left := (
SELECT
count(1)
FROM
launches_to_process
);
EXIT WHEN (launches_left < 1);
cnt := cnt + batch_size;
raise notice 'Try to delete an oldest launches... (%)', cnt;
-- Make a list of candidates
CREATE TEMP TABLE launches_to_process_batch AS
select id
from launches_to_process
order by id asc
limit batch_size;
DELETE FROM
launch
WHERE
launch.id IN (select id from launches_to_process_batch);
DELETE FROM
launches_to_process
WHERE
launches_to_process.id IN (select id from launches_to_process_batch);
DROP TABLE launches_to_process_batch;
COMMIT;
-- Wait some time to give a chance for other queries  😃
PERFORM pg_sleep(7);
END LOOP;
DROP TABLE launches_to_process;
END
$do$;

В нем устанавливаются правила по проектно срок хранения, например Для всех проектов кроме (11,19,21) → старше 3 месяцев.
batch_size рекомендуем увеличивать до 100

TEST_RESULT
TEST_RESULT_CUSTOM_FIELD

Autovacuum — настоятельно рекомендуемая к настройке процедура для инстансов с средней и высокой нагрузкой (большим количеством запусков тестов, заметным объемам занимаемого пространства БД 

Автовакуум в PostgreSQL не является вариантом оптимизации или альтернативным способом очистки данных.
Это обязательная фоновая процедура, которая должна быть включена и корректно настроена для любой рабочей инсталляции ТестОпс.

Автовакуум выполняет следующие функции:

• помечает удалённые строки как доступные для повторного использования;
• предотвращает переполнение таблиц “мёртвыми” версиями строк;
• поддерживает работоспособность индексов.

⚠️ Автовакуум не уменьшает физический размер таблиц, но без него:

• база данных быстро деградирует по производительности;
• удаление данных (включая удаление запусков) не приводит к повторному использованию дискового пространства.

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

select
schemaname,
    relname,
    n_live_tup,
    n_dead_tup,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze
from pg_stat_all_tables
where schemaname = 'public'
order by n_dead_tup desc

n_dead_tup - количество мертвых строк в таблице
n_live_tup - количество живых\актуальных строк в таблице

Для настройки 

1. Выполнить запрос

select name, setting
from pg_settings
where name in ('autovacuum_analyze_threshold', 'autovacuum_analyze_scale_factor');

2. Рассчитать на каких количествах мертвых строк будет запускаться autovacuum
Формула для определения необходимости ANALYZE : 

autovacuum_analyze_threshold + (autovacuum_analyze_scale_factor* количество строк в таблице).

К примеру, 

в таблице test_fixture_result_children 13834619 записей, плюс 619398 мертвых. 
Последний раз autovacuum запускался 2024-05-09 08:27:32.604604+00.

Значение параметров:
autovacuum_analyze_threshold = 0.05, autovacuum_analyze_threshold = 50.
Рассчет:
50 + (0.05 * 13833401) = 691720 (5%). т.е автовакум сработает после изменения 72 322 строк.

Альтернативно 
можно выполнять vacuum в ручном режим (но мы рекомендуем настроить autovacuum)

vacuum <tablename>;

VACUUM FULL - процедура, которая вычищает мертвые строки и возвращает дисковое пространство.
Важно понимать, что vacuum full требует даунтайма т.к. блокирует таблицу над которой выполняется процедура. 

Данная процедура подходит в случае, когда уже дисковое пространство использовано под завяз, не производилось удаление исторических данных инстанса ТестОпс, не производился авто вакуум.

Отличия операций VACUUM FULL и AUTOVACUUM

Характеристика	VACUUM FULL	AUTOVACUUM
Операция	Ручная, полная перезапись таблицы	Автоматическая, легковесная очистка
Блокировка таблицы	Да, блокирует таблицу на время	Нет, не блокирует таблицу
Возврат дискового пространства	Да, возвращает пространство операционной системе	Нет, повторное использование пространства внутри таблицы
Влияние на производительность	Высокое (ресурсоемкая операция)	Низкое (фоновый процесс)
Типичный сценарий использования	После массового удаления данных, периодическое обслуживание	Рутинное обслуживание
Триггер	Ручной запуск	Автоматический, на основе пороговых значений