Создание архивной базы данных¶

В случае ухудшения работы сервера Staffcop Enterprise по мере накопления данных, рекомендуется выполнять архивирование данных в виде отдельной БД (базы данных). При этом, архивная БД может быть по-прежнему доступна через ГУИ для просмотра и анализа данных.

В данной статье рассматривается создание архива на уровне одного инстанса Postgres путём организации дополнительного TABLESPACE, который может располагаться на отдельном носителе и, таким образом, минимально затрагивать производительность работы основного сервера. Возможен так же перенос архива на отдельный (внешний) инстанс Postgres, в этом случае надо использовать утилиты pg_dump/pg_restore для переноса базы. Конечный результат действий описанных ниже - возможность выбора БД при входе в Staffcop.

Подготовка ресурсов¶

Перед выполнением архивации необходимо убедиться в наличии свободного места в достаточном объёме. Рекомендуется иметь отдельный диск для хранения архива, что улучшит производительность и упростит дальнейшее администрирование, добавление новых архивов. Если будущая основная база и архивная база располагаются на одном диске, то желательно иметь свободное место в объёме не менее 200% от размера текущей базы.

sudo service staffcop stop
sudo service nginx stop

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

Clickhouse¶

Примечание

Если вы не используете clickhouse, то переходите следущему пункту «Создание TABLESPACE и DATABASE».

Для избежания потери данных в clickhouse выполнить следующие действия.

Заходим в clickhouse и переменовываем имя текущей БД:

staffcop clickhouse
RENAME DATABASE staffcop TO имя_архивной_базы;

Далее необходимо создать новую основную базу в clickhouse:

staffcop clickhouse reinit

После этого можете приступать к следующему пункту.

Создание TABLESPACE и DATABASE¶

Сначала создаём TABLESPACE, как уже было сказано, желательно на отдельном носителе. Для этого создаём папку с правами доступа для postgres и симлинку на неё из рабочей папки postgresql:

sudo mkdir /mnt/separate_disk/archive_2019_05
sudo chmod 700 /mnt/separate_disk/archive_2019_05
sudo chown postgres:postgres /mnt/separate_disk/archive_2019_05
cd /var/lib/posgtresql/11
sudo ln -s /mnt/separate_disk/archive_2019_05 archive_2019_05

В качестве названия папки, TABLESPACE и базы данных рекомендую использовать понятное название, основанное на дате, такое как archive_2017_05. Далее, создаём TABLESPACE:

CREATE TABLESPACE archive_2019_05 LOCATION '/var/lib/postgresql/9.6/archive_2019_05';

Теперь копируем текущую базу в архивную. Здесь может быть выбрана другая тактика, например перенос текущей базы с дальнейшим переименованием, но мы рассмотрим следующее:

CREATE DATABASE archive_2019_05 TEMPLATE staffcop TABLESPACE archive_2019_05;

Здесь мы создали новую базу, скопировав старую. Теперь мы можем удалить из текущей базы staffcop всю лишнюю информацию до определённой даты. Сначала факты:

delete from agent_event where local_time <'2019-06-01';

Либо, если нужно удалить все факты:

truncate table agent_event cascade;

Далее, очищаем измерения:

delete from agent_web where id not in (select distinct web_data_id from agent_event where web_data_id IS NOT NULL);
delete from agent_time where id not in (select distinct time_id from agent_event where time_id IS NOT NULL);
delete from agent_account where id not in (select distinct account_id from agent_event where account_id IS NOT NULL);
delete from agent_appinstallation where id not in (select distinct app_installation_id from agent_event where app_installation_id IS NOT NULL);
delete from agent_application where id not in (select distinct application_id from agent_event where application_id IS NOT NULL);
delete from agent_networkconnection where id not in (select distinct net_data_id from agent_event where net_data_id IS NOT NULL);
delete from agent_dialog where id not in (select distinct dialog_id from agent_event where dialog_id IS NOT NULL);
delete from agent_device where id not in (select distinct device_id from agent_event where device_id IS NOT NULL);
delete from agent_attachedfile where id not in (select distinct attached_file_id from agent_event where attached_file_id IS NOT NULL) and id not in (select distinct app_icon_id from agent_application where app_icon_id is not null);

В случае, если события удалялись не полностью, перестроить таблицу сессий:

sudo staffcop reset_sessions

Создание конфигурационного файла с настройками БД.

В папке /usr/share/staffcop лежит файл (симлинка) local_settings.py (в некоторых случаях есть database_config.py, который имеет приоритет перед local_settings.py), примерно следующего содержания :

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'staffcop',
        'USER': 'staffcop',
        'PASSWORD': 'xxxxxxxxxxxxxxxxxxxxxxxxxxx',
        'HOST': '',
        'PORT': '',
    }
}

Нужно привести его к виду:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'staffcop',
        'USER': 'staffcop',
        'PASSWORD': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
        'HOST': '',
        'PORT': '',
    },
    'archive_2019_05': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'archive_2019_05',
        'USER': 'staffcop',
        'PASSWORD': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
        'HOST': '',
        'PORT': '',
    }
}

Добавить одну секцию, изменим название базы данных, которое будет отображаться при входе (defautl на archive_2019_05), а так же реальное название (staffcop на archive_2019_05). Кроме того, остальные параметры - HOST, PORT если отличаются от текущео сервера, если был перенос на другой инстанс, пароль, если изменён пароль пользователяя БД (если всё выполнялось по шагам данной статьи, то не менялось).

После чего запускаем сервер (staffcop start и nginx start) и открываем веб-интерфейс. В случае, если всё было сделано правильно, то в форме входа увидим выбор базы данных, default или archive_2019_05.

Дополнение¶

Надо понимать, что в созданной таким образом архивной базе данных невозможны никакие изменения, пересчёты отчётов, фильтров и т.п. Все административные скрипты staffcop будут её игнорировать. Сами данные (фильтры, конфиги) можно поменять, но изменения не будут иметь никакого эффекта, поэтому пересчёты сессий и фильтров, если таковые требуются, нужно выполнять до архивации.