I have a Redis cluster with the following nodes:
192.168.0.14:6379 master (slots from 0 to 16383)
192.168.0.15:6379 slave (slots from 0 to 16383)
192.168.0.16:6379 master (without slots)
Documentation says that any node can redirect queries to the properly node. But I can not redirect requests from 192.168.0.16:6379 master node. Here is what I tried:
192.168.0.16:6379> set myKey myValue
(error) MOVED 16281 192.168.0.14:6379
192.168.0.16:6379> get myKey
(error) MOVED 16281 192.168.0.14:6379
It neither writes nor reads. When I try to get «myKey» from 192.168.0.14:6379 it shows next:
127.0.0.1:6379> get myKey
(nil)
What is wrong with my requests? I am using redis server version 3.2.5
asked Oct 30, 2016 at 15:34
The node did redirect you.
As the documentation explains, the client is expected to connect to the specified node to retry the request. The server does not do this.
If you’re using redis-cli, then you must use the -c option if you want it to follow these redirects.
answered Oct 30, 2016 at 18:08
Michael HamptonMichael Hampton
240k42 gold badges488 silver badges954 bronze badges
For get commands you may want to run:
READONLY
first as one of the following might have happened:
- The client sent a command about hash slots never served by the
master of this replica.- The cluster was reconfigured (for example resharded) and the replica
is no longer able to serve commands for a given hash slot.
answered Aug 22, 2022 at 8:26
I have a Redis cluster with the following nodes:
192.168.0.14:6379 master (slots from 0 to 16383)
192.168.0.15:6379 slave (slots from 0 to 16383)
192.168.0.16:6379 master (without slots)
Documentation says that any node can redirect queries to the properly node. But I can not redirect requests from 192.168.0.16:6379 master node. Here is what I tried:
192.168.0.16:6379> set myKey myValue
(error) MOVED 16281 192.168.0.14:6379
192.168.0.16:6379> get myKey
(error) MOVED 16281 192.168.0.14:6379
It neither writes nor reads. When I try to get «myKey» from 192.168.0.14:6379 it shows next:
127.0.0.1:6379> get myKey
(nil)
What is wrong with my requests? I am using redis server version 3.2.5
asked Oct 30, 2016 at 15:34
The node did redirect you.
As the documentation explains, the client is expected to connect to the specified node to retry the request. The server does not do this.
If you’re using redis-cli, then you must use the -c option if you want it to follow these redirects.
answered Oct 30, 2016 at 18:08
Michael HamptonMichael Hampton
240k42 gold badges488 silver badges954 bronze badges
For get commands you may want to run:
READONLY
first as one of the following might have happened:
- The client sent a command about hash slots never served by the
master of this replica.- The cluster was reconfigured (for example resharded) and the replica
is no longer able to serve commands for a given hash slot.
answered Aug 22, 2022 at 8:26
Introduction
In this article I will try to explain a weird error that I had to deal with, working with Redis.
The common message of the error is «(error) MOVED 12933 127.0.0.1:30003». Now let’s
see when this could happened.
Requirements
In order to follow me you maybe will need to have Redis, I will also assume that you are
using some UNIX like distro, but you could find out the equivalents command on Windows by yourself.
You are a big boy. In total we only need:
- Redis
- OS: Ubuntu, Debian, Centos, etc… you got the idea.
Basic setup
Downloading and compiling Redis
Downloading
The current stable version of Redis is 6.2.6, you could download it
through this link or making use of curl, like this:
curl -sO https://download.redis.io/releases/redis-6.2.6.tar.gz
Enter fullscreen mode
Exit fullscreen mode
Extracting folder
tar -xf redis-6.2.6.tar.gz
Enter fullscreen mode
Exit fullscreen mode
Now you should have a folder called redis-6.2.6, let’s position inside of it with cd command:
cd redis-6.2.6
Enter fullscreen mode
Exit fullscreen mode
Compiling
Now we are good to go.
make
Enter fullscreen mode
Exit fullscreen mode
In case you want to run the tests inside the redis code, you could run make test. There are other parameters that you can pass in the
build, that could be interesting to trying out, but not now.
Description
In case you are in hurry, let me just summarize it to you. You will find this error when you try to use a redis client on a redis cluster,
without specifying on this redis client that you are actually connecting to a redis cluster and not a normal redis node. Of course, if you just
read this sentence could be the case that it makes no sense to you, right? Let’s go deeper then.
Reproducing the error
Let’s try to reproduce this error without any particular library in any language first, just making use of redis-cli.
Setup
Let’s run a Redis cluster locally, it will be easy. If you already compiled the source code of redis in the previous setup, you will
notice that there’s a folder called utils. Inside this folder there’s another one called create-cluster, so I’m going to make use
of the script inside this folder to create a cluster, is just the easiest way.
In order to run this scrip you need to be position in the same folder as the script, so let’s go into there:
cd utils/create-cluster/
Enter fullscreen mode
Exit fullscreen mode
Run the script:
./create-cluster start
./create-cluster create
Enter fullscreen mode
Exit fullscreen mode
Yes, like that. Wait what? Is already created? Yep, is code written in C so… A little confusing what they mean by start and create, usually the order
is first create and then start, but naming is hard.
In the create command it will ask you Can I set the above configuration? (type ‘yes’ to accept), so type yes, you are following a
tutorial that’s the point.
Now we have our cluster locally running.
How to stop and clean this?
./create-cluster stop
./create-cluster clean
Enter fullscreen mode
Exit fullscreen mode
Connecting
Let’s connect to the cluster with redis-cli.
In the previous step you must notice a line like this one in the logs printed on the ./create-cluster create command:
>>> Performing Cluster Check (using node 127.0.0.1:30001)
In my case the port that I will be trying to connect is 30001, but in your case could be any other.
./src/redis-cli -c -p 30001
Enter fullscreen mode
Exit fullscreen mode
VERY IMPORTANT HERE
The -c option is for
-c Enable cluster mode (follow -ASK and -MOVED re-direction).
So right now we are connecting using the cluster mode, so we won’t have any problem, the problem will come later
if we try to make operation with a connection that doesn’t have this Cluster mode enabled. I’ll comment more on that later.
Make a PING command just to check if everything looks fine,
127.0.0.1:30001> PING
Enter fullscreen mode
Exit fullscreen mode
You should get PONG as an answer.
Reproducing error
Now let’s back to business ), I will set several pairs and later I will try to fetch them
127.0.0.1:30001> SET name Lola
-> Redirected to slot [5798] located at 127.0.0.1:30002
OK
127.0.0.1:30002> SET name1 Lola
-> Redirected to slot [12933] located at 127.0.0.1:30003
OK
127.0.0.1:30003> SET name2 Manolo
-> Redirected to slot [742] located at 127.0.0.1:30001
OK
127.0.0.1:30001> SET name3 Juan
OK
127.0.0.1:30001> SET name4 Juan
-> Redirected to slot [8736] located at 127.0.0.1:30002
OK
127.0.0.1:30002
Enter fullscreen mode
Exit fullscreen mode
Take a look at these logs, yes I’m connected to port 30001 but my pairs, not always were set at that node. In my case
the value for key name1, on command SET name1 Lola was located in a slot in node 30003. I will explain more in advance, for now let’s just
reproduce the error.
Connecting without cluster mode enabled
Let’s try to connect to one of this node without enabling cluster mode, so open another terminal and run a this command:
./src/redis-cli -p 30001
Enter fullscreen mode
Exit fullscreen mode
IMPORTANT AGAIN
Here the difference is that the option -c was not supplied.
Let’s make PING, can we? Yes, we can!
127.0.0.1:30001> PING
PONG
Enter fullscreen mode
Exit fullscreen mode
THE ERROR
Now comes the cool surprise, at the moment you must be thinking like,
«Well I just made PING without problem, so I’m sure that I could retrieve those that I already pushed, right?»
Let’s try to retrieve them with GET command,
127.0.0.1:30001> GET name1
Enter fullscreen mode
Exit fullscreen mode
ERROR
127.0.0.1:30001> GET name1
(error) MOVED 12933 127.0.0.1:30003
127.0.0.1:30001>
Enter fullscreen mode
Exit fullscreen mode
Enjoy debugging this on your application, is not fun at all really. You start thinking, like, why? I ran the magical command called PING and
everything is fine.
Just to clarify, this is NOT an error of the server, this is YOUR FAULT, for setting up bad your redis client.
Rule of thumb
In general if you are using a redis cluster in your server, you should enabled the cluster mode on your client. There’s a lot of alternatives
for this, depending on the Programming Language that you are using. Here is a list from the redis website:
- redis-rb-cluster is a Ruby implementation written by me (@antirez) as a reference for other languages. It is a simple wrapper around the original redis-rb, implementing the minimal semantics to talk with the cluster efficiently.
- redis-py-cluster A port of redis-rb-cluster to Python. Supports majority of redis-py functionality. Is in active development.
- The popular Predis has support for Redis Cluster, the support was recently updated and is in active development.
- The most used Java client, Jedis recently added support for Redis Cluster, see the Jedis Cluster section in the project README.
- StackExchange.Redis offers support for C# (and should work fine with most .NET languages; VB, F#, etc)
- thunk-redis offers support for Node.js and io.js, it is a thunk/promise-based redis client with pipelining and cluster.
- redis-go-cluster is an implementation of Redis Cluster for the Go language using the Redigo library client as the base client. Implements MGET/MSET via result aggregation.
- ioredis is a popular Node.js client, providing a robust support for Redis Cluster.
- The redis-cli utility implements basic cluster support when started with the -c switch.
Related to Golang, the library go-redis, have also support for this.
Bibligraphy
- Redis cluster tutorial
- Redis cluster specification
- Cluster Nodes
Until next error guys ).
I try to execute a hmset command on AWS Redis Cluster, and I’m getting the following «moved» error. Not sure what is going on.
MOVED 7652 10.0.4.210:6379
from rediscluster import StrictRedisCluster
startup_nodes = [{"host": self.host, "port": self.port}]
client = StrictRedisCluster(startup_nodes=startup_nodes,
decode_responses=True,
skip_full_coverage_check=True)
client.hmset('my_key', {'abc':'123'})
asked Jan 12, 2018 at 19:04
user1187968user1187968
6,75015 gold badges75 silver badges144 bronze badges
2
As your data is sharded and distributed into different nodes in the cluster, you should use -c option to be able to connect to redis in cluster mode.
In your question, it is not known what type of client library you using, however the same concept, you need to use a library that supports cluster mode. Here is a list of client packages in nodejs
If you’re trying to get data it will redirect you as a client to the correct shard/partition that holds the requested data.
if you have redis-cli, you can try this:
redis-cli -c -h {REDIS_HOST_OR_PORT} -p 6379
if you have docker installed, you can connect to the cluster using the following:
docker run -ti --rm redis redis-cli -c -h {REDIS_HOST_OR_IP} -p 6379
answered Oct 26, 2018 at 1:35
Muhammad SolimanMuhammad Soliman
20.6k5 gold badges107 silver badges73 bronze badges
1
The «MOVED» error happens when you connect to one node in a redis cluster with standalone mode, and data you query is on other nodes in the cluster.
I don’t know how your StrictRedisCluster implenmented, but something is definitively wrong in this client.
answered Jan 15, 2018 at 7:21
MobilityMobility
3,05716 silver badges31 bronze badges
For get commands you may want to run:
READONLY
first as one of the following might have happened:
- The client sent a command about hash slots never served by the
master of this replica.- The cluster was reconfigured (for example resharded) and the replica
is no longer able to serve commands for a given hash slot.
answered Aug 22, 2022 at 8:25
NaeNae
13.4k5 gold badges54 silver badges78 bronze badges
I’m using ElastiCache for Redis. Why are my Redis client read requests always read from or redirected to the primary node of a shard?
Last updated: 2021-03-23
I’m using Amazon ElastiCache for Redis. Why are my Redis client read requests always read from or redirected to the primary node of a shard?
Resolution
Any node in a Redis cluster can receive queries from Redis clients. When a client sends a read/write query to a replica node, the node analyzes the request to confirm whether it is a single key or multi-key operation that belongs to the same hash slot of the shard. The default behavior of replica nodes in cluster-mode enabled clusters is to redirect all client read/write requests to an authoritative primary node of the shard that belongs to the key’s hash slot. The replica node serves the read request only if that shard belongs to the hash slot and a readonly command is initiated by the client. This means that the replica node processes the request only if readonly is issued by the client before the request. Otherwise, the request is redirected to the primary node of the shard that the hash slot belongs to.
Example
1. Log in to your cluster to set a key.
172.31.21.72:6379> set key8 "This is testing for readonly"
-> Redirected to slot [13004] located at 172.31.21.72:6379
OK
172.31.21.72:6379>2. Connect to a replica node.
In the following example, the readonly command isn’t sent, and the request is redirected to a primary node.
172.31.30.175:6379> info replication
# Replication
role:slave
master_host:172.31.21.72
master_port:6379
master_link_status:up
172.31.30.175:637> CLUSTER KEYSLOT key8
(integer) 13004
172.31.30.175:637> get key8
(error) MOVED 13004 172.31.21.72:6379
172.31.30.175:637> get key8
-> Redirected to slot [13004] located at 172.31.21.72:6379
"This is testing for readonly"
172.31.21.72:6379>Note: The MOVED error shown in the preceding example occurs when the Redis cluster client isn’t cluster aware and can’t handle redirection requests to the primary node. For more information about the MOVED error, refer to Redis cluster specification — Redirection and resharding on the Redis.io website.
In the following example, the readonly command is sent first, so the replica node processes the request instead of redirecting it to a primary node.
172.31.30.175:6379> readonly
OK
172.31.30.175:6379> get key8
"This is testing for readonly"
172.31.30.175:6379>The readonly command needs to be issued when the client connects to a node for the first time. The command is active only until the client reads keys from the same node. If the client connects to another replica node in the same or different shard, then you might need to issue a new readonly command.
Did this article help?
Do you need billing or technial support?
AWS support for Internet Explorer ends on 07/31/2022. Supported browsers are Chrome, Firefox, Edge, and Safari.
Learn more »
Хотелось бы немного пересказать Redis Cluster tutorial. Но перед этим дам определения некоторым терминам, дабы читающий не путался и знал о чем в точности идет речь.
- Масштабирование — абстрактное определение, увеличение числа функциональных блоков, выполняющих схожую функцию.
- Кластеризация — способ масштабирования за счет распределения нагрузки по многим серверам.
- Репликация — создание полной копии базы данных, с синхронизацией.
- Master — главный сервер, на который осуществляется запись.
- Slave — копия, в которую синхронизируются данные.
- Multi-master репликация — репликация, при которой существует несколько master серверов, синхронизирующихся друг с другом.
- Шардинг, сегментация, или партицирование — логическое разбиение данных так, чтобы их можно было разнести, например разбиение по хеш-функции.
- Вертикальный шардинг — разбиение по различным таблицам в рамках одного сервера.
- Горизонтальный шардинг — разбиение по различным таблицам различных серверов.
Основные цели
Как понятно из предисловия, масштабирование является основной из функций кластера. Помимо этого кластер может гарантировать некоторую степень отказоустойчивости. В частности:
- Если некоторые узлы не работают, кластер перераспределяет с них нагрузку на другие узлы.
- Если не работают ключевые узлы, то весь кластер заканчивает работу.
Основные порты
Кластер используется два TCP-соединения.
- Клиентский порт — как правило 6379. Как видно из названия, используется клиентами.
- Порт кластерной шины — клиентский порт + 10000, например 16379. Этот порт используется для работы кластера: обнаружение ошибок, обновление конфигурации, авторизации и прочего.
Сегментация
Кластер не использует консистентное хеширование, вместо этого используется так называемые хэш-слоты (анг. hash-slot). Весь кластер имеет 16384 слотов, для вычисления хэш-слота для ключа используется формула crc16(key) % 16384. Каждый узел Redis отвечает за конкретное подмножество хэш-слотов, например:
- Узел A седержит хеш-слоты от 0 до 5500.
- Узел B седержит хеш-слоты от 5501 до 11000.
- Узел C седержит хеш-слоты от 11001 до 16383.
Это позволяет легко добавлять и удалять узлы кластера. Если мы добавляем узел D, то можно просто переместить некоторые хеш-лоты других узлов. Если же удаляем A, то нам необходимо постепенно переместить все хэш-слоты узла А на другие, а когда хэш-слотов не останется, то просто удалить узел из кластера. Всё это выполняется постепенно командами, нам не нужно приостанавливать выполнение операций, не нужно пересчитывать процентное соотношение хеш-слотов к количеству узлов, никаких прочих остановок системы.
Возникает вопрос — Redis имеет сложные структуры данных с составными ключами, ведь хэш-функция посчитает для них разные значения? Имеется и ответ:
- Составные ключи одной команды, одной транзакции или одного скрипта Lua, гарантировано попадут в один хэш-слот.
- Пользователь может принудительно сделать составные ключи частью одного хэш слота с помощью концепта хэш-тегов.
Если в кратце, то хэш-теги говорят Redis что именно хешировать, цель хэширования задается в фигурных скобках. Так, хэши этих ключей будут равны — foo.{key}.bar и baz.{key}.biz.
Репликация
Каждый хэш-слот имеет от 1 (master) до N (N-1 slave) реплик. Таким образом, если выйдет из строя некоторый слот, то кластер назначит его slave master-ом.
Гарантия целостности
Может возникнуть ситуация:
- Клиент пишет в узел B.
- B отвечает ОК.
- B пытается записать в slave B1, B2, B3.
Как можно заметить, B не ждет репликации данных, а сразу отвечает клиенту ОК. При этом, если запись может не попасть в B1, а возможность стать мастером у B1 остается. Разумеется, в этом случае B1 будет иметь не все данные.
Redis Cluster пользоволяет использовать команду WAIT <numbers of replicas> <timeout>.
Также может возникнуть ситуация, когда A, C, A1, B1, C1 перестают видеть B, а клиент всё еще продолжает записывать туда данные. Если этот сбой будет очень короткий, то ничего страшного не случится, но если B не будет доступен продолжительное время, то мастером станет B1. Это время устанавливается в параметрах и называется таймаутом узла (анг. node timeout). В частности, это время также дается для записи клиенту, если клиент не укладывается в данное время, то узел больше не принимает записи. Также, если мастер не будет видеть это время другие узлы, то он самостоятельно перестанет работать.
Конфигурация
Конфигурация Redis Cluster задается в файле redis.conf.
- cluster-enabled <yes/no> — флаг включение Redis Cluster.
- cluster-config-file — файл, в который будет писаться системная информация: другие узлы, их состояние, глобальные переменные и прочее.
- cluster-node-timeout — максимальное время, которое master-узел может быть недоступен, по истечению этого времени он помечается как нерабочий и slaves начинают его аварийное переключение.
- cluster-slave-validity-factor — это число умноженное на таймаут узла — максимальное время, через которое slave начнет аварийное переключение.
- cluster-migration-barrier — минимальное количество slaves master-а.
- cluster-require-full-coverage <yes/no> — параметр, который говорит, нужно ли продолжать работоспособность всего кластера, если хотя бы часть хэш-слотов не покрыта.
Создание и использование Redis Cluster
Настройка
Чтобы создать кластер, во-первых необходимо запустить несколько узлов в режиме cluster mode. Минимальная конфигурация для этого:
port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
Redis Cluster требует как минимум три узла, поэтому чтобы создать тестовый кластер, например, с тремя master и тремя slave узлами следует выполнить действия:
- Создаем директории
mkdir cluster-test cd cluster-test mkdir 7000 7001 7002 7003 7004 7005 - В каждой директории создаем файл redis.conf, заменяем значение port на число из имени директории.
- Запускаем узлы, например
redis-server 7002/redis.conf. Мы увидим что-то типа34821:M 01 Apr 11:39:06.018 * No cluster configuration found, I'm 5d68f16ba5a6125f1e55017c4966b78d56817e0d. В данном случае 5d68f16ba5a6125f1e55017c4966b78d56817e0d — это уникальный идентификатор Node ID, он никогда не меняется, может поменяться IP-адрес, порт, но не он. - Устанавливаем утилиту redis-trib, с помощью которой можно развернуть кластер.
git clone https://github.com/antirez/redis gem install redis - Запускаем
./redis/src/redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005, где опция--replicasговорит, сколько slave будет у каждого мастера. Когда команда попросит создать конфигурацию, то соглашаемся. По окончанию увидим вывод[OK] All 16384 slots covered..
В директории исходного кода по пути ./utils/ можно найти больше утилит.
Некоторые полезные команды
redis-cli -p 7000 cluster nodes — посмотреть список узлов.
redis-cli -p 7002 debug segfault — вызвать segfault на одном из узлов.
redis-cli -p 7003 cluster failover — переключает slave на мастер.
redis-cli -p 7000 cluster forget b47bebb03d1342d22818623ad109b084b599e308 — удалить неиспользуемый узел.
./redis-trib del-node 127.0.0.1:7000 <node-id> — удалить узел.
./redis-trib.rb add-node 127.0.0.1:7002 127.0.0.1:7004 — добавить узел 127.0.0.1:7002, если использовать опцию --slave, то добавиться как slave, --master-id ID как slave конкретного мастера.
Решардинг
Под решардингом понимается перемещение хэш-слотов между узлами — вызываем ./redis-trib.rb reshard 127.0.0.1:7000 и следуем инструкциям:
> ./redis-trib.rb reshard 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 95a95d655730734f6bae77633dfba5642f14b7e3 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: aa9dd8e76746863e232701c3342c67ef407d1956 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
M: b47bebb03d1342d22818623ad109b084b599e308 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
S: f639ce60360e0dad1b941c9efa5b317c57ed45f3 127.0.0.1:7005
slots: (0 slots) slave
replicates 95a95d655730734f6bae77633dfba5642f14b7e3
S: 7a44229d6806e9f0e4545d9419f2067f5a47f4cf 127.0.0.1:7003
slots: (0 slots) slave
replicates aa9dd8e76746863e232701c3342c67ef407d1956
S: 14ef302c003f0e688dd20cd78677e644d3f8090b 127.0.0.1:7004
slots: (0 slots) slave
replicates b47bebb03d1342d22818623ad109b084b599e308
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 50
What is the receiving node ID? b47bebb03d1342d22818623ad109b084b599e308
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1:all
Ready to move 50 slots.
Source nodes:
M: 95a95d655730734f6bae77633dfba5642f14b7e3 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: aa9dd8e76746863e232701c3342c67ef407d1956 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
Destination node:
M: b47bebb03d1342d22818623ad109b084b599e308 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
Resharding plan:
Moving slot 5461 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5462 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5463 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5464 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5465 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5466 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5467 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5468 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5469 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5470 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5471 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5472 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5473 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5474 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5475 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5476 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5477 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5478 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5479 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5480 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5481 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5482 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5483 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5484 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5485 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 5486 from aa9dd8e76746863e232701c3342c67ef407d1956
Moving slot 0 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 1 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 2 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 3 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 4 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 5 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 6 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 7 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 8 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 9 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 10 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 11 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 12 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 13 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 14 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 15 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 16 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 17 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 18 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 19 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 20 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 21 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 22 from 95a95d655730734f6bae77633dfba5642f14b7e3
Moving slot 23 from 95a95d655730734f6bae77633dfba5642f14b7e3
Do you want to proceed with the proposed reshard plan (yes/no)? yes
Moving slot 5461 from 127.0.0.1:7001 to 127.0.0.1:7002:
39288:M 01 Apr 12:13:42.048 # New configEpoch set to 7
39288:M 01 Apr 12:13:42.048 # configEpoch updated after importing slot 5461
Moving slot 5462 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5463 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5464 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5465 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5466 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5467 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5468 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5469 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5470 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5471 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5472 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5473 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5474 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5475 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5476 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5477 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5478 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5479 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5480 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5481 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5482 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5483 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5484 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5485 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 5486 from 127.0.0.1:7001 to 127.0.0.1:7002:
Moving slot 0 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 1 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 2 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 3 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 4 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 5 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 6 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 7 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 8 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 9 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 10 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 11 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 12 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 13 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 14 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 15 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 16 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 17 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 18 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 19 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 20 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 21 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 22 from 127.0.0.1:7000 to 127.0.0.1:7002:
Moving slot 23 from 127.0.0.1:7000 to 127.0.0.1:7002:
Коротко о репликации
При создании кластера мы указываем количество master-узлов, а также мультипликатор количества slave для каждого мастера. При этом мы можем вручную добавить slave — CLUSTER REPLICATE <master-node-id>. Это может быть полезно, рассмотрим пример. Есть три master и три slave. В 4:00 падает один из slave, а в 4:30 падает его master, таким образом мы теряем хэш-слоты и кластер становится неработоспособен. Теперь представим туже схему, но один из master имеет два slave, тогда в 4:00 один из slave отличного от данного master, и весь кластер начинает миграцию «лишнего» slave в slave другого master, в 4:30 падает master, его slave начинает аварийное переключение, кластер продолжает работоспособность. Параметр, который отвечает за минимальное количество slave называется cluster-migration-barrier.
Redis Cluster спецификация
Основные свойства и дизайн кластера
Основные цели Redis Cluster в порядке их значимости в дизайне:
- Высокая производительности и масштабируемость до 1000 узлов.
- Безопасная запись.
- Доступность, о которой говорилось ранее.
Redis Cluster не поддерживает базы и команду SELECT.
Redis Cluster Bus
Узлы кластера общаются между собой с помощью TCP по бинарному протоколу, который называется шиной кластера. По протоколу отправляются информация об узлах, сообщения очередей, пинги, а также пользовательские аварийные переключения. Так как Redis Cluster не может быть использован как прокси, то при редиректе на другие узлы в ответе будут сообщения типа MOVED, -ASK.
(error) MOVED 15891 127.0.0.1:7004