7-3-4. Delaying Shard Allocation

As discussed way back in Scale Horizontally, Elasticsearch will automatically balance shards between your available nodes, both when new nodes are added and when existing nodes leave.

Scale Horizontally에서 이야기했던 것으로 돌아가 보면, 새로운 node를 추가하거나 기존의 node가 제거되면, Elasticsearch는 자동으로 활용할 수 있는 node간의 shard 균형울 맞추려 한다.

Theoretically, this is the best thing to do. We want to recover missing primaries by promoting replicas as soon as possible. We also want to make sure resources are balanced evenly across the cluster to prevent hotspots.

이론적으로 이것이 최선의 방법이다. 가능한 한 빨리 replica를 primary로 만들어 누락된 primary를 복구하려 할 것이다. 또한, hotspot을 방지하기 위해 resource가 cluster에 전체에 균등하게 분산되어야 한다.

In practice, however, immediately re-balancing can cause more problems than it solves. For example, consider this situation:

그러나 실제로는, 즉시 균형을 조정하면 해결할 수 있는 것보다 더 많은 문제가 발생할 수 있다. 예를 들어 다음과 고려해 보자.

1. Node 19 loses connectivity to your network (someone tripped on the power cable)

   node 19가 네트워크 연결이 끊어졌다.(누군가 파워 케이블에 걸려 넘어졌다)

2. Immediately, the master notices the node departure. It determines what primary shards were on Node 19 and promotes the corresponding replicas around the cluster

   master는 즉시 node의 누락을 알게된다. node 19에 있는 primary shard가 무엇인지를 알아보고, cluster에서 해당하는 replica를 승격(promote)하기로 한다.

3. After replicas have been promoted to primary, the master begins issuing recovery commands to rebuild the now-missing replicas. Nodes around the cluster fire up their NICs and start pumping shard data to each other in an attempt to get back to green health status

   replica가 primary로 승격(promote)되면, master는 현재 누락된 replica를 다시 만드는 복구 명령을 내린다. cluster의 node들은 NIC를 작동시키고, green health 상태로 돌아가기 위해, 서로에게 shard 데이터를 보내기 시작한다.

4. This process will likely trigger a small cascade of shard movement, since the cluster is now unbalanced. Unrelated shards will be moved between hosts to accomplish better balancing

   지금 cluster는 균형이 맞지 않기 때문에, 이 process는 shard 이동의 작은 시발점이 될 가능성이 높다. 관련없는 shard가 더 나은 균형을 위해 host간에 이동하게 될 것이다.

Meanwhile, the hapless admin who kicked out the power cable plugs it back in. Node 19 reboots and rejoins the cluster. Unfortunately, the node is informed that its existing data is now useless; the data being re-allocated elsewhere. So Node 19 deletes its local data and begins recovering a different set of shards from the cluster (which then causes a new minor re-balancing dance).

그러는 동안에, 파워 케이블을 뽑은 불운한 관리자는 다시 플러그를 꽂았다. node 19는 다시 부팅되고 cluster에 다시 조인되었다. 불행하게도, node는 이제 기존 데이터가 쓸모없다는 것을 알게된다. 데이터는 다른 곳에 다시 할당되었다. 그래서, node 19는 자신의 local 데이터를 삭제하고, cluster의 다른 shard 집합을 복구하기 시작한다. 그러면 새로운 조그마한 균형 조정 작업이 다시 일어난다.

If this all sounds needless and expensive, you’re right. It is, but only when you know the node will be back soon. If Node 19 was truly gone, the above procedure is exactly what we want to happen.

이 모든 것이 불필요하고 비용이 많이 소모되는 작업이다. 그러나, node가 곧 정상화될 것이라는 것을 알고 있는 경우에만 그렇다. node 19가 완전히 사라졌다면, 위의 과정은 정확히 우리가 원하는 것이다.

To help address these transient outages, Elasticsearch has the ability to delay shard allocation. This gives your cluster time to see if nodes will rejoin before starting the re-balancing dance.

이러한 일시적인 중단 문제를 해결하기 위해, elasticsearch는 shard 할당을 지연할 수 있다. 이렇게 하면, cluster가 다시 균형을 조정하는 작업을 시작하기 전에, node가 다시 join되는지를 확인할 시간을 준다.

Changing the default delayedit

By default, the cluster will wait one minute to see if the node will rejoin. If the node rejoins before the timer expires, the rejoining node will use its existing shards and no shard allocation occurs.

기본적으로, cluster는 node가 다시 join되는지를 확인하기 위해 1분을 기다린다. node가 시간 만료전에 다시 조인하면, 다시 조인하는 node는 자신의 기존 shard를 사용하고, shard 할당 작업은 발생하지 않는다.

This default time can be changed either globally, or on a per-index basis, by configuring the delayed_timeout setting:

이 기본 시간은 delayed_timeout 설정을 구성하여, 전역적으로 혹은 index별로 변경될 수 있다.

PUT /_all/_settings 
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m" 
  }
}

	index 이름 _all 을 사용하여, cluster에 있는 모든 index에 이 설정을 적용할 수 있다.
	기본 시간이 5분으로 변경되었다.

The setting is dynamic and can be changed at runtime. If you would like shards to allocate immediately instead of waiting, you can set delayed_timeout: 0.

이 설정은 동적으로 운영중에 변경될 수 있다. 기다리지 않고 즉시 shard 할당을 시작하려면 delayed_timeout: 0 으로 설정한다.

Delayed allocation won’t prevent replicas from being promoted to primaries. The cluster will still perform promotions as necessary to get the cluster back to yellowstatus. The allocation of the now-missing replicas will be the only process that is delayed

지연된 할당은 replica가 primary로 승격(promote)되는 것을 막지 않는다. cluster는 여전히yellow 상태로 돌아가기 위해 필요한 승격 작업을 수행할 것이다. 현재 누락된 replica의 할당은 지연되는 유일한 프로세스이다.

Auto-cancellation of shard relocationedit

What happens if the node comes back after the timeout expires, but before the cluster has finished moving shards around? In this case, Elasticsearch will check to see if the on-disk data matches the current "live" data in the primary shard. If the two shards are identical — meaning there have been no new documents, updates or deletes — the master will cancel the on-going rebalancing and restore the on-disk data.

시간이 만료된 후에, 그러나 cluster가 shard 이동을 끝내기 전에, node가 돌아오면 어떤 일이 일어날가? 이런 경우에는, Elasticsearch는 디스크 상의 데이터가 primary shard에 있는 현재의 "live" 데이터와 일치하는지를 확인할 것이다. 두 shard가 일치하면(새로운 그리고 update 또는 삭제된 document가 없다는 의미), master는 진행중인 균형조정 작업과 디스크상의 데이터 복구 작업을 취소할 것이다.

This is done since recovery of on-disk data will always be faster than transferring over the network, and since we can guarantee the shards are identical, the process is a win-win.

디스크상의 데이터 복구가 네트워크를 통한 전송보다 항상 더 빠르기 때문에 이 작업은 완료된다. shard가 동일하다고 보장하 수 있으므로 그 process는 양쪽 모두 이득이다.

If the shards have diverged (e.g. new documents have been indexed since the node went down), the recovery process will continue as normal. The rejoining node will delete it’s local, out-dated shards and obtain a new set.

shard가 나누어지면(예: node가 down된 후, 새로운 document가 색인되면) 복구 프로세스는 정상적으로 진행된다. 다시 조인하는 node는 자신의 local, 기간 만료된 shard를 삭제하고, 새로운 집합을 얻을 것이다.