Ручная очистка истории или оптимизация базы

[EvGn]

Как в ручную очистить данные триггеров за определенный период?
Как в оптимизировать БД путь удаления или сжатия данных?
Может есть какие-то рекомендации?

[DShegolkov]

Приветствую. У триггера есть два состояния выкл и вкл. Может быть отключить триггеры? или имеется ввиду события?
По поводу удаления неактуальных данных - что-то в духе DELETE FROM zabbix.history WHERE itemid NOT IN (SELECT itemid FROM zabbix.items);
Сжатие данных - в mysql ничего делать не нужно - удалил место освободилось (могу ошибаться). В postgresql есть автовакумация.

[EvGn]

Приветствую. У триггера есть два состояния выкл и вкл. Может быть отключить триггеры? или имеется ввиду события?
По поводу удаления неактуальных данных - что-то в духе DELETE FROM zabbix.history WHERE itemid NOT IN (SELECT itemid FROM zabbix.items);
Сжатие данных - в mysql ничего делать не нужно - удалил место освободилось (могу ошибаться). В postgresql есть автовакумация.

в настройках указал в большинстве пунктов автоочистку после 30 дней, при применении настроек данные старше 30 дней автоматически удалятся?

[nameuser]

Не создаю новую тему, т.к. название топика отражает суть моего вопроса.
При больших размерах базы, рекомендуется делать партиционирование.
А что считать большими размерами? Какого размера должна быть таблица, чтобы партиционирование стало полезным?
Сейчас у меня самые большие таблицы это history_uint и trends_uint - 40Гб и 22Гб соответственно, чистятся встроенным хаускипером. Нагрузка около 1200 NVPS, планируется рост до 1500.
Планирую хранить данные в два раза дольше настроенных параметров. Стоит ли делать партиционирование?
MySQL (innodb)

[Onizuca]

У меня есть некоторые тригеры которые срабатывают много раз в день (Режим генерации событий ПРОБЛЕМА - множественный). При срабатывании данные отрабатывает скрипт и после этого информация о срабатывании тригера уже не нужна. Поэтому я делаю чистку истоии проблем каждый день.
Вот запросы:
#Delete old problems and (only not classified and informational)
echo "Delete old problems"
/usr/bin/mysql -u zabbix --password=password zabbix -e "delete from problem where objectid in ( select triggerid from triggers where priority < 1 ) and clock < $(date +%s -d "1 day ago");"

#Delete dublicate problems
echo "Delete dublicate problems"
/usr/bin/mysql -u zabbix --password=password zabbix -e "CREATE TABLE eventids AS (select eventid from problem where eventid in (select eventid from problem s where objectid in (select objectid FROM problem GROUP BY objectid) and clock < (select max(clock) from problem where objectid = s.objectid)));
delete from problem where eventid in (select * from eventids);
drop table eventids;"

По поводу партиционирования. У меня самая большая таблица имеет ~20ГБ в день. Поэтому я делаю партиции каждые 3 часа. Партиционирование стоит использовать, а вот какой период выбирайте в зависимости от размера таблиц. Кроме сокращения размера таблиц, это ещё и помогает в удалении старых данных. Без использования "housekeeper" в заббиксе, которому и так есть чем заняться

[Kos]

Onizuca, пара замечаний.

1) на форуме есть возможности форматирования текста, иногда бывает удобно ими пользоваться. Например, обрамлять куски кода тегом "CODE" – он вставляется при нажатии на решётку (#) в панели инструментов в верхней части окна, где набирается ответ. В свою очередь сама панель инструментов включается/выключается нажатием на кнопочку "A" справа.

2) у вас в комментарии говорится, что удаляются события уровней "not classified" и "informational", но по факту условие в SQL-запросе – "priority строго меньше одного". С учётом того, что для уровней severity заданы следующие числовые значения (цитата из файла исходников include/common.h):

/* trigger severity */
#define TRIGGER_SEVERITY_NOT_CLASSIFIED 0
#define TRIGGER_SEVERITY_INFORMATION    1
#define TRIGGER_SEVERITY_WARNING        2
#define TRIGGER_SEVERITY_AVERAGE        3
#define TRIGGER_SEVERITY_HIGH           4
#define TRIGGER_SEVERITY_DISASTER       5
#define TRIGGER_SEVERITY_COUNT          6       /* number of trigger severities */

то под условие "строго меньше одного" попадает лишь уровень "not classified", но не "informational".

[nameuser]

Не создаю новую тему, т.к. название топика отражает суть моего вопроса.
При больших размерах базы, рекомендуется делать партиционирование.
А что считать большими размерами? Какого размера должна быть таблица, чтобы партиционирование стало полезным?
Сейчас у меня самые большие таблицы это history_uint и trends_uint - 40Гб и 22Гб соответственно, чистятся встроенным хаускипером. Нагрузка около 1200 NVPS, планируется рост до 1500.
Планирую хранить данные в два раза дольше настроенных параметров. Стоит ли делать партиционирование?
MySQL (innodb)

Вопрос актуален

[BiMW]

Вопрос актуален

Тут скорее всего нужно смотреть как с этим справляется хаузкипер. Если нагрузки ооочень большие тогда переходить на партиционирование. Все зависит от мощностей сервера. Ну это мое мнение.