2016.11.11 - 번역 - Every shard deserves a home ...

Here are some great slides from our Core Elasticsearch: Operations course that help explain the concept. We'd recommend that you take the full course to understand this even better, but I'll provide an overview from our training here:

다음은 Core Elasticsearch: Operations 과정(개념을 설명하는)에서 제공하는 몇 개의 멋진 slide이다. 이 내용을 더 잘 이해하기 위해서는 전체 과정을 수강하는 것이 좋겠지만, 여기에서 과정의 개요를 제공한다.

Shard allocation is the process of allocating shards to nodes. This can happen during initial recovery, replica allocation, rebalancing, or when nodes are added or removed. Most of the time, you don't need to think about it, this work is done by Elasticsearch in the background. If you've ever found yourself curious about these particulars, this blog will explore shard allocation in several different scenarios.

shard allocation은 shard를 node에 할당하는 process이다. 이는 초기 recovery, replica allocation, rebalancing, node의 추가 또는 제거에서 발생한다. 대부분의 경우, Elasticsearch가 background에서 수행하므로, 그것에 대해 생각할 필요가 없다.이들 세부 사항에 대해 궁금하다면, 이 게시물에서, 여러 가지 상황에서의 shard allocation을 살펴보자.

This is our 4 node cluster, it's what we'll use for the examples within our content:

여기에서 예제로 사용할 4개의 node를 가진 cluster이다.

We'll cover several different scenarios.

몇 가지 상황을 다룰 것이다.

Scenario 1. Index creation

This is the most simple use case. We've created an index, c, and for it we've got to assign new shards. This will be done by indexing the first document into a new index c, with a command like you see in the grey box, using the Console(formerly Sense) plugin from within Kibana.

가장 간단환 상황이다. index c를 생성했으니, 이를 위해 새로운 shard를 생성해야 한다. Kibana의 Console plugin(일반적으로 Sense)을 사용하여 회색 박스에 보이는 command를 이용하여, 새로운 index c에 첫번째 document를 index하여 이 작업을 할 수 있다.

For index c, we're creating one primary shard, and one replica. The master needs to create index c, and assign 2 shards for c0, a primary and a replica. The way that the cluster will balance the cluster is by:

index c에 대해, primary/replica shard 각 1개씩 생성된다. master는 index c를 생성하고 c0 에 2개의 shard(primary, replica)를 할당한다. cluster가 cluster의 균형(balance)을 맞추는 방법은 아래와 같다.

1. By looking at the average number of shards that each node in the cluster contains and then trying to get that number to be as close to the same as possible
   cluster의 각 node에 있는 shard의 평균 수를 보고, 가능한 한 동일하게 하려 한다.
2. By evaluating on a per index level in the cluster, and trying to rebalance shards across those indices.
   cluster의 각 index level로 평가해보고, 해당 index에서 shard를 재조정한다.

There are certain restrictions on this process, and those restrictions are imposed by allocation deciders. They evaluate every decision the cluster tries to make and make a yes/no decision. They run on the master. You can think of it like the master proposing changes, and the deciders tell the master if there are any blocks that prevent the master's proposition.

이 process에는 어떤 제한이 있는데, 이 제한은 allocation decider에 의해 결정된다. decider는 cluster의 모든 시도를 평가하고, yes/no를 결정하며, master에서 동작한다. master가 변경하려는 것처럼 생각할 수 있고, master의 제안을 막는 어떤 것이 있으면, decider는 master에게 알린다.

The cleanest example of this is that you cannot put a primary and a replica on the same node.

가장 명확한 점은 primary와 replica를 동일한 node에 둘 수 없다는 것이다.

There are other examples as well:

다른 예도 있다.

1. Allocation Filtering on Hot/Warm setups. This allows you to only put shards on nodes with certain attributes and will either accept or reject decisions made by the cluster made via this logic. This is an example of a User-driven decision controlling this configuration.

Hot/Warm 설정의 allocation filtering. 이렇게 하면 특정 attribute를 가진 nodex에만 shard를 둘 수 있으며, 이 logic을 통해 cluster가 내린 결정을 받아들이거나 거절한다. 이 것은 이 구성을 제어하는 user-driven 결정이다.

2. Disk usage allocator. The Master monitors disk usage on cluster and looks at high/low watermark. (see "Time to move a shard" below).

Disk usage allocator. master는 cluster의 disk 사용량을 모니터링하고, high/low watermark를 검토한다. (아래의 "Time to move a shard" 참조)

3. Throttles, which mean that in principle we can assign a shard to the node, but there are too many ongoing recoveries. To protect the node and allow recovery, the allocation decider can tell the cluster to wait and retry to assign the shard to the same node in the next iteration.

Throttles 은 기본적으로 node에 shard를 할당할 수 있지만 recovery가 진행 중인 것이 너무 많다는 것을 의미한다. node를 보호하고 recovery를 허용하기 위하여, allocation decider는 cluster가 다음에 동일한 noder에 shard를 할당하기 위해 기다렸다가 재시도하라고 할 수 있다.

Shard initialization.

Once we've made a decision about where the primary shard belongs, it'll get marked as "initializing" and decision will be broadcast to cluster via a modified cluster state which is made available to all nodes within the cluster.

일단, primary shard를 가질 곳이 결정되면, "initializing" 이라고 표시하고, cluster에 있는 모든 node가 이용할 수 있는 변경된 cluster state를 통해 cluster에 알린다.

Once marked initializing, the node assigned will detect it was assigned the new shard. An empty lucene index will be created and once this is done the master will be alerted the shard is ready, master marks the shard as started, and sends out another modified cluster state. Once the node assigned the primary gets the updated cluster state it'll mark the shard as started. Because it's a primary, we'll now be allowed to index:

initializing 이라고 표시되면, 할당된 node는 새로운 shard가 할당되었음을 감지한다. 비어 있는 Lucene index가 생성되고 이를 완료하면, master는 shard가 준비되었음을 알리고, master는 shard를 started로 표시한다. 그리고, 다른 수정된 cluster state를 보낸다. primary가 할당된 node가 update된 cluster state를 얻게 되면, shard는 started로 표시될 것이다. 그것이 primary이므로, 이제 index할 수 있다.

All of this communication, as you've seen, is done via modified cluster state. Once this cycle is complete, the master will perform a re-route and reevaluate shard assignment, potentially making decisions about what was throttled in the previous iteration.

지금까지 보았듯이, 이 모든 통신은 변경된 cluster state를 통해 이루어진다. 이 작업들이 완료되면, master는 shard 할당을 re-route, re-evaluate하여, 이전 반복에서 throttle된 것에 대해 결정한다.

In our example, the master now must attempt to assign the leftover replica, c0. This is also decision of the allocation deciders, which prevent replicas from being assigned until the primary is marked as started on the node containing it.

이 예에서, master는 이제 남아 있는 replica c0를 할당해야 한다. 이것 역시 allocation decider의 결정이다. decider는 primary를 가지고 있는 node에서 primary가 started로 표시될 때까지 replica의 할당을 막는다.

At this point, the re-balancing happens using the same process as describe above, with the goal of ensuring data balanced across the cluster, and in the case of this example we'll assign the c0 replica shard to node3 in the cluster in order to keep things balanced. This should leave us with 3 shards on each node in the cluster.

이 시점에서, re-balancing은 cluster 전체의 data 균형을 유지하면서, 위에서 설명한 것과 동일한 process를 이용하여 이루어진다. 이 예의 경우, 균형을 유지하기 위해, cluster의 node3에 replica shard c0 를 할당한다. 이렇게 하면, cluster의 각 node에는 3개의 shard가 있게 된다.

In our previous example, we just created an empty replica shard, which was a bit simpler than if we imagine we already have a started primary that already has data. With this in mind, we need to ensure the new replica has the same data as the primary.

이전 예에서, 비어 있는 replica shard를 생성했는데, 이미 data를 가지고 있는 이미 started 상태인 primary를 가정해 보면, 좀 더 간단하다. 이를 위해, 새로운 replica가 primary와 동일한 data를 가지고 있는지 확인해야 한다.

When replicas are assigned, it's important to understand we're going to copy any missing data from the primary back to the replica. After this, the master will again mark the replica as started and broadcast a new cluster state.

replica가 할당될 때, 누락된 data를 primary에서 replica로 복사한다는 것을 이해하는 것이 중요하다. 그런 다음 master는 replica를 started로 다시 표시하고 cluster state에 알린다. 

Scenario 2. Time to move a shard.

From time to time your cluster may need to move already existing shards within the cluster. This can happen for a number of reasons:

가끔, cluster는 cluster내의 기존 shard를 이동해야 할 수도 있다. 이런 상황은 다음과 같은 이유로 발생한다.

1. Explicit user configuration. A common example of this is a Hot/Warm configuration which moves data to slower disks as it ages:

명시적인 사용자 설정. 이의 일반적인 예는 오래된 data를 더 느린 disk로 이동하는 Hot/Warm 구성이다.

2. User instructs elasticsearch to actually move a shard from one place to another for you with the cluster re-route command.

사용자가 cluster re-route 명령어를 통해 shard룰 다른 곳으로 이동하도록 한다.

3. Allocation decider blocking on disk space because of exceeded thresholds for:

아래 설정의 임계값을 초과하였기 때문에 allocation decider가 disk 공간에서 차단한다.

a. cluster.routing.allocation.disk.watermark.low 
b. cluster.routing.allocation.disk.watermark.high

The low watermark prevents us from writing new shards when threshold is triggered. Likewise, the high watermark threshold the moves shards off the node until such time as disk space falls below the threshold.

low watermark는 임계값 이하이면 새로운 shard 쓰기가 금지된다. 마찬가지로, high watermark는 임계값은 disk 공간이 임계값 아래로 떨어질 때까지 다른 node로 이동시킨다.

4. Nodes added to cluster. Maybe your cluster is at maximum capacity, so you've added a new node. Elasticsearch will attempt to rebalance the cluster.

node가 cluster에 추가된다. 어쩌면, cluster는 최대 가용성 상태라서, 새로운 node를 추가한 것이다. Elasticsearch는 cluster의 rebalance를 시도한다.

Since shards may contain many gigabytes of data, moving these across the cluster could potentially have significant impacts on performance. In order for this process to be transparent to users, this has to happen in the background. The idea is to, as much as possible, limit impacts on other aspects of elasticsearch performance. Toward that end, a throttle(indices.recovery.max_bytes_per_sec/cluster.routing.allocation.node_concurrent_recoveries) is introduced to ensure that we can continue to index into these shards.

shard는 수 GB의 data를 가질 수 있으므로, cluster에서 이를 이동시키면, cluster는 성능에 상당한 영향을 받을 수 있다. 이 process가 사용자에게 영향을 덜 미치도록 하려면, background로 수행되어야 한다. 이 아이디어는 Elasticsearch 성능의 다른 측면에 대한 영향을 제한하기 위한 것이다. 그러한 목적으로, 이들 shard에 index를 계속 할 수 있는지를 확인하기 위해, throttle(indices.recovery.max_bytes_per_sec/cluster.routing.allocation.node_concurrent_recoveries)이 도입되었다.

Remember, all elasticsearch data is stored through Lucene. Lucene contains a set of inverted indices in a set of files called segments. These inverted indices have a structure to tell you about where certain tokens/words appear within a set of documents. When indexing documents in Lucene, they're parked within an indexing buffer that sits in memory. There it sits until it a buffer becomes full, or in the case of elasticsearch, when something called a refresh is issued it forces all the data in the buffer into an inverted index called a segment.

기억하자. 모든 Elasticsearch data는 Lucene을 통해 저장된다. Lucene은 segment라는 file의 집합에 inverted index 집합을 포함한다. 이 inverted index는 document의 집합내에서 특정 token/word의 위치를 알려주는 구조를 가지고 있다. Lucene에 document를 index하면, document는 memory에 있는 indexing buffer에 위하게 된다. buffer가 가득 찰 때까지 또는 Elasticsearch가 refresh를 실행하면 buffer에 있는 모든 data가 segment라는 inverted index로 만든다..

As we continue indexing, we create new segments in the same fashion. The thing about segments is they're immutable. Meaning, once you've written one, they don't ever change. If you issue a delete, or any change at all, it goes into a new segment where the same merging process happens again.

index를 계속하면, 동일한 방법으로 새로운 segment를 생성한다. segment는 불변이다. 즉, 일단 한번 쓰면 절대 변경하지 않는다. 삭제 또는 변경을 하면, 동일한 merge process가 다시 발생하는 곳에 있는 새로운 segment로 이동한다.

Since data is stored in memory, theoretically data could be lost before it's committed into a segment file. To mitigate this, elasticsearch makes use of a transaction log. Whenever a document is indexed into lucene, it's also written to the transaction log.

data가 memory에 저장되므로, 이론적으로 segment file에 commit되기 전에 data가 손실될 수 있다. 이를 완화하기 위해, Elasticsearch는 transaction log를 사용한다. document가 Lucene에 index될 때마다, transaction log에도 기록된다.

The transaction log is written sequentially, with the last request at the end of the file. The transaction logs allow us to recover documents which may not have made it into lucene.

transaction log는 file의 마지막에, 마지막 request를 연속적으로 기록한다. transaction log를 사용하면 Lucene에 만들어지지 않은 document를 복구할 수 있다.

It's possible for us make a segment without fsyncing, allowing the filesystem to keep in memory or pending flushes to disk. This is done for performance reasons, and because of this the transaction log needs to be cleaned. This is done with an elasticsearch flush.

filesystem을 memory에 저장하거나 disk에 flush하는 것을 보류하여, fsync 없이 segment를 만들 수 있다. 이것은 성능상의 이유로 수행되며, 이때문에 transaction log는 정리되어야 한다. 이것은 Elasticsearch flush가 수행한다.

On issuing elasticsearch flush, lucene commit, which does 2 things:

Elasticsearch flush를 실행하면, Lucene이 commit하는데, 이것을 다음 2 가지를 한다.

1. Take everything in buffer and commit it to disk in new segment
   buffer에 있는 모든 것을 가져와 새로운 segment의 disk에 commit한다.
2. Goes through all segment files and asks the file system cache to persist to disk using fsync.
   모든 segment file을 살펴보고, fsync를 사용하여 file system cache가 disk에 유지되도록 요청한다.

This allows us to flush the transaction log and guarantees we have all the data. For relocation, if we capture a given set of segments and keep them around we have a point in time consistent and immutable snapshot of our data.

이를 통해, transaction log를 flush할 수 있으며, 모든 data를 가지고 있다는 것을 보증하게 된다. 재배치(relocation)를 위해, 주어진 segment 집합을 capture하고 유지하면, 일정 시점의 일관되고 불변인 data의 snapshot을 가진다.

In our example, when the cluster wants to move a0 from node4 to node5, first the master does it by marking shard a0 as relocating from node4 to node5. Node5 interprets this as an initializing shard copy on itself. An important thing to note around this behavior is that while rebalancing is happening it may appear a replica is being moved from node4 to node5, when relocating data it will always be copied from the primary shard(node1).

이 예제에서, cluster가 a0 를 node4 에서 node5 로 이동시킬 경우, master는 먼저 shard a0 를 node4 에서 node5 로 재배치한다고 표시한다. node5 는 이것을 shard 복사본 자체의 초기화로 해석한다. 이 동작에서 주목해야 할 중요한 점은 rebalancing이 진행되는 동안 replica가 node4 에서 node5 로 이동되는 것처럼 보일 수 있다는 점이다. data를 재배치할 경우에는 항상 primary shard(node1)에서 복사된다.

In the example below, we have an empty node5 and a node with the primary, node1. Keep in mind the two data storage mechanisms we mentioned previously, the transaction log and the lucene segments. We're illustrating Node5 responding to a request from the master to initialize a shard after reading an updated cluster state. Node5 goes to node1 and ask to start a recovery process. Node1 will then validate it knows about the request that node5 is making. Once a request is found, elasticsearch will pin the transaction log to prevent it from being deleted and take a snapshot in lucene, ensuring that we capture all the data within the shard. Once we do this, we can start sending segments over to the target file. This all happens in the background, so you can still index into the primary shards during this process. Once that happens, we'll replay the transaction log to ensure whatever wasn't in the segments is now captured.

아래 예에서, 비어 있는 node5 와 primary를 가진 node1 이 있다. 위에서 언급했던 2가지 data 저장 메커니즘,  즉, transaction log와 Lucene segment를 기억하자. update된 cluster state를 읽은 후, shard를 초기화하라는 master의 request에 응답하는 node5 를 보여준다. node5 는 node1 에게 recovery process를 시작하도록 요청한다. 그러면, node1 은 node5 가 하고 있는 것에 대해 알고 있는지를 확인한다. 일단, 요청이 발견되면, Elasticsearch는 transaction log가 삭제되지 않도록 고정하고, shard내의 모든 data를 capture하도록 Lucene에서 snapshot을 만든다. 이렇게 하면, segment를 대상 file로 보내는 것을 시작할 수 있다. 이 모든 작업은 background에서 이루어지므로, 이 process가 진행되는 동안 여전히 primary shard에 index할 수 있다. 이런 상황이 벌어지면, segment에 없는 항목이 모두 capture되도록 transaction log를 다시 실행한다.

Now the question comes up, when do we stop? People can still index into primary shard, which means that the transaction log grows. In 1.x, we locked the trans log and from that point on all incoming requests are blocked until we finish replaying the transaction log.

문제가 있다. 언제 멈춰야 할까? 여전히 primary shard에 index할 수 있다는 것은 transaction log가 점점 증가한다는 것을 의미한다. 1.x에서는, transaction log를 다시 실행하는 것을 완료할 때까지, transaction log를 잠그고, 이 시점부터 모든 들어오는 request를 차단했다.

In 2.x/5.x, we're better. As soon as we start relocation, primary will start to send all indexing operations to the new primary(node5). Since we know when we did the lucene snapshot, and when the shard was initialized, we know what exactly to replay from the transaction log.

2.x/5.x 에서는 더 나아졌더, relocation을 시작하자마자, primary는 모든 index 연산을 새로운 primary(node5)에 보내기 시작한다. 언제 Lucene snapshot을 만들었는지 알고 있기 때문에, shard가 초기화되었을 때, transaction log에서 다시 실행해야 할 것이 무엇니지 정확히 알고 있다.

Once recovery is done, the target nodes sends notification that the shard is ready to it's master. Master processes request, copies remaining primary data, and activates shard. It can then be removed from the source and the process repeats until rebalancing is completed.

recovery가 완료되면, 대상 node는 master에서 shard가 준비되었다고 알린다. master는 요청을 처리하고, 나머지 primary data를 복사하고, shard를 활성화한다. 그런 다음, source로 부터 제거될 수 있으며, rebalancing이 완료될 때까지 process는 반복된다.

Scenario 3. Full Cluster Restart

The next scenario we'll look at is a full cluster restart. This is a scenario in which we're not dealing with active segments, but finding data locally on each node.

다음 상황은 전체 cluster 재시작이다. 활성화된 segment를 다루지 않고, 각 node애서 local data를 찾는 상황이다.

This covers things like Maintenance cycles, upgrades, anything related to planned maintenance.

여기에서는 유지보수 주기, upgrade, 예정된 유지보수와 관련된 것들을 다룬다.

Here our Master is elected, then a cluster state is created or restored from disk. Now we have a list of shard that need to be assigned. Unlike newly indexed data, these shards can't be assigned anywhere as they've previously been assigned. That means we'll have to go find the data and make sure we open the lucene indices we've previously created.

master가 선출되면, cluster state가 생성되거나 disk에서 복구된다. 이제 할당해야 할 shard 목록을 가지게 된다. 새로 index된 data와 달리, 이들 shrard는 이전에 할당된 것처럼 아무데나 할당될 수 없다. 즉, data을 찾아 이전에 생성된 Lucene index를 열어야 한다.

To do this, the master reaches out to the nodes to assign a primary and asks for a list of everything on disk. That means we physically open the segments and then respond to the master with a confirmation of a shard copy. At that point the master will decide who gets the primary. In 5.x, we introduced preferences for previous primaries(optimization).

이를 위해, master는 primary를 할당기 위하여 각 node에 disk에 있는 모든 shard의 목록을 요청한다. 즉, 물리적으로 segment를 열고 master에게 shard 복사본 확인 메세지를 보낸다. 이 시점에서 master는 primary를 가질 node를 결정한다. 5.x 에서, 이전의 primary에 대한 기본 설정을 도입했다.

Below, we can see that shard a0 on node1 had previously acted as primary, but potential exists for any valid copy to become primary. In this case, node4's shard is marked as initializing, but what's different is this time we know we're supposed to use existing data and can look at our nodes lucene indices to validate they're valid and can be opened. The Master is notified that the shard is ready, shard is assigned, and the master adds that assignment to the cluster state.

아래에서, node1 의 shard a0 가 이전에 primary로 동작했음을 알 수 있으나, 유효한 복사본이 primary가 될 가능성이 있음을 알 수 있다. 이 경우, node4 의 shard가 initializing으로 표시되지만, 차이점은 이번에는 기존 data를 사용해야 한다는 것을 알고 있고, node의 Lucene index를 살펴보고, 유효한지 열 수 있는지 확인해야 한다는 것이다. shard가 준비되고 shard가 할당되었음을 master에게 알리면, master는 cluster state에 해당 할당을 추가한다.

In order to validate the data is the same on both shards, we go to a process similar to relocation except that because all copies of the shard are restored from disk, they may already match and no shards would need to be transferred. This process is described in more detail here.

shard의 모든 복사본이 dosk에서 복구되기 때문에, 그들은 이미 일치할 수도 있고, shard 전송이 불필요하다는 점을 제외하면, 2 shard의 data가 동일한지 확인하기 위해 relocation과 유사한 process가 진행된다. 이 process는 여기에 더 자세히 설명되어 있다.

Because segments are independent lucene indices, after heavy indexing there is a strong likelihood they're going to be different on disk vs the same segments on other nodes. Some of them will use more resources than others, some of them will have nosy neighbors.

segment는 독립적인 Lucene index이므로, 많은 index 후에는 다른 node의 동일한 segment와 disk에 있는 것이 다를 가능성이 크다. 그들 중 일부는 다른 것보다 더 많은 resource를 사용할 것이다. 

Prior to 1.6, all segments had to be copied over. Because of this, recoveries prior to 1.6 were slow. We have to sync primary and replica, but can't use any local data. To deal with this we added sync_flush and sync_id. It's a way of taking a moment when no indexing is occurring, capture the information with a unique identifier, guaranteeing the data is identical between copies of the same shard. So when we go to recovery, we send the sync_id to act as a marker, and if it matches it won't copy the file over and will reuse old copies. Because segments in lucene are immutable, this can only be done for inactive shards. NOTE: below the image shows the same shard on separate nodes, the copy numbers are what change.

1.6 이전에서는 모든 segment를 복사했다. 이 때문에, 1.6 이전의 recovery는 느렸다. primary와 replica를 동기화해야 하는데, local data를 사용할 수 없었다. 이를 처리하기 위해, sync_flush와 sync_id를 추가했다. 이것은 index가 없을 때 유일한 구분자를 가진 정보를 capture하여, 동일한 shard 복사본간에 data가 동일하다는 것을 보장하는 방법이다. 따라서, recovery시에, sync_id를 marker로 보내고, 일치하면 file을 복사하지 않고 기존 복사본을 재사용한다. Lucene의 segment는 불변이므로, 비활성화된 shard에 대해서만 이 작업이 가능하다. 참고: 아래 그림은 별개 node의 동일한 shard에서 복사 번호가 변경된 것을 보여준다.

Scenario 4. Single node Loss on node3.

In the figure below, node3 is removed from the cluster, and with it, the primary copy of shard b1. The first, immediate step is that the master will promote the single replica of b1, currently on node1, to be the new primary. The health of that index, as well of the cluster, is now yellow, because there is a shard which doesn't have all of the shard copies allocated (as indicated by the user in the index definition). Hence, the master should attempt to allocate a new replica copy of that shard to one of the other remaining nodes. If node3 left because of a temporary network disruption (or a long pause of the JVM due to garbage collection), and there is no additional indexing of the shard before the disruption passes and the node returns to the cluster, replication of the shard to another node during its absence will have been a wasteful use of resources.

아래 그림에서, node3 는 shard b1 의 primary 복사본과 함께 cluster에서 제거된다. 첫번째 즉각적인 단계는 먼저, master는 현재 node1 에 있는 단일 replica b1 을 새로운 primary로 승격시킬 것이다. 모든 shard 복사본이 할당(index 정의에 사용자가 정의한 대로)되어 있지 않기 때문에, index 뿐만 아니라 cluster의 health는 이제 yellow이다. 따라서, master는 남아있는 다른 node 중 하나에 해당 shard의 새로운 replica 복사본을 할당해야 한다. 일시적인 network 중단(또는 garbage collection으로 인해 JVM이 길게 일시 정지) 때문에 node3 가 남아 있고, 중단이 계속되고 node가 cluster가 돌아오기 전에 shard의 추가 index가 없다면, 해당 shard가 없는 동안 다른 node로 shard의 replica를 생성하면 resource의 낭비가 된다.

In v1.6, a per-index setting was introduced (index.unassigned.node_left.delayed_timeout, defaults to 1m) to address this issue. When node3 leaves, re-allocation of the shard will be delayed for this period. If node3 returns before this, the shard copies will be compared, and if the primary hasn't changed in the interim, the copy on node3 will be designated as the replica. If it has changed, the shard will be re-replicated to node3.

v1.6 에서, 이 문제를 해결하기 위해, index별 설정(index.unassigned.node_left.delayed_timeout, 기본값은 1m)이 도입되었다. node3 가 제거되면, shard의 re-allocation은 이 시간동안 연기된다. node3 가 이 시간 이전에 돌아오면, shard 복사본은 비교되며, 그 사이에 primary가 변경되지 않으면 node3 의 복사본은 replica로 지정된다. 변경되면, shard는 node3 에 다시 replicate된다.

In v2.0, an improvement was added so that, if node3 returns after the delayed_timeout, for any shards on node3 that still match the primary copy(based on the sync_id marker), any replications that have been initiated will be stopped, and the copy on node3 will be designated the replica.

v2.0에서는, 이를 위해 개선사항이 추가되었다. node3가 지정한 시간 이후에 돌아왔는데, node3 의 어떤 shard가 여전히 primary 복사본과 일치(sync_id marker를 기준으로)하면, 시작된 모든 replication은 중단되고, node3 의 복사본은 replica로 지정된다.

원문 : Every shard deserves a home