반응형

Cluster 상태 모니터링

삭제 작업 중 Kibana의 Monitoring이나 /_cat/health API를 사용하여 클러스터 상태를 모니터링 할 수 있다

GET /_cat/health?v=true

curl 코드

curl -X GET "localhost:9200/_cat/health?v=true&pretty"

 

결과 예시

cluster       status node.total node.data shards pri relo init unassign unassign.pri pending_tasks max_task_wait_time active_shards_percent
elasticsearch green           1         1      1   1    0    0        0            0             0                  -                100.0%

 

상태(status)

- grenn : 모든 샤드가 정상적으로 작동 중

- yellow : 일부 복제본 샤드가 활성화되지 않았지만, 데이터는 사용 가능

- red : 일부 데이터 샤드가 손실된 상태

 

노드 상태 모니터링

GET /_nodes/stats

curl코드

curl -X GET "localhost:9200/_nodes/stats?pretty"

 

출력 예시

- CPU 사용량

- Heap 메모리 사용량

- 디스크 사용량 및 가용량

샤드 상태 모니터링

GET /_cat/shards?v

curl 코드

curl -X GET "localhost:9200/_cat/shards?v=true&pretty"

출력예시 : 

index       shard prirep state   docs  store ip            node
user_data   0     p      STARTED 10000 5mb   192.168.1.10 node-1
user_data   1     r      STARTED 10000 5mb   192.168.1.11 node-2

p : primary 샤드

r : replica 샤드

 

state : STARTED, RELOCATING, INITIALIZING, UNASSIGNED 등의 사앹 확인 가능

 

작업 큐 상태 확인

GET /_cat/thread_pool?v

curl 코드

crul -X GET "localhost:9200./_cat/shards?v=true&pretty"

출력 예시

node_id   name    active queue rejected
node-1    write   2      15    0
node-2    search  0      10    5

queue : 작업 대기열의 크기

rejected : 처리할 수 없어 거부된 작업 수(거부 작업이 많다면 리소스가 부족하다는 신호다)

 

_tasks를 통해 특정 작업 모니터링 하기(나의 경우 delete_by_query)

curl 코드

curl -X GET "localhost:9200/_tasks?detailed=true&actions=*/delete/byquery&pretty"

출력예시

{
  "nodes": {
    "node-1": {
      "tasks": {
        "node-1:12345": {
          "action": "indices:data/write/delete/byquery",
          "status": {
            "total": 100000,
            "deleted": 5000,
            "version_conflicts": 0,
            "throttled_millis": 0
          }
        }
      }
    }
  }
}

 

 

굿굿

 

반응형
반응형

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend.에러

1. 프로세스를 종료시킨다

sudo killall apt apt-get

 

2. 위 방법으로 효과가 없다면 디렉토리 삭제

sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock*

 

3. 패키지 재구성

sudo dpkg --configure -a

 

4. 마무리

sudo apt update

 

추가로 터미널이나, bash 창을 닫았다가 열어서 시도하기

운영 체제 재부팅

등으로 해결하였다는 분들도 있었다.

 

참고

https://askubuntu.com/questions/1109982/e-could-not-get-lock-var-lib-dpkg-lock-frontend-open-11-resource-temporari

 

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)

I'm trying to run this command in the terminal: sudo apt install software-properties-common This is the error message I get: E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource

askubuntu.com

 

반응형
반응형

엘라스틱 서치 작업을 해야하는데

RDBMS만 다루다보니 삭제 작업에서 락이 발생하지는 않을지 궁금하여 찾아본 내용 정리

 

*RDBMS 는 MySQL 기준으로 작성

 

혹시 잘못된 내용이 있다면 댓글 주시면 감사하겠습니다.

MySQL의 동작방식

REBMS에서 데이터 삭제가 조회/수정에 영향을 미치는 이유

- 트랙잭션 관리 : MySQL은 ACID를 준수한다. 데이터를 삭제할 때, 해당 행을 잠그고 삭제가 완료되기 전까지 다른작업이 영향을 받을 수 있다.

 

- 물리적 삭제 : MySQL은 데이터를 삭제할 때 디스크에서 데이터를 즉시 제거한다.

 

- 락의 종류

행 레벨 락 : 삭제가 진행 중인 특정 행에 대해 검색/삽입 작업이 대기 상태가 된다.

테이블 락 : 대량 삭제가 테이블에 걸리는 락을 유발할 경우, 모든 작업이 영향을 받을 수 있다.

 

Elasticsearch의 동작방식

NoSQL기반으로 분산형 아키텍처라 데이터 삭제 방식이 RDBMS와 다르다

 

삭제 마킹

엘라스틱에서 데이터를 삭제할 때 해당 문서를 디스크에서 즉시 제거하는게 아니라 삭제된 것으로 표시만 한다

물리적 삭제는 나중에 처리됨

삭제 마킹된 데이터는 백그라운드 병합 작업 중 물리적으로 디스크에서 제거된다.

따라서 삭제 작업이 진행 중일 때도 검색 및 삽입 작업이 계속 정상적으로 이루어질 수 있다.

 

Elasticsearch 에서 검색과 삽입이 영향을 받지 않는 이유 

1. 읽기/쓰기 동시성 처리 :

- 샤드 기반 분산 처리를 사용하여 데이터가 여러 샤드에 분산되어 작업이 특정 샤드에서 이루어져도 다른 샤드에서는 검색 및 삽입 작업이 독립적으로 실행

- 검색과 삭제 작업은 서로 다른 리소스를 사용하므로, 병렬 처리 가능

 

2. 삭제가 논리적으로 처리됨 :

- 삭제는 문서 검색 결과에서 제외하는 논리적 작업에 불과하여 문서가 삭제되더라도 검색은 실시간으로 작동

 

3. document 기반 데이터 모델 :

- 데이터를 독립적인 문서 단위로 저장

- 각 문서가 고유하여 삭제 작업이 진행 중이라도 다른 문서에 삽입되거나 검색될 수 있음

 

특징 MySQL Elasticsearch
삭제 방식 물리적 삭제 논리적 삭제 (삭제 마킹)
데이터 모델 행(row) 단위 관리 독립적인 문서(Document) 단위 관리
트랜잭션 강제성 ACID (강력한 일관성) 최종적 일관성 (Eventual Consistency)
삭제 중 검색/삽입 영향 락 발생 가능성 높음 영향 거의 없음
삭제 처리 시점 즉시 (삭제와 병합 동시 진행) 삭제는 나중에 병합 작업에서 처리

 

반응형

+ Recent posts