Z której wersji do Solr 8?

Pierwsze o czym należy powiedzieć, to zmiany związane z odzyskiwaniem, które zostały opublikowane wraz z Solr 7.3. Ze względu na nie nie ma możliwości migracji do Solr 8 z wersji Solr starszej, niż Solr 7.3 bez pełnego restartu klastra.

Dodatkowo musimy pamiętać, iż wersja 8.0 biblioteki Lucene, a tym samym Solr w wersji 8 nie będzie w stanie przeczytać danych zaindeksowanych przy pomocy Solr 5.x. Co za tym idzie, jeżeli chcemy migrować ze starszej wersji Solr czeka nas powolna migracja i przepisywanie danych lub po prostu pełna indeksacja.

Migracja z Solr 7.3 i nowszych

W przypadku migracji z Solr 7.3 lub nowszych istnieje sposób pozwalający na aktualizację całego klastra SolrCloud do wersji 8 bez konieczności pełnego wyłączenia klastra, który aktualizujemy. Jak powinna wyglądać taka procedura:

1. Przygotowujemy klaster do aktualizacji, sugerowane jest wykonanie kopii zapasowej danych, kopii zapasowej danych z Zookeepera, itd.
2. Wyłączamy pojedynczą instancję Solr,
3. Aktualizujemy wyłączoną instancję do wersji 8.0,
4. Dodajemy parametr -Dsolr.http1=true do SOLR_OPTS w pliku konfiguracyjnym solr.in.sh,
5. Uruchamiamy zaktualizowaną instancję Solr,
6. Czekamy na stabilizację klastra i ewentualną replikację danych,
7. Zaczynamy aktualizację kolejnej instancji Solr, czyli przechodzimy do punktu 2), ale dla kolejnej instancji.

Po aktualizacji wszystkich instancji Solr musimy wykonać kolejną rundę restartów. Tym razem dla każdej instancji Solr, która działa w naszym klastrze musimy przeprowadzić następujące czynności:

1. Wyłączamy pojedynczą instancję Solr,
2. Usuwamy parametr -Dsolr.http1 z SOLR_OPTS z pliku konfiguracyjnego solr.in.sh,
3. Uruchamiamy Solr po modyfikacji konfiguracji,
4. Czekamy na stabilizację klastra i ewentualną replikację danych,
5. Zaczynamy zmianę konfiguracji kolejnej instancji Solr, czyli przechodzimy do punktu 1), ale dla kolejnej instancji Solr.

Dodatkowa runda restartów – dlaczego?

Możesz zastanawiać się dlaczego wykonujemy dodatkową rundę restartów po dokonanej już aktualizacji do wersji 8.0. Problem leży u podstaw zmian, które zostały wprowadzone do najnowszej wersji Solr. Wraz z wersją 8.0 komunikacja wewnętrzna pomiędzy instancjami Solr odbywa się przy pomocy protokołu HTTP/2. Wykorzystanie tego protokołu i zmiany związane z jego implementacją spowodowały dość znaczne usprawnienie oraz przyspieszenie komunikacji, ale także powoduje problemy z wsteczną kompatybilnością. Z tego względu, przy pierwszym uruchomieniu Solr 8.0, od razu pod aktualizacji z Solr 7.x, wymuszamy wsteczną kompatybilność poprzez dodanie parametru -Dsolr.http1=true. Oczywiście po skończonej aktualizacji klastra chcemy skorzystać z wszystkich nowych funkcjonalności i usprawnień i dlaczego usuwamy dodany parametr i znowu restartujemy Solr.

Czy jest się czego obawiać

Każda migracja niesie za sobą pewną dozę ryzyka i możliwych komplikacji, dlatego warto się do niej dobrze przygotować oraz zaplanować ją w czasie kiedy nie mamy największego obciążenia klastra. Dodatkowo, jeżeli możemy ograniczyć indeksowanie danych w czasie migracji do nowej wersji Solr czas inicjalizacji oraz ewentualnej replikacji danych na poszczególnych instancjach Solr będzie znacząco szybsza. Warto o tym pomyśleć planując migrację do Solr 8. Powodzenia!

Osobiście, jestem zwolennikiem rozwiązań, które mają jak najmniejszą szansę powodować problemy – po prostu lubię w nocy spać. Do takich rozwiązań zaliczam usunięcie indeksu po modyfikacji jego struktury, a następnie pełną indeksację danych. Zdaję sobie jednak sprawę, że nie zawsze takie rozwiązanie jest akceptowalne. Kiedy zatem nie jesteśmy zmuszeni do usunięcia indeksu, a kiedy nie usunięcie indeksu naraża nas na ewentualne problemy z poprawnym działaniem Solr ?

Odpowiedź na pytanie zależy od tego, co zmieniliśmy w strukturze indeksu. Zmiany takie, można podzielić na trzy obszary obejmujące większość ze zmian jakie możemy dokonać w strukturze indeksu:

• Dodanie/usunięcie nowego pola
• Modyfikacja podobieństwa (Similarity)
• Modyfikacja typu pola

Dodanie/usunięcie nowego pola

W przypadku pierwszego typu modyfikacji sprawa jest dość prosta – jeżeli dodamy do schema.xml (bądź usuniemy) nowe pole, nie ma konieczności usuwania całego indeksu przed ponowną indeksacją. Solr poradzi sobie z dodaniem nowego pola, do aktualnego indeksu. Oczywiście, należy sobie zdawać sprawę, iż dokumenty, które nie będą po tej operacji ponownie zaindeksowane nie będą automatycznie uaktualnione.

Modyfikacja podobieństwa

W drugim przypadku, czyli przy ewentualnej zmianie klasy odpowiedzialnej za Similarity także nie musimy usuwać indeksu po zmianie schema.xml. Jednak w odróżnieniu od poprzedniego przykładu, do poprawnego wyliczania współczynnika score, a tym samym do poprawnego sortowania będzie konieczna ponowna indeksacja wszystkich dokumentów wcześniej obecnych w indeksie.

Modyfikacja typu pola

Zatrzymajmy się na trzecim przypadku. Załóżmy, że modyfikujemy nieznacznie pole w indeksie z prozaicznej przyczyny – przestaje interesować nas normalizacja jego długości. Ustawiamy sobie omitNorms=”true” (zakładam, iż wcześniej było omitNorms=”false”). Indeksujemy ponownie wszystkie dokumenty, Lucene łączy nam indeksy i co się okazuje – dalej w połączonych segmentach mamy dalej znormalizowane informacje o długości pola. Coś poszło nie tak. To jest właśnie ten przypadek kiedy konieczne jest usunięcie indeksu po zmianie jego struktury, a przed pełną indeksacją. Na pierwszy rzut oka wygląda, iż jest to bardzo mała zmiana, jednak zastanawiając się dalej, mamy takie, a nie inne skutki. Warto pamiętać, iż niektóre z właściwości pól są nadpisywane przez inne, tak jak w przypadku normalizacji długości – jeżeli w jednym segmencie pole będzie posiadało normalizację, a w drugim nie, to po połączeniu segmentów otrzymamy jeden, w którym to pole będzie posiadało normalizację.