originalchoi

ES 카운트에만 문제가 있을 경우의 재처리HDFS 의 nar 가 정상처리 되었는지도 반드시 확인해야 한다. 1. es 가 아닌 첨부의 재처리는? 첨부 업로드 이상은 hadoop 에 문제가 있을 경우, 콜렉터 자체에 문제가 있을 경우정상 동작하지 못해서 marking 이 y 가 아니면 추후 콜렉터에서 확인하고 다시 처리한다 2. 콜렉터 노드가 다운될 경우 다른 콜렉터가 해당 작업을 백업한다. 그러나 다운된 콜렉터가 자동으로 살아나지는 않는다. 3. es 재기동시 빠른 재기동을 위한 screen shot 기능이 없을까? 4. es 재처리시 벌크 업로드 스크립트 hadoop fs -get /backup/json/20131024/2013102416* . gunzip *gz #!/bin/shfor file in ..

그동안 대용량 데이터를 바탕으로 Hadoop, Hive, Es 가 결합된 검색시스템을 운용 중이었는데 갑작스럽게 장애가 발생하였다. 정황상 ES head plug in 에서 발생시킨 쿼리가 영향을 끼친 것 으로 보인다. (거의 확실함) 쿼리 자체는 범위가 한정된 지극히 일반적인 쿼리 문이었으나, 검색용 index 를 지정하지 않아 부하가 발생하고, 쿼리 리퀘스팅 상태가 완료되지 않은 채로, 여러 건의 쿼리가 누적되어 부하가 급증한 것으로 보인다. Q) 내 경험 상 ES head plug in 의 검색은 cli 에서 curl 을 이용한 것보다 항상 느렸다. 그동안 인덱스를 지정하지 않아서 그랬던 것인가? plug in 의 any request 기능에 문제가 있는 것인가? head pluging 을 이용할 ..

보통 es 에서 query 사용해야 할 때 아래와 같은 식으로 쉘을 짜서 돌리곤 한다. 1 #!/bin/sh 2 3 echo "curl -XPOST sgmm:9200/others_201307/_search?pretty=true -d ' { 4 \"fields\" : [ \"*\" ], 5 \"query\": { 6 \"query_string\" : { 7 \"query\" : \"USERID:aa..bb.cc AND CTIME:[20130723000000 TO 20130723235959] \" 8 } 9 }, 10 \"size\" : 100, 11 \"sort\" : { \"MSGID\" : \"asc\" }}'" > tmp.sh 12 13 14 15 sh tmp.sh > result.log 16 그러나..

1. 개요 현재 12대 구성의 Elastic Search Cluster 를 운영 중이고, 그중 한대 노드의 이상이 감지되어 장애처리를 하였다. 일반적인 경우 ES 장애처리 수순은 아래와 같다.1. ES 클러스터에서 장애 노드 제거2. 장애 노드 로컬에서 Hardware Fault 확인3. 부품(Disk 등) 교체 후 ES 클러스터에서 장애 노드 신규 추가 ES 에서 해줘야 할일은 노드 제거 및 추가가 전부이기에 Hadoop Slave 교체 처럼 성능에서는 별 영향이 없을 것이라고 예상했으나 예상과 다르게 전체 성능 저하 및 부하 급증을 겪어야 했다. 2. 시스템 현황 작업 전 curl 명령어를 활용해 ES cluster status 를 확인해보자curl -XGET 'http://hostname:9200/..