Использование партиционирования в MySQL для Zabbix с большим количеством объектов мониторинга

[iddqda]

Спасибо. Как раз собирался этим заняться после НГ
Правда мне на лету это делать не особо и нужно. Производительности хватает пока.
Я думаю просто начать создавать партиций начиная с определенного момента, а потом, через год, отключить housekeeping и начать дропать хвосты.

кстати, как считаете, вот эта хранилка из wiki zabbix-а достаточно надежная для автоматизации обслуживания партицирования?

[akryukov]

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

Зачем делать два прохода переливки, если можно в самом начале выполнить

BEGIN;
CREATE TABLE history_tmp LIKE history;
RENAME TABLE history TO history_old;
RENAME TABLE history_tmp TO history;
COMMIT;

и дальше уже упражняться с копией данных как заблагорассудится?

[larrabee]

В MySQL DDL операции (ALTER, CREATE, RENAME TABLE и другие) не работают с транзакциями и выполняются сразу же, а не при комите.
Чтобы выполнить RENAME атомарно следует делать так:

CREATE TABLE history_tmp LIKE history;
RENAME TABLE history TO history_old, history_tmp TO history; ;

По теме самой статьи. Мы тоже некоторое время использовали партиционирование, но оно не удобно по следующим причинам:

• Меняется схема данных. При обновлениях могут вылезать проблемы. (Актуально для версий <3.2, т.к. для них требовалась модификация индексов для работы партиционирования. )
• Удаление данных происходит только целыми партициями. Нельзя одну метрику хранить неделю, а другую два года.

Поэтому сейчас мы применяем не партиционирование, а храним историю в таблицах с движком RocksDB. Плюсы следующие:

• Встроенный housekeeper работает даже на больших объемах данных. Можно гибко назначать метрикам время хранения.
• Отличное сжатие. По сравнения с InnoDB компрессией данные стали занимать примерно в 2 раза меньше места.
• Простая процедура миграции. Надо только поставить RocksDB плагин и сделать ALTER нужных таблиц.
• Не меняется схема, только движок для нескольких таблиц. Пока еще ни разу не было проблем при апгрейде. (3.4 -> 4.0 -> 4.2)
• Выборки из БД также работают быстрее.

В общем для существующих инсталляций лучше использовать решение с RocksDB. Для новых лучше наверно использовать официальное решение с TimescaleDB.

[corochoone]

Почитал про RocksDB. Ничего не нашёл про репликацию. Её нет? А как же отказоустойчивость?

[larrabee]

Работает стандартная MySQL репликация.
Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
Почитать подробнее можно например тут.

[corochoone]

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

[akryukov]

Где именно я предложил "создать пустую таблицу, а затем лить туда данные из оригинальной"?
Я предложил только "создать пустую таблицу и сделать два переименования".
Деталей реализации RENAME в MySQL я не знаю, но исхожу из предположения, что эта операция только редактирует метаданные таблиц (и эта операция выполняется за несколько милисекунд).

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

[Grand_piano]

Победа над mysql это конечно всегда приятно и радует любого нормального админа. Особенно когда применяются новые решения. Однако, именно для таких случаев zabbix включил у себя поддержку timescale в рамках работы с postgresql. Там, по сути, используется автопартицирование "из коробки" и удаление чанков посуточно. Причём настройка крайне просто и хорошо описана в документации zabbix. Перенос данных из mysql в postgresql потребует не очень длительной остановки, но он вполне возможен.

[AlexGluck]

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

[rahs]

Инструкция хорошая, но совсем не полная. Таблицы надо обслуживать, то есть удалять и добавлять патриции, и делать это надо никак не вручную.
Ничего не сказано про обновлнния, которые на партиционированных таблицах могут не отрабатывать

[luxter]

По своей практике мне сказать, что лучше секционировать все таблицам истории, в т.ч. trends, ибо равно или поздно понадобится их очистка. Удобно делать на функциях в mysql для автоматического создания и удаления партиций, есть подробная официальная документация у zabbix.