[fractal]

Приветствую, собираюсь делать партиционирование, zabbix последней версии, база уже 220 Gb (работает все равно шустро, но хаускипер долго чистит), нашел статью - http://unixadm.info/content/разбиени...;-zabbix-mysql я так понимаю бэкап делать нет смысла? т.к. выделено всего 320 гигов (виртуалка) и просто не влезет?, далее как я понял я к примеру хочу сохранить последнюю неделю инфы, т.е. к примеру секционирование запущу 27.07.2016 и интервал дней сделаю с 20 по 28, также не могу найти в статье через какой срок будет удаляться старая инфа? или все будет зависеть от настроек очитски в вебе?

[SergeiK]

Приветствую, собираюсь делать партиционирование, zabbix последней версии, база уже 220 Gb (работает все равно шустро, но хаускипер долго чистит), нашел статью - http://unixadm.info/content/разбиени...;-zabbix-mysql я так понимаю бэкап делать нет смысла? т.к. выделено всего 320 гигов (виртуалка) и просто не влезет?, далее как я понял я к примеру хочу сохранить последнюю неделю инфы, т.е. к примеру секционирование запущу 27.07.2016 и интервал дней сделаю с 20 по 28, также не могу найти в статье через какой срок будет удаляться старая инфа? или все будет зависеть от настроек очитски в вебе?

Бэкап можно отправлять на выходе из mysqldump | gzip -c > xxx и вы получите объем в 10 гиг вместо 220.

Но БэкАп БД из 220 гигов вы будете делать до-о-олго.

Чистит долго - это сколько?

 

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

Посмотрите в логах, сколько строк удаляет хаускиппер, и сколько написано в конфигурации максимум. Если он удаляет уже максимум, число надо увеличивать.

Поставьте его в работу пореже.

 

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

Удаление старых записей идет через SQL alter table ... drop partition - файл со старыми данными просто удаляется совсем, дешево и быстро.

[fractal]

Приветствую, собираюсь делать партиционирование, zabbix последней версии, база уже 220 Gb (работает все равно шустро, но хаускипер долго чистит), нашел статью - http://unixadm.info/content/разбиени...;-zabbix-mysql я так понимаю бэкап делать нет смысла? т.к. выделено всего 320 гигов (виртуалка) и просто не влезет?, далее как я понял я к примеру хочу сохранить последнюю неделю инфы, т.е. к примеру секционирование запущу 27.07.2016 и интервал дней сделаю с 20 по 28, также не могу найти в статье через какой срок будет удаляться старая инфа? или все будет зависеть от настроек очитски в вебе?

Бэкап можно отправлять на выходе из mysqldump | gzip -c > xxx и вы получите объем в 10 гиг вместо 220.

Но БэкАп БД из 220 гигов вы будете делать до-о-олго.

Чистит долго - это сколько?

 

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

Посмотрите в логах, сколько строк удаляет хаускиппер, и сколько написано в конфигурации максимум. Если он удаляет уже максимум, число надо увеличивать.

Поставьте его в работу пореже.

 

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

Удаление старых записей идет через SQL alter table ... drop partition - файл со старыми данными просто удаляется совсем, дешево и быстро.

 

в вебе у меня стоит 90 дней, хаускипер запускается один раз и чистит часа полтора, в логах не глядел сколько он чистит, просто по статистике он много жрет ресурсов что не очень хорошо, постоянно 100 процентов занимает хаускипер по графикам internal process busy

[SergeiK]

в вебе у меня стоит 90 дней, хаускипер запускается один раз и чистит часа полтора, в логах не глядел сколько он чистит, просто по статистике он много жрет ресурсов что не очень хорошо, постоянно 100 процентов занимает хаускипер по графикам internal process busy

Забикс разделяет понятие истории и трендов. 80 дней истории? Или 80 дней трендов?

И я не понял, есть ли у вас общие настройки для хаускиппера.

Это вот тут.

В поле Override должна стоять галка и желаемый срок хранения данных.

Часто это сильно разгружает хаукиппер и позволяет не мучиться с партированием.

 

Да, ссылка ваша кривая, так что не могу сказать ничего по этому поводу.

[fractal]

events b alerts, user session, trends - у меня 90 дней, history 30, автоочистка включена, но хаускипер не справляется.

 

ссылка - http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql

[SergeiK]

events b alerts, user session, trends - у меня 90 дней, history 30, автоочистка включена, но хаускипер не справляется.

Вы не ответили на самый важный вопрос :).

"Override item history period", он же "Переопределить период хранения истории элементов данных" нажата?

 

Разница существенна, и она в работе с БД.

Если этой галки не включено, то для каждого элемента данных отрабатывает своя команда SQL Delete.

Сколько параметров - столько запросов. Каждый запрос Delete в большой таблице - серьезная нагрузка на БД.

Если выставите галку - срок истории у всех одинаковый, и старые данные удаляются одним запросом. Это тоже нагрузка - но запрос всего один!

 

ссылка - http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql

Посмотрел. Я пользуюсь другой обвязкой, но суть та же.

В этой схеме удаление старых данных в последних абзацах статьи.

Там создается event в БД (не заббикс) - аналог крона, и в процедуре этого event-а - удаление старых партиций и создание новых.

 

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

Вся суть процесса в командах SQL ALTER TABLE ... PARTITION/ADD PARTITION/DROP PARTITION ...

[fractal]

events b alerts, user session, trends - у меня 90 дней, history 30, автоочистка включена, но хаускипер не справляется.

Вы не ответили на самый важный вопрос :).

"Override item history period", он же "Переопределить период хранения истории элементов данных" нажата?

 

Разница существенна, и она в работе с БД.

Если этой галки не включено, то для каждого элемента данных отрабатывает своя команда SQL Delete.

Сколько параметров - столько запросов. Каждый запрос Delete в большой таблице - серьезная нагрузка на БД.

Если выставите галку - срок истории у всех одинаковый, и старые данные удаляются одним запросом. Это тоже нагрузка - но запрос всего один!

 

ссылка - http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql

Посмотрел. Я пользуюсь другой обвязкой, но суть та же.

В этой схеме удаление старых данных в последних абзацах статьи.

Там создается event в БД (не заббикс) - аналог крона, и в процедуре этого event-а - удаление старых партиций и создание новых.

 

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

Вся суть процесса в командах SQL ALTER TABLE ... PARTITION/ADD PARTITION/DROP PARTITION ...

 

 

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

[SergeiK]

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

Здесь для управления временем используется дополнительная таблица, см п.4.

Там вы указываете, какие таблицы, на какие интервалы вы разбиваете данные (по месяцам или по дням), сколько интервалов хранить (см. Insert команды).

 

С этой таблице работают потом остальные скрипты БД.

 

В п.6 очищаются все данные. Это значит, что, без резервной копии вы все данные потеряете.

Сами оценивайте важность ваших данных, и как с этим быть.