Я читаю много документации по конфигурациям сети Redis, и меня смущает то, как кажется, что требования в ментальной модели архитектуры, которая у меня была, похоже, не соответствуют текущим параметрам.
Прежде всего: мне не нужен шардинг, потому что масштабируемость сейчас не проблема. Итак, пока один мастер (узел M).
Во-вторых: мне нужна избыточность, то есть, если главный узел выходит из строя, я хочу, чтобы второй узел взял на себя управление и выполнял запросы, которые клиент им отправляет. Назовем это первым ведомым устройством: резервное ведомое устройство (узел FS).
В-третьих: мне также нужен еще один узел-реплика, который является подчиненным, но обслуживает только запросы только для чтения. Если к нему подключается клиент, и он пытается изменить данные, узел должен выдать ошибку. Назовем это вторым подчиненным устройством: подчиненное устройство только для чтения (RS).
Последнее: я хочу аварийное переключение для ведомого устройства, доступного только для чтения. То есть, в случае, если RS умирает, я хочу, чтобы другой подчиненный сервер, доступный только для чтения, взял на себя его задачи. Назовем это четвертым подчиненным устройством: резервное подчиненное устройство только для чтения (FRS).
Есть ли способ настроить Redis таким образом? Кажется, все режимы развертывания (читал эту статью: https://blog.octo.com/en/what-redis-deployment-do-you-need/) иметь один мастер, кроме кластерного. Теперь мне кажется, что мой узел «FS» будет вторым мастером, потому что он принимает запросы на запись, однако в конфигурации кластера по умолчанию включен шардинг и, кажется, нет нормального способа отключить его, если я что-то не упускаю.
Насколько я понимаю, redis sentinel удовлетворит ваши потребности.
У вас будет 1 главный (M) и 3 подчиненных (FS, RS и FRS). Все подчиненные устройства подключены к одному и тому же мастеру.
Затем вы развертываете нечетное количество процессов-дозорных, которые контролируют мастер. Если ведущий выходит из строя, стражи продвигают одно из трех ведомых устройств к новому мастеру.
Теперь, исходя из ваших заметок, вы хотите сделать «FS» подчиненным в качестве нового мастера. Sentinel не знает, что «FS» является особенным, он может выбрать любое из 3 ведомых устройств в качестве кандидата на роль нового мастера. Чтобы сделать «FS» особенным, вам необходимо установить «приоритет реплики» для каждого из ведомых устройств. Вы не хотите, чтобы «RS» и «FRS» когда-либо становились мастером, поэтому установите приоритет реплики = 0 для обоих этих узлов. Тогда дозорный будет рассматривать «FS» только тогда, когда придет время выполнить аварийное переключение.
Другая часть вашего вопроса - что происходит, когда "RS" умирает? Для ведомых устройств нет механизма переключения при отказе - он просто не нужен. «RS» и «FRS» - это всего лишь две реплики для чтения, обе указывают на один и тот же мастер. Клиенты должны быть настроены на случайную пробу одной из двух реплик, чтобы вы распределяли нагрузку. Если «RS» умирает, клиент просто пробует «FRS». Поскольку он доступен только для чтения, согласованность данных не имеет значения.
Для РС и ФРС - установить дополнительное свойство replica-read-only yes. Это гарантирует, что запись не удастся.
Вы можете использовать нестандартную настройку, если хотите. Если вы это сделаете, переключение с M на FS не произойдет автоматически. Если / когда мастер M выйдет из строя, вам нужно будет: а) обнаружить его, б) пометить FS как подчиненный, в) убедиться, что все ваши клиенты Redis начинают писать новому мастеру, и г) перенастроить RS и FRS, чтобы начать следовать новый хозяин. Sentinel делает это автоматически, но имеет повышенную сложность. Вы также можете легко сделать это самостоятельно.