Database/Elasticsearch

# ES_v5.6.8 실제 운영시 유용한 명령어 정리

skysoo1111 2019. 9. 10. 18:03

es_v5.6.8을 실제 운영 환경에서 사용하면서 많이 사용하고 또 유용하게 활용됐던 명령어를 정리하려고 한다.

 

이 글은 계속 업데이트 될 것이다.

 

[ 샤드 지연 할당 옵션 ]

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

의도적이든 아니든 어떤 이유로든 노드가 클러스터를 떠나면 다음과 같은 작업이 일어난다.

  • replica shard를 primary shard로 대체
  • 누락된 replica shard를 대체하기 위해 primary shard로 부터 replica shard를 할당
  • 클러스터 내에 남아있는 노드들에서 shard들을 균등하게 재 분배

위 과정 (shard-shuffle)은 클러스터로 하여금 많은 자원을 필요로 하며, 작업에 있어 상당한 부하를 가할 수 있다.

 

특히나 노드가 떠났다가 바로 다시 돌아온다면 그 손해는 막심하다.

=> 노드가 떠나는 순간 shard-shuffle이 일어나고, 곧이어 다시 노드가 돌아왔을 때 클러스터에서는 또다시 shard-shuffle이 발생할 것이기 때문이다.

 

따라서 ES의 Version-Up 이든 Cluster 서버의 변경이든 Node들을 재기동해야 하는 순간이 발생했을 때, 샤드 지연 할당 옵션을 사용하여 Node가 Down 되더라도 shard-shuffle이 이루어 지지 않도록 하는 것이 바람직 할 것이다.

 

[ unassigned primary 샤드 재할당 ]

POST _cluster/reroute
{ 
   "commands" :
   [ 
      { 
         "allocate_empty_primary" :
         { 
           "index" : "index_name", 
           "shard" : "shard_number", 
           "node" : "node_name", 
           "accept_data_loss" : "true" 
          }
       } 
    ]
}

ES를 쓴다는 것은 기본적으로 대용량 데이터를 다루고 있을 확률이 높은데, 이는 곧 디스크의 in/out이 많이 발생하게 된다는 것을 의미한다.

 

실제로 ES를 운영하다가 디스크에 문제가 생겼던 적이 있는데, 이 때 Data Node가 강제로 Down되면서 내부 데이터가 일부 깨졌던 적이 있다.

그리고 다시 Data Node를 기동했었는데, 깨진 데이터들 때문에 Node 자체가 기동이 안되고 난리도 아니었다.

그래도 어떻게 깨진 바이너리 파일들을 삭제하고 Data Node들을 올렸는데, 클러스터가 정상화가 안되는 것이다.

이유는 깨진 샤드들의 primary / replica 샤드 모두 할당이 되지 못하고 있었다. ( 아마 서버에서 깨진 바이너리 파일들을 삭제 했기 때문인 것 같다 )

 

서론이 길었는데 위와 같은 상황에서 사용하는 것이 allocate_empty_primary 이다.

primary / replica 모두 unassigned 상황을 유지할 때 강제로 해당 샤드를 Node에 할당하는 것이다.

단, 해당 명령어는 강제 할당된 샤드의 데이터가 다 지워지기 때문에 신중히 결정해야 할 것이다.

나같은 경우, 어차피 깨진 샤드들이었고 일부 데이터보다 서비스 정상화가 시급했기 때문에 위 명령어로 작업을 진행했었다.