Как стать автором
Обновить

Комментарии 11

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

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

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


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


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

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

В 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.
Почитал про RocksDB. Ничего не нашёл про репликацию. Её нет? А как же отказоустойчивость?
Работает стандартная MySQL репликация.
Обратите внимание, что RocksDB это только библиотека и она никак не завязана на MySQL и может применяться отдельно от него. А есть RocksDB плагины к MySQL (например у Percona он зовется MyRocks), которые реализуют интерфейс взаимодействия с библиотекой и интегрируют ее в MySQL.
Почитать подробнее можно например тут.
Вначале статьи было написано, что необходимо было всё сделать «на лету». Если сделать так, как вы предлагаете (т.е. создать пустую таблицу, а затем лить туда данные из оригинальной), то на время переливки данных (которое может занять несколько часов) все эти данные окажутся недоступны. Т.е. не будет (как минимум) возможности смотреть и анализировать графики. Это было неприемлимо.

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


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

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

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

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

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