migrate

Polecenie "migrate"

Pozwala na migrację konfiguracji lokalnych serwisów. Migracja oznacza wyznaczenie dla każdego serwisu szablonu konfiguracyjnego oraz detekcję różnic między bieżącą konfiguracją a szablonem konfiguracyjnym.

Dostępne są migracje konfiguracji:

  • sowa2 - migracja konfiguracji zainstalowanych serwisów typu SOWA2 (przejÄ™cie kontroli nad plikiem .inf, katalog.ini oraz index.py)
  • sowasql - migracja konfiguracji zainstalowanych serwisów typu SOWASQL (przejÄ™cie kontroli nad caÅ‚ym katalogiem etc/)

Składnia

sowizor migrate sowa2|sowasql
sowizor migrate <sid> [--force] [--nodelete] [--ignore-params|--generate-params] [--generate-services] [--use-schema=<hid>] [--override-records]

Migracja konfiguracji serwisów SOWA2 i SOWASQL

Wydając polecenie z parametrem sowa2 lub sowasql można wyświetlić listę serwisów, potencjalnie nadających się do migracji.

PodajÄ…c jako parametr identyfikator <sid> uruchamia siÄ™ migracjÄ™ serwisu (o ile jest to serwis SOWA2 lub SOWASQL).

Jest to zaawansowany, skomplikowany proces, który wymaga szczegółowej wiedzy na temat architektury systemu i sposobu jego konfiguracji. Z tego powodu wskazane jest przeprowadzanie tej operacji pod nadzorem pracowników firmy SOKRATES-software.

Proces ten dzieli się na fazę check (detekcja ustawień) i start (wykonanie migracji).

Etapy w fazie check

  • detekcja schematu (schemat okreÅ›la przeznaczenie serwisu, ukÅ‚ad katalogu, dostÄ™pne rekordy i bazy aplikacji)
  • detekcja używanych typów rekordów
  • wykrycie różnic w konfiguracji pól logicznych rekordów SOWY2
  • sprawdzenie poprawnoÅ›ci parametrów systemu
  • wykrycie używanych usÅ‚ug katalogu SOWY2 (detekcja m.in. formatów, zestawieÅ„, programów, indeksów, kryteriów itd.)
  • sprawdzenie dostÄ™pnoÅ›ci i poprawnoÅ›ci struktur plików DBF (nie dotyczy wersji SQL)

Po zakończeniu fazy check, program dla każdego migrowanego serwisu wyświetli podsumowanie i możliwe dalsze kroki migracji. Możliwe są następujące statusy:

  • Migracja już wykonana - oznacza to, że serwis zostaÅ‚ już wczeÅ›niej zmigrowany i nie ma potrzeby robić tego ponownie. Można to jednak wymusić podajÄ…c opcjonalny argument --force.
  • Migracja możliwa: katalog gotowy do automatycznej migracji
  • Migracja możliwa: zalecana weryfikacja przez specjalistÄ™ - ten status wystÄ…pi w przypadku stwierdzenia istotnych różnic np. w konfiguracji struktur pól logicznych rekordów SOWA2. Wymagana jest Å›wiadoma decyzja o aktualizacji tych struktur do wykrytego (lub zadeklarowanego) schematu konfiguracyjnego.
  • Migracja niemożliwe: wymagana aktualizacja rÄ™czna - ten status wystÄ…pi w przypadku, gdy proces automatycznej detekcji ustawieÅ„ napotkaÅ‚ na problemy wymagajÄ…ce rÄ™cznej ingerencji. JeÅ›li operator programu nie wykona odpowiednich modyfikacji, wówczas migracja automatyczna nie bÄ™dzie możliwa.
  • Konieczność kontaktu z firmÄ… SOKRATES-software - ten status oznacza, że napotkano serwis o konfiguracji wyjÄ…tkowo niestandardowej (której nie opisuje żaden dostÄ™pny szablon konfiguracyjny)

Rozwiązywanie problemów

W trakcie detekcji ustawień program może napotkać problemy wymagające podjęcia dodatkowych kroków lub decyzji przez operatora. Zwykle w tym momencie proces analizy jest przerywany i wyświetlana jest sugestia na temat możliwych sposobów rozwiązania problemów. Rozwiązać je można albo poprzez poprawienie bieżącej konfiguracji (i w ten sposób wyeliminowanie problemu) lub użycie sugerowanych opcji dodatkowych wywołania polecenia.

  • Napotkano niepoprawne (nieznane) parametry w plikach parametry.inc oraz katalog.ini.
    Wszystkie dopuszczalne parametry są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Zdarzają się sytuacje w których w migrowanym serwisie pojawi się parametr, którego definicji nie ma w szablonie. Zwykle jest to wynik błędu użytkownika (użycie niepoprawnej składni polecenia administracyjnego), niekiedy zaś jest to lokalny parametr stosowany tylko i wyłącznie w danej instalacji. W zależności od tego jakiego rodzaju jest ów nieznany parametr, należy użyć jednej z dostępnych opcji:
    --ignore-params - ignoruje nieznane parametry i kontynuuje migrację. Parametry te zostaną usunięte z konfiguracji serwisu.
    --generate-params - generuje lokalne definicje parametrów, a ich bieżącą wartość ustawia jako domyślną. Parametry te zostaną zachowane w konfiguracji serwisu.
  • Napotkano niepoprawne (nieznane) serwisy/usÅ‚ugi w pliku .inf
    Wszystkie dopuszczalne w standardowych instalacjach serwisy/usługi są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Dość częstym przypadkiem jest jednak definiowanie lokalnych serwisów (np. nietypowe zestawienia, programy, czy formaty wyświetlania lub indeksy). W większości przypadków właściwym rozwiązaniem tego problemu jest użycie opcji --generate-services. Dzięki temu wygenerowane zostaną lokalne definicje nietypowych serwisów i zostaną one zachowane w konfiguracji.
  • Nie udaÅ‚o siÄ™ okreÅ›lić schematu konfiguracyjnego dla ceÅ‚ego serwisu.
    Jest to rzadki przypadek, w którym nie udało się określić schematu dla migrowanego serwisu. W takiej sytuacji można wymusić użycie schematu o podanej nazwie, np.:
    --use-schema=marc21-akc - powoduje użycie schematu dla serwisu katalogu bibliotecznego w formacie MARC21 z akcesją dokumentów zwartych.
  • Napotkano konflikt oznaczeÅ„ indeksów dla rekordów
    W takim przypadku zwykle konieczna jest fachowa ingerencja pracownika SOKRATES-software. Jednym z możliwych rozwiązań jest użycie opcji --override-records, która spowoduje zignorowanie konfliktu i zastosowanie oznaczeń zdefiniowanych w szablonach konfiguracyjnych. Należy używać tej opcji z dużą ostrożnością.

Etapy w fazie start

Serwis, który przejdzie przez etap check można ostatecznie zmigrować wywołując polecenie z parametrem start.

Uwaga na temat opcji polecenia

Jeśli na etapie check użyto opcji rozwiązywania problemów (np. --ignore-params czy --generate-services) - na etapie start trzeba je powtórzyć!

Migracja wykona następujące czynności:

  • w razie koniecznoÅ›ci zainstaluje i skonfiguruje moduÅ‚ SMAILER
  • wygeneruje i obejmie nadzorem plik katalog.ini (zlikwiduje to wszystkie dotychczasowe pliku .inc w katalogu bazy danych)
  • wygeneruje i obejmie nadzorem plik index.py (stosowany do reindeksacji bazy danych w trybie offline)
  • jeÅ›li jest to wymagane - przeprowadzi migracjÄ™ struktur plików DBF
  • jeÅ›li jest to wymagane - wykona reindeksacjÄ™ nowo utworzonych lub zmienionych plików DBF
  • przeniesie konfiguracjÄ™ wysyÅ‚ki poczty do moduÅ‚u SMAILER
  • wygeneruje lokalny wariant schematu sÅ‚użący do automatycznego generowania konfiguracji
  • wygeneruje i obejmie nadzorem nowy plik konfiguracyjny .inf

Proces ten archiwizuje dotychczasowe ustawienia, dzięki czemu można w razie potrzeby odzyskać starą konfigurację. Domyślnie jest ona archiwizowana i usuwana. Można to zmienić dzięki opcji --nodelete - podanie jej spowoduje, że dotychczasowa konfiguracja nie zostanie usunięta, lecz tylko zostaną przemianowane pliki na rozszerzenie .old.

Zmiana bazowego schematu serwisu

Polecenie migrate służy także do zmiany bazowego schematu serwisu. W ten sposób można np. rozszerzyć funkcjonalność serwisu - do serwisu obsługującego katalogowanie MARC21 dołożyć typy rekordów i programy dla zasobów czasopism, albo np. do akcesji zbiorów. W szczególności należy jednak pamiętać, że jedyne bezpieczne migracje wykonuje się od schematu węższego do szerszego. "Obcinanie" funkcjonalności (czyli np. usuwanie akcesji) wymaga wcześniejszego zweryfikowania, że dla usuwanych typów rekordów nie ma żadnych danych w bazie.

Operacja zmiany schematu bazowego jest oparta na tych samych mechanizmach, co zwykła migracja. Wymagane jest jedynie użycie parametru --use-schema=<hid>. Listę dostępnych schematów można zobaczyć w dokumentacji polecenia add.

Przykład zmiany schematu bazowego na marc21 + zasoby czasopism
sowizor migrate biblioteka_pub_ks start --use-schema=marc21-zasob

 

Â