У нас есть план обслуживания главного и подчиненного коммутатора Redis, который вручную переводит подчиненное устройство в ведущее, сохраняя в то же время записи доступными.Это работает так:
В начале у нас есть
Master(M) <-- Slave(S1)
, и мы хотим сделать S1 новым мастером.Поэтому мы добавляем нового ведомого (S2):
M <-- S1 <-- S2
и делаем доменное имя, указывающее на M, указывающим на S1.DNS вступает в силу, чтобы через какое-то время записи от клиентов могли поступать как к M, так и к S1:
M <-- S1 <-- S2
^ ^ ^
|(Write) |(Write) |(Read)
Client1 Client2 Client3
Все в порядке, что чтение может видеть данные с задержкой, мы можем принять возможную согласованность.Поскольку обе записи в M и S1 в конечном итоге будут реплицироваться в S2, данные не будут потеряны.
Через некоторое время (DNS вступит в силу), M не будет писать в него, мы можем смело забрать его, чтобысделайте S1 новым главным:
M(previously S1) <-- S2
Приведенный выше план обслуживания главного и подчиненного коммутатора работает хорошо, пока мы не попытаемся обновить наш Redis до версии 4.x.
В Redis Replication doc , в нем говорится:
Также обратите внимание, что, поскольку записи Redis 4.0 подчиненные являются только локальными и не распространяются на подчиненные устройства, подключенные к экземпляру.Вместо этого подчиненные подчиненные всегда будут получать поток репликации, идентичный потоку, отправляемому ведущим верхнего уровня промежуточным подчиненным.Так, например, в следующей настройке:
A ---> B ---> C
Даже если B доступен для записи, C не будет видеть записи B и вместо этого будет иметь такой же набор данных, какглавный экземпляр A.
В этом случае, если мы обновимся до Redis 4.x, следующий
M <-- S1 <-- S2
^ ^ ^
|(Write) |(Write) |(Read)
Client1 Client2 Client3
S1 больше не будет распространять свои записи на S2, таким образом читаетв S2 будет потеря данных!
Поэтому мой вопрос: как заставить наш обычный план обслуживания главного и подчиненного коммутатора снова работать в Redis версии 4?