AK
А, ну оповещения это не даст, конечно
Size: a a a
2020 June 11
D
Мм, а прокси не вариант поставить?
Так-то можно (я так понимаю, на тот же хост, где и сервер заббикса живёт, чтобы не менять настройки заббикс агента на наблюдаемых хостах). Но тогда придётся в заббикс сервере указывать, что узлы подключены через прокси (на время работ с базой), а потом менять обратно. Узлов много.
OM
configuration - host выбрать хосты. -> mass update -> monitored by proxy
AK
Так-то можно (я так понимаю, на тот же хост, где и сервер заббикса живёт, чтобы не менять настройки заббикс агента на наблюдаемых хостах). Но тогда придётся в заббикс сервере указывать, что узлы подключены через прокси (на время работ с базой), а потом менять обратно. Узлов много.
Ну вообще, да, это всё не так быстро. Наверное как-то так:
1. Вводить прокси, переключать на них хосты. Включать буфер на прокси, чтобы хранили данные уже переданные на сервер
2. Ждать пока сбор пойдёт через прокси
3. Дамп и рестор на тест
4. ALTER TABLE на тесте
5. Выключать основной сервер, наливать сконвертированную базу.
6. И вот тут я не знаю, передадут ли прокси историю или нужно это делать вручную.
1. Вводить прокси, переключать на них хосты. Включать буфер на прокси, чтобы хранили данные уже переданные на сервер
2. Ждать пока сбор пойдёт через прокси
3. Дамп и рестор на тест
4. ALTER TABLE на тесте
5. Выключать основной сервер, наливать сконвертированную базу.
6. И вот тут я не знаю, передадут ли прокси историю или нужно это делать вручную.
AK
А вообще, альтер не получится наживую делать? Я что-то и не пробовал никогда.
AK
Глянул, в современных версиях таблица не блокируется.
D
А вообще, альтер не получится наживую делать? Я что-то и не пробовал никогда.
Получится, но в моем кейсе не хватит места для временных таблиц, хистори 200 гб
А
Там не отвечают
AK
Там не отвечают
Ответил )
D
Коллеги, ещё одна проблема при обновлении 4.4 - 5.0.1. Апгрейд БД ВРОДЕ бы прошёл успешно, но при старте сервера в логах пишется:
3988:20200611:084617.885 Zabbix supports only "utf8_bin" collation. Database "zabbix" has default collation "utf8_general_ci"
3988:20200611:084617.890 character set name or collation name that is not supported by Zabbix found in 424 column(s) of database "zabbix"
3988:20200611:084617.890 only character set "utf8" and collation "utf8_bin" should be used in database
3988:20200611:084617.894 database is not upgraded to use double precision values
И вот такая картина на дешборде. Что с этим делать?
3988:20200611:084617.885 Zabbix supports only "utf8_bin" collation. Database "zabbix" has default collation "utf8_general_ci"
3988:20200611:084617.890 character set name or collation name that is not supported by Zabbix found in 424 column(s) of database "zabbix"
3988:20200611:084617.890 only character set "utf8" and collation "utf8_bin" should be used in database
3988:20200611:084617.894 database is not upgraded to use double precision values
И вот такая картина на дешборде. Что с этим делать?
На моей 400Гб ALTER всех таблиц занял около 30 минут, ошибка ушла. Осталось решить проблему с сообщением, показанном на скриншоте. В интернетах нашёл упоминание, что нужно "внести дополнительный ключ в zabbix.conf.php". Какой именно, не нашёл.
MO
там IEEE в названии
MO
(если конечно реально тип колонок на double сменён)
MO
в том sql, что ты сюда показывал, вроде не было про это
AK
На моей 400Гб ALTER всех таблиц занял около 30 минут, ошибка ушла. Осталось решить проблему с сообщением, показанном на скриншоте. В интернетах нашёл упоминание, что нужно "внести дополнительный ключ в zabbix.conf.php". Какой именно, не нашёл.
D
Эти запросы я выполнил, рестартанул и скуль и сервер - сообщение "Таблицы истории в базе данных обновлены Нет" не пропало
D
ALTER TABLE trends
MODIFY value_min DOUBLE PRECISION DEFAULT '0.0000' NOT NULL,
MODIFY value_avg DOUBLE PRECISION DEFAULT '0.0000' NOT NULL,
MODIFY value_max DOUBLE PRECISION DEFAULT '0.0000' NOT NULL;
ALTER TABLE history MODIFY value DOUBLE PRECISION DEFAULT '0.0000' NOT NULL;
MODIFY value_min DOUBLE PRECISION DEFAULT '0.0000' NOT NULL,
MODIFY value_avg DOUBLE PRECISION DEFAULT '0.0000' NOT NULL,
MODIFY value_max DOUBLE PRECISION DEFAULT '0.0000' NOT NULL;
ALTER TABLE history MODIFY value DOUBLE PRECISION DEFAULT '0.0000' NOT NULL;
AK
Эти запросы я выполнил, рестартанул и скуль и сервер - сообщение "Таблицы истории в базе данных обновлены Нет" не пропало
Там есть параметры который нужно поменять
U
подскажите, а при сжатии timescale место освобождается сразу?
Пишется ли куда-то в лог компрессия timescale или это происходит в самой бд и "снаружи" в заббиксе этого не увидеть?
Спрашиваю т.к. неясно происходит ли сжатие или нет. В настройках стоит сжимать после 7 дней, они прошли. Изменения темпов роста базы не заметно - под базу выделен отдельный раздел диска, used space продолжает расти линейно.
Я представляд процесс так: данные сжимаются, место в базе освобождается, на это место пишутся новые данные и файлы бд какое-то время не растут. Но по росту used space раздела с базой этого не заметно - рост линейный.
Пишется ли куда-то в лог компрессия timescale или это происходит в самой бд и "снаружи" в заббиксе этого не увидеть?
Спрашиваю т.к. неясно происходит ли сжатие или нет. В настройках стоит сжимать после 7 дней, они прошли. Изменения темпов роста базы не заметно - под базу выделен отдельный раздел диска, used space продолжает расти линейно.
Я представляд процесс так: данные сжимаются, место в базе освобождается, на это место пишутся новые данные и файлы бд какое-то время не растут. Но по росту used space раздела с базой этого не заметно - рост линейный.
MO
в лог постгреса пишет про сжатие чанков