Комментарии 11
Правда мне на лету это делать не особо и нужно. Производительности хватает пока.
Я думаю просто начать создавать партиций начиная с определенного момента, а потом, через год, отключить housekeeping и начать дропать хвосты.
кстати, как считаете, вот эта хранилка из wiki zabbix-а достаточно надежная для автоматизации обслуживания партицирования?
Хорошая статья с точки зрения технических подробностей.
Странно что у нее ни плюсов ни минусов, в то время, как рядом всякий бред плюсуют.
Зачем делать два прохода переливки, если можно в самом начале выполнить
BEGIN;
CREATE TABLE history_tmp LIKE history;
RENAME TABLE history TO history_old;
RENAME TABLE history_tmp TO history;
COMMIT;
и дальше уже упражняться с копией данных как заблагорассудится?
Чтобы выполнить 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.
Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
Почитать подробнее можно например тут.
Где именно я предложил "создать пустую таблицу, а затем лить туда данные из оригинальной"?
Я предложил только "создать пустую таблицу и сделать два переименования".
Деталей реализации RENAME в MySQL я не знаю, но исхожу из предположения, что эта операция только редактирует метаданные таблиц (и эта операция выполняется за несколько милисекунд).
Возможно вы заметили слово "копия данных" в конце сообщения. Это я неточно выразился. Я имел в виду таблицу history_old, которая получится в результате выполнения указанного мной скрипта.
Победа над mysql это конечно всегда приятно и радует любого нормального админа. Особенно когда применяются новые решения. Однако, именно для таких случаев zabbix включил у себя поддержку timescale в рамках работы с postgresql. Там, по сути, используется автопартицирование "из коробки" и удаление чанков посуточно. Причём настройка крайне просто и хорошо описана в документации zabbix. Перенос данных из mysql в postgresql потребует не очень длительной остановки, но он вполне возможен.
Инструкция хорошая, но совсем не полная. Таблицы надо обслуживать, то есть удалять и добавлять патриции, и делать это надо никак не вручную.
Ничего не сказано про обновлнния, которые на партиционированных таблицах могут не отрабатывать
Использование партиционирования в MySQL для Zabbix с большим количеством объектов мониторинга