Redis cluster live reshard отказ

Я столкнулся с этой проблемой при работе с поддержкой Redis-кластеризации для нашего собственного проекта. Я обнаружил проблему с командой redis-trib reshard. Он отлично работает, если в слотах, которые переносятся с одного мастера на другой, не хранится ключ.

Но redis-5 (все еще разрабатывается, но еще не стабилен) имеет собственный `redis-cli ', который, как мне кажется, не имеет проблем с командой resharding. Только у младших версий 5 такое бывает.

Если вы посмотрите официальную документацию по redis, скажите перенастройка redis и redis cluster resharding, вы узнаете, что они делают внутри решард.

Итак, я решил проблему, выполнив эти задачи, запустив сценарий bash вместо команды redis-trib reshard.

Предположим, вы хотите перенастроить некоторые слоты с главного узла на другой главный узел. Мы назовем узел, который в настоящее время владеет хэш-слотом, исходным узлом, а узел, на который мы хотим перенести целевой узел.

Для каждого слота проделайте следующие шаги:

Помните, что в соответствии с официальными документами Redis здесь важен порядок этих шагов.

1. Отправьте CLUSTER SETSLOT <slot> IMPORTING <source-node-id> на целевой узел, чтобы установить слот в состояние импорт.
2. Отправьте CLUSTER SETSLOT <slot> MIGRATING <destination-node-id> на исходный узел, чтобы установить слот в состояние перенос.

3. Получите ключи от исходного узла с помощью команды CLUSTER GETKEYSINSLOT и переместите их в целевой узел, используя следующую команду MIGRATE.

   MIGRATE target_host target_port key target_database_id timeout

   В Redis Cluster нет необходимости указывать базу данных, отличную от 0, но MIGRATE - это общая команда, которая может использоваться для других задач, не связанных с Redis Cluster.

4. Когда процесс миграции будет окончательно завершен, используйте CLUSTER SETSLOT <slot> NODE <destination-node-id> как в исходном узле, так и в целевом узле, чтобы снова установить слот в их нормальное состояние. Эта же команда обычно отправляется всем остальным узлам, чтобы не ждать естественного распространения новой конфигурации по кластеру.

Здесь также приведен простой пример сценария bash для этого:

исходный IP: 172.17.0.5. идентификатор источника: 1f70a5107e0042a7d33a9efaf88dbdfecd78076a

IP-адрес назначения: 172.17.0.4. идентификатор-назначения: 7e428bae84697a3882ecad19bd0d13ac7ee97d02

другой главный IP: 172.17.0.7

for i in `seq 0 5460`; do
    redis-cli -c -h 172.17.0.4 cluster setslot ${i} importing 1f70a5107e0042a7d33a9efaf88dbdfecd78076a
    redis-cli -c -h 172.17.0.5 cluster setslot ${i} migrating 7e428bae84697a3882ecad19bd0d13ac7ee97d02
    while true; do
        key=`redis-cli -c -h 172.17.0.5 cluster getkeysinslot ${i} 1`
        if [ "" = "$key" ]; then
            echo "there are no key in this slot ${i}"
            break
        fi
        redis-cli -h 172.17.0.5 migrate 172.17.0.4 6379 ${key} 0 5000
    done
    redis-cli -c -h 172.17.0.5 cluster setslot ${i} node 7e428bae84697a3882ecad19bd0d13ac7ee97d02
    redis-cli -c -h 172.17.0.4 cluster setslot ${i} node 7e428bae84697a3882ecad19bd0d13ac7ee97d02
    redis-cli -c -h 172.17.0.7 cluster setslot ${i} node 7e428bae84697a3882ecad19bd0d13ac7ee97d02
done