Попытка перевести большую систему с 1.8.13 на 2.0.2

[Dev_LC]

В общем полная лажа, краткий отчет которой решил изложить.

1) База данных не пропатчилась скриптом, вываливались куча ошибок, в результате чего была поднята чистая 2.0.2 версия и вручную смигрированы туда шаблоны, хосты, воссозданы настройки.
2) Была конфигурация с главной нодой и двумя проксиками. На 2.0.2 один из проксиков не поднялся, как ни шаманил я с ним, кроме как heartbeat больше от него ничего получить не удавалось, второй работал нормально.
3) При установке агента на наблюдаемый хост, 1.8.13 сервер сразу клал хост в Discovery Hosts. 2.0.2 - нет.
4) Внешние проверки на 2.0.2 работать почему-то перестали (в конфиге путь к скриптам естесственно был поправлен)
5) Доступ к API интерфейсу с наскоку получить не удалось (сильно не разбирался, было и без того проблем досыта, но все же).
6) Многие элементы данных и триггеры из шаблонов 1.8.13 не подходили к 2.0.2 и во время ручной миграции их приходилось удалять.

В итоге бросил я затею перевода на Major 2.* и откатился на 1.8.13. Перекомпилил все ноды и система заработала как часы без лишьнего гемороя.

Что в 2.0.2 заработало без возни:
1) SNMP мониторинг
2) Агент-мониториг posix-серверов
3) Аутентификация через Active Directory

[Dev_LC]

Справедливости ради скажу что еще в одном месте у меня стоит маленькая Zabbix-система, состоящая из одной ноды и почти стандартных настроек. Все без проблем перевелось с 1.8.13 на 2.0.1, используюя sql-патч и простое перекомпилирование бинарников.

[lioncub]

я сделал по другому...
установил 2.0.2, с 1.8 экспортировал шаблоны и хосты, соответственно на 2.0 импортировал. Все через web интерфейс. (само сабой пернес все UserParameter)
Проблем не было.

[Dev_LC]

я сделал по другому...
установил 2.0.2, с 1.8 экспортировал шаблоны и хосты, соответственно на 2.0 импортировал. Все через web интерфейс. (само сабой пернес все userparameter)
Проблем не было.

Я тоже экспортировал/импортировал через веб.

[sersad]

не скажу что система очень большая, но

Количество узлов сети (под наблюдением/без наблюдения/шаблоны)	825	712 / 29 / 84
Количество элементов данных (активных/деактивированых/не поддерживаются)	203554	123737 / 78579 / 1238
Количество триггеров (активированных/деактивированных)[проблема/неизвестно/ок]	27498	26955 / 543  [145 / 0 / 26810]
Количество пользователей (в сети)	39	9
Требуемое быстродействие сервера, новые значения в секунду	153.04	-

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

[saa]

Перехал без особых трудностей, не считая патча который пришлось править, так как использую партиции для хранения данных

Извините за оффтоп, а какой патч?

[sersad]

saa, патч который ковертирует БД с версии 1.8 на 2.0. Проблема была в foreign key.

[gdgsoft]

Готовлюсь, потихоньку, переползать на 2.0.
Жду 2.0.3, т.к. в 2.0.2 появились некотрые баги, для меня важные. Связанные с value_mapped.

Т.к. БД была порядка 100гиг, то решил убить все старые данные. Собственно очистить те таблицы, которые рекомендуются к разбиению для партишенинга. Забекапил базу. Потом пусканул скрипт для ковертирования БД от версии 2.0.2 и получил ошибку:

ERROR 1062 (23000) at line 1752: Duplicate entry '63377-63378' for key 'trigger_depends_1'
Failed to patch Zabbix database. Restore from backup

Что самое интересное, что как экспорт, так и импорт самой БД в/из MySQL проходит без проблем.
Кто то встречался с таким? Что нужно подправить?

Спасибо.

[dotneft]

Готовлюсь, потихоньку, переползать на 2.0.
Жду 2.0.3, т.к. в 2.0.2 появились некотрые баги, для меня важные. Связанные с value_mapped.

Т.к. БД была порядка 100гиг, то решил убить все старые данные. Собственно очистить те таблицы, которые рекомендуются к разбиению для партишенинга. Забекапил базу. Потом пусканул скрипт для ковертирования БД от версии 2.0.2 и получил ошибку:

ERROR 1062 (23000) at line 1752: Duplicate entry '63377-63378' for key 'trigger_depends_1'
Failed to patch Zabbix database. Restore from backup

Что самое интересное, что как экспорт, так и импорт самой БД в/из MySQL проходит без проблем.
Кто то встречался с таким? Что нужно подправить?

Спасибо.

Самое простое, это исправить патч заменив:
CREATE UNIQUE INDEX trigger_depends_1 ON trigger_depends (triggerid_down,triggerid_up);
на
ALTER IGNORE TABLE trigger_depends ADD UNIQUE INDEX trigger_depends_1 (triggerid_down,triggerid_up);

А так... надеюсь что эту вероятную проблему исправят к выходу версии 2.0.3 в ZBX-5125.

[gdgsoft]

dotneft,
внес изменения, но увы... Ошибка осталась.

- Создал заново БД zabbix_test.
- Импортирвал в нее слепок БД от версии 1.8
- Модифировал скрипт:
-- CREATE UNIQUE INDEX trigger_depends_1 ON trigger_depends (triggerid_down,triggerid_up);
ALTER IGNORE TABLE trigger_depends ADD UNIQUE INDEX trigger_depends_1 (triggerid_down,triggerid_up);
- Запускаю скрипт:
./upgrade -uroot -p zabbix_test

И опять таже ошибка:
ERROR 1062 (23000) at line 1753: Duplicate entry '63377-63378' for key 'trigger_depends_1'
Failed to patch Zabbix database. Restore from backup

Единственно номер строки другой, т.к. старую закоментировал, а указанную Вами добавил.

Скрипты от версии pre-zabbix-2.0.3rc1-29617.tar.gz тоже не прошли. В том числе и если изменить команду.

[dotneft]

Очень странно, а попробуйте попросту выполнить этот запрос, вне скрипта.

[Jimson]

1) Беглый взгляд на эти таблицы говорит что таблица trigger_depends это зависимости тригерров где trigger_down это ID зависимого тригера, а trigger_up это ID тригера от которого зависит. Таким образом дубликат сочитания trigger_down+trigger_up это бред. У вас в базе данных мусор, хлам. Понятно что вы не виноваты, но это не меняет сути.

2) Нельзя игнорировать создание уникального индекса, это игнорирование самого себя. Можно вставить в таблицу дубликат (INSERT/UPDATE) предварительно отключив проверку. Но строить уникальный индекс с опцией "это ничего что он не будет уникальный" нельзя.

3) select * from triggers where triggerid in (63377, 63378)
ну и рыть дальше, если не вычистить хлам из базы, то вы уже никогда никуда не сможете мигрировать

[sersad]

а если руками найти все дубликаты в бд и их выпилить?

[gdgsoft]

Выполнил обе команды:

ALTER IGNORE TABLE trigger_depends ADD UNIQUE INDEX trigger_depends_1 (triggerid_down,triggerid_up);
ERROR 1061 (42000): Duplicate key name 'trigger_depends_1'

и:
mysql> select * from triggers where triggerid in (63377, 63378)\G
*************************** 1. row ***************************
triggerid: 63377
expression: {98009}>20
description: Флаппинг интерфейса 3-1 (>20/сутки): {ITEM.VALUE}
url:
status: 0
value: 2
priority: 2
lastchange: 0
dep_level: 0
comments:
error: Trigger just added. No status update so far.
templateid: 0
type: 0
*************************** 2. row ***************************
triggerid: 63378
expression: {98010}=0
description: Административное состояние интерфейса 3-1: {ITEM.VALUE}
url:
status: 0
value: 2
priority: 1
lastchange: 0
dep_level: 2
comments:
error: Trigger just added. No status update so far.
templateid: 0
type: 0
2 rows in set (0.01 sec)


Честно скажу, даже не представляю в какую сторону рыть.
Может убить/пересоздать через веб-интерфейс данные тригеры и создать заново зависимость и посмотреть что получится.

Посмотрел несколько триггеров с ID меньшим чем 63377 и 63378. Обратил внимание на то, что до для триггеров "Административное состояние интерфейса" поле "dep_level" содержит "1". Начиная с триггера 63378, "dep_level" содержит "2".

С ID 63377 это уже другой шаблон, но функционально, элементы и триггеры абсолютно идентичны тем, которые идут до ID 63377. Оба шаблона создавались практически на основе одного и того же скрипта через API.

[Jimson]

dep_level выпилили еще полтора года назад, из беты в смысле

что тебе надо делать, надо сделать следующее

select triggerid_down, triggerid_up, count(*) as duplicate from trigger_depends group by triggerid_down, triggerid_up having duplicate > 1;

получишь портятнку дублей и их кол-во

далее делаешь
select * from triggers where triggerid = xxx
где xxx это идентификаторы из колонки triggerid_down предыдущей портянки

затем пробуешь через интерфейс для найденных таким образом тригеров убрать зависимости, притом если это шаблон, то удостовериться что в хостах, использующих этот шаблон, тоже зависимости снимаются

затем вернуться к пункту один - сделать заново портянку, до тех пор пока она не перестанет выдавать дубли