SolrCloud 는 색인 하나를 여러 조각으로 나눠 여러 노드에 흩는다. 컬렉션을 만들 때 정하는 값들이 그 배치를 결정한다.
즉 코어 수 = 샤드 수 × 레플리카 수다. 8샤드에 복제 3이면 코어 24개가 클러스터에 배치된다.
컬렉션을 몇 조각으로 나눌지다. 나눌수록 한 질의가 여러 노드에서 병렬로 처리되지만, 모든 샤드에 질의를 뿌리고 결과를 모으는 비용도 같이 늘어난다.
기준은 샤드 하나의 크기다. 일반적으로 샤드 하나가 수십 GB 를 넘어가면 병합과 재기동이 무거워진다. 데이터 총량을 목표 샤드 크기로 나눈 값에서 시작한다.
compositeId 라우터로 만든 컬렉션은 나중에 샤드를 쪼갤 수 있다(SPLITSHARD). 처음부터 과하게 나누는 것보다 늘려 가는 편이 낫다.
샤드마다 사본을 몇 개 둘지다.
Solr 7 이후로는 사본에 종류가 생겼다. NRT(색인을 직접 수행), TLOG(리더의 트랜잭션 로그를 복제), PULL(세그먼트만 복제, 색인 안 함)이다. 조회 부하를 나누는 것이 목적이면 PULL 사본을 늘리는 쪽이 쓰기 비용을 덜 늘린다.
curl "http://solr1.example.com:8983/solr/admin/collections?action=CREATE\
&name=logs&numShards=4&nrtReplicas=2&pullReplicas=1&collection.configName=logs_conf"
한 노드에 배치할 수 있는 코어 수의 상한이었다. Solr 9 에서 제거됐다. Solr 8 에서 이미 폐기 예정으로 표시됐다.
옛 문서를 보고 Solr 9 에 이 파라미터를 넣으면 컬렉션 생성이 실패한다. 배치를 제한하려면 그 자리에 들어온 두 가지를 쓴다.
createNodeSet — 컬렉션을 만들 때 배치 대상 노드를 직접 지정한다.curl "http://solr1.example.com:8983/solr/admin/collections?action=CREATE\
&name=logs&numShards=4&replicationFactor=2\
&createNodeSet=solr1.example.com:8983_solr,solr2.example.com:8983_solr"
Solr 8 이하를 아직 쓰고 있다면 maxShardsPerNode 가 동작한다. 다만 값이 작으면 Cannot create collection ... Value of maxShardsPerNode is N, and the number of nodes currently live ... is insufficient 로 생성이 거부되므로, 필요한 코어 수를 노드 수로 나눈 값보다 크게 잡아야 한다.
curl "http://solr1.example.com:8983/solr/admin/collections?action=CLUSTERSTATUS&wt=json"
curl "http://solr1.example.com:8983/solr/admin/collections?action=COLLSTATUS&collection=logs"
레플리카가 down 이나 recovering 에 오래 머물면 그 노드의 디스크 여유와 ZooKeeper 연결부터 본다. SolrCloud 의 상태 판단은 ZooKeeper 에 의존하므로, ZooKeeper 세션이 끊기면 색인은 멀쩡해도 레플리카가 빠진 것처럼 보인다.