Автоматическое переключение на продвинутый Redis Slave с использованием Redis Cluster

Question

Конфигурация: три раздела кластера Redis в трех наборах: один ведущий и один ведомый.Когда мастер выходит из строя, салат сразу обнаруживает сбой и начинает повторную попытку.Тем не менее, салат не обнаруживает, что связанный ведомый повысил себя до уровня «мастер», и продолжает повторять попытку, используя старый мастер, который недоступен и в конечном итоге истекает.Попытка установки различных параметров обновления топологии безрезультатно.

Предлагаемое решение: после сбоя при первом повторении (что является вторым повторением в строке при сбое), повторно запустите обновление топологии (которое использовалось для получения топологии во время инициализации)использование топологии любого из предоставленных узлов (поскольку все они имеют одинаковую информацию о топологии).Это восстановит соединения с текущими мастерами.Затем повторите неудачную операцию на том разделе, который ранее был неудачным.

Answer 1

Redis Cluster ограничен с точки зрения распространения обновлений конфигурации по сравнению с Redis Sentinel.Redis Sentinel передает обновления через Pub / Sub, в то время как Redis Cluster оставляет опрос как единственный вариант.

Салат поддерживает периодическое и адаптивное триггеры обновления топологии кластера .Периодическое обновление топологии через регулярные интервалы, адаптивное обновление прослушивает разъединения и перенаправления кластера.

Вы можете настроить как с помощью ClusterClientOptions.

Периодические, так и адаптивные обновления пытаются охватить большинство случаев, которыев основном догадки, компенсирующие отсутствие правильного распространения изменений конфигурации.Всегда есть лазейки (см. выпуск # 672 ), в которых салат быстрее, чем фактическое изменение топологии.Это оставляет салат с устаревшим представлением топологии, поскольку фактическое изменение происходит несколько позже.