개요

ES를 운영하다보면 버전 업그레이드나 플러그인 설치 혹은 elasticsearch.yml 변경으로 인해 노드들을 재시작 할 필요성이 있다. 상용환경에서 ES를 운영하면 클러스터에 속한 노드가 2대 이상일 가능성이 있고 이 클러스터가 상용 트래픽을 받으며 재시작을 하려면 순차적 재시작(Rolling Restart)를 수행해야 한다. 이때 유의할 점을 정리하여 포스팅 한다.

TODO 리스트

샤드 할당 비활성화

ES 입장에서는 클러스터에 속한 노드중 한대가 중지되면 그 노드에 속한 프라이머리 샤드나 레플리카 샤드를 다른 노드로 옮기려는 Shard Allocation 작업을 수행한다. 이는 클러스터의 특정 노드가 장애상황일 때 이부분에 대한 FailOver가 동작하는 과정이다. 그러나 순차적 재시작 case에서는 이 과정이 오히려 오버헤드(overhead)로 동작하기 때문에 재시작 전 클러스터의 샤드 할당 기능을 꺼두어 샤드 할당이 다시 일어나는 것을 미연에 방지한다.

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}
'

synced flush

Synced Flush를 수행하면 flush 수행후 존재하는 모든 샤드마다 유니크한 sync-id를 발급하여 샤드간의 비교(서로 동일한 샤드인지) sync-id만으로 비교가 가능하게 만든다. 링크의 문서에 의하면 샤드 비교는 recovery나 재시작 시 가장 비용(cost) 소모가 심한 작업으로 적혀있다. (따라서 필자의 생각은 이부분이 sync-id로 대체가 되면 recovery나 재시작 시 훨씬 효율적일듯 하다.)

POST _flush/synced
curl -XPOST 'localhost:9200/_flush/synced?pretty'

재시작 수행

재시작 수행은 따로 언급하지 않는다.

노드상태 보기

재시작 후 로그 파일이나 노드의 상태를 관찰하여 이상이 없는지 모니터링 한다. GET _cat/nodes curl -XGET ‘localhost:9200/_cat/nodes?pretty’

샤드 할당 활성화

샤드 할당을 다시 활성화 한다.

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"
  }
}
curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
  "transient": {
    "cluster.routing.allocation.enable": "all"
  }
}
'

클러스터 헬스 체크

노드가 정상화 되었는지 헬스체크를 통해 확인한다.

GET /_cat/health
curl -XGET 'localhost:9200/_cat/health?pretty'

버전 업그레이드시 유의 할 점

롤링 업그레이드 동안 신규 버전에 속한 프라이머리 샤드는 레플리카 샤드를 하위 버전 노드로 복사하지 않는다. 이유는 신규버전의 데이터 포맷은 하위버전과 다를수 있기 때문이다.

만약 타이밍적으로 신규버전으로 업그레이드 된 노드가 1대 뿐이라면 레플리카 샤드는 존재하지 않기 때문에 클러스터 상태는 yellow상태이다.

업그레이드가 점점 진행됨에 따라(신규버전 노드가 복수대로 바뀜에 따라) 레플리카 샤드가 생겨나므로 클러스터 상태는 다시 green으로 바뀔 것이다.

참고문서