Синхронизация конфигураций 2-х Zabbix серверов

[Fyntik]

Коллеги, добрый день.
Поставлена задача дублировать систему мониторинга на резервной площадке. Необходимо именно дублирование, а не геокластеризация текущей системы. Дублированная система мониторинга будет наблюдать за теми же узлами, что и основная. В качестве БД используется mysql.

Возник вопрос корректной синхронизации конфигураций Zabbix'a на резервной площадке.
Как я вижу итоговую реализацию:
- оператор вносит изменения на основном сервере мониторинга;
- средствами mysql (какими именно средствами вопрос еще открытый и требует обсуждений) изменения из БД основной системы мониторинга переносятся в БД резервной системы мониторинга.

Переноситься будут только таблицы содержащие информацию о настройках, таблицы history, trends, allerts, events и т.п. переноситься не будут.

На сколько жизнеспособна такая реализация и какие лучше всего использовать механизмы для переноса изменений из основной в дублированную систему мониторинга?

Если кто-то решал схожую задачу, то поделитесь итоговым решением.

[yukra]

Ну если мы не говорим о распределенном мониторинге, который в текущей версии более не поддерживается, то я вижу 2 варианта:
1) Репликация нужных таблиц средствами mysql
2) mysqldump && mysqlrestore

Первый вариант должен быть почти мгновенным (сомневаюсь что операторы смогут так быстро что либо создавать\удалять\менять, что бы реплика отстала), второй же более надежным.
Тут же сразу возникает вопрос: Вы хотите Master => Slave или Master <=> Master (в контексте zabbix-сервера)?

На счет жизнеспособности - я как минимум для начала бы попробовал сделать "в лоб".

Как запасной вариант - воять синхронизатор на основе API.

[Fyntik]

Конфигурация будет Master => Slave.

По поводу репликации таблиц, можете подсказать варианты реализации, т.к. ранее с подобным не сталкивался?

[sergadm]

У меня дублирование выполняет система виртуализации путем репликации виртуалок. Нагрузки позволяют держать zabbix на виртуалке.

[Fyntik]

У меня дублирование выполняет система виртуализации путем репликации виртуалок. Нагрузки позволяют держать zabbix на виртуалке.

Приветствую.
Что именно делает vmware, идет реплецирование на резервную площадку?
Если да то получается у Вас единовременно работает только 1 система мониторинга. У меня задача чтобы одновременно работало 2 системы мониторинга на разных площадках, который следят за одними и теми же узлами сети.

[yukra]

По поводу репликации таблиц, можете подсказать варианты реализации, т.к. ранее с подобным не сталкивался?

Как то так: habrahabr.ru/post/56702/ но с опцией replicate-ignore-table

[Phoen]

Репликация master master + ucarp.

https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

http://ruhighload.com/post/%D0%9A%D0%B0%D0%BA+%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D1%8C+MySQL+Master-Master+%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8E

[yukra]

ucarp

Перед этим стоит уточнить возможность переноса ip-адресов между разными площадками. Да и не особо понятно нафиг оно вообще тут нужно

[Fyntik]

Перед этим стоит уточнить возможность переноса ip-адресов между разными площадками. Да и не особо понятно нафиг оно вообще тут нужно

переноса ip адресов не нужно, замысел в том чтобы иметь 2 независимые системы мониторинга, но одинаковым набором узлов, шаблонов и прочего для мониторинга.

[pzabortsev]

Да и не особо понятно нафиг оно вообще тут нужно

Все для пресловутой отказоустойчивости, видимо.
А мониторить вы будете оборудование на третьей площадке?
Иначе не очень понятен выбор варианта обеспечения отказоустойчивости

[Fyntik]

Все для пресловутой отказоустойчивости, видимо.
А мониторить вы будете оборудование на третьей площадке?
Иначе не очень понятен выбор варианта обеспечения отказоустойчивости

именно для отказоустойчивости, мониторить будем оборудование на других площадках.
т.к. полностью обеспечить отказоустойчивость аплинков на обоих площадках не можем и появился такой вариант реализации.
вариант 2-ух нодового геокластера тоже пока что не рассматривается из-за отсутствия 100% надежного канала между датацентрами, во избежание сплитбрейна.

[Fyntik]

Появился небольшой вопрос по настройке master-slave mysql базы.
Если настроить подобную репликацию с опцией --replicate-ignore-table у slave ноды не реплицирующиеся таблицы тоже будут в read only или будут доступны для записи?

[yukra]

Появился небольшой вопрос по настройке master-slave mysql базы.
Если настроить подобную репликацию с опцией --replicate-ignore-table у slave ноды не реплицирующиеся таблицы тоже будут в read only или будут доступны для записи?

Вообще форум для вопроса выбран не совсем корректно, но ситуация примерно такая: read only включается в конфигах mysql опцией "read-only = 1". Это запрещает писать в таблицу всем пользователям, у которых нету Super_priv и Repl_slave_priv (если я не путаю). Если данная опция в конфиге не указана, то работают стандартные правила: "у пользователя доступ за запись - пишем". Автоматически read-only на слэйве не включается. То есть самый обычный пользователь может изменять данные на слэйве имея права на запись в соответствующую таблицу\базу.