Как стать автором
Обновить

Комментарии 2

Было бы интересно узнать подробности почему именно групповая репликация, на мой вкус выбор странный (подробности ниже).

>> Из-за использования MySQL в текущей конфигурации и тяге к стандартной комплектации
принципиально не бьётся с
>> Шаг 9: Добавление первичных ключей

То есть выбирая между просто master-master репликацией и групповой с внесением изменений в БД zbx-server вы выбрали второе, что на мой вкус принесло такие сайд-эффекты:
— при обновлении zbx-server обновление может не поехать автоматически (представьте, что обновлять его будете не вы?)
— в одной из прошлых версий у забикса были проблемы с gtid-mode=on где-то в районе create table xxx (select * from… ), тут тоже можно словить такие себе грабли
— групповую репликацию на порядок сложнее дебажить чем ММ
— кажется, забиксу для чего-то нужен тип таблиц BLACKHOLE, а он отключен как обязательное требование групповой репликации

при реализации любого из этих четырёх рисков или вы проклянёте сами себя или вас ваши последователи)
Основным критерием выбора групповой репликации было то, что она сама может очень много всего. То есть затраты на обслуживание снижаются, так как не надо тратить время на переключение, восстановление БД и добавление нового сервера очень простое.

В блоге Zabbix есть статья (смотри в Дополнительной литературе), где написано, что добавлять ключи можно. Значит разработчики будут иметь ввиду этот кастом и в будущем я думаю добавят в основную схему БД.

ГП тоже может работать в режиме multi-primary. Но насколько мне известно, так не надо делать, ибо Забикс сам генерит какие-то уникальные ключи и если не дай бог в один момент времени будет запущено несколько инстансов Zabbix сервера, то возникнет конфликт, который придётся решать. Поэтому режим single-primary.

Правильному обновлению Забикс мешала только таблица dbversion, поэтому так был создан ключ по существующему столбцу.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории