f.
сама база небось 200-500 тогда норм
Size: a a a
2020 August 07
ОД
Бери те, у которых иопсов на запись больше
ᅠ
сама база небось 200-500 тогда норм
К тому же в старых версиях хранятся все запросы, а в новых только изменения
f.
К тому же в старых версиях хранятся все запросы, а в новых только изменения
3,4 не настолько древняя
ᅠ
Тем не менее
ЯR
Шо, много?) база то сейчас 800
Ну и заббикс старый.
Ну и заббикс старый.
Апгрейд заббикса до 5.0, переход на СУБД Postgresql+timescale dB со сжатием. База уменьшится в разы и скорость обработки тоже, при этом время хранения хистори и трендов уменьшать не придётся. Но придется поработать, чтобы все это провернуть)
ᅠ
Сомнительный выигрыш... даже не понятно чего.. места?) да ну его нафиг)
ЯR
Места и ресурсов
ᅠ
Бери те, у которых иопсов на запись больше
Тут уж выбирать не из чего оказалось) чисто по объёму и скорости
ЯR
Тут уж выбирать не из чего оказалось) чисто по объёму и скорости
Для 3.5 корзин диски дешевле
ЯR
И ничто не мешает туда 2.5 вставить через адаптер)
ᅠ
Ну я их и взял
ЯR
Разумно
f.
Сомнительный выигрыш... даже не понятно чего.. места?) да ну его нафиг)
такие заморочки оправданы если нагрузка большая и надо постоянно историю дергать за долгие периоды
f.
а так, мне партицирование помогло на 5.0 версии
ЯR
Ну партицирование конечно тоже поможет, но если его изначально не было, то проще сразу мигрировать на постгрес + timescale. И пусть оно дальше под капотом заббикса само работает
f.
Ну партицирование конечно тоже поможет, но если его изначально не было, то проще сразу мигрировать на постгрес + timescale. И пусть оно дальше под капотом заббикса само работает
ну у меня получилось наживую сделать
f.
ну почти
f.
на соседнем сервера из бэкапа базы развернул настроил партицирование и переселил забикс на него
f.
Ну я их и взял
а почему железный сервак?