После того, как в прошлой статье Как мигрировать Zabbix с MySQL на PostgreSQL с минимальным downtime я успешно перенес Zabbix с MySQL на PostgreSQL, встала необходимость сделать следующий шаг — мигрировать БД на TimescaleDB, т.к. ради нее все и затевалось.
У читателя может возникнуть вопрос: зачем нужна эта статья, если есть простой и понятный мануал?
Но проблема, как и в прошлой статье, скрыта в downtime. В мануале ясно написано:
Я всячески игрался с тюнингом PostgreSQL, добавлял ресурсы на виртуальную машину с PostgreSQL. Испытанный максимум ресурсов — 24 CPU, 64 GB RAM. Но, очевидно, скрипт миграции упирается в дисковую производительность. В итоге при моей базе данных размером в ~350 Гб миграция занимала 15 часов. Все это время мониторинг отключен.
Я пошел читать документацию TimescaleDB по миграции данных и нашел такой способ, обозначенный как "Faster Method":
И так надо сделать для таблиц:
Для ускорения процесса я поместил команды для каждой таблицы в отдельные файлы, чтобы запускать их параллельно.
Ссылка на github репозиторий со скриптами.
Скрипт finish.sql необходимо выполнить уже после завершения миграции всех таблиц.
В итоге миграция таблиц в гипертаблицы TimescaleDB в моем случае заняла 5 часов, что сильно меньше изначальных 15.
PROFIT.
Источник статьи: https://habr.com/ru/post/549428/
У читателя может возникнуть вопрос: зачем нужна эта статья, если есть простой и понятный мануал?
Но проблема, как и в прошлой статье, скрыта в downtime. В мануале ясно написано:
Исходные данные следующие:
- Zabbix 5.0
- СУБД PostgreSQL 12
- Применен патч ENABLING EXTENDED RANGE OF NUMERIC (FLOAT) VALUES
- Установлен TimescaleDB 1.7 (поддержка 2.0 пока отсутствует)
Я всячески игрался с тюнингом PostgreSQL, добавлял ресурсы на виртуальную машину с PostgreSQL. Испытанный максимум ресурсов — 24 CPU, 64 GB RAM. Но, очевидно, скрипт миграции упирается в дисковую производительность. В итоге при моей базе данных размером в ~350 Гб миграция занимала 15 часов. Все это время мониторинг отключен.
Я пошел читать документацию TimescaleDB по миграции данных и нашел такой способ, обозначенный как "Faster Method":
- выбираем таблицу, которую хотим мигрировать в гипертаблицу. Например, history
- создаем новую таблицу, аналогичную старой, при этом исключая индексы
CREATE TABLE history_new (LIKE history INCLUDING DEFAULTS INCLUDING CONSTRAINTS EXCLUDING INDEXES); - конвертируем новую таблицу в гипертаблицу
SELECT create_hypertable('history_new', 'clock', chunk_interval => 86400); - перемещаем все данные из history в history_new
INSERT INTO history_new SELECT * FROM history; - удаляем старую таблицу history
DROP TABLE IF EXISTS history; - переименовываем history_new в history
ALTER TABLE IF EXISTS history_new RENAME TO history; - создаем индекс (как — описано в файле схемы БД schema.sql)
CREATE INDEX history_1 in history (itemid,clock);
И так надо сделать для таблиц:
- history
- history_log
- history_str
- history_text
- history_uint
- trends
- trends_uint
Для ускорения процесса я поместил команды для каждой таблицы в отдельные файлы, чтобы запускать их параллельно.
Ссылка на github репозиторий со скриптами.
Скрипт finish.sql необходимо выполнить уже после завершения миграции всех таблиц.
В итоге миграция таблиц в гипертаблицы TimescaleDB в моем случае заняла 5 часов, что сильно меньше изначальных 15.
PROFIT.
Источник статьи: https://habr.com/ru/post/549428/