Strumieniowa konwersja baz danych Firebird 2.5 do formatu ODS12 (Firebird 3.0)

Każda wersja Firebirda ma własną wersję formatu struktury dysku bazy danych, O(n)D(isk)S(tructure). Do wersji 2.5 włącznie silnik Firebird mógł współpracować z ODS poprzednich wersji, to znaczy bazy danych ze starych wersji były otwierane przez nową wersję i działały w trybie zgodności, ale silnik Firebird 3.0 działa tylko z bazami danych we własnej wersji ODS 12.0.

Aby przeprowadzić migrację do wersji 3.0, bazę danych z wersji 2.5 należy przekonwertować do nowego formatu za pomocą funkcji tworzenia kopii zapasowej/przywracania. Oczywiście zakładamy, że baza została wcześniej przygotowana do konwersji – tj. metadane i zapytania zostały sprawdzone pod kątem zgodności z Firebird 3.0.

Jeśli postępujesz zgodnie ze standardowym podejściem, oznacza to, że musisz wykonać kopię zapasową w wersji 2.5, a następnie zainstalować wersję 3.0 i przywrócić. Taka procedura jest dopuszczalna, jeśli jest na to wystarczająco dużo czasu, ale przy migracji dużych baz danych lub migracji kilkudziesięciu baz jednocześnie, gdy czas ucieka, można skorzystać z konwersji strumieniowej, która jest o 30-40% szybsza. Jak dokładnie to zrobić (w systemie Windows i pod Linuksem), przeczytaj pod nacięciem.

Ogólny pomysł jest taki, że użyjemy potoku, aby przyspieszyć działanie:

gbak -b … база25 stdout | gbak -c … stdin база30

Gbak z wersji 2.5 generuje kopię zapasową w formacie liniowym i wysyła ją na standardowe wyjście, które natychmiast pobiera gbak z wersji 3.0 przez stdin i tworzy nową bazę danych.

Konieczne jest zorganizowanie takiego potoku z lokalną (plikową) metodą dostępu, ponieważ dostęp do sieci (nawet przez localhost) znacznie spowolni ten proces.

Poniżej omówimy szczegóły dotyczące systemów Windows i Linux.

Windows

W przypadku Windowsa najłatwiej jest zrobić całkowicie samodzielną kompilację Firebirda. Do tego bierzemy osadzone archiwum Firebird 2.5, zmień nazwę fbemded.dll na fbclient.dll, dodaj narzędzia gbak.exe i (opcjonalnie) isql.exe ze „zwykłego” archiwum 2.5.

Używa Firebirda 3.0 pojedynczy montaż i nie wymaga żadnych modyfikacji.

Wersja minimalna (która nie wymaga instalacji bibliotek wykonawczych VS2008/VS2010 w systemie docelowym) 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.dll

Doświadczony administrator może zauważyć, że wersja 2.5 nie zawiera plików intl/fbintl.dll i intl/fbintl.conf. To prawda, ponieważ gbak nie używa zestawu znaków połączenia i nie konwertuje danych między zestawami znaków, ale po stronie „odbiorczej” Firebirda 3.0 pliki te są potrzebne podczas tworzenia indeksów.

W firebird.conf Firebird 3.0 zaleca się dodanie:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Pożądane jest również ustawienie różnych wartości IpcName dla wersji 2.5 i 3.0.

Wybierając wartości innych parametrów pliku firebird.conf wychodzimy z prostego rozważenia: na etapie transfuzji danych gbak uruchamia 2.5 w jednym procesie, a 3.0 w drugim, następnie 2.5 wychodzi, a 3.0 zaczyna się budować indeksy.

Aby przyspieszyć fazę budowania indeksu w wersji 3.0, zaleca się zwiększenie wielkości parametru TempCacheLimit do ~40% RAM (oczywiście jeśli jest to serwer dedykowany).

Na przykład, jeśli serwer ma 16 GB pamięci RAM, możesz umieścić

TempCacheLimit=6G

Oczywiście tę wartość można ustawić tylko dla 64-bitowego Firebirda 3, ponieważ żaden 32-bitowy proces nie może przydzielić więcej niż 2 gigabajty pamięci.

W wersji 2.5 tego parametru nie trzeba zmieniać - i tak nie może być większy niż 2 gigabajty i nie wpływa na szybkość podczas tworzenia kopii zapasowej.

Przed wykonaniem operacji należy sprawdzić, czy pamięć podręczna strony w nagłówku bazy danych jest ustawiona na 0 (command gstat -h databasename, patrz wiersz Bufory strony).

Jeśli cache jest ustawiony jawnie w nagłówku bazy danych, to nadpisuje wartości z firebird.conf (oraz databases.conf w wersji 3.0), a w przypadku nieadekwatnie dużych wartości może prowadzić do nadmiernego zużycia pamięci i wymiany.

Następnie skopiuj pliki do systemu docelowego.

Konwersja przeprowadzana jest po zatrzymaniu „systemowej” usługi Firebird 2.5, w wierszu poleceń z podwyższonymi uprawnieniami do lokalnego administratora (przykład):

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

W tym przykładzie użyto „ukośnika” w cudzysłowach (prawidłowy „w stylu uniksowym”), a „czapki” (znak „^”) oznaczają znak nowej linii, co jest przydatne podczas wpisywania długich poleceń. Opcja -st(atus) pojawiła się w Firebird 2.5.8 i umożliwia logowanie danych o czasie działania procesu gbak (szczegóły w dokumentacji).

Linux

W systemie Linux Firebird 3 zależy od biblioteki Tommath. Na CentOS (RHEL) ta biblioteka znajduje się w repozytorium epel, na Ubuntu (Debian) w repozytorium systemowym.

W przypadku CentOS musisz najpierw podłączyć repozytorium epel, a dopiero potem to zrobić

yum install libtommath

Ubuntu nie musi zawierać dodatkowych repozytoriów, ale Ubuntu 16 i Ubuntu 18 instalują różne wersje pakietów - odpowiednio libtommath0 i libtommath1.

Firebird 3.0 szuka tommath.so.0, a dla Ubuntu 18 dodatkowo wymagane jest utworzenie dowiązania (symlink) z tommath.so.0 do tommath.so.1. Aby to zrobić, musisz najpierw znaleźć tommath.so.1.

Wyszukiwana ścieżka w Ubuntu - /usr/lib/x86_64-linux-gnu/, ale inne dystrybucje oparte na Debianie mogą być inne.

Drugi problem związany jest z faktem, że do wersji Firebird 3.0.1 włącznie nie było łatwego sposobu na zainstalowanie dwóch różnych wersji serwera. Nie rozważamy opcji „kompiluj ze źródła z wymaganym prefiksem” ze względu na jej względną złożoność.

Zaimplementowano Firebird 3.0.2 i nowsze skompiluj z --enable-binreloc oraz oddzielną opcję instalatora (ścieżka -ścieżka).

Zakładając, że do systemu dodano bibliotekę tommath i, jeśli to konieczne, dowiązanie symboliczne do tommath.so.0, możesz zainstalować aktualną (w chwili pisania tego tekstu) dystrybucję Firebird 3.0.4 w np. /opt /fb3:

./install.sh -path /opt/fb3

Następnie możesz zatrzymać usługę systemową Firebird i rozpocząć konwersję strumieniową.

Podczas zatrzymywania Firebirda należy pamiętać, że procesy Firebid 2.5 w trybie Klasycznym są zwykle uruchamiane przez xinetd - więc należy albo wyłączyć usługę Firebird dla xinetd, albo całkowicie zatrzymać xinetd.

W firebird.conf dla wersji 3.0 w systemie Linux nie trzeba ustawiać parametrów MaxUnflushed (działają one tylko w systemie Windows) i zmieniać ustawienia Firebirda 2.5.

W Linuksie lokalny (plikowy) dostęp Firebirda 2.5 nie jest równoważny z wersją embed pod Windows - serwer 2.5 będzie działał w procesie gbak (bez części sieciowej), ale uprawnienia dostępu będą sprawdzane względem bazy użytkowników, co oznacza że wymagany będzie nie tylko login, ale także hasło:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

Po udanej konwersji należy najpierw odinstalować „dodatkowego” Firebirda 3.0, potem „głównego” Firebirda 2.5, a następnie przeprowadzić czystą instalację Firebirda 2.5 - i najlepiej ze zwykłego instalatora tar.gz, a nie przez repozytoria, ponieważ. wersja w repozytoriach może pozostawać w tyle.

Ponadto po przywróceniu bazy danych w systemie Linux i ponownej instalacji należy sprawdzić, czy nowa baza danych jest własnością użytkownika Firebird.

Jeśli tak nie jest, trzeba będzie to poprawić.

chown firebird.firebird database

Łączny

Oprócz oszczędności czasu i miejsca na dysku, konwersja strumieniowa ma jeszcze jedną ważną zaletę - konwersja bazy danych odbywa się bez usuwania istniejącego Firebirda 2.5, co znacznie ułatwia wycofanie w przypadku nieudanej konwersji (najczęściej z powodu braku miejsca lub nieoczekiwanego restartu podczas migracji) proces).

Oszczędność czasu wynika z faktu, że „klasyczna” konwersja to „czas podtrzymania” plus „czas przywracania”. Odzyskiwanie składa się z dwóch części: odczytania danych z pliku kopii zapasowej oraz zbudowania indeksu.

W przypadku konwersji strumieniowej całkowity czas uzyskuje się jako „czas tworzenia kopii zapasowej plus pięć do dziesięciu procent” i „czas budowania indeksu”.

Konkretne wyniki zależą od struktury bazy danych, ale średnio czas odzyskiwania jest około dwukrotnie dłuższy niż czas tworzenia kopii zapasowej. Dlatego jeśli przyjmiemy czas tworzenia kopii zapasowych jako jednostkę, to „klasyczna konwersja” to trzy jednostki czasu, przesyłanie strumieniowe to dwie jednostki czasu. Zwiększenie TempCacheLimit pomaga jeszcze bardziej skrócić czas.

Ogólnie rzecz biorąc, konwersja strumieniowa w praktyce pozwala zaoszczędzić 30-40% czasu alternatywnego tworzenia kopii zapasowych i przywracania.

Pytania?

Wszystkie pytania prosimy pisać w komentarzach lub przesyłać je do autora metodologii i współautora tego artykułu - Wasilija Sidorowa, iBase Leading System Engineer, w bs at ibase ru.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Jakiej wersji Firebirda używasz?

• Firebird 3.x

• Ognisty ptak 2.5

• Ognisty ptak 2.1

• Firebird 2.0, 1.5 lub 1.0

Głosowało 16 użytkowników. 1 użytkownik wstrzymał się od głosu.

Źródło: www.habr.com