Мажорное обновление сервера в контейнере

[Griboed0ff]

Коллеги, приветствую!
Вот и пришла пора мне обновиться с 5.0.34 до 6.0.х. Имею сервер и 3 прокси в контейнере 5.0.34, postgresql 14.8(мастер база и реплика), timescaledb 2.11.1, oracle linux 7.9(возможности сменить ОС на машинах пока нет). Сервер, прокси, веб, базы все на разных машинах.
Просмотрел несколько инструкций по обновлению сервера, но не видел инструкций по обновлению сервера и прокси, если они находятся в контейнерах. Я немного не понимаю в какой момент происходит перестроение схемы базы и прочие обновления. Если я просто запущу контейнер с 6 заббиксом на базе 5 заббикса, чуда не произойдет? Может кто-либо уже обновлялся в контейнерах и знает тонкости такого обновления?
Так же вопрос по включению первичных ключей в таблицах истории и трендов. Как я понимаю при классическом обновлении создаются новые таблицы с уже включенным ключом и потом туда нужно перенести историю. Или мне надо включить первичный ключ самому, а уже потом туда переносить данные истории?
И вопрос по обновлению схемы данных при обновлении. Долгая эта процедура? Понятно, что зависит от конфигураций машин(озу 80гб, 2тб ссд, 18 cpu 3.00GHz), но я переживаю за время простоя при данной операции, у меня 1.5тб база.

[Kos]

Добрый день!

Насколько я понимаю, механизм следующий.

Схема базы данных перестраивается для новой версии при первом запуске сервера (либо прокси) Zabbix, имеющем более высокую версию. Процесс занимает некоторое время, оценить которое лучше всего можно, просто опробуя эту процедуру на тестовой среде (подняли копию базы из бэкапа, запустили нацеленный на неё бинарник сервера, по логам проследили за успешностью обновления базы и временем этой операции).

После обновления схемы с этой базой может успешно работать веб-интерфейс новой версии. Однако, откатиться назад, просто поднимая сервер и интерфейс прежней версии уже не получится - если необходимость отката всё же возникнет, то начинать его нужно с восстановления базы в состояние "до обновления схемы".

Версия 6.0 пока что жёстко на первичные ключи для исторических таблиц не завязана - это, скорее, некоторый задел на будущее. Поэтому данная операция выполняется не автоматически, а вручную (ссылка); а обновлять таблицы истории для добавления первичных ключей можно как до, так и после перехода на версию 6.0 - как вам удобнее. Поскольку именно таблицы истории и трендов самые объёмные, то как раз это обновление может занять времени гораздо больше (тоже нужно предварительно потренироваться на тестовой среде). Можно и совместить - мы, например, при переходе v5.0.x -> v6.0.x останавливали веб-интерфейс, сервер и прокси Zabbix, конвертировали исторические таблицы (занимало 15-20 минут на базе PostgreSQL 20 GB, но без TimescaleDB), затем запускали бинарник новой версии Zabbix (конвертация структуры базы занимала 15-20 секунд), потом поднимали прокси и веб-интерфейс. У нас не было контейнеров, но в данном случае это непринципиально.

Относительно прокси нужно иметь в виду два момента.
1) прокси должны быть той же версии, что и сервер; разные версии между собой не взаимодействуют (это поменялось только начиная с версии 6.4, если не ошибаюсь). Так что останавливать и обновлять в любом случае надо всё одновременно - данные, пересылаемые старыми прокси, в любом случае на новый сервер не попадут.
2) в случае, если прокси используют в качестве базы SQLite, то прокси обновлять структуру такой базы не умеет (её надо просто удалить, и он её пересоздаст). До недавнего времени удалять нужно было руками, с какой-то версии это автоматизировали (но точного номера версии я не помню, можно поискать).

(добавлено)
В принципе, вся процедура обновления достаточно хорошо расписана в разделе "Обновление из исходников" (ссылка на аглийскую версию и на русский перевод); эти разделы вполне подходят и для контейнерного варианта использования.

[Griboed0ff]

Схема базы данных перестраивается для новой версии при первом запуске сервера (либо прокси) Zabbix

А таблицы истории сохранятся при первом запуске сервера? Просто меня вводит в заблуждение статья, в которой перед первым запуском сервера, запускается скрипт, который переименовывает старые и создает новые таблицы истории и трендов.
Как я понимаю мне все же придется проделывать манипуляции с таблицами истории и трендов из-за timescaledb. Но для прокси история не важна, если схема обновляется сама при первом запуске, то получается я просто поднимаю контейнер с новой версией прокси и на этом обновление прокси можно считать законченным? У меня на прокси тоже на Postgresql.

[Kos]

А таблицы истории сохранятся при первом запуске сервера? Просто меня вводит в заблуждение статья, в которой перед первым запуском сервера, запускается скрипт, который переименовывает старые и создает новые таблицы истории и трендов.

Да, конечно, история сохраняется. Если я правильно понимаю, то в этой статье как раз описывается процедура миграции таблиц истории на использование первичных ключей. Текущая ссылка на документацию (тыц), эта страница немного менялась с начального релиза 6.0.0 (имеет смысл внимательно её прочитать). Поскольку у нас, как я говорил, TimescaleDB не используется, то этот шаг выглядел немного проще. А так да - смысл сводится к тому, что прежние таблицы истории переименовываются и выгружаются в текстовые файлы, после чего на их месте создаются новые с чуть обновлённой структурой, куда из текстовых файлов содержимое заливается обратно. По окончании процедуры нужно не забыть удались старые версии таблиц и эти текстовые файлы (под них, кстати, нужно довольно много места).

Но для прокси история не важна, если схема обновляется сама при первом запуске, то получается я просто поднимаю контейнер с новой версией прокси и на этом обновление прокси можно считать законченным? У меня на прокси тоже на Postgresql.

Я так понимаю, что да. Причём, в отличие от сервера, прокси свою базу должен обновлять очень быстро, и, наверное, можно его запустить сразу же - когда основной сервер поднимется, прокси новые данные на него перешлёт.

[Griboed0ff]

Поскольку у нас, как я говорил, TimescaleDB не используется

Если не секрет, какой размер базы у вас и сколько значений в секунду, раз можете позволить себе жить без timescaledb?
Жаль у меня нет тестовой среды, поэтому только действия без ошибок и бэкапы всего. По итогу своих обновлений отпишусь, что получилось, какие проблемы встретил.

[Hamardaban]

У меня на прокси тоже на Postgresql.

Вы уверены что вам нужно на прокси использовать psql ?
IMHO база прокси на sqlite гораздо проще, производительность нормальная. А в обслуживании вообще прелесть - если что поломалось - грохаем файл и забикс при старте все создает сам.

[Griboed0ff]

Вы уверены что вам нужно на прокси использовать psql ?

sqlite был ранее, но производительности не хватает. До 1000знач\сек еще было нормально, выше 1000 с такими объемами psql справляется намного лучше. Во всяком случае у меня такой опыт. Пробовал mysql(mariadb), sqlit, psql - пока psql для меня самый производительный.
Плюс используется docker-compose для psql и zabbix-proxy. Что-то сломалось, потушил, поднял снова, создалась база с чистой схемой, такая же красота как и sqlite.

[Kos]

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

Директория с базой на диске занимает 30 GB, бэкап (в виде .tar.gz) - 7 GB.
Zabbix - 140 VPS.

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

Ой.
Ну можно же временно хотя бы на сервере с репликой попробовать:

• перевести его в режим мастера;
• во избежание ложных срабатываний во время тестирования - отключить (прямо в базе) все действия и каналы доставки:

update MEDIA_TYPE set STATUS=1
update ACTIONS set STATUS=1

• запустить где-нибудь (в контейнере должно быть не очень сложно) бинарник, нацеленный на этот экземпляр базы;
• проконтролировать по логам время конвертации структуры базы, остановить бинарник;
• опробовать на этом же экземпляре базы процедуру добавления первичных ключей, оценить время;
• потом заново запустить реплику с исходного сервера (хоть через базовый бэкап).

Понятно, что с базой в полтора терабайта это будет не так просто и займёт кучу времени, но хоть даст какие-то ориентиры - какое время простоя потом планировать.

эта страница немного менялась с начального релиза 6.0.0 (имеет смысл внимательно её прочитать)

Кстати, только сейчас обратил внимание, что там появились варианты добавления первичных ключей при работающем сервере Zabbix (изначально их не было).

[Griboed0ff]

Кстати, только сейчас обратил внимание, что там появились варианты добавления первичных ключей при работающем сервере Zabbix (изначально их не было).

Интересно будет ли заметное влияние присутствия первичных ключей в таблицах историй и трендов, именно для заббикса. Для меня возможно будет плюс, так как у меня есть отчетность на основе данных заббикса. Питоновскими скриптами делаю запросы в базу ззабикса и помещаю ответ в двх оракл, далее на bi строятся отчеты. И для выборок очень полезно иметь первичку и временные ряды.

[Griboed0ff]

Опробовал на одном небольшом экземпляре. База примерно 50гб. Заняло около 4 часов. В общем применяешь скрипты sql, которые шли в комплекте. Они переименовывают таблицы истории, создают новые с первичными ключами, выгружают в csv, загружают во временные, потом в постоянные таблицы истории. Потом поднимаешь контейнер и через какое-то время все работает. Есть какие-то эд и триггеры, которые отпали по разным причинам и требуют ручного исправления. Масштаб бедствия непонятен, позже отпишусь какие именно проблемные.

[Griboed0ff]

Перестали раскрываться макросы в действиях вида:{{HOST.HOST}:{ITEM.KEY}.last()} (мой конкретный случай {{HOST.HOST}:last_ip.last()}), в триггере не участвует поэтому {ITEM.LASTVALUE<1-9>} не могу использовать.

[Kos]

Перестали раскрываться макросы в действиях вида:{{HOST.HOST}:{ITEM.KEY}.last()} (мой конкретный случай {{HOST.HOST}:last_ip.last()}), в триггере не участвует поэтому {ITEM.LASTVALUE<1-9>} не могу использовать.

Подозреваю, что это связано не с базой данных, а с этими изменениями.

[Griboed0ff]

Подозреваю, что это связано не с базой данных, а с этими изменениями.

Я сильно надеялся, что и макросы будут обновлены вместе со всеми имениями в триггерах\эд во время обновления базы.

[Kos]

Я сильно надеялся, что и макросы будут обновлены вместе со всеми имениями в триггерах\эд во время обновления базы.

Сейчас навскидку не найду, но где-то было перечисление, в каких именно местах эти изменения делались автоматически, а в каких их нужно было корректировать руками. Из того, что помню, - руками нужно было править в Action-ах (действиях) и картах сети.