다음 options들은 모든 REST API에 적용할 수 있다.

Pretty Results

Request의 말미에 ?pretty=true를 추가했을 때는 JSON이 예쁜 형태로 리턴된다. (단지 디버깅 목적으로만 사용하라!) 또다른 옵션으로 ?format=yaml로 설정하면 더 읽기 쉬운 yaml 형태로 결과가 리턴될 것이다.

Human Readable Output

통계는 사람에게 적합한 형태 (예를 들어 "exist_time":"1h" or "size":"1kb")와 컴퓨터에게 적합한 형태 (예를 들어 "exists_time_in_millis": 3600000 or "size_in_bytes": 1024)로 리턴된다. 사람이 읽기에 적합한 형태의 값들은 query string에 ?human=false를 추가하여 기능을 끌 수 있다. 이것은 통계 결과가 사람보다는 모니터링 툴에 의해 다루어질 때 의미가 있다. 기본적으로 human flag는 false이다.

Flat Settings

Flat_settings flag는 설정값들을 제시하는 효과가 있다. Flag_settigns값이 true일 때, 설정값들이 flat format 형태로 리턴된다.

{
  "persistent" : { },
  "transient" : {
   "discovery.zen.minimum_master_nodes" : "1"
  }
}

Flat_settings가 false일 때, 설정값들은 좀 더 사람이 읽을 수 있는 구조화된 형태로 리턴된다.

{
  "persistent" : { },
  "transient" : {
   "discovery" : {
     "zen" : {
       "minimum_master_nodes" : "1"
     }
   }
  }
}

기본적으로 flat_settings 값은 false이다.

Parameters

REST parameter들(HTTP를 사용할 때, HTTP URL에 사용되는 parameter들)은 underscore를 사용한다. (underline 사용)

Boolean Values

모든 REST API parameter들은 (request parameter와 JSON body) boolean "false"에 해당하는 값으로 false, 0, no, off를 사용할 수 있다. 그 이외 다른 값들은 모두 "true"로 간주한다. Index된 document내에서 boolean field를 다루는 것과는 아무 상관이 없다는 것에 유의하라. (단지 request parameter와 json body에서만 이렇게 다룬다는 뜻임.)

Number Values

모든 REST API는 JSON number type 뿐만 아니라 string으로 number 값을 표시하는 것을 지원한다.

Time Units

Duration이 필요할 경우, 예를 들어 timeout parameter이 경우에 duration은 밀리초를 나타내는 숫자로 표시할 수 있다. 혹은 2일의 경우 2d와 같이 표시할 수도 있다. 지원되는 단위는 다음과 같다.

y : Year

M : Month

w : Week

d : Day

h : Hour

m : Minute

s : Second

Index parameter를 가리키는 대부분의 API는 간단히 test1, test2, test3 notation을 사용하여 (혹은 모든 index에 대해서는 _all) 여러 index에 걸쳐 실행될 수 있다. 물론 wildcard도 지원한다. 예를 들어 test*와 같이 사용할 수도 있다. 또한 +기호를 추가의 의미로, -기호를 삭제의 의미로 사용할 수도 있다. 예를 들어 +test*, -test3과 같이 사용할 수 있다.

모든 multiple indices API는 다음과 같은 url에 사용되는 string parameter를 지원한다.

• Ignore_unavailable : 특정 index가 사용불가능하다면 무시하도록 한다. 존재하지 않거나 closed index에 대해서도 적용할 수 있다. 값은 true | false를 갖는다.
• Allow_no_indices : wildcard index 표현에 맞는 index 결과가 없다면 실패라고 설정한다. True나 false값을 가질 수 있다. 예를 들어, wildcard 표현으로 foo*에 해당하는 index가 없다면 이 요청에 대해서는 fail일 것이다. 이 설정은 또한 _all, *, index가 전혀 없을 때도 적용할 수 있다. 또한 Closed index에 대한 Alias에도 적용할 수 있다.

• Expand_wildcards : 어떤 종류의 구체적인 index에 대해서도 wildcard index 표현을 확장할 수 있다. 예를 들어 open이라고 사용하면, wildcard 표현은 단지 open index에 대해서만 확장된다. 반대로 closed가 사용되면 wildcard 표현은 단지 closed index에만 확장된다. 또한 모든 index에 대해서 두가지 (open, closed) 모두 사용할 수도 있다.

만약 none을 사용하면 wildcard 표현은 사용할 수 없다. All의 경우에는 모든 index에 대해서 wildcard 표현을 사용할 수 있다.

위 parameter의 기본 설정은 사용되는 api에 달려 있다.

[NOTE]

Document API (http://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html) 와 single-index alias API (http://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html) 와 같은 Single Index API는 multiple index를 지원하지 않는다.

Elasticsearch REST API는 HTTP 프토토콜과 JSON Data format을 이용한다.

이 chapter에서 언급된 convention은 별도로 기술되어 있지 않는 한, REST API를 통해 적용할 수 있다.

• Multiple Indices

• Common Options

이 섹션에서는 application을 elasticsearch의 다른 버전으로 migration을 할 필요가 있을 때, 변경사항에 대해서 논의한다.

일반적으로 다음 Rule을 따른다.

• Major version이 다른 제품으로 migration - 예를 들어 1.x에서 2.x로 - 전체 cluster 재시작 필요 (restart upgrade)
• Minor version이 다른 제품으로 migration - 예를 들어 1.x에서 1.y로 - 한번에 하나의 node upgrade 수행 (rolling upgrade)

더 자세한 내용은 07. Upgrading 섹션을 참고하라.

Rolling upgrade process

Rolling upgrade는 ES cluster에서 한번에 하나의 노드만 upgrade되게 한다. 따라서 end user는 다운타임을 느낄 수 없다. 동일 cluster에서 upgrade를 지원하는 기간을 넘어서 더 이상 지원하지 않는 여러 버전의 elasticsearch를 실행하는 것, 특히 더 최근 버전으로 이전 버전에 대한 shard replication을 구성하는 것은 동작하지 않는다.

1.0 release 이후 minor or maintenance release에서, rolling upgrade가 지원된다. Rolling upgrade를 수행하기 위해서는,

• Disable Shard reallocation(optional). Cluster shutdown 이후 작업이 더 빠르게 수행하게 한다. 이 단계를 수행하지 않으면, 노드들은 startup 시점에 각각 shard를 즉시 복제하려고 할 것이다. 그리고 그것은 IO에 많은 시간을 써버린다. Shard reallocation을 disable하면 노드들은 rebalance를 시도하지 않고, 각각의 index만을 그대로 가지고 cluster에 참여한다. Startup이 완료되면 백그라운드에서 reallocation이 일어난다.

Elasticsearch 1.0 이후 버전에서 다음과 같이 실행한다.

curl -XPUT localhost:9200/_cluster/settings -d '{
               "transient" : {
                  "cluster.routing.allocation.enable" : "none"
               }
       }'

• Cluster내에서 하나의 노드를 shutdown한다.

curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'

• 남아 있는 실행 중인 노드들에서 모든 shard들이 완전히 reallocate되었는지 확인한다.

• 정지된 노드의 upgrade를 실행한다. Elastic.co로부터 zip 파일이나 tarball을 사용하여 upgrade를 수행한다.
• 새로운 디렉토리에 zip이나 tarball을 압축해제한다. 일반적으로 현재 설치된 elasticsearch와 동일한 volume에 위치시킨다. 현재 설치된 폴더를 덮어쓰면 안 된다. 왜냐하면 다운로드 받은 압축파일에는 default elasticsearch.yml 파일을 포함하고 있어서 현재 설정을 덮어쓰기 때문이다.
• 이전 Elasticsearch 설치 폴더에서 설정 파일을 복사하여 새로운 Elasticsearch의 config directory에 넣는다. 필요하면 이전 Elasticsearch 설치 버전의 data directory를 다른 곳으로 옮긴다. 만약 tarball 압축해제 폴더 내에 data file이 없으면 다른 곳으로 옮길 필요 없다.
• 하나의 버전에서 다른 버전으로 옮기는 가장 간단한 해결책은 현재 실행중인 버전을 나타내는 elasticsearch의 sympolic link를 가지고 하는 것이다. 이 link는 쉽게 가장 최근 버전을 나타내도록 update할 수 있고, 안정적으로 접근할 수 있게 한다. 만약 link를 사용하고 있다면 이 link를 update하라.

• .deb나 .rpm package를 사용하여 upgrade하기 위해서는
• 새로운 패키지를 설치하기 위해 rpm이나 dpkg를 이용하라. 모든 파일들은 적합한 location에 위치하게 되고, config 파일은 덮어쓰면 안된다.

• Upgrade된 노드를 시작하라. Cluster에 참여하는지 확인한다.

• Shard reallocation을 재활성화한다. (re-enable)

curl -XPUT localhost:9200/_cluster/settings -d '{
               "transient" : {
                  "cluster.routing.allocation.enable" : "all"
               }
       }'

• 모든 노드에 모든 shard가 적장하게 할당되었는지 확인한다. Balancing은 약간의 시간이 걸린다.

• 모든 남아 있는 노드들에 대해서 이 과정을 반복한다.

[IMPORTANT]

Rolling upgrade 하는 동안, 더 높은 버전의 노드에 할당된 primary shard는 절대로 하위 버전의 노드에 replicas를 할당하지 않는다. 왜냐하면 새로운 버전은 이전 버전에서 이해할 수 없는 다른 데이터 형태를 갖고 있기 때문이다.

상위 버전의 노드에서 다른 노드로 replica르 ㄹ할당하는 것이 가능하지 않다면, 예를 들어 cluster내에 하위 버전의 노드가 하나밖에 없을 경우, replica shard는 할당되지 않고 남아 있게 된다. 따라서 cluster health는 yellow 상태이다. Cluster내에 다른 상위 버전의 노드가 참여하는 즉시 replica는 할당되고 cluster의 상태는 green으로 변경될 것이다.

서비스가 실행되고 있는 동안에 새로운 소프트웨어가 설치되어 upgrade를 수행하는 것도 가능하다. 이것은 upgrade된 노드에서 service가 정지하자마자 새로운 버전을 실행하여 downtime을 감소시킨다. 이것은 새로운 버전을 별도의 디렉토리에 설치하고, symbolic link method를 이용하면 가능하다. 이 과정을 테스트 하기 위해서는 먼저 site-specific 설정 데이터와 production index들을 upgrade 과정 중에 덮어쓰지 않아야 한다.

Cluster restart upgrade process

Elasticsearch의 1.0버전 이전과 이후는 서로 호환되지 않는다. 따라서 rolling upgrade는 불가능하다. 1.0 이전 버전 시스템에서 1.0 이후버전 시스템으로 upgrade하기 위해서는 cluster 전체를 stop하고 start하는 것이 필요하다. 이러한 upgrade를 수행하기 위해서는

• Disable Shard reallocation (optional). Cluster shutdown이후 더 빠르게 시작할 수 있다. 이 작업을 수행하지 않으면, 노드들은 시작시점에 즉시 서로 shard를 복제하려고 시작할 것이다. 그리고 이 과정에서 낭비되는 IO로 많은 시간을 보낸다. Shard reallocation이 disable되면, 노드들은 자신의 index들만 가지고 cluster에 참여하고 rebalance를 시도하지 않는다. Startup이 완료되면, reallocation이 백그라운드에서 실행될 것이다.

1.0 이전 버전에서 syntax는 다음과 같다.

curl -XPUT localhost:9200/_cluster/settings -d '{
               "persistent" : {
              "cluster.routing.allocation.disable_allocation" : true
               }
       }'

• Upgrade할 첫번째 노드에 압축 파일을 해제하고 위 Rolling Upgrade Section에서 설명한 대로 새로운 package를 설치한다. 모든 노드에 대해서 반복한다.

• 모든 노드에 elasticsearch upgrade가 완료되면 각 노드를 개별적으로 실행하여 cluster를 시작한다.
• Master 자격이 있는 노드를 먼저 시작한다. Quorum 기반 master가 선출되었는지 확인하라.
• Data 노드를 실행하고, client 노드들을 시작하라. Cluster에 성공적으로 참여했는지 확인하라.

• Cluster가 실행되고, yellow 상태에 이르면 shard reallocation을 할 수 있다.

1.0 이후 버전에서는 다음 syntax로 실행할 수 있다.

curl -XPUT localhost:9200/_cluster/settings -d '{
               "persistent" : {
              "cluster.routing.allocation.disable_allocation": false,
              "cluster.routing.allocation.enable" : "all"
               }
       }'

이 cluster upgrade는 cluster 서비스를 종료하기 전에 새로운 소프트웨어를 설치하여 간단하게 수행할 수 있다. 이 작업이 완료되면 restart를 시작하기 전에 production data와 설정 파일들이 덮어써지지는 않았는지 반드시 확인하는 테스트가 수행되어야 한다.