Среда состоит из двух виртуальных машин 2012R2, на которых запущен RabbitMQ в режиме высокой доступности (ха-все) в своих очередях. Я использую Veeam для создания резервных копий моментальных снимков, которые отправляются за пределы предприятия в рамках политики аварийного восстановления.
Я наблюдаю периодические сбои кластера при резервном копировании Veeam. Когда кластер ломается, это вызывает регистрацию событий Mnesia или иногда приводит к полному отключению одного узла. Я считаю, что проблема заключается в том, как Veeam передает виртуальную машину на паузу, по сути, на короткое время, а затем продолжает работу. Когда возникает этот всплеск, оба узла видят, что другой исчезает, и вторичный узел немедленно продвигается к мастеру. Когда два мастера бегут, как только они видят друг друга (буквально через несколько секунд), они бодаются друг с другом, и кластер ломается.
Я читал о net_ticktime Вот и реализовал 300 секунд, думая, что это поможет сделать кластер более устойчивым к коротким ошибкам Veeam, но, похоже, это не помогло. Когда один узел видит, что другой исчезает, вторичный узел немедленно продвигается к мастеру и, похоже, не использует net_ticktime настройка.
Пример ошибки Mnesia:
Mnesia('rabbit@Node01'): ** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, 'rabbit@Node02'}
Кто-нибудь еще испытывал это или что-то подобное? Существуют ли дополнительные параметры конфигурации с RabbitMQ или Erlang, которые могут помочь сделать кластер более устойчивым к небольшим всплескам потери связи между узлами?