Każda wersja Firebird ma swoją własną wersję formatu dyskowych struktur bazy danych – O(n)D(isk)S(tructure). Do wersji 2.5 włącznie, silnik Firebird mógł działać z ODS wcześniejszych wersji, co oznacza, że bazy z starszych wersji były otwierane w nowej wersji i działały w trybie zgodności, ale silnik Firebird 3.0 działa tylko z bazami w swojej własnej wersji ODS 12.0.
Aby przejść na 3.0, bazę danych z 2.5 należy przekształcić do nowego formatu poprzez backup/restore. Oczywiście, zakładamy, że baza danych została wcześniej przygotowana do konwersji – tzn. metadane i zapytania zostały sprawdzone pod kątem zgodności z Firebird 3.0.
Jeżeli zastosować standardowe podejście, oznacza to, że należy wykonać backup w wersji 2.5, następnie zainstalować 3.0 i wykonać restore. Taka procedura jest akceptowalna, jeśli jest wystarczająco dużo czasu, ale przy migracji dużych baz danych, lub przy jednoczesnej migracji kilku dziesiątek baz danych, gdy czas jest ograniczony, można skorzystać z potokowej konwersji, która jest o 30-40% szybsza. Jak dokładnie to zrobić (na Windows i Linux), przeczytasz poniżej.
Ogólna idea polega na tym, że dla przyspieszenia skorzystamy z rurociągu:
gbak -b … baza25 stdout | gbak -c … stdin baza30Gbak w wersji 2.5 generuje backup w formacie liniowym i wysyła go do stdout, który następnie natychmiast przez stdin odbiera gbak w wersji 3.0 i tworzy nową bazę danych.
Taki rurociąg należy organizować wyłącznie lokalną (plikową) metodą dostępu, ponieważ dostęp sieciowy (nawet przez localhost) znacznie spowolni proces.
Poniżej omawiamy szczegóły dla Windows i Linux.
Windows
W przypadku Windows najprościej jest wykonać całkowicie autonomiczną wersję Firebirda. W tym celu bierzemy , zmieniamy nazwę fbemded.dll na fbclient.dll, dodajemy z archiwum "zwykłego" 2.5 narzędzie gbak.exe i (opcjonalnie) – isql.exe.
Firebird 3.0 używa i nie wymaga żadnych poprawek.
Najmniejsza wersja (nie wymagająca instalacji bibliotek runtime VS2008/VS2010 na docelowym systemie) zawiera następujące pliki:
25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll
30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dllDoświadczony administrator może zauważyć, że w wersji 2.5 nie są dołączone pliki intl/fbintl.dll i intl/fbintl.conf. Rzeczywiście, ponieważ gbak nie wykorzystuje zestawu znaków połączenia oraz nie konwertuje danych między zestawami znaków, ale po stronie 'odbiorczej' Firebird 3.0 te pliki są niezbędne do tworzenia indeksów.
W pliku firebird.conf dla Firebird 3.0 zaleca się dodać:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Dodatkowo warto ustawić różne wartości dla IpcName dla wersji 2.5 i 3.0.
Wybierając wartości innych parametrów firebird.conf, kierujemy się prostą zasadą: podczas migracji danych w jednym procesie działa gbak 2.5, a w drugim – 3.0, następnie 2.5 kończy działanie, a 3.0 rozpoczyna budowę indeksów.
Aby przyspieszyć etap budowania indeksów w 3.0, zaleca się zwiększenie rozmiaru parametru TempCacheLimit do ~40% RAM (jeśli to serwer dedykowany, oczywiście).
Na przykład, jeśli na serwerze jest 16 GB RAM, można ustawić
TempCacheLimit=6GOczywiście, taką wartość można ustawić tylko w 64-bitowym Firebird 3, ponieważ jakikolwiek proces 32-bitowy nie będzie w stanie alokować więcej niż 2 GB pamięci.
W przypadku 2.5 ten parametr nie wymaga zmiany – i tak nie może być większy niż 2 GB, a przy tworzeniu kopii zapasowej nie ma wpływu na prędkość.
Przed przystąpieniem do operacji należy upewnić się, że bufor stron w nagłówku bazy danych jest ustawiony na 0 (komenda gstat -h databasename, zobacz linię Page buffers).
Jeśli bufor został jawnie określony w nagłówku bazy danych, to nadpisuje wartości z firebird.conf (i databases.conf w 3.0), a przy nieadekwatnie dużych wartościach może prowadzić do nadmiernego zużycia pamięci i przeniesienia do swapu.
Następnie kopiujemy pliki na docelowy system.
Konwersja przeprowadzana jest po zatrzymaniu 'systemowej' usługi Firebird 2.5, w wierszu poleceń z podniesionymi uprawnieniami do lokalnego administratora (przykład):
set ISC_USER=właściciel
"25/gbak" -z -b -g -v -st t -y 25.log baza25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin baza30W tym przykładzie używana jest 'prosta ukośna' w cudzysłowach (dozwolony 'unix-style'), a 'daszek' (znak '^') eskapiuje znak nowej linii, co jest wygodne przy wpisywaniu długich komend. Opcja -st (atus) pojawiła się w Firebird 2.5.8 i umożliwia zapis danych o czasie działania procesu gbak w protokole (szczegóły – w dokumentacji).
Linuxa
Na Linuxie Firebird 3 zależy od biblioteki tommath. W CentOS (RHEL) ta biblioteka znajduje się w repozytorium epel, w Ubuntu (Debian) – w systemowym.
Aby zainstalować CentOS, najpierw trzeba podłączyć repozytorium epel, a dopiero potem wykonać
yum install libtommathW Ubuntu nie trzeba podłączać dodatkowych repozytoriów, jednak w Ubuntu 16 i Ubuntu 18 instalowane są różne wersje pakietów – odpowiednio libtommath0 i libtommath1.
Firebird 3.0 szuka tommath.so.0 i dla Ubuntu 18 dodatkowo należy utworzyć symlink do tommath.so.1. W tym celu trzeba najpierw znaleźć tommath.so.1.
Szukana ścieżka w Ubuntu to /usr/lib/x86_64-linux-gnu/, ale w innych dystrybucjach opartych na Debianie może być inaczej.
Drugim problemem jest to, że do Firebird 3.0.1 włącznie nie było prostego sposobu na zainstalowanie dwóch różnych wersji serwera. Opcję 'kompilujemy ze źródeł z odpowiednim prefiksem' pomijamy z powodu względnej pracochłonności.
Dla Firebird 3.0.2 i nowszych zrealizowano i oddzielną opcję instalatora (-path ścieżka).
Zakładając, że biblioteka tommath oraz, w razie potrzeby, symlink dla tommath.so.0 zostały dodane do systemu, można zainstalować aktualny (w momencie pisania tego artykułu) dystrybucyjny Firebird 3.0.4 do, na przykład, /opt/fb3:
./install.sh -path /opt/fb3Po tym można zatrzymać systemową usługę Firebird i rozpocząć konwersję strumieniową.
Podczas zatrzymywania Firebird należy pamiętać, że procesy Firebird 2.5 w trybie Classic zwykle uruchamia xinetd – dlatego należy albo zablokować usługę firebird dla xinetd, albo całkowicie zatrzymać xinetd.
W firebird.conf dla wersji 3.0 na Linux nie trzeba ustawiać parametrów MaxUnflushed (działają tylko na Windows) ani zmieniać ustawień Firebird 2.5.
W Linuksie lokalny (plikowy) dostęp do Firebird 2.5 nie jest równoważny z wariantem embeded pod Windows – serwer 2.5 będzie działał w procesie gbak (bez części sieciowej), ale prawa dostępu będą sprawdzane na podstawie bazy użytkowników, co oznacza, że będziemy potrzebować nie tylko loginu, ale również hasła:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … baza25 stdout
|/opt/fb3/bin/gbak -c … stdin baza30Po udanej konwersji najpierw należy usunąć 'dodatkowy' Firebird 3.0, następnie 'główny' Firebird 2.5, a potem przeprowadzić czystą instalację Firebird 2.5 – najlepiej z standardowego instalatora tar.gz, a nie przez repozytoria, ponieważ wersja w repozytoriach może być przestarzała.
Ponadto, po przywróceniu bazy danych na Linuxie i ponownej instalacji, należy upewnić się, że nowa baza danych ma użytkownika firebird jako właściciela.
Jeśli tak nie jest, to należy to poprawić
chown firebird.firebird databasePodsumowanie
Oprócz oszczędności czasu i miejsca na dysku, konwersja strumieniowa ma jeszcze jedną istotną zaletę – przekształcenie bazy odbywa się bez usuwania istniejącego Firebird 2.5, co zdecydowanie ułatwia cofnięcie w przypadku nieudanej konwersji (najczęściej z powodu braku miejsca lub niespodziewanego restartu podczas procesu migracji).
Oszczędność czasu związana jest z tym, że „klasyczna” konwersja to „czas kopii zapasowej” plus „czas przywracania”. Przywracanie składa się z dwóch etapów: odczyt danych z pliku kopii zapasowej oraz budowa indeksu.
Przy konwersji strumieniowej całkowity czas wynosi „czas kopii zapasowej plus pięć-dziesięć procent” oraz „czas budowy indeksów”.
Konkretne wyniki zależą od struktury bazy, ale średnio czas przywracania jest w przybliżeniu równy podwójnemu czasowi kopii zapasowej. Dlatego, przyjmując czas kopii zapasowej jako jednostkę, „klasyczna konwersja” wynosi trzy jednostki czasu, a strumieniowa – dwie jednostki czasu. Dodatkowo skrócenie czasu pomaga zwiększenie TempCacheLimit.
Ogólnie rzecz biorąc, konwersja strumieniowa w praktyce pozwala zaoszczędzić 30-40% czasu w porównaniu do sekwencyjnej kopii zapasowej i przywracania.
Masz pytania?
Proszę, wszystkie pytania kieruj w komentarzach lub wysyłaj do autora metodyki i współautora tego artykułu – Wasyla Sidorowa, wiodącego inżyniera systemowego firmy „iBase”, na adres bs at ibase ru.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Jakiej wersji Firebird używasz?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 lub 1.0
16 użytkowników zagłosowało. 1 użytkownik wstrzymał się.
Źródło: habr.com
