Я оцениваю кластерные возможности Redis 3 (на данный момент я использую Redis 2 автономно), поэтому читаю информацию по адресу http://redis.io/topics/cluster-tutorial.
В этом документе я прочитал очень важную информацию:
Обратите внимание, что минимальный кластер для нормальной работы требуется как минимум три главных узла. Для ваших первых тестов настоятельно рекомендуется запустить кластер из шести узлов с тремя ведущими и тремя ведомыми.
Это правда? На мой взгляд, это правильно, если я буду использовать возможности сегментирования (данные распределяются между узлами), но что, если мне это не нужно, и я был бы счастлив иметь данные только на одном узле?
Мне в основном нужен один мастер и два подчиненных (чтобы кластер работал, если один узел выйдет из строя), могу ли я использовать эту конфигурацию в производственной среде? Если да, то каковы противопоказания?
Спасибо большое за помощь!
Это правда?
Да, поэтому это есть в документации :)
На мой взгляд, это правильно, если я буду использовать возможности сегментирования (данные распределяются между узлами), но что, если мне это не нужно, и я был бы счастлив иметь данные только на одном узле?
Использование Redis в кластерном режиме означает сегментирование. Если вас устраивает единственный экземпляр, просто не используйте кластер. В противном случае см. сама спецификация кластера чтобы лучше понять основные предположения. В частности, в случае минимальной конфигурации кластера вам понадобятся 3 мастера для обеспечения доступности кластера в случае раздела, иначе вы не сможете договориться о большинстве.
Я знаю, что это старый вопрос, но если кому-то нужна аналогичная настройка, можно использовать конфигурацию Master-Slaves вместо Cluster. Тебе нужно:
Если вы можете сделать его достаточно умным, вы можете просто писать для мастера и читать со всех узлов. Я использую эту настройку на некоторых сайтах Wordpress, но плагин не предназначен для определения того, кто является мастером, поэтому я просто использую HAProxy для обнаружения мастера и отправки всего трафика на этот узел. Если главный узел умирает, подчиненный узел берет на себя роль ведущего (это управляет redis-sentinel). HAProxy обнаруживает, что мастер изменился, а затем меняет узел, который получает весь трафик.
Извините, что не публикую код и примеры, но сейчас я не могу это сделать.
Приветствую!!
Это правда?
Нет, это не так действительно правда. Это сильная рекомендация (как вы можете понять по формулировке «это работает, как ожидалось»; если вы не ожидаете, что ваши данные будут надежными, и вы ожидаете, что они исчезнут, и т. Д. - вы жестяная банка настроить кластер с одним узлом. Почему вы вместо того, чтобы просто выключить кластерный режим ... решать вам.)
Так что да ты жестяная банка настроить одноузловой кластер, даже если это не рекомендуется (по всем причинам, указанным в других ответах и документации). В коде кластера redis нет ничего, что вас остановит, кроме проверки в redis- Помощник trib.rb, призванный отговорить наивных пользователей.
Чтобы обойти эту проверку и настроить кластер с одним узлом (если вы уверены, что это именно то, что вам нужно - помните, что почти наверняка это не так), вы можете вручную назначить осколки своему узлу с помощью CLUSTER ADDSLOTS 1 2 3 ... (и т. д. для всех 16384 шардов). Или используйте версию redis-trib для Python, в которой нет проверки безопасности с тремя узлами (redis-trib.py create 127.0.0.1:6379).
Если вы полагаетесь на Redis для отработки отказа, вам понадобится минимум три главных узла и три подчиненных узла (минимум 3 сервера, на каждом из которых работает главный и подчиненный).
Если вы используете внешнее программное обеспечение кластера, например контрольное сообщение, вы можете настроить два узла, один из которых является главным, а другой - подчиненным, в режиме кластера, выделить все 16384 слота для главного и использовать сценарии аварийного переключения для «CLUSTER FAILOVER TAKEOVER», когда главный ВНИЗ. Конечно, вы также можете настроить IP-адрес службы для аварийного переключения вместе с redis. Эта дополнительная договоренность также позволяет использовать некластерный клиент Redis.
Производство работало в течение одного года и несколько раз выполнялось после сбоя (перезагрузка компьютера для обновления ядра), и пока никаких проблем со стороны операционной группы не сообщалось.