Файлы history

[aleksey.ishchenko]

Настроен zabbix 4,4, работает несколько лет, но в последнее время на сервере БД каждые 2-3 месяца стало не хватать места. Каждый день создается файл в /home/mariadb/zabbix/mysql/zabbix/history#P#p2022_10_10.ibd размером примерно 500Мб настроено партиционирование скриптом выполняется ежедневно.
Как мне сказали это файлы таблицы history. Как-то можно изменить или отменить создание этих файлов, сейчас размер диска уже больше 2Tb. Самый старый файл от декабря 22 года. 2046 файлов.

[Kos]

Наверное, стОит начать с того, чтобы почитать, что такое партиционирование вообще и зачем оно бывает нужно в Zabbix-е.
Затем либо разбираться с тем, как оно настроено у вас (и, соответственно, как его подкорректировать или вообще убрать, если надумаете), либо нанять человека, который сможет это сделать для вас.

В общих чертах: в базе данных Zabbix есть несколько таблиц, где хранится история элементов данных (5 штук, по типам данных) и данные динамики изменений (они же тренды, две таблицы - только для числовых элементов данных). На больших инсталяциях рекомендуется настраивать партиционирование этих таблиц, отключая встроенный процесс очистки истории (housekeeper). Обычно housekeeper запускается каждый час и занимается тем, что удаляет из базы данных старые данные (те, для которых уже истёк срок их хранения). На объёмных базах это может оказаться достаточно тяжёлой задачей (нагружающей и процесс housekeeper, и СУБД), поэтому в качестве альтернативы предлагается партиционирование. Оно, в свою очередь, заключается в том, что какие-то конкретные таблицы в базе данных настраиваются таким образом, чтобы данные за конкретный период (обычно сутки, но может быть и неделя, и месяц) писались бы физически в отдельное место на диске - партицию (файл или папку), которую затем при необходимости можно отсоединить от общей базы и удалить одним простым действием, не делая сложных запросов к базе. Преимущества очевидны: очистка выполняется без нагрузки на систему; недостатки - тоже очевидны: нужны дополнительные настройки базы (поддержание партиционирования, регулярное создание новых партиций и удаление старых - обычно делается какими-то скриптами), потенциальные проблемы при апгрейдах, к тому же теряется гибкость настроек времени хранения истории (при удалении партиции убираются все находящиеся в ней данные, независимо от того, к каким узлам сети и элементам данных они относились).

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

Ну и замечание в сторону: версия 4.4 - не-LTS, она перестала поддерживаться через месяц после выхода версии 5.0 (т.е. с лета 2020 года). А версия 5.0, хоть и LTS, но уже тоже не поддерживается с 31 мая этого года (ссылка). Текущие версии - 6.4 (не-LTS) и 6.0 (LTS). Наверное, имеет смысл задуматься об обновлении.

[Kos]

Наверное, стОит начать с того, чтобы почитать, что такое партиционирование вообще и зачем оно бывает нужно в Zabbix-е.
Затем либо разбираться с тем, как оно настроено у вас (и, соответственно, как его подкорректировать или вообще убрать, если надумаете), либо нанять человека, который сможет это сделать для вас.

В общих чертах: в базе данных Zabbix есть несколько таблиц, где хранится история элементов данных (5 штук, по типам данных) и данные динамики изменений (они же тренды, две таблицы - только для числовых элементов данных). На больших инсталяциях рекомендуется настраивать партиционирование этих таблиц, отключая встроенный процесс очистки истории (housekeeper). Обычно housekeeper запускается каждый час и занимается тем, что удаляет из базы данных старые данные (те, для которых уже истёк срок их хранения). На объёмных базах это может оказаться достаточно тяжёлой задачей (нагружающей и процесс housekeeper, и СУБД), поэтому в качестве альтернативы предлагается партиционирование. Оно, в свою очередь, заключается в том, что какие-то конкретные таблицы в базе данных настраиваются таким образом, чтобы данные за конкретный период (обычно сутки, но может быть и неделя, и месяц) писались бы физически в отдельное место на диске - партицию (файл или папку), которую затем при необходимости можно отсоединить от общей базы и удалить одним простым действием, не делая сложных запросов к базе. Преимущества очевидны: очистка выполняется без нагрузки на систему; недостатки - тоже очевидны: нужны дополнительные настройки базы (поддержание партиционирования, регулярное создание новых партиций и удаление старых - обычно делается какими-то скриптами), потенциальные проблемы при апгрейдах, к тому же теряется гибкость настроек времени хранения истории (при удалении партиции убираются все находящиеся в ней данные, независимо от того, к каким узлам сети и элементам данных они относились).

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

Ну и замечание в сторону: версия 4.4 - не-LTS, она перестала поддерживаться через месяц после выхода версии 5.0 (т.е. с лета 2020 года). А версия 5.0, хоть и LTS, но уже тоже не поддерживается с 31 мая этого года (ссылка). Текущие версии - 6.4 (не-LTS) и 6.0 (LTS). Наверное, имеет смысл задуматься об обновлении.