Summary: | Бэкпортировать на t6 | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Andrew Kornilov <hiddenman> |
Component: | zabbix-mysql | Assignee: | Alexei Takaseev <taf> |
Status: | CLOSED WORKSFORME | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P3 | CC: | cas, taf |
Version: | unstable | Keywords: | backport |
Hardware: | all | ||
OS: | Linux |
Description
Andrew Kornilov
2013-03-27 18:37:54 MSK
Правильно. Но мне интересно, почему на p6 не просите? Ну с t6 на p6 проще, думаю, хотя не уверен до конца. Вот из сизифа это бэкпортировать печально. Я сам request tracker с трудом обновил в сизифе, со всеми модулями и как это все всем гамбузом перекинуть в t6/p6 - не представляю. Но если майнтейнер соберет для p6 еще, буду благодарен. Ибо новый zabbix уже даааавно нужно везде сделать. Приветствую. Для своих нужд я использую zabbix 2.0 на p6. Но переход с 1.8 на 2.0 с наработанной базой в сотни узлов и тысячи контролируемых параметров у меня потребовал весьма нетривиальных ручных действий. В клинических случаях может потребоваться полное пересоздание базы с настройками узлов. Именно по этой причине я не выкладываю бэкпорт в репозитории t6/p6. Для сильных духом я могу выложить в people/taf сборки zabbix'а под p6/t6 (В ответ на комментарий №3) > Именно по этой причине я не выкладываю бэкпорт в репозитории t6/p6. Приветствую. Разве это повод не выкладывать? Если можно, выложите в people и уточните, какого плана проблемы возникли? 1.8 и 2.0 же вроде бы недалеко ушли друг от друга по структуре базы. Спасибо. (В ответ на комментарий №4) > (В ответ на комментарий №3) > > Именно по этой причине я не выкладываю бэкпорт в репозитории t6/p6. > > Приветствую. > Разве это повод не выкладывать? > > Если можно, выложите в people и уточните, какого плана проблемы возникли? 1.8 и > 2.0 же вроде бы недалеко ушли друг от друга по структуре базы. > > Спасибо. База там все-таки переделана значительно. Очень много добавлено-удалено-переименовано полей в таблицах, смена типов, умолчаний, индексы. Но это вполне по силам отследить и загнать в скрипт. Больше всего неприятностей мне доставило то, что в новой версии был занчительно расширен объем первоначально помещаемых в базу данных (типы оборудования, изображения, контролируемые данные, триггеры и тд), при этом новые данные пересекаются со старым набором первоначальных данных. К этому еще стоит добавить то, что заведенные пользователем данные никак не изолируются от тех, что вносятся при установке. Потому будут еще пересечения и с данными пользователя. После серии экспериментов я просто на старой версии все данные, которые можно экспортировать, перегнал в xml. Потом на новой произвел импорт. Но и после этого пришлось кропотливо наводить порядок в шаблонах, узлах данных и т.д. Естественно наработанными на предыдущей версии данными пришлось пожертвовать. Собственно, вот сборка под P6: ftp://ftp.altlinux.ru/pub/people/taf/p6/ новые версии буду выкладывать туда же. Желающие могут использовать zabbix по ссылке в предыдущем сообщении > База там все-таки переделана значительно. Очень много
> добавлено-удалено-переименовано полей в таблицах, смена типов, умолчаний,
> индексы. Но это вполне по силам отследить и загнать в скрипт.
Так у заббикса всегда так было вроде. И всегда с ним шел некий мегаскрипт, который это все сам делал. В случае 2.0 разве не так?
(В ответ на комментарий №7) > > База там все-таки переделана значительно. Очень много > > добавлено-удалено-переименовано полей в таблицах, смена типов, умолчаний, > > индексы. Но это вполне по силам отследить и загнать в скрипт. > Так у заббикса всегда так было вроде. И всегда с ним шел некий мегаскрипт, > который это все сам делал. В случае 2.0 разве не так? Мегастрипт в наличии, и он даже вполне рабочий. Но головняк доставляет не структура базы, а данные в ней. |