Как ведут себя Redis с часовыми после раскола мозга?
Вопрос о настройке сервера Redis и дозорных.
Есть две подсети, и я хочу иметь всего 4 сервера Redis, по 2 в каждой подсети. Так как могут быть проблемы с подключением, я хотел бы настроить часовые, чтобы разрешить разделение мозгов для высокой доступности.
Поэтому, когда возникает проблема с подключением, появляются две установки Redis, которые некоторое время работают независимо.
Теперь вопрос, что произойдет после подключения подсетей, будет восстановлен. Часовые будут обнаруживать раскол мозга и двух мастеров? Далее они выберут только хозяина, а второй будет понижен до раба? Данные от уцелевшего мастера будут отправлены на более низкий уровень, и ему нужно будет удалить все различия в данных, которые были получены во время проблемы с подключением?
Можно ли что-то настроить для объединения данных?
1 ответ
Существует два способа обработки HA в Redis - сторожевой и Redis кластер.
часовой
Если ведущий не работает должным образом, Sentinel может запустить процесс восстановления после сбоя, когда ведомое устройство переводится в ведущее, другие дополнительные ведомые устройства перенастраиваются для использования нового главного устройства, и приложения, использующие сервер Redis, информируются о новом адресе, который следует использовать при соединительный
В: Поскольку могут возникнуть проблемы с подключением, я бы хотел настроить часовые, чтобы обеспечить разделение мозгов для высокой доступности.
Это анти-паттерн использования часового. Вот аналогичный пример с четным числом узлов, объясненным в документации
Пример 1: только два Стража, НЕ ДЕЛАЙТЕ ЭТОГО
В вышеупомянутой конфигурации мы создали двух мастеров (предполагая, что S2 может переключаться при отказе без авторизации) совершенно симметричным способом. Клиенты могут писать неопределенно обеим сторонам, и нет никакого способа понять, когда раздел исцеляет, какая конфигурация является правильной, чтобы предотвратить постоянное разделенное состояние мозга. Поэтому, пожалуйста, используйте как минимум три Стража в трех разных коробках.
Q: Теперь вопрос, что будет после восстановления подключения подсетей. Часовые будут обнаруживать раскол мозга и двух мастеров?
Эти данные будут потеряны навсегда, так как, когда раздел будет заживать, мастер будет переконфигурирован как раб нового мастера, отбрасывая его набор данных.
Q: Данные от выжившего мастера будут отправлены на пониженный уровень мастер, и ему нужно будет сбросить все различия в данных, которые были получены во время проблемы с подключением?
да
В: Могу ли я что-то настроить для объединения данных? Вы не можете, Redis никогда бы не слить
Redis кластер
Для чего этот зверь?
Возможность автоматического разделения вашего набора данных между несколькими узлами. Возможность продолжить работу, когда подмножество узлов испытывают сбои или не могут связаться с остальной частью кластера.
Так что это в основном решение для нескольких авторов. Но он также не поддерживает операции слияния
Конструкция Redis Cluster позволяет избежать конфликтующих версий одной и той же пары ключ-значение в нескольких узлах, поскольку в случае модели данных Redis это не всегда желательно. Значения в Redis часто очень велики; Обычно можно увидеть списки или отсортированные наборы с миллионами элементов. Также типы данных семантически сложны. Передача и объединение значений такого типа может быть основным узким местом и / или может потребовать нетривиального участия логики на стороне приложения, дополнительной памяти для хранения метаданных и т. Д.
Вернуться к вашему сценарию
Цитирую отсюда
Основные сведения о Sentinel перед развертыванием
Вам нужно как минимум три экземпляра Sentinel для надежного развертывания. Три экземпляра Sentinel должны быть размещены на компьютерах или виртуальных машинах, которые, как считается, выходят из строя независимо. Например, разные физические серверы или виртуальные машины, выполняемые в разных зонах доступности.
Обратите внимание, что вы также можете разместить сторожей на клиентских машинах - этот подход широко используется в демонстрационных версиях Redis https://redis.io/topics/sentinel
Вы также можете использовать кластерное решение, но его сложнее настроить + оно имеет некоторые ограничения для операций с несколькими ключами, и вам все равно нужно будет предоставить большинство узлов на случай, если одна из подсетей выйдет из строя, чтобы иметь какую-то HA