2 узла Redis высокой доступности

Как правило, использование двух узлов никогда не является хорошей идеей, потому что это обязательно приведет к проблеме разделения мозга: когда сеть между двумя узлами не работает на мгновение или два, два узла неизбежно будут думать, что друг друга нет в сети, и будут продвигать/сохранять себя. стать мастером и начать принимать запросы от других сервисов. Затем происходит расщепление мозга.

И если вы согласны с этой возможной ситуацией, то вы можете изучить настройку master-slave с помощью файла сценария и службы высокой доступности, такой как кардиостимулятор или keepalived.

Как правило, вы должны сообщить менеджеру кластера с помощью предопределенного правила, что, когда две машины воссоединяются в состоянии разделенного мозга, какая из них является вашим предпочтительным мастером.

Когда выбран мастер, выполните скрипт, и в основном он выполняет slaveof no one на себе и выполняет slaveof <new-master-ip> <port> на другом узле.

Вы можете сделать еще один шаг в своем файле сценария и попытаться объединить два набора данных вместе, но достижимо это или нет, полностью зависит от того, как вы организовали свои данные в Redis и как долго вы готовы ждать, чтобы получить все необходимые данные. данные синхронизированы.

Я сам делал это раньше через кардиостимулятор + коросинк.

Хорошо, частичное решение с SLAVEOF:

Вы можете вручную повысить статус ведомого до ведущего, запустив:

SLAVEOF NO ONE

Вы можете вручную перевести ведущий на подчиненный, запустив:

SLAVEOF <HOST> <port>

Кластеризация должна быть отключена.

Я бы порекомендовал иметь как минимум 3 узла с Sentinel Setup для включения сплетен/кворума для автоматического продвижения ведомого к ведущему, когда текущий главный узел выходит из строя.

Если вы подключили реплику к сети вручную, изменив ее на replicaof no one, вам нужно быть осторожным, чтобы вернуть неисправный мастер обратно в сеть как реплику нового узла, чтобы не перезаписать более свежие данные. Я бы не рекомендовал делать это вручную. Вы хотите свести к минимуму время простоя, поэтому идеально подходит автоматическое аварийное переключение.

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

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

Что касается проблемы с разделенным мозгом, KeyDB может обрабатывать сценарии с разделенным мозгом, когда связь между мастерами разорвана, но записи продолжаются. Каждая запись имеет отметку времени, и когда соединение восстанавливается, каждый мастер будет делиться своими новыми данными. Победит самая новая запись. Это предотвращает перезапись устаревших данных новыми данными, записанными после разрыва соединения.