Как мигрировать Zabbix с MySQL на PostgreSQL с минимальным downtime

[awsswa59]

Я по этой статья прикручивал TimescaleDB к Zabbix
awsswa.livejournal.com/45940.html

[Tellamonid]

Я, может, что-то пропустил, но я не понял, зачем переходить с mySQL на PostgreSQL? mySQL чем-то не устраивал?

[niklep]

Верно, я не стал пытаться объять необъятное и включать в одну статью еще и причины выбора СУБД, и вопросы ее тюнинга. Миграция на PostgreSQL нужна была для того, чтобы в последующем применить TimescaleDB. О преимуществах TimescaleDB для Zabbix уже неоднократно писали в том числе здесь на Хабре. Базы данных временных рядов в целом больше подходят для систем мониторинга.
Например, одна из самых назойливых проблем при работе Zabbix на реляционной БД — медленный Housekeeper. Хотя бы для решения этой проблемы уже стоит мигрировать.
Нашел статью:
habr.com/ru/company/oleg-bunin/blog/470902

[looofi]

Ради timescale же

[Amikko]

Скорее просто раньше было всё равно, а тут Постгрес стал устраивать больше, ибо

"В свете того, что Zabbix с некоторых пор поддерживает TimescaleDB"

Если верно понимаю, TimescaleDB — это расширение Постгреса для оптимизации операций с временными рядами. Если в Zabbix завезли интеграцию с этой штукой, то почему бы не переехать на Постгрес.

[shamanis]

у нас Zabbix перекатили на ClickHouse недавно. Каким чудом не знаю, но его еще пару недель штормило после этого.

[norguhtar]

При большой нагрузке MySQL просто умирает. Достаточная причина?

[myz0ne]

Интересно, а если мигрировать исторические данные pgloader'ом в отдельный инстанс постгреса, а потом сделать dump/restore в основной, не получилось бы избежать проблемы? По идее восстановление дампа может оказаться эффективнее.

[blind_oracle]

Проще было бы заставить PGLoader заливать данные небольшими транзакциями по-моему. Есть ли там такая фича или нет — не знаю, но необходимость её очевидна. Указал там батч в 100к строк и коммитишь после него.

[niklep]

Я искал такую возможность в PgLoader, но не обнаружил. Оно и логично, т.к. миграция в одной транзакции позволяет легко откатить все изменения, если что-то пошло не так при миграции. У меня лично было много проблем на PgLoader 3.6.1. И без отката всех изменений было бы очень неудобно.

[niklep]

Расскажите, пожалуйста, чем эффективнее? Если отсутствием длинной транзакции, то как я написал коллеге чуть ниже, миграция одной транзакцией позволяет легко откатить изменения при проблемах. Это такая архитектурная необходимость.

[myz0ne]

Потенциально эффективнее тем, что не надо считывать данные из mysql и ждать его. Восстановление одной таблицы это одна команда COPY, так что она либо восстановится, либо нет.

Заббиксо-специфичный хинт: можно восстанавливать только таблицы с тендами, т.к. сами данные как правило все равно удаляются через 7-14 дней. На этом периоде графики были бы видны при масштабе более 1 дня. Таблицы с трендами как правило небольшие.

Сюда же вброшу postgres-специфичный хинт: можно восстанавливать в таблицу с другим именем, а затем подключить её через inherits к основной. Вам бы потенциально помогло с экспериментами, т.к. в эту таблицу писали бы только вы.

Плюс по доке: пишут что pgloader грузит данные батчами по умолчанию, и при неудаче старается выпилить плохие строки и повторить вставку. Если там нет создания хитрых функций чтобы избегать отмены транзакии при ошибке, то получается что таки он грузит не в одной транзакции. (но это не точно)

https://pgloader.readthedocs.io/en/latest/pgloader.html#batches-and-retry-behaviour

[osipov_dv]

Можно добавить еще, что число подключении и прочий тюнинг на pg лучше сделать до начала вливания. Я тут влил, переключился и удивился как быстро закончились свободные соединения :)