인수인계받은 서버에서 Solr 버전을 알아내는 방법은 설치 형태에 따라 다르다. 확실한 순서대로 적는다.
실행 중인 인스턴스에 물어보는 방법이 가장 정확하다. 응답의 lucene.solr-spec-version 이 실제로 기동된 버전이다.
curl -s "http://localhost:8983/solr/admin/info/system?wt=json" | grep -o '"solr-spec-version":"[^"]*"'
프로세스가 죽어 있으면 CLI 로 확인한다.
/opt/solr/bin/solr version
설치 경로만 남아 있을 때는 jar 이름을 본다. 심볼릭 링크 /opt/solr 가 가리키는 실제 디렉터리 이름에도 버전이 들어 있다.
ls -l /opt/solr
ls /opt/solr/server/solr-webapp/webapp/WEB-INF/lib/ | grep solr-core
로그 첫머리에도 기동 배너로 버전이 남는다.
grep -m1 -i "solr-spec-version\|Solr version" /var/solr/logs/solr.log
SolrCloud 에서 다음 메시지가 반복되면 ZooKeeper 가 보관한 클러스터 상태와 노드가 기억하는 상태가 어긋난 것이다.
ClusterState says we are the leader, but locally we don't think so. Request came from null.
노드 재시작 중 리더 선출이 끝나기 전에 갱신 요청이 들어왔거나, ZooKeeper 세션이 끊겼다가 붙으면서 /collections/<컬렉션>/leaders 의 정보가 실제 복제본 상태와 달라진 경우에 나온다. 노드와 ZooKeeper 사이의 지연, GC 정지, 세션 타임아웃이 계기가 된다.
먼저 상태를 확인한다.
curl -s "http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS&wt=json" | python3 -m json.tool | head -60
각 샤드의 leader: true 복제본이 하나뿐인지, 상태가 active 인지 본다. 리더가 없거나 둘로 보이면 아래 순서로 처리한다.
curl -s "http://localhost:8983/solr/admin/collections?action=FORCELEADER&collection=<컬렉션>&shard=shard1"
down 이면 삭제 후 다시 추가하는 편이 빠르다.curl -s "http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=<컬렉션>&shard=shard1&node=<호스트>:8983_solr"
증상이 아니라 계기를 없애야 한다. 확인할 값은 세 가지다.
ZooKeeper 세션 타임아웃(ZK_CLIENT_TIMEOUT, 기본 15초 안팎)이 GC 정지보다 짧으면 정상 노드도 세션을 잃는다. 힙을 키웠다면 GC 로그로 최대 정지 시간을 확인하고 타임아웃을 그보다 넉넉히 잡는다.
ZooKeeper 앙상블은 홀수(3 또는 5)로 구성하고, Solr 노드와 같은 디스크를 쓰지 않게 한다. 색인 I/O 가 몰리면 ZooKeeper 트랜잭션 로그 쓰기가 밀리면서 전체가 흔들린다.
Solr 와 ZooKeeper 의 버전 조합을 확인한다. Solr 9 는 자체적으로 특정 ZooKeeper 클라이언트 버전을 묶어 배포하므로, 외부 앙상블 버전이 지나치게 낮으면 세션 처리에서 문제가 생긴다.