Parametr shards

Jedną z pierwszych możliwości kontroli zapytań jeżeli chodzi o SolrCloud jest parametr shards. Pozwala on na dokładne określenie, które z shardów mają uczestniczyć w wykonywaniu zapytania. Jako wartości parametru możemy przekazywać zarówno nazwy logiczne, jak również nazwy replik, np:

http://localhost:8983/solr/test/select?q=*:*&shards=shard1

http://localhost:8983/solr/test/select?q=*:*&shards=shard1,shard2,shard3

http://localhost:8983/solr/test/select?q=*:*&shards=localhost:6683/solr/test

Pierwsze z powyższych zapytań zostanie przekazane do shardów zgrupowanych pod logiczną nazwą shard1, drugie z zapytań zostanie wykonane na shardach z logicznymi nazwami shard1, shard2 oraz shard3. Ostatnie zapytanie zostanie natomiast wykonane na replikach znajdujących się na instancji Solr o adresie localhost:6683 na kolekcji test.

Istnieje takie możliwość wskazania alternatywy, tak aby możliwy był load balancing pomiędzy instancjami, np:

http://localhost:8983/solr/test/select?q=*:*&shards=localhost:6683/solr/test|localhost:7783/solr/test

Powyższe zapytanie zostanie wykonane na instancji działającej na porcie 6683 lub na instancji działającej na porcie 7783.

Parametr shards.preference

Parametr shards daje nam pewne możliwości kontroli, gdzie wykonane zostanie nasze zapytanie. Jednak, aby wykorzystać repliki danego rodzaju musielibyśmy sami pobierać informacje na temat ich lokalizacji, a następnie zadawać odpowiednie zapytanie. Parametr shards.preference wyręcza nas udostępniając możliwość zdefiniowania typu repliki jaki ma mieć priorytet podczas wykonywania zapytania lub/oraz lokalizacji repliki.

Na przykład, aby Solr preferował repliki typu PULL podczas wykonywania zapytania wystarczy, abyśmy dodali do naszego zapytania parametr shards.preference z wartością replica.type:PULL:

http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL

Oczywiście możemy powiedzieć, aby Solr wykorzystywał najpierw repliki typu PULL, a następnie repliki typu TLOG jeżeli te pierwsze nie są dostępne. Nasze zapytanie wyglądałoby wtedy następująco:

http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.type:TLOG

Możemy także powiedzieć, aby Solr najpierw preferował repliki typu PULL, a jak takich nie ma, to te dostępne lokalnie:

http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.location:local

Wprowadziliśmy tutaj nową wartość parametru shards.preference, czyli replica.location:local. Określa on preferowaną lokalizację replik i w tym wypadku mówi, aby preferował te znajdujące się lokalnie.

Oczywiście nie jest to jedyna możliwość, jeżeli chodzi o lokalizację replik. Podobnie jak w przypadku parametru shards mamy możliwość wskazania danej instancji Solr, która ma być tą preferowaną. Na przykład, jeżeli chcemy, aby preferowaną maszyną był serwer o adresie 192.168.1.1 wystarczy zadać następujące zapytanie:

http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.location:http://192.168.1.1

Podsumowanie

Omówione parametry, a szczególnie shards.preference ze swoją wartością replica.type może być szczególnie przydatny w tych przypadkach kiedy w SolrCloud korzystamy z różnego typu replik. Mówiąc Solr, iż do wyszukiwania preferujemy repliki typu PULL lub TLOG możemy zmniejszyć lub wyeliminować obciążenie zapytaniami replik typu NRT, a tym samym zbliżyć się do tego co oferuje Solr w architekturze master – slave – podział ról replik. Wszystko to dalej korzystając z SolrCloud i wszystkich udogodnień, które za tym idą.

Tolerancja zapisu

Tolerancja zapisu to dość skomplikowany temat. Po pierwsze, wraz z wprowadzeniem Solr 7.0 dostaliśmy różne rodzaje replik. Mamy repliki typu NRT, które zapisują dane do loga transakcyjnego, a indeksowanie odbywa się na każdej z replik. Mamy repliki typu TLOG, gdzie nowe dane zapisywane są do loga transakcyjnego, a samo indeksowanie nie następuje i występuje tylko binarna replikacja. W końcu repliki typu PULL, gdzie Solr nie korzysta z loga transakcyjnego replikując segmenty od lidera.

Nie będziemy się dzisiaj jednak zajmować dokładną analizą, jak działają poszczególne typy replik i skupimy się na domyślnym typie, czyli replikach NRT. Repliki te były z nami od początku SolrCloud i na szczęście są dalej

W przypadku replik NRT procedura indeksowania danych działa następująco – na początku lider przyjmuje dane, zapisuje je w logu transakcyjnym i wysyła do swoich replik (zakładamy, że wszystkie są typu NRT). Każda z replik zapisuje dane w logu transakcyjnym. W tym momencie nasze dane są już bezpieczne i Solr może zwrócić potwierdzenie przyjęcia danych. Oczywiście, gdzieś w między czasie, w zależności od konfiguracji tworzony jest odwrócony indeks. Co się stanie kiedy nie wszystkie shardy będą dostępne? Indeksowanie nie powiedzie się. Aby to przetestować wystarczy, że uruchomimy dwie instancje Solr następującymi komendami:

$ bin/solr start -c

$ bin/solr start -z localhost:9983 -p 6983

A następnie stworzymy kolekcję:

$ bin/solr create_collection -c test_index -shards 2 -replicationFactor 1

Zabijemy jedną z instancji:

$ bin/solr stop -p 6983

I spróbujemy zaindeksować dane:

$ curl -XPOST -H 'Content-type:application/json' 'localhost:8983/solr/test_index/update' -d '{
 "id" : 2,
 "name" : "Test document"
}'

Oczywiście, tak jak mogliśmy się spodziewać Solr zwróci bład:

{
  "responseHeader":{
    "status":503,
    "QTime":4011},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"No registered leader was found after waiting for 4000ms , collection: test_index slice: shard2 saw state=DocCollection(test_index//collections/test_index/state.json/8)={\n  \"pullReplicas\":\"0\",\n  \"replicationFactor\":\"1\",\n  \"shards\":{\n    \"shard1\":{\n      \"range\":\"80000000-ffffffff\",\n      \"state\":\"active\",\n      \"replicas\":{\"core_node3\":{\n          \"core\":\"test_index_shard1_replica_n1\",\n          \"base_url\":\"http://192.168.1.11:8983/solr\",\n          \"node_name\":\"192.168.1.11:8983_solr\",\n          \"state\":\"active\",\n          \"type\":\"NRT\",\n          \"force_set_state\":\"false\",\n          \"leader\":\"true\"}}},\n    \"shard2\":{\n      \"range\":\"0-7fffffff\",\n      \"state\":\"active\",\n      \"replicas\":{\"core_node4\":{\n          \"core\":\"test_index_shard2_replica_n2\",\n          \"base_url\":\"http://192.168.1.11:6983/solr\",\n          \"node_name\":\"192.168.1.11:6983_solr\",\n          \"state\":\"down\",\n          \"type\":\"NRT\",\n          \"force_set_state\":\"false\",\n          \"leader\":\"true\"}}}},\n  \"router\":{\"name\":\"compositeId\"},\n  \"maxShardsPerNode\":\"-1\",\n  \"autoAddReplicas\":\"false\",\n  \"nrtReplicas\":\"1\",\n  \"tlogReplicas\":\"0\"} with live_nodes=[192.168.1.11:8983_solr]",
    "code":503}}

W tym wypadku nie jesteśmy w stanie zrobić nic – nie chcemy, aby nasze dane wylądowały gdziekolwiek. Musimy czekać, aż Solr powróci do stanu używalności, albo sami go do niego doprowadzimy

Co jednak w przypadku, kiedy mamy wiele replik i tylko niektóre z nich nie są dostępne? W tym wypadku zapis się powiedzie, a w najnowszych wersjach Solr poinformuje nas o stanie replikacji poprzez umieszczenie w odpowiedzi parametru rf, czyli replication factor.

Stwórzmy sobie zatem jeszcze jedną kolekcję, tym razem składającą się z jednego lidera i jego repliki:

$ bin/solr create_collection -c test_index_2 -shards 1 -replicationFactor 2

Jeżeli spróbujemy zaindeksować dane takim samym poleceniem jak wcześniej (oczywiście zmieniając nazwę kolekcji) odpowiedź Solr w wersji 7.6.0 będzie wyglądała następująco:

{
  "responseHeader":{
    "rf":2,
    "status":0,
    "QTime":316}}

Jak widać parametr rf ustawiony został na wartość 2, co mówi nam, że indeksowanie powiodło się zarówno na liderze, jak i jego replice. Jeżeli zatrzymalibyśmy instancję Solr działającą na porcie 6983 i spróbowali ponowić indeksowanie Solr poinformuje nas, iż tylko jedna replika danych została zapisana:

{
  "responseHeader":{
    "rf":1,
    "status":0,
    "QTime":4}}

We wcześniejszych wersjach Solr, aby otrzymać tą informację należało dodać parametr min_rf większy od 1 do żądania zawierającego indeksowanie, aby dostać informację, jaki poziom replikacji został osiągnięty przez Solr.

Tolerancja odczytu

W przypadku odczytu sprawy mają się trochę inaczej. Brak spójności danych, np. w przypadku braku jednego lub kliku shardów spowoduje, iż Solr zwróci błąd. Możemy to bardzo prosto pokazać – tworzymy dwie instancje Solr:

$ bin/solr start -c

$ bin/solr start -z localhost:9983 -p 6983

Następnie tworzymy prostą kolekcję:

$ bin/solr create_collection -c test -shards 2 -replicationFactor 1

A teraz zatrzymujemy jedną z instancji:

$ bin/solr stop -p 6983

I teraz wystarczy zadać proste zapytanie:

http://localhost:8983/solr/test/select?q=*:*

W odpowiedzi zamiast pustej listy dokumentów dostaniemy błąd:

{
  "responseHeader":{
    "status":503,
    "QTime":6,
    "params":{
      "q":"*:*"}},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"no servers hosting shard: shard2",
    "code":503}}

Czasami jednak chcielibyśmy zaprezentować wyniki wyszukiwania pomimo braku części informacji. Nie jest to oczywiście idealna sytuacja, ale czasem lepiej pokazać mniej danych, niż nie pokazać nic, oczywiście jeżeli zdajemy sobie sprawę co robimy. W tym celu przychodzą nam z pomocą dwa parametry: shards.tolerant oraz shards.info. Oba powinny zostać ustawione na wartość true, czyli nasze zapytanie przyjmie następującą formę:

http://localhost:8983/solr/test/select?q=*:*&shards.tolerant=true&shards.info=true

Tym razem Solr nie zwróci już błędu, a nagłówek odpowiedzi będzie wyglądał następująco:

{
  "responseHeader":{
    "zkConnected":true,
    "partialResults":true,
    "status":0,
    "QTime":45,
    "params":{
      "q":"*:*",
      "shards.tolerant":"true",
      "shards.info":"true"}},
  "shards.info":{
    "":{
      "error":"org.apache.solr.common.SolrException: no servers hosting shard: ",
      "trace":"org.apache.solr.common.SolrException: no servers hosting shard: \n\tat org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:165)\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)\n\tat org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat java.lang.Thread.run(Thread.java:748)\n",
      "time":0},
    "http://192.168.1.11:8983/solr/test_shard1_replica_n1/":{
      "numFound":0,
      "maxScore":0.0,
      "shardAddress":"http://192.168.1.11:8983/solr/test_shard1_replica_n1/",
      "time":18}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  }}

Jak widać, działa to tak jakbyśmy chcieli. Nie dostaliśmy od Solr błędu, a odpowiedź. Dodatkowo widzimy, iż zwrócone są częściowe rezultaty (partialResults ustawione na true), co pozwala nam lub naszej aplikacji na stwierdzenie, że coś jest nie tak. Oprócz tego opcja shards.info=true pozwoliła Solr zwrócić informacje których shardów brakuje.

Aby zilustrować różnicę postanowiłem zobaczyć, jak wygląda proces tworzenia kolekcji składającej się z dwóch części (shard’ów) i działającej na pojedynczej maszynie.

Solr 4.0

Solr.xml

Spójrzmy, jak wygląda proces tworzenia kolekcji w przypadku Solr 4.0. Czyścimy plik solr.xml, tak aby nie było w nim żadnych wpisów dotyczących rdzeni, jeżeli przechodzimy ze starej instancji Solr.

Uruchamiamy Solr

Następnie uruchamiamy pojedynczą instancję Solr, a wraz z nią ZooKeepera za pomocą następującej komendy:

java -DzkRun -jar start.jar

Przygotowanie konfiguracji

Przed stworzeniem kolekcji musimy przesłać konfigurację, którą zamierzamy użyć do jej stworzenia. Zakładając, że zainstalowałem Solr w katalogu /home/solrpl/solr/ oraz, że pliki konfiguracyjne umieściłem w katalogu /home/solrpl/configs/collection1/conf uruchamiam następujący skrypt dostępny wraz z Solr 4.0:

/home/solrpl/solr/cloud-scripts/zkcli.sh -cmd upconfig -zkhost localhost:9983 -confdir /home/solrpl/configs/collection1/conf/ -confname collection1

Stworzenie kolekcji

Jako, że mamy już konfigurację z ZooKeeperze możemy stworzyć nową kolekcję korzystając z API kolekcji. W tym celu wysyłamy zapytanie do /solr/admin/collections z parametrem action=CREATE mówiącym, że chcemy stworzyć kolekcję. Dodatkowo podajemy jej nazwę (parametr name=collection1). Oprócz tego informujemy Solr, że chcemy podzielić kolekcję na dwie części (parametr numShard=2) oraz, że w tym momencie nie chcemy replik (replicationFactor=0). Zatem pełne zapytanie wygląda następująco:

curl 'http://localhost:8983/solr/admin/collections?action=CREATE&name=collection1&numShards=2&replicationFactor=0'

Widok panelu administracyjnego

Widok chmury w panelu administracyjnym, po uruchomieniu powyższego polecenia, wygląda następująco:

Kilka słów komentarza

Jak widać, Solr 4.0 nie pozwolił nam na umieszczenie dwóch części tej samej kolekcji na jednej instancji Solr. Część oznaczona jako shard1 została umieszczona na maszynie xubuntu-virtual, ale już część shard2 nie została umieszczona na tej maszynie, co oznacza, że nie mamy dostępnej pełnej kolekcji. Oczywiście, jeżeli mielibyśmy więcej, niż jedną instancję Solr sytuacja uległaby zmianie, ale nie o tym mowa w niniejszym wpisie.

Solr 4.1

Solr.xml

Podobnie jak w przypadku Solr 4.0 zaczynamy od czyszczenia pliku solr.xml, który powinien wyglądać tak samo, jak poprzednio. Oczywiście, jeżeli przechodzimy ze starszej wersji Solr.

Uruchamiamy Solr

Następnie uruchamiamy pojedynczą instancję Solr, a wraz z nią ZooKeepera za pomocą dokładnie tej samej komendy co poprzednio:

java -DzkRun -jar start.jar

Przygotowanie konfiguracji

Podobnie jak w przypadku Solr 4.0, do wrzucenia konfiguracji do ZooKeepera korzystamy z tego samego polecenia:

/home/solrpl/solr/cloud-scripts/zkcli.sh -cmd upconfig -zkhost localhost:9983 -confdir /home/solrpl/configs/collection1/conf/ -confname collection1

Stworzenie kolekcji

Podobnie, jak w przypadku Solr 4.0 musimy teraz stworzyć kolekcję. Parametry action, collection i numShards nie ulegają zmianie. Dochodzi nowy parametr – maxShardsPerNode, określający maksymalną ilość części z jednej kolekcji, jaką Solr może umieścić na tej samej instancji Solr (domyślnie ustawiony na wartość 1). W naszym wypadku, ze względu na to, że chcemy mieć maksymalnie dwie części kolekcji umieszczone w ramach jednej instancji, ustawiamy ten parametr na wartość 2. Dodatkowo Solr wymusza na nas stworzenie przynajmniej jednej repliki i dlatego ustawiliśmy parametr replicationFactor na 1. Całe zapytanie wygląda następująco:

curl 'http://localhost:8983/solr/admin/collections?action=CREATE&name=collection1&numShards=2&replicationFactor=1&maxShardsPerNode=2'

Widok panelu administracyjnego

Widok chmury w panelu administracyjnym, po uruchomieniu powyższego polecenia, wygląda następująco:

Kilka słów komentarza

Jak widać w przypadku Solr 4.1 byliśmy w stanie stworzyć kolekcję podzieloną na dwie części, które to części umieszczone są w ramach tej samej instancji Solr. Zatem jeżeli ogranicza Was obecna funkcjonalność Solr 4.0, która na to nie pozwala, można ze spokojem oczekiwać Solr 4.1.