Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Теги: linux, nosql, linux-администрирование, redis, кластер, система управления базами данных, линукс, docker swarm

2 Всем привет, это заключительная часть статьи, где подробно описывается развёртываниеRedis-кластера. Начало смотрите<a>здесь</a>.

3 Итак, изначально было принято решение описать каждый сервис отдельно для удобного их размещения на нодах кластера.Docker-compose.ymlбудет выглядеть следующим образом:

4 redis-master: image: username/redis-master:0.1 ports: - mode: host protocol: tcp published: 6379 target: 6379 deploy: replicas: 1 endpoint_mode: dnsrr placement: constraints: - node.labels.redis-master == true networks: redis-net: aliases: - redis-masterВ данном примере описан сервисredis-master. В секции ports мы описываем какой режим сети использовать (в нашем случае host позволяет напрямую использовать сеть ноды кластера), какие порты контейнера мы выносим из контейнера.

5 Endpoint_mode: dnsrr означает, что мы принудительно выключаем mesh-сеть, которая по умолчанию работает вDocker swarm. Отключения mesh-сети являются крайне важным моментом в нашем сетапе. Если бы она была включена, то подключаясь к порту 6379 к любой ноде кластера, клиент был бы автоматически смаршрутизирован в любой доступный нам контейнер и не факт, что он бы подключился именно к мастеру.

6 Более подробно о типе сетей в Docker swarm вы можете ознакомиться по данной<a>ссылке</a>.Aliases- на всякий случай ещё раз указываем сетевой алиас нашего сервиса.Networks- указываем, к какой сети будет присоединен наш сервис, в данном случае к redis-net.Placement constraintsпозволяет нам ограничить размещение нашего сервиса, в данном случае мы используем ограничение по тегам, которые выставили ранее.

7 Секция, описывающая redis-slave, выглядит следующим образом:

8 redis-slave-1: image: mrgreyves/redis-slave:0.1 ports: - mode: host protocol: tcp published: 6379 target: 6379 deploy: replicas: 1 endpoint_mode: dnsrr placement: constraints: - node.labels.redis-slave-1 == true depends_on: - redis-master networks: - redis-netОсновные отличия в описании redis-slave заключаются в директиве depend_on. Она позволяет указать зависимость в запуске сервисов. Slave будет запущен только после того, как запустится redis-master.

9 Секция, описывающая redis-sentinel:

10 redis-sentinel-1: image: mrgreyves/redis-sentinel:0.6 ports: - mode: host protocol: tcp published: 5000 target: 5000 deploy: replicas: 1 endpoint_mode: dnsrr placement: constraints: - node.labels.redis-sentinel-1 == true depends_on: - redis-master networks: redis-net:Все директивы мы уже разобрали немного ранее. И вот, настал тот торжественный момент, когда мы с вами можем запустить наш кластер. Для это воспользуемся следующей командой:

11 docker stack deploy --compose-file=docker-compose-v2.yml redis--compose-file= - указываем, какой именно файл использовать. Redis - название нашего стака.

12 Также хочу отметить, что образы, которые мы создавали ранее, мы запушили в публичный репозиторий на docker hub. Если же вы используете приватный, необходимо использовать дополнительную опцию --with-registry-auth и не забыть перед этим залогиниться в нужном реджестри командой docker login.

13 Для проверки нашего стака используем команду:

14 docker stack services redisЕсли всё прошло хорошо, то вывод будет следующим:

15 Убедимся, что redis-master действительно master. Для это подключаемся любым клиентом к ноде, на которой он запущен, и воспользуемся командойINFO. Нас интересует секцияReplication, если в ней указаноrole:master, то всё прошло хорошо.

16 Далее подключаемся к следующей ноде и воспользуемся аналогичной командой. Если мы видим, чтоrole:slave, то значит, что у нас всё хорошо.

17 А теперь начинается самая интересная часть: мы будем ломать наш кластер и сделаем это слегка в софтовом режиме, а именно: просто удалим сервисredis-master. Для этого вdocker-compose.ymlпросто меняем количество реплик на 0 и деплоимся.

18 Логи redis sentinel будут следующими:

19 1:X 02 Feb 10:50:58.299 * +slave slave 10.0.3.18:6379 10.0.3.18 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.291 # +sdown master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.363 # +odown master mymaster 10.0.3.16 6379 #quorum 2/2 1:X 02 Feb 12:03:50.363 # +new-epoch 1 1:X 02 Feb 12:03:50.363 # +try-failover master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.367 # +vote-for-leader 37e8f4093969307733548e1948c184a1a69c2552 1 1:X 02 Feb 12:03:50.374 # 289730ac61e05b7edc005c348088625db26d3983 voted for 37e8f4093969307733548e1948c184a1a69c2552 1 1:X 02 Feb 12:03:50.381 # 6428c92d37154089ce67a33123f3fd0b86afe4e6 voted for 37e8f4093969307733548e1948c184a1a69c2552 1 1:X 02 Feb 12:03:50.422 # +elected-leader master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.422 # +failover-state-select-slave master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.485 # +selected-slave slave 10.0.3.17:6379 10.0.3.17 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.485 * +failover-state-send-slaveof-noone slave 10.0.3.17:6379 10.0.3.17 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:50.549 * +failover-state-wait-promotion slave 10.0.3.17:6379 10.0.3.17 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:51.440 # +promoted-slave slave 10.0.3.17:6379 10.0.3.17 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:51.440 # +failover-state-reconf-slaves master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:51.512 * +slave-reconf-sent slave 10.0.3.18:6379 10.0.3.18 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:52.447 * +slave-reconf-inprog slave 10.0.3.18:6379 10.0.3.18 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:52.447 * +slave-reconf-done slave 10.0.3.18:6379 10.0.3.18 6379 @ mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:52.510 # -odown master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:52.510 # +failover-end master mymaster 10.0.3.16 6379 1:X 02 Feb 12:03:52.511 # +switch-master mymaster 10.0.3.16 6379 10.0.3.17 6379 1:X 02 Feb 12:03:52.511 * +slave slave 10.0.3.18:6379 10.0.3.18 6379 @ mymaster 10.0.3.17 6379 1:X 02 Feb 12:03:52.511 * +slave slave 10.0.3.16:6379 10.0.3.16 6379 @ mymaster 10.0.3.17 6379 1:X 02 Feb 12:03:55.563 # +sdown slave 10.0.3.16:6379 10.0.3.16 6379 @ mymaster 10.0.3.17 6379Из них мы видим, что зафиксировано падение мастера:

20 +sdown master mymaster 10.0.3.16 6379И начался выбор нового мастера, который впоследствии стал успешно выбран:

21 +elected-leader master mymaster 10.0.3.16 6379После этого мы подключаемся к соседней ноде и командойINFOпроверяем его роль. Если роль -master, значит переключение произошло успешно.

22 Полезная заметка? Напишите в комментариях!