[6] 클러스터 운영

클러스터 설정

GET _cluster/settings

-persistent: 클러스터를 full restart 전체 재시작해도 유지된다.

path.data 내 파일로 저장됨

-transient: 전체 재시작하면 내용이 사라진다.

-설정 적용 우선순위: transient > persistent > config/elasticsearch.yml

-지정한 설정 제거하려면 null 로 지정해주기

-공식 가이드는 transient 는 사라져서 추천 안 함

_cat API

‘compact and aligned text’

GET _cat/health?v

GET _cat/health?format=json

[
  {
    "epoch" : "1701005989",
    "timestamp" : "13:39:49",
    "cluster" : "baemin-search-beta",
    "status" : "green",
    "node.total" : "6",
    "node.data" : "2",
    "shards" : "58",
    "pri" : "35",
    "relo" : "0",
    "init" : "0",
    "unassign" : "0",
    "pending_tasks" : "0",
    "max_task_wait_time" : "-",
    "active_shards_percent" : "100.0%"
  }
]

yellow: 프라이머리만 할당된 상태

red: 적어도 하나의 프라이머리 샤드 미할당 상태

GET _cat/nodes?v

노드 정보

ip            heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
10.81.108.126           14          94   0    0.00    0.00     0.00 m         -      master-a
10.81.114.55            26          44   0    0.10    0.13     0.13 d         -      data-ip-10-81-114-55
10.81.10.59             59          93   0    0.00    0.00     0.00 m         *      master-b
10.81.12.226            70          92   0    0.00    0.02     0.00 -         -      client-ip-10-81-12-226
10.81.12.41             31          94   0    0.00    0.00     0.00 m         -      master-c
10.81.11.142            50          45   0    0.02    0.03     0.00 d         -      data-ip-10-81-11-142

GET _cat/shards?v

샤드 정보

index                   shard prirep state      docs   store ip           node
shop-menu-20231116-1    1     r      STARTED  370489    64mb 10.81.11.142 data-ip-10-81-11-142
shop-menu-20231116-1    1     p      STARTED  370489  57.8mb 10.81.114.55 data-ip-10-81-114-55
shop-menu-20231116-1    3     r      STARTED  365515    69mb 10.81.11.142 data-ip-10-81-11-142

GET _cat/segments?v

루씬 세그먼트 조회

index                   shard prirep ip           segment generation docs.count docs.deleted     size size.memory committed searchable version compound
shop-info-20231124-1    0     p      10.81.11.142 _3pt          4817       9958         7999   12.6mb       70359 true      true       8.0.0   false
shop-info-20231124-1    0     p      10.81.11.142 _3qd          4837         39            0   39.5kb        9687 true      true       8.0.0   true

GET _cat/recovery?v

샤드 복구 작업 조회

GET _cat/allocation?v

샤드 할당 조회

shards disk.indices disk.used disk.avail disk.total disk.percent host         ip           node
    29       10.1gb    18.9gb    480.9gb    499.9gb            3 10.81.11.142 10.81.11.142 data-ip-10-81-11-142
    29        9.9gb    18.8gb    481.1gb    499.9gb            3 10.81.114.55 10.81.114.55 data-ip-10-81-114-55

GET _cat/thread_pool?v

스레드풀 조회

node_name              name                active queue rejected
master-a               analyze                  0     0        0
master-a               ccr                      0     0        0

GET _cat/master?v

마스터 조회

id                     host        ip          node
bqUPeNADT-acp_PdhkdQkw 10.81.10.59 10.81.10.59 master-b

인덱스 운영 가이드

템플릿과 명시정 매핑 활용

-안하면 우리가 모르는 상태에서 신규 필드가 추가될 수 있으므로 인덱스 템플릿, 동적 템플링 활용하자

라우팅 활용

-사전 설계와 정책이 필요하지만 성능이 좋아진다.

-mappings 에 _routing:required:true 로 설정하면 라우팅을 강제할 수 있다.

시계열 인덱스명

-인덱스명에 access-log-20220101 처럼 시간표현이 들어가면

오래된 데이터 백업하고 삭제하는게 편하다.
데이터 티어 구조 설계에 좋다
템플릿 설정할 때도 좋다. 인덱스 템플릿에 맞게 인덱스가 생성되게 할 수 있으니까
성능에도 이득이다. 오래된 인덱스는 새 데이터가 색인되지 않아 내용이 고정된 상태가 된다. 그러면 새 세그먼트 병합을 할 필요없으므로 성능 이득이 있고 세그먼트가 고정되면 검색 시 캐시 적중율도 더 높아진다.

alias

-is_write_index:true : 업데이트, 삭제 등 쓰기 작업 가능

-여러 인덱스를 alias 로 설정하면

단건 문서 조회는 못 한다.
is_write_index:true 설정 한 인덱스만 업데이트 한다. 없으면 쓰기 못 함

rollover

POST [alias or 데이터스트림명]/_rollover

-샤드 너무 커지면 새 인덱스 생성하고 alias 로 묶고 새 인덱스에 is_write_true 옮겨줌

-인덱스명 패턴은 ^.*-\d+$ 이다 (ex. index-2022)

인덱스명에 날짜 넣기

PUT %3ctest-index-%7bnow%2fd%7d-000001%3e

GET %3ctest-index-%7bnow%2fd%7d-000001%3e

{
  "test-index-2023.11.26-000001" : {
    "aliases" : { },
    "mappings" : { },
    "settings" : {
      "index" : {
        "routing" : {
          "allocation" : {
            "include" : {
              "_tier_preference" : "data_content"
            }
          }
        },
        "number_of_shards" : "1",
        "provided_name" : "<test-index-{now/d}-000001>",
        "creation_date" : "1701040836843",
        "number_of_replicas" : "1",
        "uuid" : "gfg5AiNfQ_Cde6KDiA-lUw",
        "version" : {
          "created" : "7170699"
        }
      }
    }
  }
}

이 인덱스를 alias 로 묶고 롤오버하면 provided_name 으로 새 인덱스를 생성한다.

직접 보자!

alias 지정

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "test-index-2023.11.26-000001",
        "alias": "alias1"
      }
    }
  ]
}

롤오버 수행

POST alias1/_rollover

alias 확인

GET _alias/alias1

{
  "test-index-2023.11.26-000002" : {
    "aliases" : {
      "alias1" : { }
    }
  }
}

000002 인덱스가 새로 생성되고 alias1 이 옮겨갔다

롤오버할 인덱스명 직접 지정하기

POST [alias]/_rollover/[새인덱스명]

데이터 스트림

내부적으로 여러 인덱스들로 구성되어 있다. 검색 요청은 모든 인덱스 대상으로 하고, 색인 요청을 제일 최근에 생성된 단일 인덱스에 문서가 들어간다.

(여처 인덱스 alias 묶고 is_write_true 인덱스 하나 둔 구성과 비슷)

그럼 alias 와 데이터 스트림의 차이점

데이터스트림 뒷받침 인덱스(backing index) 는 hidden 이고, 이름 패턴 .ds-<DS명>-<날짜>-<세대수> 로 고정이고 명시적으로 새 인덱스명 지정 불가
반드시 인덱스 템플릿으로 생성해야 한다.
문서 추가는 가능하지만 업데이트는 불가하다.
@timestamp 필드 포함된 문서만 취급한다.

데이터스트림 생성하기

ILM 생성하기
/_component_template 으로 @timestamp 필드 추가, index.lifecycle.name 에 ILM명 지정하기
데이터스트림용 index template 생성

PUT _index_template/ds-template
{
  "data_stream": {},
  "index_patterns": ["ds"],
  "composed_of": ["timestamp", "ilm_settings"]
}

"data_stream": {} 넣어줘야 한다.

데이터스트림 생성

PUT _data_stream/my-ds

데이터스트림 문서 추가하기

PUT my-ds/_create/1

데이터스트림 문서 조회하기

GET my-ds/_search

데이터스트림 문서 업데이트하기

update_by_query, delete_by_query 로 할 수는 있음

인덱스명 알아내면 _id 로 삭제도 가능함

※ 데이터스트림은 장애 발생시 데이터를 재처리하기 쉽지 않다. 그래서 그 시간대 데이터 버려도 큰 문제가 안 되는 경우에 사용하기 좋다.

reindex

-버전 충돌 일어나면 거기까지만 진행되고 종료된다. 건너뛰고 계속하고 싶으면 conflicts:proceed 해준다. (기본값: abort)

-_source 활성화돼야 한다. synthetic source 도 괜춘

-wait_for_completion:false 로 비동기로 실행하고 task API 로 확인 가능

- use case: ingest pipleline 통과한 인덱스 생성, script, 검색 쿼리, max_docs 문서 수 지정, 특정 필드만, 여러 인덱스 합치기

shrink

POST [현재인덱스]/_shrink/[새인덱스]

PUT [현재인덱스]/_shrink/[새인덱스] {”settings”: ...}

-샤드 개수 줄이면서 인덱스 새로 생성한다.

그럼 shrink 랑 reindex 차이?

reindex: 새 인덱스에 문서를 새로 색인한다.
shrink: 기존 인덱스의 루씬 세그먼트를 새 인덱스로 하드 링크한다. 그래서 샤드 개수 제외한 인덱스 설정과 매핑이 유지된다.
- 그래서 제약이 많다. index.blocks.write:true 설정해 read-only 여야 하고, 한 노드가 모든 샤드를 보유하고 있어야 하고, green 상태여야 하고, 시스템이 하드 링크를 지원해야 하고, 샤드 데이터 경로가 같아야 하고, 새 인덱스 샤드 개수(ex.4,2,1)는 원본 인덱스 샤드 개수(ex.8)의 약수여야 한다.

사용 시나리오

실무에서는 안전하게 reindex 를 더 많이 씀
ILM 에서 hot → warm phase 로 넘어갈 때 쓸 수도 있다.

split

POST [현재인덱스]/_split/[새인덱스]

PUT [현재인덱스]/_split/[새인덱스] {”settings”: ...}

shrink 와 반대로 샤드 개수를 늘리면서 인덱스를 새오 생성한다. 세그먼트를 하드 링크하는 방식으로 진행된다.

제약 사항: index.number_of_routing_shards(ex. 4,8,16) 를 기존 인덱스 index.number_of_shards(ex. 2) 의 배수이자 index.number_of_routing_shards(ex. 16) 의 약수로 지정해야 한다. read-only, green 여야 한다.
실무에서는 많이 쓰지 않음

Why doesn’t Elasticsearch support incremental resharding?

다중 필드

시나리오

서비스가 이미 운영중이고 매핑도 확정되었는데 특정 필드를 다른 방법으로 색인해야 할 때

한 번 지정한 매핑을 변경할 순 없지만 추가는 가능하다.

다중 필드 적용후 들어온 이후부터 데이터에 새로 색인된다.

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "nori_analyzer": {
          "tokenizer": "nori_tokenizer"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "message": {
        "type": "text",
        "fields": {
          "english": {
            "type": "text",
            "analyzer": "english"
          },
          "nori": {
            "type": "text",
            "analyzer": "nori_analyzer"
          }
        }
      }
    }
  }
}

타입이 계속 변경되는 데이터라면

object 타입으로 지정하도 enabled:false 로 지정한다.

대신 색인, 검색은 안됨.

루씬 텀 길이 제약

최대 텀 길이는 32766 바이트다.

→ UTF-8 쓰면 나누기 4 해서 최대 8191 글자

ignore_above를 설정하면 문자 수가 ex. 20보다 긴 데이터는 역색인하지 않는다.

근데 text 타입은 안먹혀서, 애널라이저를 바꾸거나 enabled:false 를 고려해야 한다.

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "message": {
        "type": "keyword",
        "ignore_above": 20 
      }
    }
  }
}

대량 색인이 필요할 때 색인 속도 높이기

Tune for indexing speed

PUT my-index/_settings
{
  "refresh_interval": "-1",
  "number_of_replicas": 0
}

샤드 설정 가이드

샤드 크기, 개수 조정

샤드 하나의 크기가 20~40GB 가 적절하다고 가이드 하지만, 실제론 20GB 만 돼도 느리다고 한다.

샤드 크기 확인하기: GET _cat/shards?v&s=store:desc

index                   shard prirep state      docs   store ip           node
shop-menu-20231121      4     p      STARTED 6996491   4.3gb 100.1.14.134 data-ip-100-1-14-134
shop-menu-20231121      4     r      STARTED 6996491   4.3gb 100.1.13.236 data-ip-100-1-13-236

32GB 기준으로 샤드 640개

힙 1GB 당 샤드 20개 이하가 빡빡하지만 기준으로 삼아라

샤드 개수 확인하기: GET _cat/health?v

epoch      timestamp cluster            status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1701124852 22:40:52  baemin-search-prod green          43        24    318  29    0    0        0             0                  -                100.0%

샤드 할당 정보 확인: GET _cat/allocation?v

shards disk.indices disk.used disk.avail disk.total disk.percent host         ip           node
    13       18.6gb    32.8gb    467.1gb    499.9gb            6 100.1.58.205 100.1.58.205 data-ip-100-1-58-205
    13       17.6gb    31.1gb    468.8gb    499.9gb            6 100.1.18.77  100.1.18.77  data-ip-100-1-18-7

※ 샤드 수가 너무 많으면 - 루씬 인덱스가 많이 떠서 힙 메모리를 많이 차지함

※ 샤드 크기가 너무 크면 - 샤드 복구, 레플리카 생성에 많은 시간이 소요돼 안전성이 낮아짐

모든 노드에 샤드가 고르게 분배됐는지 확인

이상적: number_of_shards 를 노드 개수의 배수로

롤링 리스타트 - 하나씩 내리고 재기동

[[ES 재기동하기 - 노드 안전하게 kill 하기]]

- 재기동 하는 경우: 동적으로 불가능한 설정 적용, 플러그인 설치/삭제, 버전 업그레이드, 장애 대응

- 단계: 샤드 할당 비활성화 → flush → 노드 재기동 → 샤드 할당 활성화 → green 까지 대기

(1) 샤드 할당 비활성화

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

primaries: 프라이머리 샤드 할당만 허용한다.

(+ all, new_primaries, none)

→ 데이터 노드에만 하면 된다. 다른 노드는 불필요한 샤드 할당 없음

(2) flush

POST _flush

translog 비우고 디스크에 기록한다. 샤드 복구 시간도 빠르게 할 수 있다.

(3) 재기동

kill 하고 재기동

(4) 샤드 할당 활성화

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

스냅샷과 복구

스냅샷: 동작중인 인덱스 백업. 데이터 디렉토리만 복사하는 백업을 복구하는 방식은 공식적으로 지원하지 않고 정합성 깨질 수 있기 때문에 스냅샷으로 백업하는게 좋다.

스냅샷 저장소 등록

nfs 같은 공유 파일 시스템 지원. S3, HDFS 는 플러그인 설치해야 한다.

PUT _snapshot/[저장소이름]
{
  "type": "fs",
  "settings": {
    "location": "/my/nfs/mount/path"
  }
}

location 은 elasticsearch.yml 에 path.repo 설정으로 등록해야 한다.

elasticsearch.yml

path: 
  repo:
  - /my/nfs/mount/path

source 전용 저장소

색인이나 doc_values 저장 안 하고 _source 만 저장해 최소 크기로 스냅샷 찍을 수 있음

PUT _snapshot/[저장소이름]
{
  "type": "source",
  "settings": {
    "delegat_type": "fs",
    "location": "/my/nfs/mount/path"
  }
}

색인 정보 없기 때문에 복구한 후 reindex 로 재색인 해야 한다.

※ 스냅샷은 증분 백업 방식으로 동작하며 이를 위해 스냅샷 작업 시작할 때 저장소 내 다른 모든 스냅샷 정보를 메모리로 올리기 때문에 스냅샷은 적게 유지 해야 한다.

스냅샷 생성하기

PUT _snapshot/[저장소이름]/[스냅샷이름]?wait_for_completion=false
{"indicies": "my-202101*", "my-202102*"}

wait_for_completion=false 로 비동기 요청할 수 있지만 tasks 에 등록하진 않는다.

진행상황은 조회 API 로 확인한다.

GET _snapshot/[저장소이름]/[스냅샷이름/_all]

전역 상태와 feautre

GET _features

{
"features": [
{
"name": "searchable_snapshots",
"description": "Manages caches and configuration for searchable snapshots"
},
{
"name": "watcher",
"description": "Manages Watch definitions and state"
},...
}

내부 시스템용 인덱스

스냅샷 찍을 때 include_global_state 설정하면 내부 인덱스도 같이 생성된다.

스냅샷 조회/삭제

GET _snapshot/[저장소이름]/[스냅샷이름]/_status

DELETE _snapshot/[저장소이름]/[스냅샷이름]/_status

삭제 요청하면 증분 백업이라 스냅샷에 포함된 파일이 다른 스냅샷에 포함되는지 파악하고 영향 안 주는 스냅샷만 삭제 된다.

스냅샷 복구

POST _snapshot/[저장소이름]/[스냅샷이름]/_restore
{
  "indicies": "my-202101*",
  "include_global_state": false,
  "feature_state": ["kibana"]
}

include_global_state:false 로 전역 상태 복구 안 하고 원하는 feature 만 지정할 수 있다. true 로 하면 persistent 클러스터 설정, 인덱스 템플릿, 인제스트 파이프라인, ILM 설정을 완전히 삭제하고 대체한다.

※ 메이저 버전이 둘 이산 차이나는 스냅샷은 복구가 불가능하다. (ex.버전5에서 생성한 인덱스 스냅샷을 7에서 복구 못함) 하려면 6버전 임시 클러스터에서 복구하고 옮겨야 한다.

SLM(Snapshot Lifecycle Management)

ILM 처럼 스냅샷도 생명주기로 관리할 수 있고 키바나 UI 로도 제어할 수 있다.

명시적으로 세그먼트 병합하기

POST [인덱스명]/_forcemerge?max_num_segments=1

더 이상 색인되지 않는 인덱스에 force merge 해서 단일 세그먼트로 유지하는 것이 좋다.

비용이 큰 작업이라 한산한 시간에 하는 게 좋다.

샤드 할당 필터링

샤드 할당할 노드를 수동으로 지정할 수 있다. 노드에 속성을 지정하고 그 속성을 통해 샤드를 특정 노드에 할당하면 된다.

속성 지정하고 확인

elasticsearch.yml

node.attr.my_rack_id: rack_one

혹은

ES 띄울 때 지정

bin/elasticsearch -Enode.attr.my_rack_id=rack_one

확인

GET _cat/nodeattrs?v

node host ip attr value

master-a 10.81.108.126 10.81.108.126 xpack.installed true

data-ip-10-81-114-55 10.81.114.55 10.81.114.55 xpack.installed true

클러스터에게 속성 알려주기

PUT _cluster/settings
{"persistent": {"cluster.routing.allocation.awareness.attributes": "my_rack_id"}}

특성 속성 가진 노드에게 샤드 할당 제어

PUT _cluster/settings
{"persistent": {"cluster.routing.allocation.include.my_rack_id": “rack_one,rack_two"}}

rack_one,rack_two 둘 중 하나 이상 가진 노드에 할당

include 대신 require, exclude 가능

내장 속성 _name, _host_ip, _ publish_ip, _ip, _id 도 있다.

사용 시나리오

특정 노드를 클러스터에서 제외할 때 강제로 빼고 yellow → green 기다려도 되지만 샤드 이동시켜버리고 안정적으로 제거할 수도 있다.

PUT _cluster/settings
{"persistent": {"cluster.routing.allocation.exclude._ip": “10.0.0.1"}}

인덱스 단위로 샤드 할당 지정할 수도 있다.

PUT _cluster/settings
{"persistent": {"index.routing.allocation.include.my_rack_id": “rack_one,rack_two"}}

데이터 티어 구조

nodes.roles

data_content: 시계열 데이터가 아닌 데이터를 담는 노드. 높은 읽기, 쓰기 성능 요구 (디폴트 역할)
- - optimized for query performance — they prioritize processing power over IO throughput so they can process complex searches and aggregations and return results quickly. (연산이 많은 역할로 지정한거라 IO 보다 cpu 높은 서버에 놓는게 좋다)
data_hot: 시계열 데이터 중 가장 최근 데이터. 업데이트 빈번
data_warm: hot 보다 덜 최근 시계열 데이터. 업데이트 수행할 수는 있음
data_cold: 더 이상 업데이트 수행하지 않는 읽기 전용 노드
data_frozen: 인덱스를 검색 가능한 스냅샷으로 변환 (엔터프라이즈 등급만 가능)

인덱스 생명 주기 (ILM)

인덱스를 hot-warm-cold-frozen-delete 페이즈로 구분

hot: 업데이트와 읽기가 가장 많음
warm: 업데이트는 안 들어오지만 읽기 작업은 들어옴
cold: 업데이트 없음, 읽기 작업도 가끔씩만 들어옴. 검색은 돼야 하나 속도 느려도 됨
frozen: 업데이트 없음, 읽기 작업 거의 안 들어옴. 검색은 돼야 하나 속도 상당히 느려도 됨
delete: 인덱스 삭제해도 되는 상태

다음 시나리오 가능

hot 페이즈에서 매일 롤오버 수행하고 샤드 크기가 8GB 넘으몬 자동으로 롤오버 수행
생성된지 3일 후에 warm 페이즈로 전환

-ILM 은 indices.lifecycle.poll_interval 에 지정된 주기(디폴트 10분) 로 인덱스 상태 확인한다.

페이즈 액션 종류

-롤오버, 읽기전용으로 만들기, 세그먼트 병합, shrink, 인덱스 복구 우선순위 변경, 인덱스 샤드 할당 필터링, 다른 노드로 인덱스 마이그레이션, 동결, 스냅샷 대기, 삭제

서킷 브레이커

-요청이 어느정도 메모리 사용할지 예상하는 방법과 현재 메모리를 체크해 과도한 요청이라 판단되면 거부한다.

-차단했다고 알아서 재시도를 해주진 않는다. 처리 책임은 기본적으로 클라이언트에게 있다.

종류

필드 데이터 서킷 브레이커: fielddata 가 메모리에 올라갈 때 얼마만큼의 메모리를 사용할지 예상한다. indices.breaker.fielddata.limit (기본 40%) 이 넘는 요청은 거부한다.
요청 서킷 브레이커: 요청 하나의 데이터 구조가 메모리 얼마나 사용하는지 계산한다. indices.breaker.request.limit (기본 60%)
실행 중 요청 (in-flight request) 서킷 브레이커: transport 나 http 로 들어오는 요청의 길이, 요청 객체 생성에 필요한 메모리를 계산한다. network.breaker.inflight_requests.limit (기본 100%)

부모 서킷 브레이커: 전체 메모리 사용량, 자식 서킷 브레이커 산정한 메모리 사용량을 체크한다. indices.breaker.total.limit (기본 70%)

PUT /_cluster/settings
{
"transient": {
"indices": {"breaker": {"fielddata.limit": "60%", "request.limit": "70%", "total.limit": "90%"}},
"network": {"breaker": {"inflight_requests.limit" "95%"}}
}
}

스크립트 컴파일 서킷 브레이커: 스크립트 컴파일 수를 제한한다. 메모리 기반이 아니라.
- ```
PUT _cluster/settings
{ "transient": {"script":{"max_compilations_rate": "50/5m"}}}
```

slow log 설정

걸린 시간은 샤드 레벨에서 측정한 시간이다.

검색 요청에서 느린 쿼리 확인

PUT /my-index-000001/_settings
{
  "index.search.slowlog.threshold.query.warn": "10s",
  "index.search.slowlog.threshold.query.info": "5s",
  "index.search.slowlog.threshold.query.debug": "2s",
  "index.search.slowlog.threshold.query.trace": "500ms",
  "index.search.slowlog.threshold.fetch.warn": "1s",
  "index.search.slowlog.threshold.fetch.info": "800ms",
  "index.search.slowlog.threshold.fetch.debug": "500ms",
  "index.search.slowlog.threshold.fetch.trace": "200ms"
}

색인할 때 느린 문서 확인

PUT /my-index-000001/_settings
{
  "index.indexing.slowlog.threshold.index.warn": "10s",
  "index.indexing.slowlog.threshold.index.info": "5s",
  "index.indexing.slowlog.threshold.index.debug": "2s",
  "index.indexing.slowlog.threshold.index.trace": "500ms",
  "index.indexing.slowlog.source": "1000"
}

버전 업그레이드

재기동 방법

롤링 업그레이드: 노드 한 대씩 종료하고 버전 올리고 재기동
- 한 메이전 버전 올리는 정도는 롤링으로 가능하다.
- 마스터 아닌 노드부터 업그레이드하기. 상위 버전 노드가 하위 버전 마스터 후보노드에 붙을 수 있지만 반대는 그렇지 않을 수 있다.
풀 리스타트 업그레이드: 클러스터 완전히 종료하고 전체 노드 버전 올리고 일괄 재기동

업그레이드 점검하기

키바나에서 7.11 버전 부터 무료로 점검가능

인덱스 생성 버전이 두 버전 이하는 아닌지 체크

GET shop-menu/_settings?human

_source 내용 백업이 가장 안전
클라이언트 호환되는지 점검
플러그인 호환 점검 (보통 버전에 종속적이라 재빌드)

레퍼런스

엘라스틱서치 바이블 6장

저작자표시 비영리 변경금지

'SearchDeveloper > 엘라스틱서치 바이블' 카테고리의 다른 글

[8] 엘라스틱서치의 내부 동작 상세 (0)	2024.03.31
[7] 운영 도중 발생하는 장애 대응 (0)	2024.03.31
[5] 서비스 환경에 클러스터 구성 (0)	2024.03.31
[4] 데이터 다루기 (0)	2024.03.31
[3] 인덱스 설계 (1)	2024.01.14