Redis: Sentinel — bind 0.0.0.0, проблема с localhost и announce-ip

Автор: | 04/10/2019
 

Изначально в файлах настроек Sentinel я использовал bind 0.0.0.0, что бы инстансы были доступны по внешним IP.

Из-за этого при развёртывании системы на реальном окружении возникла проблема при определении мастер-хоста и других инстансов Sentinel.

В этом посте — пример такой проблемы и их решение.

На самом деле проблем было больше, но получилось воспроизвести только одну, но основную.

Столкнулся со всем этим, когда разворачивал репликацию и Sentinel из Ansible, поэтому некоторые примеры будут в виде Ansible-шаблонов.

Текущий сетап

Redis реплики и Sentinel запущены на AWS EC2.

В примерах ниже будут:

  1. Console хост, он же мастер-хост: тут работает Redis Master и первый Sentinel-инстанс
  2. App1 и App2: два ЕС2 с Redis-репликами и двумя Sentinel-инстансами

Redis replication configs

Мастер конфиг — redis-cluster-master.conf.j2:

bind 0.0.0.0
port 6389
...

Слейвы — общий конфиг redis-cluster-slave.conf.j2:

slaveof dev.backend-console-internal.example.com 6379
bind 0.0.0.0
port 6389
...

Деплоим, проверяем:

root@bttrm-dev-console:/etc/redis-cluster# redis-cli -p 6389 info replication
Replication
role:master
connected_slaves:2
slave0:ip=10.0.2.91,port=6389,state=online,offset=1219,lag=1
slave1:ip=10.0.2.71,port=6389,state=online,offset=1219,lag=1
...

Гуд — тут всё хорошо.

Redis Sentinels configs

А теперь добавляем инстансы  Sentinel — redis-cluster-sentinel.conf.j2:

sentinel monitor {{ redis_cluster_name }} dev.backend-console-internal.example.com 6389 2
bind 0.0.0.0
port 26389
sentinel down-after-milliseconds {{ redis_cluster_name }} 6001
sentinel failover-timeout {{ redis_cluster_name }} 60000
sentinel parallel-syncs {{ redis_cluster_name }} 1
daemonize yes
logfile {{ redis_cluster_logs_home }}/redis-sentinel.log
pidfile {{ redis_cluster_runtime_home }}/redis-sentinel.pid

Деплоим, проверяем:

root@bttrm-dev-console:/etc/redis-cluster# redis-cli -p 26389 info sentinel
Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redis-dev-cluster,status=ok,address=127.0.0.1:6389,slaves=2,sentinels=3

Казалось бы — всё хорошо?

Но нет.

Проблемы с IP хостов

Проверяем лог на App-1:

root@bttrm-dev-app-1:/etc/redis-cluster# tail -f /var/log/redis-cluster/redis-sentinel.log
3163:X 08 Apr 14:24:18.586 * +sentinel-address-switch master redis-dev-cluster 10.0.2.104 6389 ip 10.0.2.104 port 26389 for 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
3163:X 08 Apr 14:24:19.034 * +sentinel-address-switch master redis-dev-cluster 10.0.2.104 6389 ip 127.0.0.1 port 26389 for 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
3163:X 08 Apr 14:24:20.653 * +sentinel-address-switch master redis-dev-cluster 10.0.2.104 6389 ip 10.0.2.104 port 26389 for 32aca990c4e875eab7ba8cd0a7c4e984d584e18c

И конфиг самого Sentinel:

root@bttrm-dev-app-1:/etc/redis-cluster# cat redis-sentinel.conf
sentinel myid a8fdd554a587467aadd811989c78d601433a2f37
bind 0.0.0.0
port 26389
sentinel monitor redis-dev-cluster 10.0.2.104 6389 2
...
Generated by CONFIG REWRITE
dir "/"
maxclients 4064
sentinel config-epoch redis-dev-cluster 0
sentinel leader-epoch redis-dev-cluster 0
sentinel known-slave redis-dev-cluster 10.0.2.71 6389
sentinel known-slave redis-dev-cluster 10.0.2.91 6389
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 a8fdd554a587467aadd811989c78d601433a2f37
sentinel current-epoch 0

Тут сразу две проблемы:

  1. sentinel-address-switch master redis-dev-cluster 10.0.2.104 6389 ip 127.0.0.1 — в логе видно, что постоянно меняется адрес Мастера между 10.0.2.104 и 127.0.0.1
  2. в конфиге Sentinel три записи known-sentinel, хотя должно быть две, как на мастере

К мастеру вернёмся позже, а сейчас глянем на конфиг Sentinel.

В строке sentinel myid a8fdd554a587467aadd811989c78d601433a2f37 указан ID этого инстанса.

Теперь смотрим на конфиг:

sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 a8fdd554a587467aadd811989c78d601433a2f37

Тут:

  • 10.0.2.91 26389 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d — это Sentinel на App-2
  • 127.0.0.1 26389 32aca990c4e875eab7ba8cd0a7c4e984d584e18c — это Мастер (!) на Console, при этом его IP — 127.0.0.1, хотя проверяем с хоста App-1
  • 127.0.0.1 26389 a8fdd554a587467aadd811989c78d601433a2f37 — это Sentinel на App-1, т.е. текущем хосте

Аналогичная картина на App-2:

root@bttrm-dev-app-2:/etc/redis-cluster# cat redis-sentinel.conf
sentinel myid 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d
bind 0.0.0.0
port 26389
sentinel monitor redis-dev-cluster 10.0.2.104 6389 2
...
Generated by CONFIG REWRITE
dir "/"
maxclients 4064
sentinel config-epoch redis-dev-cluster 0
sentinel leader-epoch redis-dev-cluster 0
sentinel known-slave redis-dev-cluster 10.0.2.71 6389
sentinel known-slave redis-dev-cluster 10.0.2.91 6389
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d
sentinel known-sentinel redis-dev-cluster 127.0.0.1 26389 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 a8fdd554a587467aadd811989c78d601433a2f37
sentinel current-epoch 0

И для сравнения — конфиг на Мастере:

root@bttrm-dev-console:/etc/redis-cluster# cat redis-sentinel.conf
sentinel myid 32aca990c4e875eab7ba8cd0a7c4e984d584e18c
bind 0.0.0.0
port 26389
sentinel monitor redis-dev-cluster 127.0.0.1 6389 2
...
Generated by CONFIG REWRITE
dir "/"
maxclients 4064
sentinel config-epoch redis-dev-cluster 0
sentinel leader-epoch redis-dev-cluster 0
sentinel known-slave redis-dev-cluster 10.0.2.91 6389
sentinel known-slave redis-dev-cluster 10.0.2.71 6389
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 a8fdd554a587467aadd811989c78d601433a2f37
sentinel current-epoch 0

И при вызове info sentinel на Мастере и слейвах — у них будет разное кол-во инстансов Sentinel:

root@bttrm-dev-console:/etc/redis-cluster# redis-cli -p 26389 info sentinel | tail -1
master0:name=redis-dev-cluster,status=ok,address=127.0.0.1:6389,slaves=2,sentinels=3

И слейвы:

root@bttrm-dev-app-1:/etc/redis-cluster# redis-cli -p 26389 info sentinel | tail -1
master0:name=redis-dev-cluster,status=ok,address=10.0.2.104:6389,slaves=2,sentinels=4

Т.е.

  1. во-первых — инстанс Sentinel добавляет себя в список known-sentinel, хотя не должен.
  2. во-вторых — добавляет Мастер как 127.0.0.1, вместо его реального IP.

И из-за этого при выборах нового мастера возникает проблема.

Гасим мастер:

root@bttrm-dev-console:/etc/redis-cluster# systemctl stop redis-cluster.service

Проверяем логи на мастере:

30848:X 08 Apr 14:36:36.155 # +sdown master redis-dev-cluster 127.0.0.1 6389
30848:X 08 Apr 14:36:36.436 # +new-epoch 1

Тут odown (objective down) нет вообще (см. SDOWN and ODOWN failure state)

А на обоих слейвах — выборы нового мастера не проходят вообще.

Лог на App-1:

3163:X 08 Apr 14:36:36.087 # +sdown master redis-dev-cluster 10.0.2.104 6389
3163:X 08 Apr 14:36:36.155 # +odown master redis-dev-cluster 10.0.2.104 6389 #quorum 2/2
3163:X 08 Apr 14:36:36.155 # +new-epoch 1
3163:X 08 Apr 14:36:36.155 # +try-failover master redis-dev-cluster 10.0.2.104 6389
3163:X 08 Apr 14:36:36.157 # +vote-for-leader a8fdd554a587467aadd811989c78d601433a2f37 1
3163:X 08 Apr 14:36:36.158 # a8fdd554a587467aadd811989c78d601433a2f37 voted for a8fdd554a587467aadd811989c78d601433a2f37 1
3163:X 08 Apr 14:36:36.163 # 8a705b2e0050b0bd8935e1c3efd1a28fde5d581d voted for a8fdd554a587467aadd811989c78d601433a2f37 1
3163:X 08 Apr 14:36:36.220 # +elected-leader master redis-dev-cluster 10.0.2.104 6389
3163:X 08 Apr 14:36:36.220 # +failover-state-select-slave master redis-dev-cluster 10.0.2.104 6389
3163:X 08 Apr 14:36:36.311 # -failover-abort-no-good-slave master redis-dev-cluster 10.0.2.104 6389
3163:X 08 Apr 14:36:36.377 # Next failover delay: I will not start a failover before Mon Apr  8 14:38:36 2019

App-2:

3165:X 08 Apr 14:36:36.160 # +new-epoch 1
3165:X 08 Apr 14:36:36.162 # +vote-for-leader a8fdd554a587467aadd811989c78d601433a2f37 1
3165:X 08 Apr 14:36:36.168 # +sdown master redis-dev-cluster 10.0.2.104 6389
3165:X 08 Apr 14:36:36.235 # +odown master redis-dev-cluster 10.0.2.104 6389 #quorum 3/2
3165:X 08 Apr 14:36:36.235 # Next failover delay: I will not start a failover before Mon Apr  8 14:38:36 2019

Муть.

Решение

Помогло добавление sentinel announce-ip в конфиг каждого инстанса.

См. Sentinel, Docker, NAT, and possible issues, хотя я не понял почему это проявилось при использовании AWS EC2, которые находятся в одной приватной сети и никакого NAT-а между ними нет.

Останавливаем Sentinel-ы, приводим конфиг к изначальному виду, и добавляем sentinel announce-ip с внешним IP (тут «внешний» — это приватный IP инстанса).

Например на Мастере он будет выглядеть так:

bind 0.0.0.0
port 26389
sentinel monitor redis-dev-cluster dev.backend-console-internal.example.com 6389 2
sentinel down-after-milliseconds redis-dev-cluster 6001
sentinel failover-timeout redis-dev-cluster 60000
daemonize yes
logfile "/var/log/redis-cluster/redis-sentinel.log"
pidfile "/var/run/redis-cluster/redis-sentinel.pid"
sentinel announce-ip 10.0.2.104

Проверяем статус на Мастере:

root@bttrm-dev-console:/etc/redis-cluster# redis-cli -p 26389 info sentinel
Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redis-dev-cluster,status=ok,address=127.0.0.1:6389,slaves=1,sentinels=3

Конфиги.

Мастер:

root@bttrm-dev-console:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 6072b737a93cf7812388be21360b5cb058343f4d
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 57869e8b8914861cc5a80895d3fede9259ce11f6

Окей…

App-1:

root@bttrm-dev-app-1:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 6072b737a93cf7812388be21360b5cb058343f4d
sentinel known-sentinel redis-dev-cluster 10.0.2.104 26389 1218b46be16fb759d52de6919de787c5492b4991

Окей…

App-2:

root@bttrm-dev-app-2:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 57869e8b8914861cc5a80895d3fede9259ce11f6
sentinel known-sentinel redis-dev-cluster 10.0.2.104 26389 1218b46be16fb759d52de6919de787c5492b4991

Окей.

Хорошо — добавляем его в шаблон.

Что бы не пилить отдельный файл для каждого хоста — используем lookup(), см. пост. Ansible: получить IP сервера.

Обновляем redis-cluster-sentinel.conf.j2:

sentinel monitor {{ redis_cluster_name }} dev.backend-console-internal.example.com 6389 2
bind 0.0.0.0
port 26389
sentinel announce-ip {{ hostvars[inventory_hostname]['ansible_default_ipv4']['address'] }}
sentinel down-after-milliseconds {{ redis_cluster_name }} 6001
sentinel failover-timeout {{ redis_cluster_name }} 60000
sentinel parallel-syncs {{ redis_cluster_name }} 1
daemonize yes
logfile {{ redis_cluster_logs_home }}/redis-sentinel.log
pidfile {{ redis_cluster_runtime_home }}/redis-sentinel.pid

Вообще — ничего не мешает просто использовать тот же подход в bind.

Деплоим, проверяем.

Мастер:

root@bttrm-dev-console:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 8148dc7b30a692af02aee44ff051bee129710618
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 156a28ee1c3db77876c0e7326694313c24a56dc2

App-1:

root@bttrm-dev-app-1:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.91 26389 156a28ee1c3db77876c0e7326694313c24a56dc2
sentinel known-sentinel redis-dev-cluster 10.0.2.104 26389 b1fafcde1685861736930c7a88819b2aeac49eea

App-2:

root@bttrm-dev-app-2:/etc/redis-cluster# cat redis-sentinel.conf | grep known-sentinel
sentinel known-sentinel redis-dev-cluster 10.0.2.71 26389 8148dc7b30a692af02aee44ff051bee129710618
sentinel known-sentinel redis-dev-cluster 10.0.2.104 26389 b1fafcde1685861736930c7a88819b2aeac49eea

Работает.

Кстати — в логах пропало постоянное sentinel-address-switch master.

Далее — стопаем мастер, и проверяем логи на инстансах:

Сейчас у нас Sentinel’s IDs:

  1. console/master: b1fafcde1685861736930c7a88819b2aeac49eea
  2. app1: 8148dc7b30a692af02aee44ff051bee129710618
  3. app2: 156a28ee1c3db77876c0e7326694313c24a56dc2

Логи на мастере:

1744:X 08 Apr 16:17:15.495 # +sdown master redis-dev-cluster 127.0.0.1 6389
1744:X 08 Apr 16:17:15.745 # +new-epoch 1
1744:X 08 Apr 16:17:16.809 # +config-update-from sentinel 156a28ee1c3db77876c0e7326694313c24a56dc2 10.0.2.91 26389 @ redis-dev-cluster 127.0.0.1 6389
1744:X 08 Apr 16:17:16.809 # +switch-master redis-dev-cluster 127.0.0.1 6389 10.0.2.71 6389
1744:X 08 Apr 16:17:16.809 * +slave slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.71 6389
1744:X 08 Apr 16:17:16.809 * +slave slave 127.0.0.1:6389 127.0.0.1 6389 @ redis-dev-cluster 10.0.2.71 6389
1744:X 08 Apr 16:17:22.823 # +sdown slave 127.0.0.1:6389 127.0.0.1 6389 @ redis-dev-cluster 10.0.2.71 6389

На App-1:

4954:X 08 Apr 16:17:15.411 # +sdown master redis-dev-cluster 10.0.2.104 6389
4954:X 08 Apr 16:17:15.548 # +new-epoch 1
4954:X 08 Apr 16:17:15.550 # +vote-for-leader 156a28ee1c3db77876c0e7326694313c24a56dc2 1
4954:X 08 Apr 16:17:16.539 # +odown master redis-dev-cluster 10.0.2.104 6389 #quorum 2/2
4954:X 08 Apr 16:17:16.540 # Next failover delay: I will not start a failover before Mon Apr  8 16:19:16 2019
4954:X 08 Apr 16:17:16.809 # +config-update-from sentinel 156a28ee1c3db77876c0e7326694313c24a56dc2 10.0.2.91 26389 @ redis-dev-cluster 10.0.2.104 6389
4954:X 08 Apr 16:17:16.809 # +switch-master redis-dev-cluster 10.0.2.104 6389 10.0.2.71 6389
4954:X 08 Apr 16:17:16.810 * +slave slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.71 6389
4954:X 08 Apr 16:17:16.810 * +slave slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389
4954:X 08 Apr 16:17:22.859 # +sdown slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389

И App-2:

4880:X 08 Apr 16:17:15.442 # +sdown master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.542 # +odown master redis-dev-cluster 10.0.2.104 6389 #quorum 2/2
4880:X 08 Apr 16:17:15.543 # +new-epoch 1
4880:X 08 Apr 16:17:15.543 # +try-failover master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.545 # +vote-for-leader 156a28ee1c3db77876c0e7326694313c24a56dc2 1
4880:X 08 Apr 16:17:15.551 # 8148dc7b30a692af02aee44ff051bee129710618 voted for 156a28ee1c3db77876c0e7326694313c24a56dc2 1
4880:X 08 Apr 16:17:15.604 # +elected-leader master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.604 # +failover-state-select-slave master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.671 # +selected-slave slave 10.0.2.71:6389 10.0.2.71 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.671 * +failover-state-send-slaveof-noone slave 10.0.2.71:6389 10.0.2.71 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:15.742 * +failover-state-wait-promotion slave 10.0.2.71:6389 10.0.2.71 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:16.711 # +promoted-slave slave 10.0.2.71:6389 10.0.2.71 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:16.712 # +failover-state-reconf-slaves master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:16.808 * +slave-reconf-sent slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:17.682 # -odown master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:17.759 * +slave-reconf-inprog slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:17.759 * +slave-reconf-done slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:17.849 # +failover-end master redis-dev-cluster 10.0.2.104 6389
4880:X 08 Apr 16:17:17.849 # +switch-master redis-dev-cluster 10.0.2.104 6389 10.0.2.71 6389
4880:X 08 Apr 16:17:17.850 * +slave slave 10.0.2.91:6389 10.0.2.91 6389 @ redis-dev-cluster 10.0.2.71 6389
4880:X 08 Apr 16:17:17.850 * +slave slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389
4880:X 08 Apr 16:17:23.853 # +sdown slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389

Проверяем текущий мастер:

root@bttrm-dev-console:/etc/redis-cluster# redis-cli -h 10.0.2.104 -p 26389 sentinel get-master-addr-by-name redis-dev-cluster
1) "10.0.2.71"
2) "6389"

10.0.2.71 — это хост App-1.

Проверяем статус репликации на нём:

root@bttrm-dev-app-1:/etc/redis-cluster# redis-cli -p 6389 info replication
Replication
role:master
connected_slaves:1
slave0:ip=10.0.2.91,port=6389,state=online,offset=70814,lag=1

role:master — переключение роли сработало, всё хорошо.

slave0:ip=10.0.2.91 — только один слейв, т.к. на Redis Master нода выключена.

Включаем её:

root@bttrm-dev-console:/etc/redis-cluster# systemctl start redis-cluster.service

Логи Sentinel:

4954:X 08 Apr 16:23:43.337 # -sdown slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389
4954:X 08 Apr 16:23:53.351 * +convert-to-slave slave 10.0.2.104:6389 10.0.2.104 6389 @ redis-dev-cluster 10.0.2.71 6389

Нода поднялась, и Sentinel переключил её в Slave-mode.

Вроде работает…

А ещё сталкивался с такой прелестью, когда Redis Sentinel перенастраивал Слейв так, что она становился слейвом самого себя:

14542:S 04 Apr 13:25:35.187 * SLAVE OF 127.0.0.1:6389 enabled (user request from ‘id=15 addr=10.0.2.104:40087 fd=5 name=sentinel-dc0483ad-cmd age=60 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 event
s=r cmd=exec’)
14542:S 04 Apr 13:25:35.187 # CONFIG REWRITE executed with success.
14542:S 04 Apr 13:25:36.059 * Connecting to MASTER 127.0.0.1:6389
14542:S 04 Apr 13:25:36.060 * MASTER <-> SLAVE sync started
14542:S 04 Apr 13:25:36.060 * Non blocking connect for SYNC fired the event.
14542:S 04 Apr 13:25:36.060 * Master replied to PING, replication can continue…
14542:S 04 Apr 13:25:36.060 * Partial resynchronization not possible (no cached master)
14542:S 04 Apr 13:25:36.060 * Master does not support PSYNC or is in error state (reply: -ERR Can’t SYNC while not connected with my master)

Увы — не получилось зарепродьюсить эту проблему сейчас.