Исходное сообщение
"Выпуск системы мониторинга Zabbix 2.2" Отправлено Andrey Mitrofanov, 13-Ноя-13 17:46
>> -  Реализован режим автоматического обновления структуры базы данных, при котором при переходе на новую значительную версию Zabbix  не требуется ручной запуск SQL-скриптов; > Меня это пугает. При апгрейде с 1.8 до 2.0 в таблицах истории > и трендов появилось поле наносекунд. Если бы это обновление делалось автоматически > на базе размером в 300-400 Гб, у нас бы весь мониторинг > на неделю остановился бы. При ручном обновлении как-то попроще понять, какую > часть телодвижений можно сделать вручную и безопасным образом. У меня апгрейд 1.8->2.0 (psql -U zabbix < patch.sql) базы 35Гб(фрагментированный исходник ~45G) занял 16 минут. Вместе с бекапами и перезапусками всего и вся руками -- пара часов. На неделю? Ну да, верю... #Если те 300-400 [фрагментированы =не исп.партишонинг,] не придуманы, на PgSQL и ещё доступны: посмотри на вывод wiki.postgresql.org/wiki/Show_database_bloat там. ---- Ну, продакшен базу я ещё побэкапил для проформы (исх.база 1.8: 45.2G 1) pg_dump -v -Fd -Z9 -f dumpdir, <20min, out:2,4G 2) nice pg_dump -v -U zabbix -Fc -Z9 -f dump-file zabbix, 64m7s, 2.23G +ресторы во вторую базу - проверка и сравнение с/без -jNN (CREATE DATABASE 0 -> 5.8Gb ) на том же сервере (с работающим осн.продакшеном) 1й) restore то ли не делал, то ли не записал - интереснее были другие два->> 2a) pg_restore -v -d newzab -U zabbix -Fc dump-file, 71m58, 5.8G -> 34.4G 2b) тот же pg_restore с -j16, 41m13, [те же]34.4G)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> - Реализован режим автоматического обновления структуры базы данных, при котором при переходе на новую значительную версию Zabbix не требуется ручной запуск SQL-скриптов; >> Меня это пугает. При апгрейде с 1.8 до 2.0 в таблицах истории >> и трендов появилось поле наносекунд. Если бы это обновление делалось автоматически >> на базе размером в 300-400 Гб, у нас бы весь мониторинг >> на неделю остановился бы. При ручном обновлении как-то попроще понять, какую >> часть телодвижений можно сделать вручную и безопасным образом. > У меня апгрейд 1.8->2.0 (psql -U zabbix < patch.sql) базы 35Гб(фрагментированный исходник > ~45G) занял 16 минут. > Вместе с бекапами и перезапусками всего и вся руками -- пара часов. > На неделю? Ну да, верю... > #Если те 300-400 [фрагментированы =не исп.партишонинг,] не придуманы, на PgSQL и ещё > доступны: посмотри на вывод wiki.postgresql.org/wiki/Show_database_bloat там. > ---- > Ну, продакшен базу я ещё побэкапил для проформы (исх.база 1.8: 45.2G > 1) pg_dump -v -Fd -Z9 -f dumpdir, <20min, out:2,4G > 2) nice pg_dump -v -U zabbix -Fc -Z9 -f dump-file zabbix, 64m7s, > 2.23G > +ресторы во вторую базу - проверка и сравнение с/без -jNN (CREATE DATABASE > 0 -> 5.8Gb ) на том же сервере (с работающим осн.продакшеном) > 1й) restore то ли не делал, то ли не записал - интереснее > были другие два->> > 2a) pg_restore -v -d newzab -U zabbix -Fc dump-file, 71m58, 5.8G -> > 34.4G > 2b) тот же pg_restore с -j16, 41m13, [те же]34.4G)
	Введите код, изображенный на картинке: