Комментарии 5
Где же вы были? Пару недель назад мигрировал с древнего appliance'а с Убунтой 16.04 на CentOS 8, PostgreSQL и timescaledb. Не без трудностей. Кстати, в репах для 8-го Цента почему-то не смог найти pgloader, пришлось собирать их исходников.
К сожалению до хабра публикация добралась только сейчас, но она была доступна уже некоторое время на нашем сайте, в виде презентации, здесь. А что касается pgloader, в репозиториях PostgreSQL 12 на CentOS 8 его и правда нет, поэтому собирать пока единственный вариант.
Хорошая дока. Я делал с полгода назад — пришлось поразбираться. У нашего заббикса история длинная: он был 3.0, потом обновили до 4.0 и прикрутили партиционирование, когда вышел 4.4 — обновились, а через некоторое время смигрировали его в постгрес с TimescaleDB (кстати, да — стал держать бо́льшую нагрузку), потом апгрейднулись до 5.0 (были проблемы, правили индексы и констрайнты — получилось). Единственное, что не смог пока победить — это компрессию. При попытке включить, в логах вот такое:
[Z3005] query failed: [0] PGRES_FATAL_ERROR:ERROR: return type of integer_now_func must be the same as the type of the time partitioning column of the hypertable
[select set_integer_now_func('history_uint', 'zbx_ts_unix_now', true)]
В этом отчасти и проблема, возможно не очевидная. Вот вы смигрировали на PgSQL + TimescaleDB, а специалистов по TimescaleDB не так много в наличии и при появлении проблем, хотя бы с компрессией, Вы сами не можете решить эту проблему. А что делать? Пустить на самотек? Вы не специалист по TimescaleDB и заглянуть в будущее или посмотреть потроха TimescaleDB тоже не можете, а вдруг эта ошибка потом сыграет роковую роль и Вы (не дай бог конечно) потеряете все данные мониторинга? Ну вот вдруг, маленькая ошибка и большая беда.
Поэтому лично я если когда то и буду мигрировать на PgSQL + TimescaleDB, то прежде задамся вопросом, а зачем? А я реально спец или рядом есть спецы по Pg + TimescaleDB, чтобы потом разрулить возможные проблемы?
Поэтому лично я если когда то и буду мигрировать на PgSQL + TimescaleDB, то прежде задамся вопросом, а зачем? А я реально спец или рядом есть спецы по Pg + TimescaleDB, чтобы потом разрулить возможные проблемы?
Да не, мы не вчера родились, понимаем риски. У нас данные мониторинга хранятся месяц и их потеря не критична, а данные конфигурации туда-сюда не трудно перетащить. А производительность нам важнее. Но это даже вторично. Всё таки, PostgreSQL и TimescaleDB в контексте Zabbix — это не rocket science, разберёмся.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Миграция с MySQL на PostgreSQL