Я использую 1 мастер и 1 подчиненный Redis.
Я также хочу использовать оба сервера под балансировкой нагрузки, чтобы можно было использовать оба сервера redis одновременно.
Также я хочу добавить подчиненное устройство в качестве основного. Так я могу это сделать?
Я никогда не пробовал, но главная проблема в том, что при репликации, даже синхронной репликации, redis допускает только отношения «главный-подчиненный», а не отношения «главный / главный».
Следствием этого является то, что если вы пишете на ведомое устройство, эти записи не будут доступны на ведущем устройстве.
Я бы не рекомендовал это. Redis в настоящее время является механизмом репликации главный-подчиненный, и вам нужно будет разделить записи и чтения. Балансировщик нагрузки не сделает этого за вас без значительной работы. Вам нужно будет разделить чтение и запись в вашем приложении или написать промежуточный уровень. Как только вы это сделаете, вы можете разместить несколько подчиненных устройств за балансировщиком нагрузки и направить запись на один мастер.
Redis достаточно быстр, поэтому вы редко увидите значительную задержку репликации. Особенно, если вы запускаете ведущее устройство, настроенное не на локальную запись, и запускаете одно или несколько ведомых устройств не за балансировщиком нагрузки, которые обрабатывают постоянство.
Что касается обработки неработающего мастера, вы можете записать / использовать монитор в стиле пульса на одном или нескольких подчиненных устройствах, которые отслеживают неработающий мастер и переходят к нему. Вы все еще можете использовать балансировщик нагрузки для некоторых из них. Например, используйте виртуальный IP-адрес на LB и установите для назначенного вторичного сервера более низкий вес или любой другой выбранный вами термин LB). Затем настройте этот сервер как подчиненный по отношению к главному, но не в пуле чтения. Попросите его прослушивать нестандартный порт, на который LB не направляется. Когда он обнаруживает, что ведущее устройство отказало процессу, который вы используете, затем перенастраивает его для использования правильного порта и выдает команду SLAVE OF NOONE.
Я также предпочел бы видеть этот процесс мониторинга, а затем сказать балансировщику нагрузки, чтобы он вообще не использовал мастер. Таким образом, если он вернется в оперативный режим до того, как вы будете готовы, вы сможете подчинить его текущему мастеру, а затем вернуться к нему после синхронизации с резервным мастером.
В конечном итоге, насколько важна работа, зависит от того, насколько строги ваши истинные требования. В любом случае, если вы действительно нуждаетесь в том, чтобы не потерять ни одной записи, вы захотите закодировать свой писатель так, чтобы, если он не может подключиться, он ставил в очередь записи на диск и регистрировал или предупреждал кого-то.
Как насчет того, чтобы обрабатывать это в коде вашей настраиваемой службы состояний вместо использования встроенной синхронизации redis?
Таким образом, с двумя или более серверами с балансировкой нагрузки каждый из них будет иметь список других серверов, и после записи в свой локальный экземпляр Redis они просто будут писать ту же запись для остальных?
Предполагая, что это работает, тогда это должно быть просто вопросом обработки синхронизации экземпляра при возвращении сервера в оперативный режим. Не могли бы вы сделать это принудительно при перезапуске службы? Синхронизировать локальную версию с другим экземпляром? Или просто получить все записи с более поздними датами на местном уровне?