이것은 사용자가 2025-1-9 16:10에 https://blog.mygraphql.com/zh/notes/redis/redis-cluster/redis-cluster-design/을(를) 위해 저장한 이중 언어 스냅샷 페이지로, 몰입형 번역에 의해 제공된 이중 언어 지원이 있습니다. 저장하는 방법을 알아보세요?
Please enable Javascript to view the contents

 ·  ☕ 23 分钟   ☕ 23 분

https://redis.io/topics/cluster-spec

Implemented subset  구현된 하위 집합

Redis Cluster implements a concept called hash tags that can be used in order to force certain keys to be stored in the same hash slot. However during manual resharding, multi-key operations may become unavailable for some time while single key operations are always available.
Redis Cluster는 특정 키를 동일한 해시 슬롯에 저장하도록 강제할 수 있는 hash tags 라는 개념을 구현합니다. 그러나 수동 리샤딩 중에는 멀티 키 작업이 일정 시간 동안 사용할 수 없게 될 수 있으며, 단일 키 작업은 항상 사용할 수 있습니다.

Clients and Servers roles in the Redis Cluster protocol
Redis Cluster 프로토콜에서 클라이언트와 서버의 역할

In Redis Cluster nodes are responsible for holding the data, and taking the state of the cluster, including mapping keys to the right nodes. Cluster nodes are also able to auto-discover other nodes, detect non-working nodes, and promote replica nodes to master when needed in order to continue to operate when a failure occurs.
Redis Cluster에서 노드는 데이터를 보유하고 클러스터의 상태를 유지하는 책임이 있으며, 키를 올바른 노드에 매핑하는 작업을 포함합니다. 클러스터 노드는 다른 노드를 자동으로 발견하고, 작동하지 않는 노드를 감지하며, 필요할 때 복제 노드를 마스터로 승격시켜 장애가 발생할 때 계속 운영할 수 있습니다.

To perform their tasks all the cluster nodes are connected using a TCP bus and a binary protocol, called the Redis Cluster Bus. Every node is connected to every other node in the cluster using the cluster bus. Nodes use a gossip protocol to propagate information about the cluster in order to discover new nodes, to send ping packets to make sure all the other nodes are working properly, and to send cluster messages needed to signal specific conditions. The cluster bus is also used in order to propagate Pub/Sub messages across the cluster and to orchestrate manual failovers when requested by users (manual failovers are failovers which are not initiated by the Redis Cluster failure detector, but by the system administrator directly).
모든 클러스터 노드는 Redis Cluster Bus라고 불리는 TCP 버스와 이진 프로토콜을 사용하여 연결되어 작업을 수행합니다. 모든 노드는 클러스터 버스를 사용하여 클러스터 내의 다른 모든 노드에 연결됩니다. 노드는 정보 전파를 위해 가십 프로토콜을 사용하여 새로운 노드를 발견하고, 모든 다른 노드가 제대로 작동하는지 확인하기 위해 핑 패킷을 전송하며, 특정 조건을 신호하기 위해 필요한 클러스터 메시지를 전송합니다. 클러스터 버스는 또한 클러스터 전반에 걸쳐 Pub/Sub 메시지를 전파하고 사용자가 요청할 때 수동 장애 조치를 조정하는 데 사용됩니다(수동 장애 조치는 Redis Cluster 장애 감지기가 시작하지 않고 시스템 관리자가 직접 시작하는 장애 조치입니다).

Since cluster nodes are not able to proxy requests, clients may be redirected to other nodes using redirection errors -MOVED and -ASK. The client is in theory free to send requests to all the nodes in the cluster, getting redirected if needed, so the client is not required to hold the state of the cluster. However clients that are able to cache the map between keys and nodes can improve the performance in a sensible way.
클러스터 노드가 요청을 프록시할 수 없기 때문에 클라이언트는 리디렉션 오류 -MOVED 및 -ASK 를 사용하여 다른 노드로 리디렉션될 수 있습니다. 이론적으로 클라이언트는 클러스터의 모든 노드에 요청을 보낼 수 있으며, 필요할 경우 리디렉션됩니다. 따라서 클라이언트는 클러스터의 상태를 유지할 필요가 없습니다. 그러나 키와 노드 간의 맵을 캐시할 수 있는 클라이언트는 성능을 합리적인 방식으로 향상시킬 수 있습니다.

Write safety  안전하게 작성하세요

Redis Cluster uses asynchronous replication between nodes, and last failover wins implicit merge function. This means that the last elected master dataset eventually replaces all the other replicas. There is always a window of time when it is possible to lose writes during partitions. However these windows are very different in the case of a client that is connected to the majority of masters, and a client that is connected to the minority of masters.
Redis Cluster는 노드 간 비동기 복제를 사용하며, 마지막 장애 조치 승자가 암묵적 병합 기능을 갖습니다. 이는 마지막으로 선출된 마스터 데이터 세트가 결국 다른 모든 복제본을 대체함을 의미합니다. 파티션 중에 쓰기를 잃을 수 있는 시간 창이 항상 존재합니다. 그러나 이러한 시간 창은 대다수의 마스터에 연결된 클라이언트와 소수의 마스터에 연결된 클라이언트의 경우 매우 다릅니다.

脑裂问题：  뇌裂 문제:

Redis Cluster tries harder to retain writes that are performed by clients connected to the majority of masters, compared to writes performed in the minority side. The following are examples of scenarios that lead to loss of acknowledged writes received in the majority partitions during failures:
Redis Cluster는 소수의 마스터에 연결된 클라이언트가 수행한 쓰기 작업에 비해 대다수의 마스터에 연결된 클라이언트가 수행한 쓰기 작업을 더 잘 유지하려고 합니다. 다음은 장애 발생 시 대다수 파티션에서 수신된 승인된 쓰기가 손실되는 시나리오의 예입니다:

  1. A write may reach a master, but while the master may be able to reply to the client, the write may not be propagated to replicas via the asynchronous replication used between master and replica nodes. If the master dies without the write reaching the replicas, the write is lost forever if the master is unreachable for a long enough period that one of its replicas is promoted. This is usually hard to observe in the case of a total, sudden failure of a master node since masters try to reply to clients (with the acknowledge of the write) and replicas (propagating the write) at about the same time. However it is a real world failure mode.
    쓰기 작업이 마스터에 도달할 수 있지만, 마스터가 클라이언트에 응답할 수 있는 경우에도 쓰기가 마스터와 복제 노드 간에 사용되는 비동기 복제를 통해 복제본으로 전파되지 않을 수 있습니다. 만약 마스터가 복제본에 쓰기가 도달하기 전에 사망하면, 마스터가 충분히 오랜 시간 동안 도달할 수 없는 경우 복제본 중 하나가 승격되면 쓰기는 영원히 잃게 됩니다. 이는 마스터 노드의 총체적이고 갑작스러운 실패의 경우 관찰하기 어려운 경우가 많습니다. 마스터는 클라이언트(쓰기의 확인)와 복제본(쓰기를 전파)에게 거의 동시에 응답하려고 하기 때문입니다. 그러나 이는 실제 세계의 실패 모드입니다.

  2. Another theoretically possible failure mode where writes are lost is the following:

  • A master is unreachable because of a partition.
  • It gets failed over by one of its replicas.
  • After some time it may be reachable again.
  • A client with an out-of-date routing table may write to the old master before it is converted into a replica (of the new master) by the cluster.

Availability

Redis Cluster is not available in the minority side of the partition. In the majority side of the partition assuming that there are at least the majority of masters and a replica for every unreachable master, the cluster becomes available again after NODE_TIMEOUT time plus a few more seconds required for a replica to get elected and failover its master (failovers are usually executed in a matter of 1 or 2 seconds).

This means that Redis Cluster is designed to survive failures of a few nodes in the cluster, but it is not a suitable solution for applications that require availability in the event of large net splits.

Thanks to a Redis Cluster feature called replicas migration the Cluster availability is improved in many real world scenarios by the fact that replicas migrate to orphaned masters (masters no longer having replicas). So at every successful failure event, the cluster may reconfigure the replicas layout in order to better resist the next failure.
레디스 클러스터의 복제본 마이그레이션이라는 기능 덕분에 클러스터의 가용성이 많은 실제 시나리오에서 향상됩니다. 이는 복제본이 고아 마스터(더 이상 복제본이 없는 마스터)로 마이그레이션하기 때문입니다. 따라서 매번 성공적인 실패 이벤트가 발생할 때 클러스터는 다음 실패에 더 잘 저항할 수 있도록 복제본 레이아웃을 재구성할 수 있습니다.

Overview of Redis Cluster main components
Redis Cluster 주요 구성 요소 개요

Keys distribution model  키 분배 모델

The key space is split into 16384 slots, effectively setting an upper limit for the cluster size of 16384 master nodes (however the suggested max size of nodes is in the order of ~ 1000 nodes).
키 공간은 16384 슬롯으로 나뉘어져 있으며, 이는 클러스터 크기의 상한을 16384 마스터 노드로 설정합니다(그러나 권장 최대 노드 수는 약 1000 노드 정도입니다).

Each master node in a cluster handles a subset of the 16384 hash slots. The cluster is stable when there is no cluster reconfiguration in progress (i.e. where hash slots are being moved from one node to another). When the cluster is stable, a single hash slot will be served by a single node (however the serving node can have one or more replicas that will replace it in the case of net splits or failures, and that can be used in order to scale read operations where reading stale data is acceptable).
클러스터의 각 마스터 노드는 16384 해시 슬롯의 하위 집합을 처리합니다. 클러스터가 안정적일 때는 클러스터 재구성이 진행 중이지 않습니다(즉, 해시 슬롯이 한 노드에서 다른 노드로 이동되고 있는 경우). 클러스터가 안정적일 때, 단일 해시 슬롯은 단일 노드에 의해 제공됩니다(그러나 제공 노드는 네트워크 분할이나 실패의 경우 이를 대체할 수 있는 하나 이상의 복제본을 가질 수 있으며, 오래된 데이터를 읽는 것이 허용되는 경우 읽기 작업을 확장하는 데 사용할 수 있습니다).

The base algorithm used to map keys to hash slots is the following (read the next paragraph for the hash tag exception to this rule):
키를 해시 슬롯에 매핑하는 데 사용되는 기본 알고리즘은 다음과 같습니다(이 규칙에 대한 해시 태그 예외는 다음 단락을 읽으십시오):

HASH_SLOT = CRC16(key) mod 16384

Keys hash tags  키 해시 태그

There is an exception for the computation of the hash slot that is used in order to implement hash tags. Hash tags are a way to ensure that multiple keys are allocated in the same hash slot. This is used in order to implement multi-key operations in Redis Cluster.
해시 태그를 구현하기 위해 사용되는 해시 슬롯의 계산에는 예외가 있습니다. 해시 태그는 여러 키가 동일한 해시 슬롯에 할당되도록 보장하는 방법입니다. 이는 Redis Cluster에서 다중 키 작업을 구현하기 위해 사용됩니다.

In order to implement hash tags, the hash slot for a key is computed in a slightly different way in certain conditions. If the key contains a “{…}” pattern only the substring between { and } is hashed in order to obtain the hash slot.
해시 태그를 구현하기 위해 특정 조건에서 키의 해시 슬롯은 약간 다른 방식으로 계산됩니다. 키에 “{…}” 패턴이 포함되어 있으면 { 과 } 사이의 하위 문자열만 해시되어 해시 슬롯을 얻습니다.

Then instead of hashing the key, only what is between the first occurrence of { and the following first occurrence of } is hashed.
그럼 키를 해싱하는 대신, { 의 첫 번째 발생과 그 다음 } 의 첫 번째 발생 사이의 것만 해싱됩니다.

Examples:  예시:

  • The two keys {user1000}.following and {user1000}.followers will hash to the same hash slot since only the substring user1000 will be hashed in order to compute the hash slot.
    두 키 {user1000}.following 와 {user1000}.followers 은 해시 슬롯을 계산하기 위해 서브스트링 user1000 만 해시되므로 동일한 해시 슬롯으로 해시됩니다.
  • For the key foo{}{bar} the whole key will be hashed as usually since the first occurrence of { is followed by } on the right without characters in the middle.
    키 foo{}{bar} 의 경우, { 의 첫 번째 발생이 오른쪽에 } 가 있으며 중간에 문자가 없기 때문에 전체 키는 일반적으로 해시됩니다.
  • For the key foo{{bar}}zap the substring {bar will be hashed, because it is the substring between the first occurrence of { and the first occurrence of } on its right.
    키 foo{{bar}}zap 에 대해 부분 문자열 {bar 이 해시될 것입니다. 이는 { 의 첫 번째 발생과 오른쪽의 } 의 첫 번째 발생 사이에 있는 부분 문자열이기 때문입니다.
  • For the key foo{bar}{zap} the substring bar will be hashed, since the algorithm stops at the first valid or invalid (without bytes inside) match of { and }.
    키 foo{bar}{zap} 에 대해 부분 문자열 bar 이 해시될 것이며, 알고리즘은 { 와 } 의 첫 번째 유효하거나 무효(바이트가 없는) 일치에서 중지됩니다.
  • What follows from the algorithm is that if the key starts with {}, it is guaranteed to be hashed as a whole. This is useful when using binary data as key names.
    알고리즘에서 나오는 것은 키가 {} 로 시작하면 전체가 해시되는 것이 보장된다는 것입니다. 이는 이진 데이터를 키 이름으로 사용할 때 유용합니다.

Cluster nodes attributes  클러스터 노드 속성

Every node has a unique name in the cluster. The node name is the hex representation of a 160 bit random number, obtained the first time a node is started (usually using /dev/urandom). The node will save its ID in the node configuration file, and will use the same ID forever, or at least as long as the node configuration file is not deleted by the system administrator, or a hard reset is requested via the CLUSTER RESET command.
클러스터의 각 노드는 고유한 이름을 가지고 있습니다. 노드 이름은 160비트 랜덤 숫자의 16진수 표현으로, 노드가 처음 시작될 때 얻어집니다(보통 /dev/urandom을 사용하여). 노드는 노드 구성 파일에 자신의 ID를 저장하며, 시스템 관리자가 노드 구성 파일을 삭제하지 않거나 CLUSTER RESET 명령을 통해 하드 리셋이 요청되지 않는 한 동일한 ID를 영구적으로 사용합니다.

The node ID is used to identify every node across the whole cluster. It is possible for a given node to change its IP address without any need to also change the node ID. The cluster is also able to detect the change in IP/port and reconfigure using the gossip protocol running over the cluster bus.
노드 ID는 전체 클러스터에서 모든 노드를 식별하는 데 사용됩니다. 특정 노드가 노드 ID를 변경할 필요 없이 IP 주소를 변경하는 것이 가능합니다. 클러스터는 또한 IP/포트의 변경을 감지하고 클러스터 버스를 통해 실행되는 가십 프로토콜을 사용하여 재구성할 수 있습니다.

The node ID is not the only information associated with each node, but is the only one that is always globally consistent. Every node has also the following set of information associated. Some information is about the cluster configuration detail of this specific node, and is eventually consistent across the cluster. Some other information, like the last time a node was pinged, is instead local to each node.
노드 ID는 각 노드와 관련된 유일한 정보가 아니지만 항상 전 세계적으로 일관된 유일한 정보입니다. 모든 노드는 또한 다음과 같은 정보 세트를 가지고 있습니다. 일부 정보는 이 특정 노드의 클러스터 구성 세부 사항에 관한 것이며, 클러스터 전반에 걸쳐 결국 일관성을 유지합니다. 마지막으로 노드가 핑된 시간과 같은 다른 정보는 각 노드에만 국한됩니다.

Every node maintains the following information about other nodes that it is aware of in the cluster: The node ID, IP and port of the node, a set of flags, what is the master of the node if it is flagged as replica, last time the node was pinged and the last time the pong was received, the current configuration epoch of the node (explained later in this specification), the link state and finally the set of hash slots served.
각 노드는 클러스터 내에서 인식하고 있는 다른 노드에 대한 다음 정보를 유지합니다: 노드 ID, 노드의 IP 및 포트, 플래그 집합, 노드가 replica 으로 표시된 경우의 마스터, 노드가 마지막으로 핑을 받은 시간과 마지막으로 퐁을 받은 시간, 노드의 현재 구성 에포크(이 사양에서 나중에 설명됨), 링크 상태 및 마지막으로 제공되는 해시 슬롯 집합.

A detailed explanation of all the node fields is described in the CLUSTER NODES documentation.
CLUSTER NODES 문서에 모든 노드 필드에 대한 자세한 설명이 나와 있습니다.

The CLUSTER NODES command can be sent to any node in the cluster and provides the state of the cluster and the information for each node according to the local view the queried node has of the cluster.
CLUSTER NODES 명령은 클러스터의 모든 노드에 전송할 수 있으며, 클러스터의 상태와 쿼리된 노드가 클러스터에 대해 가진 로컬 뷰에 따라 각 노드에 대한 정보를 제공합니다.

The following is sample output of the CLUSTER NODES command sent to a master node in a small cluster of three nodes.
다음은 세 개의 노드로 구성된 작은 클러스터의 마스터 노드에 전송된 CLUSTER NODES 명령의 샘플 출력입니다.

$ redis-cli cluster nodes
d1861060fe6a534d42d8a19aeb36600e18785e04 127.0.0.1:6379 myself - 0 1318428930 1 connected 0-1364
3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1:6380 master - 1318428930 1318428931 2 connected 1365-2729
d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1:6381 master - 1318428931 1318428931 3 connected 2730-4095

In the above listing the different fields are in order: node id, address:port, flags, last ping sent, last pong received, configuration epoch, link state, slots. Details about the above fields will be covered as soon as we talk of specific parts of Redis Cluster.
위 목록에서 다양한 필드는 다음과 같은 순서로 나열됩니다: 노드 ID, 주소:포트, 플래그, 마지막으로 보낸 핑, 마지막으로 받은 퐁, 구성 에포크, 링크 상태, 슬롯. 위 필드에 대한 세부 사항은 Redis Cluster의 특정 부분에 대해 이야기할 때 다룰 것입니다.

The Cluster bus  클러스터 버스

Every Redis Cluster node has an additional TCP port for receiving incoming connections from other Redis Cluster nodes. This port will be derived by adding 10000 to the data port or it can be specified with the cluster-port config.
모든 Redis Cluster 노드는 다른 Redis Cluster 노드로부터 들어오는 연결을 수신하기 위한 추가 TCP 포트를 가지고 있습니다. 이 포트는 데이터 포트에 10000을 더하여 파생되거나 cluster-port 구성으로 지정할 수 있습니다.

Example 1:  예시 1:

If a Redis node is listening for client connections on port 6379, and you do not add cluster-port parameter in redis.conf, the Cluster bus port 16379 will be opened.
Redis 노드가 포트 6379에서 클라이언트 연결을 수신하고 있으며 redis.conf에 cluster-port 매개변수를 추가하지 않으면 클러스터 버스 포트 16379가 열립니다.

Cluster topology  클러스터 토폴로지

Redis Cluster is a full mesh where every node is connected with every other node using a TCP connection.
Redis Cluster는 모든 노드가 TCP 연결을 사용하여 서로 연결된 완전 메시입니다.

In a cluster of N nodes, every node has N-1 outgoing TCP connections, and N-1 incoming connections.
N개의 노드로 구성된 클러스터에서, 각 노드는 N-1개의 나가는 TCP 연결과 N-1개의 들어오는 연결을 가지고 있다.

These TCP connections are kept alive all the time and are not created on demand. When a node expects a pong reply in response to a ping in the cluster bus, before waiting long enough to mark the node as unreachable, it will try to refresh the connection with the node by reconnecting from scratch.
이 TCP 연결은 항상 유지되며 필요에 따라 생성되지 않습니다. 노드가 클러스터 버스에서 핑에 대한 퐁 응답을 기대할 때, 노드를 도달할 수 없는 것으로 표시하기 위해 충분히 오랫동안 기다리기 전에, 노드와의 연결을 새로 고치기 위해 처음부터 다시 연결을 시도합니다.

While Redis Cluster nodes form a full mesh, nodes use a gossip protocol and a configuration update mechanism in order to avoid exchanging too many messages between nodes during normal conditions, so the number of messages exchanged is not exponential.
Redis Cluster 노드가 완전 메쉬를 형성하는 동안, 노드는 정상적인 조건에서 노드 간에 너무 많은 메시지를 교환하지 않기 위해 가십 프로토콜과 구성 업데이트 메커니즘을 사용하므로 교환되는 메시지의 수는 기하급수적이지 않습니다.

Nodes handshake  노드 핸드셰이크

Nodes always accept connections on the cluster bus port, and even reply to pings when received, even if the pinging node is not trusted. However, all other packets will be discarded by the receiving node if the sending node is not considered part of the cluster.
노드는 항상 클러스터 버스 포트에서 연결을 수락하며, 핑을 받을 때 응답하기도 합니다. 핑을 보내는 노드가 신뢰되지 않더라도 마찬가지입니다. 그러나 다른 모든 패킷은 송신 노드가 클러스터의 일부로 간주되지 않으면 수신 노드에 의해 폐기됩니다.

A node will accept another node as part of the cluster only in two ways:
노드는 클러스터의 일부로 다른 노드를 수용하는 방법은 두 가지뿐입니다:

  • If a node presents itself with a MEET message. A meet message is exactly like a PING message, but forces the receiver to accept the node as part of the cluster. Nodes will send MEET messages to other nodes only if the system administrator requests this via the following command:
    노드가 MEET 메시지를 가지고 자신을 나타내면, 만남 메시지는 PING 메시지와 정확히 같지만 수신자가 노드를 클러스터의 일부로 수용하도록 강제합니다. 노드는 시스템 관리자가 다음 명령어를 통해 이를 요청할 경우에만 다른 노드에 MEET 메시지를 보냅니다:

    CLUSTER MEET ip port

  • A node will also register another node as part of the cluster if a node that is already trusted will gossip about this other node. So if A knows B, and B knows C, eventually B will send gossip messages to A about C. When this happens, A will register C as part of the network, and will try to connect with C.
    노드는 이미 신뢰받는 노드가 다른 노드에 대해 소문을 퍼뜨리면 클러스터의 일부로 다른 노드를 등록합니다. 따라서 A가 B를 알고, B가 C를 알면, 결국 B는 A에게 C에 대한 소문 메시지를 보낼 것입니다. 이 경우 A는 C를 네트워크의 일부로 등록하고 C와 연결하려고 시도할 것입니다.

This means that as long as we join nodes in any connected graph, they’ll eventually form a fully connected graph automatically. This means that the cluster is able to auto-discover other nodes, but only if there is a trusted relationship that was forced by the system administrator.
이는 우리가 연결된 그래프에 노드를 추가하는 한, 결국 자동으로 완전 연결 그래프를 형성한다는 것을 의미합니다. 이는 클러스터가 다른 노드를 자동으로 발견할 수 있지만, 시스템 관리자가 강제로 설정한 신뢰 관계가 있을 때만 가능하다는 것을 의미합니다.

This mechanism makes the cluster more robust but prevents different Redis clusters from accidentally mixing after change of IP addresses or other network related events.
이 메커니즘은 클러스터를 더 견고하게 만들지만 IP 주소 변경이나 기타 네트워크 관련 이벤트 후에 서로 다른 Redis 클러스터가 우연히 섞이는 것을 방지합니다.

Redirection and resharding
리디렉션 및 리샤딩

MOVED Redirection  MOVED 리디렉션

A Redis client is free to send queries to every node in the cluster, including replica nodes. The node will analyze the query, and if it is acceptable (that is, only a single key is mentioned in the query, or the multiple keys mentioned are all to the same hash slot) it will lookup what node is responsible for the hash slot where the key or keys belong.
Redis 클라이언트는 복제 노드를 포함하여 클러스터의 모든 노드에 쿼리를 자유롭게 보낼 수 있습니다. 노드는 쿼리를 분석하고, 쿼리가 허용 가능한 경우(즉, 쿼리에서 단일 키만 언급되거나 언급된 여러 키가 모두 동일한 해시 슬롯에 해당하는 경우) 해당 키 또는 키가 속한 해시 슬롯을 담당하는 노드를 조회합니다.

If the hash slot is served by the node, the query is simply processed, otherwise the node will check its internal hash slot to node map, and will reply to the client with a MOVED error, like in the following example:
해시 슬롯이 노드에 의해 제공되면 쿼리는 간단히 처리되고, 그렇지 않으면 노드는 내부 해시 슬롯에서 노드 맵을 확인하고 클라이언트에게 다음 예와 같이 MOVED 오류로 응답합니다:

GET x
-MOVED 3999 127.0.0.1:6381

The error includes the hash slot of the key (3999) and the ip:port of the instance that can serve the query. The client needs to reissue the query to the specified node’s IP address and port. Note that even if the client waits a long time before reissuing the query, and in the meantime the cluster configuration changed, the destination node will reply again with a MOVED error if the hash slot 3999 is now served by another node. The same happens if the contacted node had no updated information.
오류에는 키의 해시 슬롯(3999)과 쿼리를 처리할 수 있는 인스턴스의 ip:port가 포함됩니다. 클라이언트는 지정된 노드의 IP 주소와 포트로 쿼리를 다시 발행해야 합니다. 클라이언트가 쿼리를 다시 발행하기 전에 오랜 시간을 기다리더라도 그 사이에 클러스터 구성이 변경되었다면, 해시 슬롯 3999가 이제 다른 노드에 의해 제공되는 경우 대상 노드는 다시 MOVED 오류로 응답할 것입니다. 연락한 노드에 업데이트된 정보가 없었던 경우에도 동일한 일이 발생합니다.

So while from the point of view of the cluster nodes are identified by IDs we try to simplify our interface with the client just exposing a map between hash slots and Redis nodes identified by IP:port pairs.
그래서 클러스터의 관점에서 노드는 ID로 식별되지만, 우리는 클라이언트와의 인터페이스를 단순화하기 위해 해시 슬롯과 IP:포트 쌍으로 식별된 Redis 노드 간의 맵을 노출하려고 합니다.

The client is not required to, but should try to memorize that hash slot 3999 is served by 127.0.0.1:6381. This way once a new command needs to be issued it can compute the hash slot of the target key and have a greater chance of choosing the right node.
클라이언트는 필수는 아니지만, 해시 슬롯 3999가 127.0.0.1:6381에 의해 제공된다는 것을 기억하려고 노력해야 합니다. 이렇게 하면 새로운 명령을 발행해야 할 때 대상 키의 해시 슬롯을 계산하고 올바른 노드를 선택할 확률이 높아집니다.

An alternative is to just refresh the whole client-side cluster layout using the CLUSTER NODES or CLUSTER SLOTS commands when a MOVED redirection is received. When a redirection is encountered, it is likely multiple slots were reconfigured rather than just one, so updating the client configuration as soon as possible is often the best strategy.
대안은 MOVED 리디렉션을 받을 때 CLUSTER NODES 또는 CLUSTER SLOTS 명령을 사용하여 전체 클라이언트 측 클러스터 레이아웃을 새로 고치는 것입니다. 리디렉션이 발생하면 하나가 아닌 여러 슬롯이 재구성되었을 가능성이 높으므로 가능한 한 빨리 클라이언트 구성을 업데이트하는 것이 종종 최선의 전략입니다.

Note that when the Cluster is stable (no ongoing changes in the configuration), eventually all the clients will obtain a map of hash slots -> nodes, making the cluster efficient, with clients directly addressing the right nodes without redirections, proxies or other single point of failure entities.
클러스터가 안정적일 때(구성에 대한 변경이 진행 중이지 않을 때), 결국 모든 클라이언트는 해시 슬롯 -> 노드의 맵을 얻어 클러스터가 효율적으로 작동하게 되며, 클라이언트는 리디렉션, 프록시 또는 기타 단일 실패 지점 엔티티 없이 직접 올바른 노드에 접근하게 됩니다.

A client must be also able to handle -ASK redirections that are described later in this document, otherwise it is not a complete Redis Cluster client.
클라이언트는 이 문서에서 나중에 설명할 -ASK 리디렉션을 처리할 수 있어야 하며, 그렇지 않으면 완전한 Redis Cluster 클라이언트가 아닙니다.

Cluster live reconfiguration
클러스터 실시간 재구성

Redis Cluster supports the ability to add and remove nodes while the cluster is running. Adding or removing a node is abstracted into the same operation: moving a hash slot from one node to another. This means that the same basic mechanism can be used in order to rebalance the cluster, add or remove nodes, and so forth.
Redis Cluster는 클러스터가 실행 중일 때 노드를 추가하고 제거할 수 있는 기능을 지원합니다. 노드를 추가하거나 제거하는 것은 해시 슬롯을 한 노드에서 다른 노드로 이동하는 동일한 작업으로 추상화됩니다. 이는 클러스터의 균형을 재조정하고, 노드를 추가하거나 제거하는 데 동일한 기본 메커니즘을 사용할 수 있음을 의미합니다.

  • To add a new node to the cluster an empty node is added to the cluster and some set of hash slots are moved from existing nodes to the new node.
    클러스터에 새 노드를 추가하기 위해 빈 노드가 클러스터에 추가되고 기존 노드에서 새 노드로 일부 해시 슬롯 세트가 이동됩니다.
  • To remove a node from the cluster the hash slots assigned to that node are moved to other existing nodes.
    클러스터에서 노드를 제거하려면 해당 노드에 할당된 해시 슬롯이 다른 기존 노드로 이동됩니다.
  • To rebalance the cluster a given set of hash slots are moved between nodes.
    클러스터의 균형을 맞추기 위해 주어진 해시 슬롯 세트가 노드 간에 이동됩니다.

The core of the implementation is the ability to move hash slots around. From a practical point of view a hash slot is just a set of keys, so what Redis Cluster really does during resharding is to move keys from an instance to another instance. Moving a hash slot means moving all the keys that happen to hash into this hash slot.
구현의 핵심은 해시 슬롯을 이동할 수 있는 능력입니다. 실용적인 관점에서 해시 슬롯은 단지 키의 집합일 뿐이므로, Redis Cluster가 리샤딩 동안 실제로 하는 일은 인스턴스에서 다른 인스턴스로 키를 이동하는 것입니다. 해시 슬롯을 이동하는 것은 이 해시 슬롯에 해시되는 모든 키를 이동하는 것을 의미합니다.

To understand how this works we need to show the CLUSTER subcommands that are used to manipulate the slots translation table in a Redis Cluster node.
이 작동 방식을 이해하기 위해서는 Redis Cluster 노드에서 슬롯 변환 테이블을 조작하는 데 사용되는 CLUSTER 하위 명령어를 보여줄 필요가 있습니다.

The following subcommands are available (among others not useful in this case):
다음 서브커맨드가 사용 가능합니다 (이 경우에 유용하지 않은 다른 것들 중에서):

The first four commands, ADDSLOTS, DELSLOTS, ADDSLOTSRANGE and DELSLOTSRANGE, are simply used to assign (or remove) slots to a Redis node. Assigning a slot means to tell a given master node that it will be in charge of storing and serving content for the specified hash slot.
첫 네 개의 명령어, ADDSLOTS , DELSLOTS , ADDSLOTSRANGE 및 DELSLOTSRANGE 는 Redis 노드에 슬롯을 할당(또는 제거)하는 데 사용됩니다. 슬롯을 할당하는 것은 주어진 마스터 노드에게 지정된 해시 슬롯에 대한 콘텐츠를 저장하고 제공하는 책임이 있음을 알리는 것을 의미합니다.

After the hash slots are assigned they will propagate across the cluster using the gossip protocol, as specified later in the configuration propagation section.
해시 슬롯이 할당된 후, 구성 전파 섹션에서 나중에 지정된 대로, 그들은 가십 프로토콜을 사용하여 클러스터 전반에 전파될 것입니다.

The ADDSLOTS and ADDSLOTSRANGE command are usually used when a new cluster is created from scratch to assign each master node a subset of all the 16384 hash slots available.
ADDSLOTS 및 ADDSLOTSRANGE 명령은 일반적으로 새로운 클러스터가 처음부터 생성될 때 각 마스터 노드에 사용 가능한 16384 해시 슬롯의 하위 집합을 할당하는 데 사용됩니다.

The DELSLOTS and DELSLOTSRANGE are mainly used for manual modification of a cluster configuration or for debugging tasks: in practice it is rarely used.
DELSLOTS 와 DELSLOTSRANGE 은 주로 클러스터 구성의 수동 수정이나 디버깅 작업에 사용됩니다: 실제로는 거의 사용되지 않습니다.

The SETSLOT subcommand is used to assign a slot to a specific node ID if the SETSLOT <slot> NODE form is used. Otherwise the slot can be set in the two special states MIGRATING and IMPORTING. Those two special states are used in order to migrate a hash slot from one node to another.
SETSLOT 서브커맨드는 SETSLOT <slot> NODE 형식이 사용될 경우 특정 노드 ID에 슬롯을 할당하는 데 사용됩니다. 그렇지 않으면 슬롯은 두 개의 특별한 상태 MIGRATING 와 IMPORTING 에서 설정될 수 있습니다. 이 두 개의 특별한 상태는 해시 슬롯을 한 노드에서 다른 노드로 마이그레이션하기 위해 사용됩니다.

  • When a slot is set as MIGRATING, the node will accept all queries that are about this hash slot, but only if the key in question exists, otherwise the query is forwarded using a -ASK redirection to the node that is target of the migration.
    슬롯이 MIGRATING 로 설정되면, 노드는 이 해시 슬롯에 대한 모든 쿼리를 수락하지만, 해당 키가 존재할 경우에만 그렇고, 그렇지 않으면 쿼리는 -ASK 리디렉션을 사용하여 마이그레이션의 대상 노드로 전달됩니다.
  • When a slot is set as IMPORTING, the node will accept all queries that are about this hash slot, but only if the request is preceded by an ASKING command. If the ASKING command was not given by the client, the query is redirected to the real hash slot owner via a -MOVED redirection error, as would happen normally.
    슬롯이 IMPORTING 으로 설정되면, 노드는 이 해시 슬롯에 대한 모든 쿼리를 수락하지만, 요청이 ASKING 명령으로 선행되어야만 합니다. 클라이언트가 ASKING 명령을 제공하지 않은 경우, 쿼리는 일반적으로 발생하는 것처럼 -MOVED 리디렉션 오류를 통해 실제 해시 슬롯 소유자에게 리디렉션됩니다.

ASK redirection  ASK 리디렉션

In the previous section we briefly talked about ASK redirection. Why can’t we simply use MOVED redirection? Because while MOVED means that we think the hash slot is permanently served by a different node and the next queries should be tried against the specified node, ASK means to send only the next query to the specified node.
이전 섹션에서는 ASK 리디렉션에 대해 간략하게 이야기했습니다. 왜 MOVED 리디렉션을 간단히 사용할 수 없을까요? MOVED는 해시 슬롯이 다른 노드에 의해 영구적으로 제공된다고 생각하고 다음 쿼리는 지정된 노드에 대해 시도해야 한다는 것을 의미하는 반면, ASK는 다음 쿼리만 지정된 노드로 보내야 한다는 것을 의미합니다.

This is needed because the next query about hash slot 8 can be about a key that is still in A, so we always want the client to try A and then B if needed. Since this happens only for one hash slot out of 16384 available, the performance hit on the cluster is acceptable.
이것이 필요한 이유는 해시 슬롯 8에 대한 다음 쿼리가 여전히 A에 있는 키에 관한 것일 수 있기 때문에, 우리는 항상 클라이언트가 A를 시도하고 필요할 경우 B를 시도하도록 하고 싶기 때문입니다. 16384개의 사용 가능한 해시 슬롯 중 하나에 대해서만 이러한 일이 발생하므로 클러스터에 대한 성능 저하는 수용 가능합니다.

127.0.0.1:7000> cluster slots
1) 1) (integer) 5461
   2) (integer) 10922
   3) 1) "127.0.0.1"
      2) (integer) 7001
   4) 1) "127.0.0.1"
      2) (integer) 7004
2) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 7000
   4) 1) "127.0.0.1"
      2) (integer) 7003
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 7002
   4) 1) "127.0.0.1"
      2) (integer) 7005

Fault Tolerance  장애 허용

Heartbeat and gossip messages
하트비트 및 소문 메시지

Redis Cluster nodes continuously exchange ping and pong packets. Those two kind of packets have the same structure, and both carry important configuration information. The only actual difference is the message type field. We’ll refer to the sum of ping and pong packets as heartbeat packets.
Redis Cluster 노드는 지속적으로 핑과 퐁 패킷을 교환합니다. 이 두 종류의 패킷은 동일한 구조를 가지고 있으며, 둘 다 중요한 구성 정보를 담고 있습니다. 실제로 유일한 차이점은 메시지 유형 필드입니다. 우리는 핑과 퐁 패킷의 합을 하트비트 패킷이라고 부를 것입니다.

Usually nodes send ping packets that will trigger the receivers to reply with pong packets. However this is not necessarily true. It is possible for nodes to just send pong packets to send information to other nodes about their configuration, without triggering a reply. This is useful, for example, in order to broadcast a new configuration as soon as possible.
일반적으로 노드는 핑 패킷을 보내고, 수신자는 퐁 패킷으로 응답하게 됩니다. 그러나 이것이 반드시 사실은 아닙니다. 노드는 응답을 유도하지 않고 다른 노드에게 자신의 구성에 대한 정보를 보내기 위해 퐁 패킷만 보낼 수 있습니다. 예를 들어, 가능한 한 빨리 새로운 구성을 브로드캐스트하기 위해 유용합니다.

Usually a node will ping a few random nodes every second so that the total number of ping packets sent (and pong packets received) by each node is a constant amount regardless of the number of nodes in the cluster.
일반적으로 노드는 클러스터의 노드 수와 관계없이 각 노드가 보내는 핑 패킷(및 수신하는 퐁 패킷)의 총 수가 일정하도록 매초 몇 개의 임의의 노드에 핑을 보냅니다.

However every node makes sure to ping every other node that hasn’t sent a ping or received a pong for longer than half the NODE_TIMEOUT time. Before NODE_TIMEOUT has elapsed, nodes also try to reconnect the TCP link with another node to make sure nodes are not believed to be unreachable only because there is a problem in the current TCP connection.
그러나 모든 노드는 반 이상 NODE_TIMEOUT 시간이 경과한 경우 핑을 보내지 않거나 퐁을 받지 않은 다른 모든 노드에 핑을 보내도록 합니다. NODE_TIMEOUT 시간이 경과하기 전에 노드는 현재 TCP 연결에 문제가 있기 때문에 노드가 도달할 수 없는 것으로 간주되지 않도록 다른 노드와 TCP 링크를 재연결하려고 시도합니다.

The number of messages globally exchanged can be sizable if NODE_TIMEOUT is set to a small figure and the number of nodes (N) is very large, since every node will try to ping every other node for which they don’t have fresh information every half the NODE_TIMEOUT time.
전 세계적으로 교환되는 메시지의 수는 NODE_TIMEOUT 이 작은 수로 설정되고 노드 수(N)가 매우 클 경우 상당할 수 있습니다. 모든 노드는 매 NODE_TIMEOUT 시간의 절반마다 최신 정보가 없는 다른 모든 노드에 핑을 시도하기 때문입니다.

For example in a 100 node cluster with a node timeout set to 60 seconds, every node will try to send 99 pings every 30 seconds, with a total amount of pings of 3.3 per second. Multiplied by 100 nodes, this is 330 pings per second in the total cluster.
예를 들어, 노드 타임아웃이 60초로 설정된 100개 노드 클러스터에서 각 노드는 30초마다 99개의 핑을 보내려고 하며, 총 핑 수는 초당 3.3개입니다. 100개 노드에 곱하면, 전체 클러스터에서 초당 330개의 핑이 됩니다.

There are ways to lower the number of messages, however there have been no reported issues with the bandwidth currently used by Redis Cluster failure detection, so for now the obvious and direct design is used. Note that even in the above example, the 330 packets per second exchanged are evenly divided among 100 different nodes, so the traffic each node receives is acceptable
메시지 수를 줄이는 방법이 있지만, 현재 Redis Cluster 장애 감지에 사용되는 대역폭에 대한 보고된 문제는 없으므로 현재로서는 명백하고 직접적인 설계가 사용됩니다. 위의 예에서도 초당 330개의 패킷이 100개의 서로 다른 노드 간에 고르게 분배되므로 각 노드가 수신하는 트래픽은 허용 가능합니다.

Failure detection  장애 감지

Redis Cluster failure detection is used to recognize when a master or replica node is no longer reachable by the majority of nodes and then respond by promoting a replica to the role of master. When replica promotion is not possible the cluster is put in an error state to stop receiving queries from clients.
Redis Cluster 장애 감지는 마스터 또는 복제 노드가 대다수 노드에 의해 더 이상 도달할 수 없을 때 이를 인식하고, 그에 따라 복제 노드를 마스터 역할로 승격시키는 데 사용됩니다. 복제 승격이 불가능할 경우 클러스터는 클라이언트로부터 쿼리를 받지 않도록 오류 상태로 전환됩니다.

As already mentioned, every node takes a list of flags associated with other known nodes. There are two flags that are used for failure detection that are called PFAIL and FAIL. PFAIL means Possible failure, and is a non-acknowledged failure type. FAIL means that a node is failing and that this condition was confirmed by a majority of masters within a fixed amount of time.
이미 언급했듯이, 각 노드는 다른 알려진 노드와 관련된 플래그 목록을 가져옵니다. 실패 감지에 사용되는 두 개의 플래그가 있으며, 이를 PFAIL 와 FAIL 이라고 합니다. PFAIL 는 가능한 실패를 의미하며, 비인정된 실패 유형입니다. FAIL 는 노드가 실패하고 있으며, 이 조건이 정해진 시간 내에 다수의 마스터에 의해 확인되었음을 의미합니다.

PFAIL flag:

A node flags another node with the PFAIL flag when the node is not reachable for more than NODE_TIMEOUT time. Both master and replica nodes can flag another node as PFAIL, regardless of its type.
노드는 다른 노드가 NODE_TIMEOUT 시간 이상 도달할 수 없을 때 PFAIL 플래그로 표시합니다. 마스터 노드와 복제 노드 모두 다른 노드를 PFAIL 로 표시할 수 있으며, 노드의 유형에 관계없이 가능합니다.

The concept of non-reachability for a Redis Cluster node is that we have an active ping (a ping that we sent for which we have yet to get a reply) pending for longer than NODE_TIMEOUT. For this mechanism to work the NODE_TIMEOUT must be large compared to the network round trip time. In order to add reliability during normal operations, nodes will try to reconnect with other nodes in the cluster as soon as half of the NODE_TIMEOUT has elapsed without a reply to a ping. This mechanism ensures that connections are kept alive so broken connections usually won’t result in false failure reports between nodes.
Redis Cluster 노드에 대한 비접근성 개념은 우리가 아직 응답을 받지 못한 활성 핑(우리가 보낸 핑)이 NODE_TIMEOUT 보다 오래 대기 중이라는 것입니다. 이 메커니즘이 작동하려면 NODE_TIMEOUT 이 네트워크 왕복 시간에 비해 커야 합니다. 정상 작동 중 신뢰성을 추가하기 위해, 노드는 핑에 대한 응답 없이 NODE_TIMEOUT 의 절반이 경과하면 클러스터의 다른 노드와 재연결을 시도합니다. 이 메커니즘은 연결이 유지되도록 보장하므로 끊어진 연결이 노드 간의 잘못된 실패 보고로 이어지지 않도록 합니다.

FAIL flag:

The PFAIL flag alone is just local information every node has about other nodes, but it is not sufficient to trigger a replica promotion. For a node to be considered down the PFAIL condition needs to be escalated to a FAIL condition.
PFAIL 플래그만으로는 각 노드가 다른 노드에 대해 가지고 있는 로컬 정보일 뿐이며, 복제본 승격을 유도하기에는 충분하지 않습니다. 노드가 다운으로 간주되기 위해서는 PFAIL 조건이 FAIL 조건으로 격상되어야 합니다.

As outlined in the node heartbeats section of this document, every node sends gossip messages to every other node including the state of a few random known nodes. Every node eventually receives a set of node flags for every other node. This way every node has a mechanism to signal other nodes about failure conditions they have detected.
이 문서의 노드 하트비트 섹션에 설명된 바와 같이, 모든 노드는 몇 개의 무작위로 알려진 노드의 상태를 포함하여 다른 모든 노드에 가십 메시지를 보냅니다. 모든 노드는 결국 다른 모든 노드에 대한 노드 플래그 집합을 수신합니다. 이렇게 하면 모든 노드는 감지한 실패 조건에 대해 다른 노드에 신호를 보낼 수 있는 메커니즘을 갖게 됩니다.

A PFAIL condition is escalated to a FAIL condition when the following set of conditions are met:

  • Some node, that we’ll call A, has another node B flagged as PFAIL.
    어떤 노드 A는 다른 노드 B가 PFAIL 로 표시되어 있습니다.
  • Node A collected, via gossip sections, information about the state of B from the point of view of the majority of masters in the cluster.
    노드 A는 군집 내 다수의 마스터 관점에서 B의 상태에 대한 정보를 소문 섹션을 통해 수집했습니다.
  • The majority of masters signaled the PFAIL or FAIL condition within NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT time. (The validity factor is set to 2 in the current implementation, so this is just two times the NODE_TIMEOUT time).
    대부분의 마스터는 PFAIL 또는 FAIL 조건을 NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT 시간 내에 신호를 보냈습니다. (유효성 요소는 현재 구현에서 2로 설정되어 있으므로 이는 단지 NODE_TIMEOUT 시간의 두 배입니다).

Configuration handling, propagation, and failovers
구성 처리, 전파 및 장애 조치

Cluster current epoch  클러스터 현재 에포크

Redis Cluster uses a concept similar to the Raft algorithm “term”. In Redis Cluster the term is called epoch instead, and it is used in order to give incremental versioning to events. When multiple nodes provide conflicting information, it becomes possible for another node to understand which state is the most up to date.
Redis Cluster는 Raft 알고리즘의 "term"과 유사한 개념을 사용합니다. Redis Cluster에서는 이 용어를 epoch이라고 하며, 이벤트에 점진적인 버전 관리를 제공하는 데 사용됩니다. 여러 노드가 상충하는 정보를 제공할 때, 다른 노드가 어떤 상태가 가장 최신인지 이해할 수 있게 됩니다.

The currentEpoch is a 64 bit unsigned number.
currentEpoch 는 64비트 부호 없는 숫자입니다.

At node creation every Redis Cluster node, both replicas and master nodes, set the currentEpoch to 0.
모든 Redis Cluster 노드, 복제본 및 마스터 노드에서 노드 생성 시 currentEpoch 을 0으로 설정합니다.

Every time a packet is received from another node, if the epoch of the sender (part of the cluster bus messages header) is greater than the local node epoch, the currentEpoch is updated to the sender epoch.
다른 노드로부터 패킷이 수신될 때마다, 발신자의 에포크(클러스터 버스 메시지 헤더의 일부)가 로컬 노드 에포크보다 크면 currentEpoch 이 발신자 에포크로 업데이트됩니다.

Because of these semantics, eventually all the nodes will agree to the greatest currentEpoch in the cluster.
이러한 의미론 때문에 결국 모든 노드가 클러스터에서 가장 큰 currentEpoch 에 동의하게 될 것입니다.

This information is used when the state of the cluster is changed and a node seeks agreement in order to perform some action.
이 정보는 클러스터의 상태가 변경될 때 사용되며, 노드가 어떤 작업을 수행하기 위해 합의를 구할 때 사용됩니다.

Currently this happens only during replica promotion, as described in the next section. Basically the epoch is a logical clock for the cluster and dictates that given information wins over one with a smaller epoch.
현재 이것은 다음 섹션에서 설명된 대로 복제본 승격 중에만 발생합니다. 기본적으로 에포크는 클러스터의 논리적 시계이며, 주어진 정보가 더 작은 에포크를 가진 정보보다 우선한다는 것을 규정합니다.

Replica election and promotion
복제본 선출 및 승진

replica election and promotion is handled by replica nodes, with the help of master nodes that vote for the replica to promote. A replica election happens when a master is in FAIL state from the point of view of at least one of its replicas that has the prerequisites in order to become a master.
복제본 선거 및 승격은 복제본 노드에 의해 처리되며, 복제본을 승격시키기 위해 투표하는 마스터 노드의 도움을 받습니다. 복제본 선거는 마스터가 최소한 하나의 복제본의 관점에서 마스터가 되기 위한 전제 조건을 갖춘 FAIL 상태에 있을 때 발생합니다.

In order for a replica to promote itself to master, it needs to start an election and win it. All the replicas for a given master can start an election if the master is in FAIL state, however only one replica will win the election and promote itself to master.
복제가 마스터로 승격되기 위해서는 선거를 시작하고 이를 이겨야 합니다. 주어진 마스터에 대한 모든 복제본은 마스터가 FAIL 상태에 있을 때 선거를 시작할 수 있지만, 오직 하나의 복제본만이 선거에서 승리하여 마스터로 승격됩니다.

A replica starts an election when the following conditions are met:
복제본은 다음 조건이 충족될 때 선거를 시작합니다:

  • The replica’s master is in FAIL state.
    복제본의 마스터는 FAIL 상태입니다.
  • The master was serving a non-zero number of slots.
    마스터는 0이 아닌 슬롯 수를 제공하고 있었습니다.
  • The replica replication link was disconnected from the master for no longer than a given amount of time, in order to ensure the promoted replica’s data is reasonably fresh. This time is user configurable.
    복제본 복제 링크는 승격된 복제본의 데이터가 합리적으로 최신 상태를 유지하도록 하기 위해 주어진 시간 이상으로 마스터와 연결이 끊어지지 않았습니다. 이 시간은 사용자 설정이 가능합니다.

Replica migration  복제본 마이그레이션

For example:  예를 들어:

  • Master A has a single replica A1.
    Master A는 단일 복제본 A1을 가지고 있습니다.
  • Master A fails. A1 is promoted as new master.
    마스터 A가 실패했습니다. A1이 새로운 마스터로 승격되었습니다.
  • Three hours later A1 fails in an independent manner (unrelated to the failure of A). No other replica is available for promotion since node A is still down. The cluster cannot continue normal operations.
    세 시간 후 A1이 독립적으로 실패합니다(A의 실패와는 무관합니다). 노드 A가 여전히 다운되어 있기 때문에 승격할 수 있는 다른 복제본이 없습니다. 클러스터는 정상 운영을 계속할 수 없습니다.

If the map between masters and replicas is fixed, the only way to make the cluster more resistant to the above scenario is to add replicas to every master, however this is costly as it requires more instances of Redis to be executed, more memory, and so forth.
마스터와 복제본 간의 맵이 고정되어 있다면, 위의 시나리오에 대해 클러스터를 더 저항력 있게 만드는 유일한 방법은 모든 마스터에 복제본을 추가하는 것이지만, 이는 더 많은 Redis 인스턴스를 실행해야 하고, 더 많은 메모리 등이 필요하기 때문에 비용이 많이 듭니다.

An alternative is to create an asymmetry in the cluster, and let the cluster layout automatically change over time. For example the cluster may have three masters A, B, C. A and B have a single replica each, A1 and B1. However the master C is different and has two replicas: C1 and C2.
대안은 클러스터에서 비대칭을 생성하고 클러스터 레이아웃이 시간이 지남에 따라 자동으로 변경되도록 하는 것입니다. 예를 들어 클러스터에는 세 개의 마스터 A, B, C가 있을 수 있습니다. A와 B는 각각 하나의 복제본 A1과 B1을 가지고 있습니다. 그러나 마스터 C는 다르며 두 개의 복제본 C1과 C2를 가지고 있습니다.

Replica migration is the process of automatic reconfiguration of a replica in order to migrate to a master that has no longer coverage (no working replicas). With replica migration the scenario mentioned above turns into the following:
복제본 마이그레이션은 더 이상 커버리지(작동 중인 복제본이 없음)가 없는 마스터로 마이그레이션하기 위해 복제본의 자동 재구성 프로세스입니다. 복제본 마이그레이션을 통해 위에서 언급한 시나리오는 다음과 같이 변합니다:

  • Master A fails. A1 is promoted.
    마스터 A가 실패했습니다. A1이 승격되었습니다.
  • C2 migrates as replica of A1, that is otherwise not backed by any replica.
    C2는 A1의 복제본으로 마이그레이션되며, A1은 다른 복제본으로 지원되지 않습니다.
  • Three hours later A1 fails as well.
    세 시간 후 A1도 실패합니다.
  • C2 is promoted as new master to replace A1.
    C2는 A1을 대체할 새로운 마스터로 승격됩니다.
  • The cluster can continue the operations.
    클러스터는 작업을 계속할 수 있습니다.

Replica migration algorithm
복제본 마이그레이션 알고리즘

https://redis.io/topics/cluster-spec#replica-migration-algorithm

Ref

https://redis.io/topics/cluster-tutorial

分享   공유
Mark Zhu
作者   저자
Mark Zhu
An old developer   오래된 개발자