Delete By Query를 이용하여 문서를 삭제 하던 중 아래와 같은 에러가 발생

elasticsearch version : 7.6.2

{
  "error": {
    "root_cause": [
      {
        "type": "exception",
        "reason": "Trying to create too many scroll contexts. Must be less than or equal to: [500]. This limit can be set by changing the [search.max_open_scroll_context] setting."
      }
    ],
    "type": "search_phase_execution_exception",
    "reason": "Partial shards failure",
    "phase": "query",
    "grouped": true,
    "failed_shards": [
      {
        "shard": 2,
        "index": "product",
        "node": "vot-mThQS46c5aBtTd1RwA",
        "reason": {
          "type": "exception",
          "reason": "Trying to create too many scroll contexts. Must be less than or equal to: [500]. This limit can be set by changing the [search.max_open_scroll_context] setting."
        }
      }
    ]
  },
  "status": 500
}

오류 원인

정확한 원인은 알 수 없으나 github elasticsearch 에 버그로 리포팅된 issue를 발견 github
문제점이 elasticsearch 데몬을 기동 하자 마자 발생하는게 아니라 정상 동작 후 어느 순간에 도달하면 발생하는 버그라 elasticsearch에 delete by query 를 동작하는 배치 코드에는 문제가 없는데 해당 코드가 문제인 줄 알고 삽질를 유발함

해결방법

1. elasticsearch ver. 7.7.0 이상으로 업그레이드
2. elasticsearch 의 search.max_open_scroll_context 값을 int.MAX_VALUE 으로 변경

   // [step 1] cluster update api를 이용하여 바로 반영
   PUT /_cluster/settings
   {
     "persistent" : {
    "search.max_open_scroll_context": 2147483647
     },
     "transient": {
    "search.max_open_scroll_context": 2147483647
     }
   }
   

{
  "error": {
    "root_cause": [
      {
        "type": "too_many_buckets_exception",
        "reason": "Trying to create too many buckets. Must be less than or equal to: [10000] but was [10001]. This limit can be set by changing the [search.max_buckets] cluster level setting.",
        "max_buckets": 10000
      }
    ]
  }
}

원인은 elasticsearch 에 max_buckets default 값이 10,000개로 그 이상 bucket이 집계에 사용될 경우 위와 같이 에러를 발생
해결방법은 2가지로 Cluster update settings API를 이용하는 방법과 설정파일(elasticsearch.yml)에 설정하는 방법이 존재
첫번째 방법은 elasticsearch에 바로 반영이 가능 하나 elasticsearch 재기동시 초기화 되는 단점이 있으며
두번째 방법은 바로 반영이 불가능 하나 elasticsearch 재기동시 해당 설정이 영구적용됨

첫번째 방법으로 적용 후 두번째 방법으로 영구 설정하여 사용하기를 추천

해결방법

// [step 1] cluster update api를 이용하여 바로 반영
PUT _cluster/settings
{
  "persistent": {
    "search.max_buckets": "2147483647" // 원하는 설정값 입력
  }
}

// elasticsearch.yml 파일내 아래와 같이 삽입
search.max_buckets: 20000  // 원하는 설정값 입력

주의사항

buckets 사이즈를 무한정 늘리기엔 Elasticsearch Heap Memory 사용량과 비례 하기 때문에 해당 집계를 사용하는 데이터에 맞게 사이즈를 늘리는것을 추천

지금 내가 접속한 환경이 운영인지 개발인지 표시를 해주시면 쉘 명령어 입력시 한번 더 주의를 할 수 있을것 같아 iTerm2에 Automatic Profile Switching 기능을 사용하고자 했습니다.

하지만 automatic profile switching 기능을 사용할려면 변경이 필요한 환경에 shell Integration 을 설치 해야 합니다 이는 인프라팀이 좋아 하지 않을 방법이라 shell Integration 설치 없이 automatic profile switching 기능을 사용 하는 방법을 서술 합니다

저 같은 경우 로컬PC에 사용자명을 출력하지 않아 어쩔 수 없이 로컬 환경만 shell Integration을 설치 했습니다

저와 같이 zsh 쉘 환경에 사용자 명을 출력하지 않을 경우를 기준으로 설명합니다

trigger를 사용하여 Profile Switching 하기

1. iTerm2 install shell Integration
   1. iTerm2 → Install shell Integration → continue → Download and Run Installer → continue → 아래 명령어를 통해 설치 확인

    vi ~/.zshrc
   
    # 아래 항목이 추가 되었으면 정상 설치 안되어 있을 경우 추가
    test -e "${HOME}/.iterm2_shell_integration.zsh" && source "${HOME}/.iterm2_shell_integration.zsh"
   

2. default profile 설정
   1. iTerm2 → Preferences → Profiles → Default 선택 (혹은 자신이 기본으로 사용하는 profile 선택)
   2. General → Badge → 로컬 환경일때 표시 하고 싶은 text 설정
   3. Badge 텍스트 위치 필요시 Edit 눌러서 표시 크기 및 위치 조정
   4. Badge 텍스트 색 변경 필요시 Colors → Badge 항목에 원하는 색으로 변경
   5. Advanced → Triggers → Edit → + 버튼 클릭 → Action 항목 Report User & Host 선택 → Reqular Expression → 아래 케이스 참고하여 정규식 입력 → Parameters → \1@\2

    # case1
    test@product-elasticsearch-2c → (\w+)@([\w.-]+)
   
    # case2
    [test@elasticsearch-product-2 ~] → (?!\[)(\w+)@([\w.-]+)
   
    # 기타 형식일 경우 https://regexr.com 에서 작성하고 테스트 해야 함
   

3. ssh 접속 환경 별 profile 설정 (product 일 경우)
   1. iTerm2 → Preferences → Profiles → Default 선택 → Other Actions → Duplicate Profile
   2. Name을 자신이 원하는 이름으로 변경 ex) product
   3. Badge → \(session.username)@\(session.hostname) 입력
   4. Advanced → Automatic Profile Switching → ssh 접속시 console에 출력되는 username@hostname 규격 입력

   # case 1
   test@product-elasticsearch-2c → test@product-*
      
   # case 2
   test@elasticsearch-product-2 → test@*product*
   
   # 호스트명에 운영/개발 환경을 구분 할 수 있는 단어를 픽할 수 있어야 profile swithching이 가능 하다
   

원리 설명

iTerm2 에서 default profile에 설정된 정규식으로 사용자명 / 호스트명 이 인자값으로 뽑히는데 여기에 Automatic Profile Switching에 설정된 규격에 맞을경우 해당 profile로 전환 하는 것 입니다

또한 다시 default으로 전환되는건 세션이 끊기고 로컬PC에 설치된 shell Integration이 자동으로 default 프로필로 변경 해주기 때문에 별도의 Automatic Profile Switching 항목이 없어서 자동 전환 되는 것 입니다

아쉽게도 이 방법은 접속하는 서버의 호스트명에 해당 환경을 구분 할 수 있는 prefix가 있어야지 가능한 방법이며 공통적인 prefix가 없는 경우 해당하는 호스트명을 Automatic Profile Switching 에 등록 해줘야 합니다

한가지 더 팁을 드리자면 개인개정으로 접속 후 root 으로 전환시 profile이 풀리는 현상이 나타날 수 있는데 이는 Automatic Profile Switching 항목에 root 으로 개인계정과 같은 형식으로 등록 해주면 해결 됩니다

보통 github에 소스코드 업로드시 아래와 같은 방법으로 진행 합니다

github에 repo 생성 → 로컬 PC에서 해당 remote git clone → repo 폴더에 소스 코드 이동/복사 → git add → git commit → git push

아래에 설명된 방법은 clone 단계를 거치지 않고 바로 업로드 하는 방법 입니다.

작업 방법

# 소스코드가 있는 폴더로 이동
cd {소스코드가 위치한 폴더}

# git init
git init

# repo 별로 git 사용자, 이메일 정보 설정 (해당 repo만 적용되는 설정)
git config user.name "{git commit history에 노출될 이름}"
git config user.email {github email 주소}

# 설정된 사용자, 이메일 정보 확인
git config user.name
git config user.email

# 소스코드 add all
git add .

# initial commit
git commit -m "Initial Commit"

# master -> main 으로 브런치 명 변경 (master 브런치에서 수행)
git branch -M main

# remote repo 주소 등록
git remote add origin https://github.com/{github id}/{github repo name}.git

# remote repo push
git push -u origin main

# 번외 gitignore 에 등록된 파일이 업로드 되었을 경우 원격에서만 삭제 하는법
git rm --cached -r .idea
git rm --cached -r gradle/wrapper

aws 상에서 서비스 구축 중 발생한 문제를 해결 하기 위해 구글링 하였으나 정확한 내용이 없어 기록으로 남깁니다 ***

오류상황

jdk version을 1.8 u292 에서 u312 으로 변경하고 나서 application 을 기동하였는데 exception을 발생시키고 MySQL에 접속이 불가한 상황 u292를 사용 하였을때는 정상 접속이 가능한 상황이었고 u312으로 변경 후 기존 application level의 코드 변경 없이 기동을 하였으나 아래와 같은 exception을 발생 하고 기동되지 않는 문제 발생

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

원인분석

Mysql으로 접속을 u292에서는 tls 1.1 으로 하였으나, u312 부터 tls 1.0, 1.1을 비활성화 하므로 생기는 문제 사실 log에서 아래와 같이 경고 하고 있었음

WARN: This connection is using TLSv1.1 which is now deprecated and will be removed in a future release of Connector/J.

해결방안

jdk u292 버젼 이상 부터 datasource url 설정에 아래와 같이 TLS 프로토콜 명시

jdbc:mysql://test.amazonaws.com:3306/test?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&enabledTLSProtocols=TLSv1.2

NodeJS 설치 없이 docker를 이용 elasticdump를 사용하는 실전 가이드 입니다

기본적으로 docker는 설치 되어 있다고 가정하고 설명하겠습니다

준비

1. docker 이미지 pull

    docker pull elasticdump/elasticsearch-dump
   

케이스별 elasticdump 실행 명령어

1. ES TO ES index 데이터 10,000건씩 덤프

    docker run --rm -ti elasticdump/elasticsearch-dump \
    --input=http://production.es.com:9200/my_index \
    --output=http://staging.es.com:9200/my_index \
    --type=data \
    --limit=10000
   

2. ES에서 로컬에 설치한 ES으로 index 데이터 10,000건씩 덤프

    docker run --net=host --rm -ti elasticdump/elasticsearch-dump \
    --input=http://staging.es.com:9200/my_index \
    --output=http://localhost:9200/my_index \
    --type=data \
    --limit=10000
   

3. ES에서 로컬 저장소에 JSON으로 index 데이터 10,000건씩 덤프 (로컬 JSON 저장 경로 : ~/Documents/elasticdump)

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=http://production.es.com:9200/my_index \
    --output=/tmp/my_index_data.json \
    --type=data \
    --limit=10000
   

4. ES에서 로컬 저장소에 JSON으로 index 데이터 10,000건씩 100만건만 덤프 (로컬 JSON 저장 경로 : ~/Documents/elasticdump)

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=http://production.es.com:9200/my_index \
    --output=/tmp/my_index_data.json \
    --type=data \
    --size=1000000 \
    --limit=10000
   

5. ES에서 로컬 저장소에 1GB 크기 JSON으로 분할하여 index 데이터 10,000건씩 100만건만 덤프 (로컬 JSON 저장 경로 : ~/Documents/elasticdump)

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=http://production.es.com:9200/my_index \
    --output=/tmp/my_index_data.json \
    --type=data \
    --fileSize=1024MB \
    --size=1000000 \
    --limit=10000
   

6. ES QUERY를 이용하여 ES에서 로컬 저장소에 JSON으로 index 데이터 10,000건씩 덤프 (로컬 JSON 저장 경로 : ~/Documents/elasticdump)

   ~/Documents/elasticdump/search_query.json

    {
      "query": { "match_all": {} },
      "_source": ["account_number", "balance"]
    }
   

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=http://production.es.com:9200/my_index \
    --output=/tmp/my_index_data.json \
    --type=data \
    --searchBody=@/tmp/search_query.json \
    --limit=10000
   

7. elasticdump으로 생성한 JSON 파일을 ES에 10,000건씩 복원 (로컬 JSON 파일 경로 : ~/Documents/elasticdump)

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=/tmp/my_index_data.json \
    --output=http://production.es.com:9200/my_index \
    --type=data \
    --limit=10000
   

8. elasticdump로 생성하지 않은 JSON 파일을 ES에 10,000건씩 복원 (로컬 JSON 파일 경로 : ~/Documents/elasticdump)

    docker run --rm -ti -v ~/Documents/elasticdump:/tmp:/tmp elasticdump/elasticsearch-dump \
    --input=/tmp/my_index.json \
    --output=http://production.es.com:9200/my_index \
    --type=data \
    --transform=doc._source="Object.assign({},doc)" \
    --limit=10000
   

Reference

• dockerhub-elasticdump
• github-elasticdump

설치 자체는 쉬우나 OS level의 환경설정이나 jvm 관련 설정 내용들이 잘 정리되어 있는 문서가 없어 별도로 정리 합니다

centOS 환경에 root 권한을 가지고 있고 RPM 설치 기준으로 설명 하였습니다
.zip and .tar.gz으로 설치 했을 경우 부분적으로 설정이 적용되지 않을 수 있습니다

환경설정

1. vi /etc/elasticsearch/elasticsearch.yml - elasticsearch.yml 파일 수정

    cluster.name: search-dev
     
    node.name: search-dev-master
    node.roles: [master, ingest]
       
    path.data: /var/lib/elasticsearch
    path.logs: /var/log/elasticsearch
       
    network.host: 0.0.0.0
    http.port: 9200
    transport.port: 9300
    transport.compress: true
       
    discovery.seed_hosts:
      - 127.0.0.1
       
    cluster.initial_master_nodes:
      - 127.0.0.1
       
    xpack.security.enabled: false
       
    # _all api index
    action.destructive_requires_name: true
       
    # 서버에 system call filter 가 설치 되지 않았을 경우 해당 filter 사용 안함으로 설정
    bootstrap.system_call_filter: false
       
    # 메모리 스왑 방지 옵션
    bootstrap.memory_lock: true
   
    # xpack security 설정 disable - 해당 설정을 하지 않으면 kibana dev tool 사용시 경고 메세지 지속적으로 나타남
    xpack.security.enabled: false
   

2. vi /etc/elasticsearch/jvm.options - jvm.options 파일 수정

   보통 master, coordinating node 는 8GB, data node는 30GB(zero based) 설정으로 운영합니다

    ################################################################
    ## IMPORTANT: JVM heap size
    ################################################################
    ##
    ## The heap size is automatically configured by Elasticsearch
    ## based on the available memory in your system and the roles
    ## each node is configured to fulfill. If specifying heap is
    ## required, it should be done through a file in jvm.options.d,
    ## and the min and max should be set to the same value. For
    ## example, to set the heap to 4 GB, create a new file in the
    ## jvm.options.d directory containing these lines:
    ##
       
    -Xms8g
    -Xmx8g
   

3. vi /etc/fstab - centOS swap 설정 확인 (root 권한 필요)

   elasticsearch 전용으로 운영하는 서버가 아닐 경우 swap 설정에 대한 인프라 담당자와 협의 필요

    # 명령어 입력 후 /etc/fstab 내용에 swap 관련 설정이 없어야 함
    vi /etc/fstab
   

   /etc/fstab - swap 설정이 없는 경우

    #
    # /etc/fstab
    # Created by anaconda on Sat Feb 29 12:05:47 2020
    #
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    #
    UUID=388a99ed-9486-4a46-aeb6-06eaf6c47675 /                       xfs     defaults        0 0
    ~
   

4. vi /usr/lib/systemd/system/elasticsearch.service - elasticsearch.service Systemd 파일 수정

   LimitNPROC 항목 주석 제거 or 65535 값 변경, [Service] LimitMEMLOCK=infinity [Install] 위에 추가

    # Specifies the maximum number of processes
    LimitNPROC=65535   
   
    # Allow a slow startup before the systemd notifier module kicks in to extend the timeout
    TimeoutStartSec=75
       
    [Service]
    LimitMEMLOCK=infinity
       
    [Install]
    WantedBy=multi-user.target
   

5. elasticsearch Systemd 파일 수정 후 서비스 reload

    # elasticsearch.service 수정 사항 시스템에 반영
    systemctl daemon-reload
       
    # [선택사항] 재부팅시 elasticsearch daemon 자동 실행 옵션 활성화
    systemctl enable elasticsearch.service
   

6. vi /etc/sysctl.conf - /etc/sysctl.conf virtual memory, swap file, tcp 통신 복구 횟수 설정

    # swap file 설정
    vm.swappiness=1
       
    # virutal memory 설정
    vm.max_map_count=262144
       
    # [선택사항] - 클러스터 복구를 위한 TCP 통신 retry 횟수 설정 : 5번까지 시도하며, 완료시간은 6초 이내 이므로 빠르게 장애 상황을 인지 할 수 있음
    # 기본 설정은 15회이며 15회를 모두 수행하는 시간은 900초이다, 즉 클러스터 장애 상황을 900초 이후에 인지 할 수 있음
    net.ipv4.tcp_retries2=5
   

7. /etc/sysctl.conf 수정 후 reboot

   elasticsearch 전용으로 운영하는 서버가 아닐 경우 리부팅시 인프라 담당자와 협의 필요

    reboot
   

   ---

Reference

• Important System Configuration - elasticsearch 공식문서

brew 설치 후 install 실행시 Ignoring commonmarker-0.17.13 because its extensions are not built 와 같은 메세지가 계속적으로 출력되고 있었습니다.

실제 명령어 수행에는 큰 이상은 없지만 메세지가 자꾸 신경쓰여 해당 문구가 출력되지 않도록 하는 방법을 설명하였습니다.

단 설명드리는 방법은 문제를 해결하는 방법 중에 한가지 이며 설명드리는 방법으로 해결이 안될 수도 있음을 알려드립니다.

출력되는 메세지 sample

neotune@mac-neotune brew install jython
Ignoring commonmarker-0.17.13 because its extensions are not built.  Try: gem pristine commonmarker --version 0.17.13
Ignoring commonmarker-0.17.13 because its extensions are not built.  Try: gem pristine commonmarker --version 0.17.13
==> Downloading https://homebrew.bintray.com/bottles/jython-2.7.1.mojave.bottle.1.tar.gz
==> Downloading from https://akamai.bintray.com/e6/e64dc854f84ba16de19059102aa5c94d01b9ed2a996e3bafa7df1f6f2c19e3ca?__gda__=exp=1574390614~hmac=afcb679b5fb8ac48d0dfe
######################################################################## 100.0%
==> Pouring jython-2.7.1.mojave.bottle.1.tar.gz

해결방법

1. brew install 실행시 나왔던 메세지 중 try: 이후 출력된 명령어를 sudo 권한으로 실행 (ex : sudo gem pristine commonmarker –version 0.17.13)

     $ sudo gem pristine commonmarker --version 0.17.13
     Password:
     Ignoring commonmarker-0.17.13 because its extensions are not built.  Try: gem pristine commonmarker --version 0.17.13
     Restoring gems to pristine condition...
     Building native extensions.  This could take a while...
     Restored commonmarker-0.17.13 
   

2. 정상 실행 여부 확인을 위해 아래 명령어 실행 (ex : gem list | grep commonmarker)

     # 해결 완료 상태 일 경우
     $ gem list | grep commonmarker
     commonmarker (0.17.13) 
     # 해결 안된 상태 일 경우
     $ gem list | grep commonmarker
     Ignoring commonmarker-0.17.13 because its extensions are not built.  Try: gem pristine commonmarker --version 0.17.13
     commonmarker (0.17.13) 
   

리눅스 환경에서 text 파일 혹은 임의의 파일를 비교 하여 중복인 text나 key 값 등을 뽑아 내고 싶을때가 있습니다. 엄청난 크기의 파일이 아니라면 간단한 리눅스 명령어로 찾을 수 있습니다

파일 갯수는 제한이 없으며 비교 대상의 파일이 같은 형식으로 이루어져 있어야 합니다

간단하게 설명을 드리자면 1.txt 파일에는 아래와 같이 되어 있고

12354512
12311344
12354123
12341234

2.txt 파일에는 아래와 같이 되어 있으면 중복으로 들어가 있는 “12354123” 을 찾을 수 있는 방법입니다.

444444
333333
12354123
8888888

text 파일에서 중복 찾기 방법

1 . 비교를 원하는 파일을 한개의 파일에 담습니다 (diff.txt 파일에 1.txt 과 2.txt 에서 출력된 내용이 다 들어가게 됩니다)

$ more 1.txt >> diff.txt
$ more 2.txt >> diff.txt   

2 . 중복인 text를 중복 횟수가 많은 순으로 출력

$ sort diff.txt | uniq -c | sort -r -k1
# 출력 sample
4 991569114
3 991741226
2 992385238

3 . 중복인 text를 중복 횟수가 많은 순으로 result.txt 기록

$ sort diff.txt | uniq -c | sort -r -k1 >> result.txt

4 . 중복된 text만 추출 (중복횟수 X)

$ sort diff.txt | uniq -d

sort 명령어 옵션

uniq 명령어 옵션

맥에서 git branch -l 명령어 이용시 기존 bash 쉘에서는 명령어 아래에 바로 출력이 되었는데 zsh 쉘로 전환 후 갑자기 git 에서 branch 리스트를 화면전환하여 보여주고 있어서 불편했습니다

아래와 같이 명령어를 입력하면 해결 됩니다

$ git config --global pager.branch false