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.

Do pokazania, jak działa nowa funkcjonalność Solr porównajmy dwie sytuacje – kopiowanie indeksu bez żadnych limitów oraz kopiowanie indeksu podczas ustawionego limitu. W tym celu weźmiemy indeks mający około 2GB i zobaczymy jak wygląda wykorzystanie sieci podczas domyślnej konfiguracji replikacji oraz wtedy, kiedy mamy ustawione limity. Do tego celu wykorzystamy wdrożenie oparte o SolrCloud. Należy jednak pamiętać, iż sposób ten działa także we wdrożeniach opartych o architekturę master – slave.

Replikacja bez limitów

Do replikacji bez limitów wykorzystujemy następującą konfigurację:

<requestHandler name="/replication" class="solr.ReplicationHandler">
</requestHandler>

A tak wygląda wykorzystanie sieci podczas replikacji:

Replikacja z limitami

Do replikacji z limitami wykorzystujemy następującą konfigurację:

<requestHandler name="/replication" class="solr.ReplicationHandler">
 <lst name="defaults">
  <str name="maxWriteMBPerSec">0.1</str>
 </lst>
</requestHandler>

Wykorzystanie sieci w chwili replikacji wygląda następująco:

Jak widać różnica pomiędzy dwoma scenariuszami jest znaczna.

Podsumowanie

Jak widać sama konfiguracja jest banalna i działa. Oczywiście działa nie tylko w przypadku wdrożenia opartego o SolrCloud, ale także w bardziej tradycyjnym master – slave. Jedyne czego mi teraz brakuje, to możliwości kontroli za pomocą dedykowanego API, ale to może w przyszłości

Na początek

Zdecydowaliśmy się opisać te zagadnienie pomimo tego, iż jest bardzo proste. Zauważyliśmy jednak, iż dużo ludzi zapomina o oczywistych funkcjonalnościach, nie tylko w przypadku Apache Solr. Mamy nadzieję, że ten wpis przypomni użytkownikom o tej funkcjonalności, przynajmniej tym, którzy będą jej potrzebować. Zacznijmy od stanu początkowego – zawartość katalogu, w której znajduje się indeks, przed rozpoczęciem testów wyglądała następująco:

drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:17 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker

Ręczna Kopia Bezpieczeństwa

Aby wykonać ręczną kopię bezpieczeństwa indeksu, przy pomocy wywołania API HTTP, należy mieć skonfigurowany handler odpowiadający za replikację. Jeżeli handler ten jest obecny, wysyłamy do niego (na serwerze master) parametr command z wartością backup, na przykład:

curl 'http://localhost:8983/solr/replication?command=backup'

Spowoduje to utworzenie kopii bezpieczeństwa naszego indeksu. Tak wygląda katalog w którym znajduje się indeks po wykonaniu powyższego polecenia:

drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:18 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:19 snapshot.20120812201917
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker

Jak widać kopia zapasowa indeksu została utworzona w katalogu snapshot.20120812201917.

Automatyczna Kopia Bezpieczeństwa

Oprócz ręcznego tworzenia kopii bezpieczeństwa mamy także możliwość wykonania kopii indeksu po każdej operacji commit, bądź optimize. Jeżeli twój indeks zmienia się bardzo często sugerujemy nie korzystania z tej funkcjonalności, ewentualnie skorzystania z tworzenia kopii bezpieczeństwa po otrzymaniu komendy optimize.

Na początek, dodajemy następujący wpis do konfiguracji handler’a replikacji:

<str name="backupAfter">commit</str>

Zatem pełna konfiguracja serwera master mogłaby wyglądać następująco:

<requestHandler name="/replication" >
 <lst name="master">
  <str name="replicateAfter">commit</str>
  <str name="replicateAfter">startup</str>
  <str name="confFiles">schema.xml,stopwords.txt</str>
  <str name="backupAfter">commit</str>
 </lst>
</requestHandler>

Po wysłaniu dwóch poleceń commit katalog z indeksem wyglądał następująco:

drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 snapshot.20120812211203
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 snapshot.20120812211216
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker

Tutaj także można zobaczyć, że Solr wykonał to co chcieliśmy, czyli stworzył dwa katalogi z kopią indeksu.

Utrzymywanie porządku

Możliwa jest kontrola tego, jak dużo kopii bezpieczeństwa naszego indeksu będziemy przechowywać. W celu określenia tej ilości należy dodać następujący wpis do konfiguracji handler’a replikacji:

<str name="maxNumberOfBackups">10</str>

Powyższy wpis mówi Solr, aby nie przechowywał więcej, niż 10 kopi bezpieczeństwa. Oczywiście możliwe jest także ręczne usuwanie stworzonych przez Solr kopii, jeżeli nie są już nam potrzebne.